7 The change requests — 689 of them, in packs

7.1 What a change request is

A change request is a patch to a specification that already exists. It names the document, the release, the clauses it touches and the text it replaces.

Working groups write them. A plenary approves them. That division is the reason change requests dominate a plenary's paperwork without a plenary ever writing one: 120 of the meeting's documents are change-request packs ^[1], more than a third of everything it handled.

7.2 Why they travel in packs

A single correction is rarely worth a document number of its own. Related changes are gathered into one pack, given one number, and approved or not as a unit.

At SA#112 that meant 120 packs and only 14 change requests standing on their own ^[2]. The report's own annex counts the packs independently and agrees at 120 ^[3].

7.3 How many, and to what

689 individual change requests reached this meeting ^[4], landing on 114 specifications ^[5].

Two figures worth holding together: 689 corrections landed on 114 documents, and the twelve specifications that took the most of them are listed further down. Most of the meeting's repair work lands on a small number of documents.

7.4 Two counts, both right

Count the change requests a second way and you get 673: the four release counts added up — 487 for Rel-20 ^[6], 143 for Rel-19 ^[7], 36 for Rel-18 ^[8] and 7 for Rel-17 ^[9].

The difference is the question, not the answer. The 689 counts every token in the specification column of every change request and every pack. The 673 counts what is recorded inside packs only.

7.5 Which releases took the changes

Release	Change requests in packs	Its agenda bin	Documents in that bin
Rel-20	487	item 20 [10]	63
Rel-19	143	item 19 [11]	40
Rel-18	36	item 18 [12]	17
Rel-17	7	item 17 [13]	7
Rel-15	—	item 15 [14]	1

Six more bins exist and stood empty at this meeting. They are Rel-10 and older ^[15], Rel-11 ^[16], Rel-12 ^[17], Rel-13 ^[18], Rel-14 ^[19] and Rel-16 ^[20].

Two releases take almost everything. That is the normal shape: one release being written, one being finished, and a thin tail of repairs to releases that are frozen — a state that still takes corrections, unlike closed.

About that tail, the plenary noted a principle under its project management item: "Care should be taken to agree or endorse CRs against frozen releases in the working group level, especially given the existing commercial deployments." ^[21] Networks are running on those releases, so a late change is a risk, and the caution is aimed at the working groups where such changes are agreed.

7.6 Which specifications took the changes

Specification	What it covers	Change requests
TS 23.482	AI/ML enablement service architecture	46
TS 23.502	procedures for the 5G system	38
TS 23.369	ambient power-enabled Internet of Things	33
TS 23.501	5G system architecture	29
TS 28.312	intent driven management services	29
TS 28.552	5G performance measurements	29
TS 23.503	policy and charging control	24
TS 23.288	network data analytics	23
TS 23.228	IP Multimedia Subsystem	22
TS 28.561	management of network digital twins	19
TS 23.433	SEAL data delivery for vertical applications	18
TS 28.541	5G network resource model	18

The column in the middle is shortened. Each entry in the register carries the published title in full, and following the link gives you both that and the address of the specification on 3gpp.org.

7.7 What the table lets you say

Four strands account for the top of it, and none of this needs interpreting beyond reading the titles.

• Management and measurement. Four of the specifications in the table are management and measurement documents: TS 28.312, TS 28.552, TS 28.561 and TS 28.541, each with its own figure in the table above. The first two belong to SA WG5, which sent 66 documents to this meeting, more than any other group ^[22].

• AI and machine learning as a service of the network. TS 23.482 at the very top with 46, and it belongs to SA WG6, which sent 41 ^[23].

• The 5G core proper. TS 23.501 belongs to SA WG2, which sent 33 ^[24], and TS 23.502, TS 23.503 and TS 23.288 sit beside it.

• New kinds of device. TS 23.369 with 33, for devices powered from ambient energy rather than from a battery.

7.8 One pack, in detail

SP-260379 is the largest change-request pack of the meeting: Rel-19 change requests on lawful interception, from SA WG3-LI, carrying twenty-three separate changes and approved as a whole.

That single row of the document list is twenty-three decisions. If you are tracking one specification, the pack number tells you nothing until you open it — which is the argument for reading the document list by specification rather than by document number.

7.9 What the plenary is actually approving

Nobody in the room reads 689 change requests in four days. What a plenary approves when it approves a pack is the working group's judgement that the pack is ready — and the evidence for that is the volume itself. Twenty-three corrections in one document, 120 packs at one meeting, and every one of them drafted, argued and agreed somewhere else first.

That is why the plenary's note about frozen releases is aimed downwards, at the working group level. The plenary is not the place where a change is examined; it is the place where responsibility for having examined it is accepted.

Two of the ten status words exist because that arrangement sometimes fails. "Partially approved" is a pack the plenary would not take whole, and four documents ended that way ^[25]. "Revised" is a pack or a document sent back and returned under a new number during the meeting itself, which happened sixty times ^[26].

7.10 Following one specification through a meeting

If you care about one document rather than one decision, read the meeting the other way round.

• Search the document list for the specification number, not for a title. Every change request and pack carries the specifications it touches, which is how the figure of 114 changed specifications was arrived at in the first place.

• Expect several packs. TS 23.501 took 29 changes at this meeting, and they did not arrive in one document.

• Check each pack's status separately. One may be approved, one revised and one partially approved, and the specification ends the meeting with whichever subset survived.

• Check the release. A change to TS 23.228 in Rel-19 and a change to the same document in Rel-20 are different edits to different versions.

7.11 A pack that split

SP-260387 came out "partially approved": some of the changes inside it went through and some did not.

The status word tells you the pack was split. It does not tell you where. Four documents of the meeting ended that way, and each of them is a document you have to open before you can say what changed.

7.12 Where this leads

Corrections and new work are the meeting talking to itself. The last of the four strands is the meeting talking to everybody else: The post — who wrote to 3GPP, and who 3GPP wrote back to.