6 Releases 10 to 14: the browser, telepresence and the middle years

6.1 Why the work kept coming after the system was written

Releases 10 to 14 are the middle of this subject, and reading them one after another shows what happens to an area of work once its founding documents are written: people keep turning up at the door with a client, a room or a network that those documents were never told to expect.

Two of them are worth the whole chapter. One was a browser. The IETF and the W3C were specifying a browser-based client for communication services, and 3GPP had to decide what happened when that client rang an IMS network ^[4].

The other was a room. A telepresence conference is one that gives the people in remote rooms a strong sense of being in one room together ^[5], and IMS already had ordinary conferences, so the question was what to add rather than what to build.

The rest of the stretch is smaller and follows the same shape: something outside IMS needed a way in, or something inside it needed saying more exactly.

6.2 What the work plan holds for these five releases

A work plan row is one group's share of one work item. An acronym with four groups on it has four rows, so a row count is bookkeeping and not effort.

Release	Work plan rows	Documents filed against it
Rel-10	17 [6]	92 [7]
Rel-11	25 [8]	164 [9]
Rel-12	60 [10]	433 [11]
Rel-13	15 [12]	830 [13]
Rel-14	17 [14]	354 [15]

6.3 The browser arrives

IMS_WebRTC is a Rel-12 acronym over eight work plan rows, and those rows sit in four places: the requirements group, the architecture group, the security group and a CT protocol row tied to IETF work IMS_WebRTC.

That spread is the tell. A new kind of client is never one group's problem.

Its objective, in the words the plenary approved:

Read the qualification rather than the promise. Reusing … as appropriate is not a decision that a browser gets an IMS identity; it is a decision to look at each credential and each public identity and ask whether reuse makes sense.

The work item names seven documents it would change, among them the stage 1 requirements, the stage 2 architecture and three security specifications IMS_WebRTC. 139 documents in this record carry the acronym ^[16].

Its row also carries a planned start of 2012-12-14, a planned finish of 2019-03-07 and a rapporteur at China Mobile IMS_WebRTC.

Those two days are the plan's own bookkeeping. They may be read as days somebody planned, never as the day work began or ended, and nothing here says what happened on either.

6.3.1 Where the browser work actually landed

The protocol side is a separate acronym. IMS_WebRTC-CT covers three rows and names CT1, CT4 and two IETF-facing rows, was opened by CP-140192, and has 101 documents IMS_WebRTC-CT ^[17].

Two further acronyms carry the group shares of it: the CT1 part with 15 documents IMS_WebRTC-CT1 and the CT4 part with 5 IMS_WebRTC-CT4.

What came out of it is TS 24.371, the stage 3 protocol for WebRTC access to the IM CN subsystem, owned by CT1 TS 24.371. 160 IMS documents in this record name it as the document they change, and every one of those 160 is a change request.

The register stores versions of it from Rel-12 at 12.12.0 through to Rel-19 at 19.0.0, and five work item acronyms have changed it — the three WebRTC ones and two phases of the protocol alignment work TS 24.371.

6.4 Telepresence: several rooms, one meeting

IMS_TELEP is Rel-12, twelve work plan rows, and six groups: CT1, CT3, CT4, a CT-to-IETF row, an IETF row and the requirements group. Orange is named as its rapporteur — the organisation holding the pen IMS_TELEP.

It set out to extend what was already there rather than start again:

116 documents carry the acronym ^[18], and the work item names nine documents it would change, TS 24.229 and TS 29.165 among them IMS_TELEP.

Two specifications carry the result. TS 24.103 is telepresence stage 3, owned by CT1, with 30 IMS documents against it TS 24.103. TS 26.223 is the media handling — what the pictures and the sound do — owned by SA4, with 38 TS 26.223.

The media half is its own acronym and its own release. IMS_TELEP_S4, "Media Handling Aspects of IMS-based Telepresence", is Rel-13, seven rows, all in SA4, with 71 documents IMS_TELEP_S4 ^[19].

Rel-14 then added IMS_TELEP_EXT for media handling extensions: twelve rows and 17 documents IMS_TELEP_EXT.

6.5 The rest of the stretch, in four pieces

Location information. Rel-11 carries NWK-PL2IMS, network-provided location information for IMS, over four rows and with no document in this record against that acronym at all NWK-PL2IMS. The protocol half, NWK-PL2IMS-CT, carries 36 documents and names fourteen documents it would change, from numbering and addressing through to the subscriber database interfaces NWK-PL2IMS-CT ^[20].

Registration control. Rel-12 has six acronyms for it — IMS_RegCon and five relatives for the CT, CT1, CT4, stage 1 and stage 2 shares. Every one of the six has a title beginning "Deleted - " and none has a single document in this record IMS_RegCon IMS_RegCon-CT IMS_RegCon-del1.

That prefix is typed into the title by hand. 22 IMS acronyms altogether carry it ^[21], and it is the only mark of its kind the work plan has: there is no status field anywhere in it that says whether work is running, stopped or finished.

Corporate access. IMS_Corp2, "Transfer of ETSI business trunking specifications", is Rel-12, three rows across CT1 and the requirements group, 10 documents, and it names four documents it would change IMS_Corp2. The name says what it is: work another standards body had already written, being moved.

Streaming delivery. IMS_SDE, IMS-based streaming and download delivery enhancements, is a single Rel-12 row in SA4 with no document in this record carrying it IMS_SDE. SDPCN_IMS, controlling the IMS media plane with SDP capability, is Rel-13, three rows across CT3 and CT4, 71 documents, and it names eleven documents it would change SDPCN_IMS.

6.6 The rows with nothing behind them

Open the work plan rows of Rel-10 and Rel-11 and a strange thing happens: a great many of them have no document in this record at all.

• AT_IMS, AT commands for IMS configuration: one Rel-10 row, no documents AT_IMS.
• EHNB-IMS, the IMS side of the home base station architecture: one Rel-10 row, no documents EHNB-IMS.
• IMS-UICC-S, UICC access to IMS — the card, in other words: three Rel-10 rows, no documents IMS-UICC-S.
• FS_IMS_P2P, the study on IMS-based peer-to-peer content distribution: one Rel-11 row, no documents FS_IMS_P2P.
• NWK-PL2IMS, the location work above, and IMS_SDE, the streaming work: four rows and one row, no documents between them NWK-PL2IMS IMS_SDE.

The reason is the store and not the work. The earliest IMS document in this record that carries a work item acronym went up on 2015-01-23, at meeting C4-68 ^[22]. Anything argued and finished before that day left its work plan row behind and none of its paper.

FS_eIMS, "Study on IMS Evolution", is the clearest case. One Rel-11 row in SA2, opened by SP-100360, naming one report it would write, and no document in this record FS_eIMS. What survives of it is the description itself:

That is the whole of what this school can say about it. The row is real, the description is real, and the meeting paper is not in this store.

6.6.1 The small rows are real work too

Three more Rel-10 and Rel-12 rows are worth naming because they are the shape of most work item entries, which is small.

IMS_SC_eIDT, service continuity with inter-device transfer enhancements — moving a call from one of your devices to another — is five Rel-10 rows with 6 documents IMS_SC_eIDT.

CC_IMS_USIM, communication control for IMS by the card, is one Rel-10 row with 2 CC_IMS_USIM. IMS_UApAs, IMS impacts on the card's application aspects, is one Rel-12 row with 5 IMS_UApAs.

6.7 The alignment work that never stops

The protocol IMS speaks is SIP, and SIP is the IETF's. So every release carries a numbered phase of one long job: read what the IETF has published since last time, and say whether IMS supports it.

The Rel-8 phase put its own aim in one line — protocol alignment between 3GPP stage 3 IMS work and the IETF ^[23] — and phases 4 to 8 all fall inside the five releases of this chapter:

Phase	Release	Rows	Documents
IMSProtoc4 IMSProtoc4	Rel-10	1	19 [24]
IMSProtoc5 IMSProtoc5	Rel-11	7	248 [25]
IMSProtoc6 IMSProtoc6	Rel-12	7	209 [26]
IMSProtoc7 IMSProtoc7	Rel-13	4	364 [27]
IMSProtoc8 IMSProtoc8	Rel-14, Rel-15	6	169 [28]

Phase 7 is the largest of the five at 364 documents, and it names three documents it would change IMSProtoc7: the call model TS 23.218, the signalling flows for setting a session up TR 24.930, and one number, 24.998, that this machine's catalogue holds no row for at all.

Phases 5 and 6 both appear on the list of 22 acronyms whose name begins "Deleted" ^[21], and both have hundreds of documents against them — 248 and 209 ^{[25] [26]}.

Whatever that prefix records, it is written per row and by hand, and the register carries nothing that explains it.

The safe reading is the narrow one: at least one row of each of those acronyms has a name beginning with that word. It is not a status field, no group ever voted on it, and nothing here says which row carries it or when it was typed in.

6.8 What the stretch left behind

Three documents in this subject have their earliest stored version inside these five releases, and all three are still carried forward — the register stores a Rel-19 version of each:

• TS 24.371, WebRTC access to IMS, stage 3, at 19.0.0 TS 24.371.
• TS 24.103, telepresence, stage 3, at 19.0.0 TS 24.103.
• TS 26.223, telepresence media handling, at 19.0.0 TS 26.223.

That is the real answer to what a release "did". Not the announcement, not the work item title: a document that exists, that somebody still publishes a version of, and that the maintenance work keeps touching.

6.9 Where this meets the rest of the course

The alignment work carries straight on past Rel-14, and the group that does most of it is CT1 — that is CT1, CT3, CT4 and CT6: where most of it happens. The media work that begins here with telepresence is SA4's, and it runs to split rendering and machine learning in SA1 to SA5, the two RAN groups, and the plenaries above them.

Rel-15 is where the ground moves under all of it, because the network underneath IMS is replaced: Releases 15 to 17: IMS moves onto the 5G core.