5 What they write: the IMS family of specifications

5.1 Why one subject needs 241 documents

IMS — the part of a mobile network that sets a call up and carries it as an internet session — is not one document. The work touches 241 specifications ^[4], and knowing which of them answers which question is most of knowing where to read.

That number is not a shelf somebody curated. A document joins the 241 when a work item names it as one it will change, or when at least three IMS documents name it in the column that says which document a change targets ^[4].

The catalogue on this machine marks 3599 specifications active altogether ^[5]. That counts catalogue rows whose active flag is set, and the 241 counts what IMS work reaches: the two answer different questions, and neither is a share of the other.

Two labels are worth fixing before the lists start. A specification (TS) is a rule other people have to follow; a study report (TR) is the homework a group did before deciding. Both appear below, and nobody builds from a report.

5.2 The two documents that are IMS

TS 23.228 is the stage 2 description — how the system is put together. SA2 owns it, it exists in every release from Rel-5 to Rel-20, and 92 IMS documents name it as the one they change TS 23.228.

TS 24.229 is the stage 3 protocol — the bytes on the wire, 3GPP's rules for using SIP, the messages a phone and the network exchange to start, change and end a session.

CT1 owns it, it too runs from Rel-5 to Rel-20, and 1680 of the 4939 IMS documents in the local record name it ^{[6] [7]}.

5.3 The family around those two

Eight more documents make up the near family. The description in each row is what the catalogue says that document is for, in plainer words.

Document	What it is for	Owner	IMS documents
TS 23.218 TS 23.218	the call model: how one session is handled end to end	CT1	0
TS 23.167 TS 23.167	emergency sessions	SA2	10
TS 23.237 TS 23.237	service continuity, so a call survives a change of network	SA2	2
TS 23.292 TS 23.292	centralized services, so the service looks the same on any access	SA2	3
TS 23.334 TS 23.334	the interface between the IMS Application Level Gateway and the IMS Access Media Gateway	CT4	25
TS 23.380 TS 23.380	what to do when a part of IMS stops answering	CT4	22
TS 22.228 TS 22.228	the stage 1 requirements: what IMS must do	SA1	31
TS 22.173 TS 22.173	multimedia telephony and its supplementary services	SA1	0

The two zeros are worth reading carefully. No document in the local record names TS 23.218 or TS 22.173 in the change-request column, and work item descriptions name both as documents they would change.

5.4 The exact words, where a title is not enough

Three of those scopes say more in one sentence than a catalogue title does.

The other three are just as plain. TS 23.237 says it specifies the architectural requirements and procedures for delivery of IMS Service Continuity ^[8].

TS 23.292 says it specifies the architectural requirements for delivery of consistent services to the user whatever access type is attached ^[9].

TS 23.167 says it defines the stage 2 service description for emergency services in IMS, including what is needed for emergency services for eCall ^[10].

5.5 Interworking, the browser, and security assurance

Two documents describe talking to somebody else. TS 29.163 is interworking between IMS and circuit-switched networks, owned by CT3, named by 228 IMS documents TS 29.163. TS 29.165 is the interface between two IMS networks, also CT3, named by 190 TS 29.165.

One is about the browser. TS 24.371 is WebRTC access to IMS — reaching the subsystem from a web page rather than from a phone's own dialler — owned by CT1 and named by 160 documents TS 24.371.

Two are about security assurance, which is the checking of a product against a written list rather than the design of the protection itself.

TS 33.226 carries that list for IMS, with 48 IMS documents against it TS 33.226, and TR 33.926 holds the threats behind it, with 35 TR 33.926.

5.6 The studies

TR 23.794 is the Rel-16 study on fitting IMS to the 5G core, with 190 documents TR 23.794.

Its Rel-17 follow-up was split three ways, one report per group: TR 23.700-10 for CT1 with 101 documents TR 23.700-10, TR 23.700-11 for CT3 with 7 TR 23.700-11, and TR 23.700-12 for CT4 with 59 TR 23.700-12.

Two more studies are about IMS falling over. TR 29.866 is the Rel-19 study on disaster prevention and restoration, 106 documents TR 29.866, and TR 29.867 the Rel-20 study on resiliency, 73 TR 29.867. What is running under those two is Maintenance, and what is running now.

5.7 What this work does to the 5G core

The last pile is not IMS at all. These are 5G core documents that had to be edited to let IMS in.

Document	What it is for	Owner	IMS documents
TS 29.562 TS 29.562	the Home Subscriber Server services of the 5G system	CT4	230
TS 29.514 TS 29.514	the policy authorization service	CT3	100
TS 29.513 TS 29.513	policy and charging signalling flows	CT3	75
TS 23.501 TS 23.501	the architecture of the 5G system itself	SA2	33

5.8 What may be named and never quoted

72 of the 241 specifications this work touches have no parsed text on this machine ^[4]. TR 22.823, the study on new real-time services, is one TR 22.823; TR 23.794 is another TR 23.794.

Those documents may be named and their document counts may be given. Their words may not be used and none of their clauses may be cited, here or in any chapter of this school. Where they matter, the reading happens on 3gpp.org.

The way to find any of these by hand — and the traps in doing so — is Following it yourself, and what the record cannot tell you.