7 Releases 15 to 17: IMS moves onto the 5G core

7.1 Why the ground under IMS had to be rebuilt

A mobile network gives a phone a way to send IP packets. IMS sits on top of that and turns packets into a call. So when 3GPP built a new core network for 5G, the question was not whether IMS survived — it was what IMS had to be told about the new floor underneath it.

The Rel-15 work item put the reason plainly, and it is the sentence to keep:

IP-CAN is the connectivity a network gives a device to carry IP packets. Reading that sentence backwards: the 5G core is a new kind of pipe, IMS is still the thing at the end of the pipe, and somebody had to write down what changes on the IMS side.

That is what these three releases are. Rel-15 did the minimum that a first deployment needed. Rel-16 asked what a proper job would look like and then wrote half of it. Rel-17 picked up the half that had been left.

7.2 What the three releases hold

Release	Work plan rows	Documents filed against it
Rel-15	12 [7]	640 [8]
Rel-16	13 [9]	943 [10]
Rel-17	12 [11]	419 [12]

Rel-16 is the largest release in this record by document count, at 943. Twelve or thirteen rows apiece is a short list of entries carrying a great deal of writing, which is the opposite shape from Rel-12 in Releases 10 to 14: the browser, telepresence and the middle years, where 60 rows carry 433 documents.

7.3 Rel-15: the first crossing, kept deliberately narrow

5GS_Ph1-IMSo5G — "IMS impact due to 5GS IP-CAN" — is four work plan rows across CT1, CT3 and CT4, opened by CP-180094 and held by a rapporteur at China Mobile 5GS_Ph1-IMSo5G. 476 documents in this record carry the acronym ^[13].

Its objective draws a boundary in its second sentence, and the boundary is the interesting part:

So this is the IMS side of the crossing and not the 5G core's own side. Whoever wanted the other half had to go and read the 5G core's own work items.

The item names ten documents it would change 5GS_Ph1-IMSo5G, and their plainness is the point: numbering and addressing TS 23.003, the organisation of subscriber data TS 23.008, the device's management object TS 24.167 and the SIP profile itself TS 24.229.

The other six are the plumbing underneath: two policy and charging documents TS 29.213 TS 29.214 and four for the Cx, Dx and Sh interfaces into the subscriber database TS 29.228 TS 29.229 TS 29.328 TS 29.329.

7.4 Rel-16, part one: asking what a proper job would look like

FS_eIMS5G, "Study on Enhanced IMS to 5GC Integration", is one work plan row in SA2, opened by SP-180736, with 228 documents against it FS_eIMS5G ^[14].

Its justification says why a study was needed at all, and it says it directly:

Read it as an admission with a plan attached. The first 5G core work was kept small on purpose so that 5G could ship, and the bill for that decision came due in the next release.

The study's own objective sets a second boundary. It says the existing IMS architecture is the baseline, that no change to the functional split is expected, and that SIP signalling between the phone and IMS stays as it is with only necessary extensions ^[15].

Its report is TR 23.794, owned by SA2, with 190 IMS documents against it TR 23.794. This machine holds no parsed text of that report, so this course can name it and count what was written about it and cannot quote a line of it.

7.5 Rel-16, part two: writing down the part that was settled

eIMS5G_SBA, "SBA aspects of enhanced IMS to 5GC integration", is the work item that turned the settled part of the study into rules. Six work plan rows across SA2, CT1, CT3 and CT4, opened by SP-190181 eIMS5G_SBA.

SBA — the service-based architecture — is the 5G core's way of having its functions offer named services to each other rather than talk over fixed point-to-point interfaces.

Its objective names the conclusions it implements and the first new service:

The justification explains why half a study became a whole work item: the service-based conclusions had been reached, other aspects had not, and the service-based part could be implemented without waiting for them ^[16].

543 documents carry this acronym, more than any other acronym in this register ^[17]. It names nine documents it would change, and its own table spells out what four of them are for eIMS5G_SBA.

TS 23.228 is to describe the new services between the IMS functions and the IMS service logic held in the combined subscriber database. TS 23.501 is to include IMS as a consumer of the 5G core's services and to update the architecture drawings to match.

7.5.1 The nine documents it went into

The work item's own table names each document and says what it would do to it. Read down it and the shape of the change appears: two IMS documents, three 5G core architecture documents, four stage 3 interface documents.

Document	Whose	IMS documents against it
TS 23.228 IMS stage 2	SA2	92
TS 23.380 IMS restoration procedures	CT4	22
TS 23.501 5G system architecture	SA2	33
TS 23.502 5G system procedures	SA2	22
TS 23.503 5G policy and charging framework	SA2	11
TS 29.510 the register of network functions	CT4	16
TS 29.513 policy control signalling flows	CT3	75
TS 29.514 the policy authorization service	CT3	100
TS 29.571 common data types for the 5G interfaces	CT4	10

Two of the instructions in that table are worth reading whole. Against TS 23.502 it says to include details of IMS behaving as a service consumer of the 5G core, and against TS 23.503 to describe IMS using the N5 interface and to replace the older Rx interface to the policy function with it eIMS5G_SBA.

That second one is the actual technical decision of the release, written as a line in a table: the way IMS asks the network for the quality a call needs was moved from one interface to another.

7.6 Rel-17: the four key issues that were left

FS_eIMS5G2 is the second phase, four rows across CT1, CT3 and CT4, opened by CP-201358, with 184 documents FS_eIMS5G2 ^[18].

Its justification says plainly what a study can leave behind:

The odd "(FS_eIMS5G, )" is how the description itself reads. Nothing in this register says what was meant to follow that comma, so nothing is filled in here.

Its objective repeats the first study's boundary almost word for word — the existing architecture is the baseline, and SIP between the phone and IMS stays as it is ^[19].

What is new is the shape of the report. Where phase one wrote one study report, phase two wrote three, split by which protocol group owned the question:

Report	Group	IMS documents against it
TR 23.700-10 TR 23.700-10	CT1	101
TR 23.700-11 TR 23.700-11	CT3	7
TR 23.700-12 TR 23.700-12	CT4	59

Three reports for one study, and one of them has seven documents against it while another has a hundred and one. The register records no reason for that, and none may be invented here.

7.6.1 What a study report is, and how to tell one from the outside

A TR is a study report: homework a group did before deciding. A TS is a specification: rules other people have to follow. The register lets you see the difference without opening either.

TR 23.794 has 190 IMS documents against it and not one of them is a change request TR 23.794. That is what a report looks like while it is being written — text is proposed into it rather than changed in it, because there is nothing published yet to change.

Its two stored versions are Rel-16 at 1.1.0 and Rel-17 at 17.0.0 TR 23.794. What the register holds beside each of those is the day the version file went up on the 3GPP server, which is not the day it was published, so the pair of numbers is all anybody here can say about it.

The Rel-17 reports show the other end of it. TR 23.700-10 carries 101 IMS documents and four change requests, and TR 23.700-12 carries 59 and six TR 23.700-10 TR 23.700-12 — so a report can be changed by change request once it exists, and both of those were.

7.7 What was running beside it

The requirements. FS_enIMS asked what IMS would need for new real-time services, one row in SA1 with 45 documents, and it named large one-to-many communication — a live video feed to everybody in a stadium — as the kind of thing it meant FS_enIMS ^[20]. Its report is TR 22.823, which this machine also holds no parsed text of TR 22.823.

enIMS then wrote the stage 1 requirements themselves, one row in SA1 with 36 documents, taking TR 22.823 as its basis and naming seven documents it would change enIMS ^[21]. Those seven reach well past IMS into the mission-critical and group-communication requirement documents.

The register quotes what enIMS set out to do and holds no justification section for it, so this course says nothing about why it was proposed ^[21].

The pair is a clean example of how a requirement becomes a rule. The study asks and writes a report; the work item reads that report and changes the requirement documents.

TR 22.823 carries 45 IMS documents and four change requests TR 22.823 — the documents are the writing of it, and the change requests are what came afterwards.

Both rows name the same rapporteur at China Mobile FS_enIMS enIMS — the same person held the pen on the question and on the answer.

The security assurance. SCAS_IMS is Rel-17, one row in SA3, opened by SP-191128, with 83 documents SCAS_IMS ^[22]. A security assurance specification is a list of things a product of a given class must be tested against.

Its reason is a gap: the same work had been done for LTE network elements and not for the IMS ones ^[23].

What came out is TS 33.226, security assurance for IMS, with 48 IMS documents against it TS 33.226, and additions to TR 33.926, which holds threats and critical assets for network product classes generally, with 35 TR 33.926.

The two documents' stored versions show which was new and which was joined. TS 33.226 starts at Rel-17 and runs to Rel-20 TS 33.226; TR 33.926 starts at Rel-13 and runs to Rel-20 TR 33.926.

IMS did not get a threat document of its own. It was added to the one the other product classes already used.

7.8 How long each of these ran, as far as the record can say

A count entry in this register carries the meeting of its earliest document and the meeting of its latest, and for these four acronyms that pair is the closest thing to a start and an end that exists here.

Acronym	Earliest document at	Latest document at
FS_eIMS5G, 228 documents [14]	S2-125	S2-168
5GS_Ph1-IMSo5G, 476 documents [13]	C1-105	C3-131
eIMS5G_SBA, 543 documents [17]	S2-132	CP-112
FS_eIMS5G2, 184 documents [18]	C4-99-e	C1-135-e

Two things fall out of that table. The Rel-16 study never left SA2 — first and last document both at an SA2 meeting. The work item that followed it did the opposite: it started at an SA2 meeting and its most recent document sits at the CT plenary CP-112, which met at Singapore in June 2026 CP-112.

That is not a claim that the work is running. It is a claim about paper: a document filed in 2026 carries an acronym opened for Rel-16, which is what maintenance of a delivered feature looks like, and the register holds no status field that would settle it either way.

7.9 What all this did to the 5G core's own documents

Two numbers are worth putting side by side, and they are both counts of IMS documents naming a document as the one they change.

TS 23.501, the 5G system architecture, carries 33 TS 23.501. That is small, and it should be: the architecture had to admit IMS exists as a consumer of 5G core services, and little more.

TS 29.562, the HSS services of the 5G system — the stage 3 rules for the subscriber database's own service interface — carries 230 TS 29.562. It is the second-largest target in this register after TS 24.229, and it is owned by CT4, not by anybody in IMS.

That pair is the whole story of these three releases in miniature. The architecture moved a little. The interface between IMS and the subscriber database was rewritten as a service, and that is where the paper went.

7.10 Where this meets the rest of the course

The three groups that carried it are CT1, CT3 and CT4, and what each of them owns is CT1, CT3, CT4 and CT6: where most of it happens. The architecture group that ran the first study and the security group that ran the assurance work are in SA1 to SA5, the two RAN groups, and the plenaries above them.

For who filed all this paper and at which meetings, the map is The map: fourteen groups, 309 meetings and 374 names.