1 What IMS is, in the words of its own documents

1.1 Why one subject needs four documents

A network that carries a call as an internet session instead of as a circuit has to answer four different questions. 3GPP answers each of them in a separate document, and each document belongs to a different group.

What must the thing do for the person paying for it? That is TS 22.228, owned by SA1 TS 22.228. How is it put together? TS 23.228, owned by SA2 TS 23.228. What actually travels on the wire? TS 24.229, owned by CT1 TS 24.229.

And how is one session handled from the moment somebody starts it to the moment it ends? That is the call model, TS 23.218, also owned by CT1 TS 23.218.

Document	Stage	Owner	The question it answers
TS 22.228 TS 22.228	1	SA1	what it must do
TS 23.228 TS 23.228	2	SA2	how it is put together
TS 24.229 TS 24.229	3	CT1	what goes on the wire
TS 23.218 TS 23.218	2	CT1	how one session is handled

The split is not tidy-mindedness. Every specification in the catalogue carries exactly one owning group, and each group holds its own meetings and keeps its own document series SA2 CT1.

A system that needs four answers therefore needs four documents, and knowing which group owns the answer you want is how you find it at all.

1.2 What each of the four says about itself

Every 3GPP specification opens with a clause called Scope, in which it says what it covers. Those four opening clauses are the closest thing this subject has to a definition, so they are worth reading before anything else.

The architecture. TS 23.228 is the one people mean when they say "the IMS specification", and it puts itself inside a much older method for describing a telecommunication service in three stages ^[1].

The protocol. TS 24.229 is the largest thing in this subject by paperwork, and its scope is one sentence long ^[2].

Two names are expanded in that sentence and nowhere else in this course's sources: SIP, the Session Initiation Protocol, is the messaging that starts, changes and ends a session, and SDP, the Session Description Protocol, is how the two ends describe the media they are willing to exchange.

The requirements. TS 22.228 defines the service requirements from users' and operators' perspective for the support of IP multimedia applications through the IMS ^[6]. It is short, it is stage 1, and it is where the words below are defined.

The call model. TS 23.218 specifies the IP Multimedia Call Model for handling of an IP multimedia session origination and termination for an IP Multimedia subscriber ^[7].

And telephony itself. A call between two people is not IMS as such — it is one service built on IMS, and it has its own stage 1 document, TS 22.173 TS 22.173.

That document defines the IMS Multimedia Telephony service and the minimum set of capabilities required to secure multi-vendor and multi-operator inter-operability for it and its supplementary services ^[8].

1.3 The nine words these documents define

The register behind this course carries nine definitions, copied out of the definitions clause of a real specification. They are the whole of the vocabulary IMS defines for itself here, and four of them are a ladder.

IM CN subsystem is the documents' own name for IMS. TS 22.228 defines it as comprising all CN elements for the provision of IP multimedia applications over IP multimedia sessions ^[3].

Note what that definition does not do: it names no element. It says the subsystem is whatever elements are needed, which is why the architecture document exists.

Then the ladder, all four from TS 22.228:

• An IP multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers ^[9].

• An IP multimedia application handles one or more media types at the same time — speech, audio, video, data such as chat text or a shared whiteboard — in a way that is synchronised from the user's point of view ^[10].

• An IP multimedia service is the user experience provided by one or more of those applications ^[11].

• Access independence is the ability for subscribers to reach their IP multimedia services over any access network capable of providing IP connectivity ^[12].

The ladder is worth reading twice, because the four words are used loosely everywhere else and precisely in these documents.

A session is plumbing. An application handles media. A service is what somebody experiences. Access independence is the promise that the plumbing does not care how you got on the network.

Conference is the fifth word TS 22.228 defines, and its definition is two short sentences ^[4].

The remaining three come from TS 23.228. An IMS application is an application that uses an IMS communication service in order to provide a specific service to the end user.

The load-bearing half of that definition is the second sentence: an IMS application uses those communication services as they are specified, without extending their definition ^[13].

The last two are the newest piece of IMS in the register. An application data channel is a data channel within an IMS session, used to carry the data of data channel applications between devices or between a device and the network ^[14].

And a data channel application is, in the document's own words, a web page ^[5].

The register carries no expansion for CSCF, HSS, IBCF or the other element names that fill an IMS diagram, and none for the letters CN either. Where this course cannot say what a name stands for, it says so rather than guessing.

1.3.1 What a definitions clause does not do

Nine definitions is not many for a subject this size, and the gap is worth understanding rather than resenting.

A definitions clause fixes the words a document needs in order to be read without ambiguity. It is not a glossary of the field, and it never explains a mechanism: the definition of an IP multimedia session tells you what the phrase covers, not how a session is set up.

So the nine words above will let you read a sentence in TS 22.228 or TS 23.228 and know exactly what it is claiming. They will not tell you what happens when somebody presses the call button, and no chapter of this course will either — see the last section.

1.4 The vocabulary the rest of this course runs on

Six pairs of words do most of the work in every later chapter. None of them is special to IMS; all of them are how 3GPP describes its own paperwork.

Stage 1, stage 2, stage 3. The three-stage method TS 23.228 points at is ITU-T's, not 3GPP's ^[1]. In this course stage 1 is what the system must do, stage 2 is how it is put together and stage 3 is what goes on the wire.

The titles of the four documents above carry the stage they belong to, and different groups own each stage.

TS and TR. The register labels every document one or the other. A TS is a specification — text somebody else has to conform to, like TS 23.228 TS 23.228.

A TR is a technical report — the homework a group did before deciding, like TR 23.820, the study of IMS restoration procedures TR 23.820. A report binds nobody.

Work item and study item. A work item opens the writing of specification text; a study item opens a report. Each is defined by one description document that a plenary approves.

In this register a work item is known by its acronym — IMS, IMSProtoc2, eIMS5G_SBA. That acronym is what every count in this course is built on, and How this subject is cut out of the work plan is entirely about it.

Change request. Once a specification is published, the only way it is ever altered is by a change request: one proposed edit, aimed at one document, in one release, argued and agreed at a meeting. Most of the paper this subject has produced is change requests.

Plenary and working group. A working group writes the text — CT1, SA2, SA4. A plenary is the meeting of a whole technical body, such as SA or CT, that approves the work and signs off what the groups produced.

A document number beginning SP- comes from an SA plenary, CP- from a CT plenary, S2- from SA WG2, C1- from CT WG1.

Release. 3GPP cuts its work into releases, numbered Rel-5 upward, and every work plan row says which release it belongs to. A release is not a date in this data — see How this subject is cut out of the work plan — but it is the axis the middle of this course is organised on.

1.5 How the four documents have actually been used

The two central specifications carry their own history in the catalogue, and reading it tells you which of them the work really went into.

TS 23.228 exists in every release from Rel-5 to Rel-20 — the stored versions run from 5.15.0 to 20.0.0 — and 92 IMS documents in this register name it as the document they change TS 23.228.

TS 24.229 also runs from Rel-5 to Rel-20, and 1680 IMS documents name it as the document they change ^[15]. It is the largest target in this register by a wide margin.

That is the reason Releases 6 and 7: interworking, messaging, and a stream that never stopped and Releases 8 and 9: emergency calls, continuity and the fixed-network merge both spend time on the protocol alignment work: a stage 3 document has to be edited every time the protocol underneath it moves.

Two counts of the same kind, over the same store, asked of two documents. The architecture document and the protocol document plainly attract different amounts of paper, and every later chapter that talks about volume is talking about the second of them.

1.6 What this course will not tell you

The register behind these chapters was built from the 3GPP work plan, the meeting-document store, the specification catalogue and the parsed text of the specifications on this machine. It holds titles, scopes, definitions, objectives and counts.

It holds no procedure, no message, no parameter and no architecture. So no chapter here will say how a registration works, what a SIP header carries, or which element talks to which. Those answers are in the documents themselves and nowhere in this data.

That is a deliberate boundary rather than an oversight. A course that invented a mechanism to fill the gap would be worth less than one that names the document you have to go and open, which is what every chapter here ends by doing.

1.7 Where to read the real thing

Start with TS 23.228: it is the stage 2 description and everything else refers to it TS 23.228. Then TS 24.229 for what is actually on the wire TS 24.229.

For what IMS is supposed to do for anybody, TS 22.228 TS 22.228; for telephony itself, TS 22.173 TS 22.173; for how one session is handled end to end, TS 23.218 TS 23.218.

Next comes the boundary this whole course stands on: which rows of the 3GPP work plan count as IMS at all, in How this subject is cut out of the work plan.