5 Release planning — the timeline, the checkpoint and the names

5.1 Why the calendar needs a plenary

A release is a numbered snapshot of the specifications. While it is open, new features go in; once it is frozen, it is meant to be repaired and not extended, because equipment has already been built to it. 3GPP keeps the word "closed" for the later state, where no change of any kind is allowed.

That only works if everybody agrees when each release opens and closes. The date is not a technical question and no working group can answer it, which is why release planning is a plenary's business — and why the biggest date at SA#112 was not even TSG SA's alone.

5.2 The item that looks empty

Release planning has its own top-level agenda item, and at this meeting it drew three documents ^[2].

Three. Read that on its own and you would conclude the meeting did no planning at all, which would be wrong. The Release 21 timeline came through the early-consideration item, which took twenty-five documents ^[3], and was settled in a joint session with the radio plenary, TSG RAN.

This is the first thing to learn about reading a plenary: the agenda item where a subject lives is not always the agenda item where it is decided.

5.3 Release 21: a timeline, and not much else yet

The document is SP-260595, from the TSG chairs, and the draft report records what happened to it in one line: "SP-260595 was presented in the Joint session and was agreed." ^[4]

Its status word is "agreed" — the only document of the whole meeting to carry that word, because it was agreed somewhere other than this room.

Beyond the calendar, Release 21 barely exists in this meeting's paperwork: 11 documents carry it against 140 for Release 20, as the table below sets out. That is what an early release looks like — a date, a few study items, and no body of text yet.

5.4 Why a joint session exists at all

A release is not a service-side thing or a radio-side thing. It is one date that both halves of the industry build to, so a timeline agreed by TSG SA alone would be worth nothing the moment the radio plenary picked a different one.

The joint session is how that is avoided: the two plenaries sit together and the document comes out with a status word neither of them owns. At SA#112 that happened exactly once, and it is the whole reason "agreed" is the status of exactly one document of the meeting ^[5].

The same logic runs through the rest of this chapter. A timeline needs both sides. A checkpoint on where the radio ends and the core begins needs both sides. A name for the 6G core network needs both sides, which is why the decision left the room as a letter SP-260697.

5.5 The checkpoint the plenary set itself

Alongside the timeline the report records a conclusion: "checkpoint in Dec.26 for RAN-CN other than connectivity services." ^[6]

That is a date in the calendar for revisiting the boundary between the radio side and the core side, for everything except connectivity services. It is a plenary doing the thing only a plenary can do: booking a future argument between two groups so that it happens once, at a known time.

5.6 What the releases weighed at this meeting

Release	Documents	Change requests in packs
Rel-21	11 [7]	—
Rel-20	140 [8]	487 [9]
Rel-19	26 [10]	143 [11]
Rel-18	5 [12]	36 [13]
Rel-17	2 [14]	7 [15]
none	162 [16]	—

Read down that table and you see four releases in four different states at once: one being planned, one being written, one being finished, and two being repaired.

5.7 Finishing Release 19

Release 19 shows up as 26 documents and 143 change requests inside packs — a body of work being tidied rather than extended.

The document that marks the stage is SP-260604, TR 21.919, the technical report that summarises every Release 19 feature. It was approved at this meeting.

A release summary is the paper you write when a release is done enough to describe as a whole. Its approval is the closest thing in this record to a release being declared finished.

5.8 Repairing releases that are frozen

Older releases are still being changed: 36 change requests to Rel-18 and 7 to Rel-17, with the top-level bins for those releases holding 17 documents ^[17] and 7 ^[18]. One document reached back further still, to the Rel-15 bin ^[19].

The plenary noted a principle about exactly this, under its own project management item, which took thirteen documents ^[20]: "Care should be taken to agree or endorse CRs against frozen releases in the working group level, especially given the existing commercial deployments." ^[21]

In plain words: by the time a release is frozen, networks are running on it, so changing it is a risk and the decision belongs low down in the working group rather than as a late surprise at a plenary. It is a note of caution, not a ban — changes still went into both Rel-18 and Rel-17 at this meeting.

5.9 What a frozen release costs to change

The caution in that sentence is not bureaucratic. It names the reason directly: existing commercial deployments.

A release stops being a document the moment somebody ships equipment built to it. After that, a correction has to be worth more than the risk of every implementation quietly diverging, and the people best placed to judge that are the ones who wrote the text — which is why the plenary aims the caution at the working group level rather than at itself.

Notice what the sentence does not say. It does not forbid the changes, it does not set a threshold, and it does not name a release as closed. It is a noted principle, and 68 documents at this meeting ended noted ^[22], which is the category the plenary uses for things it wants on the record without deciding.

5.10 Naming the next generation

Planning a release is partly planning its vocabulary, and this meeting spent real time on words.

It settled the name of the 6G core network in one line: "It was decided to use '6GC' or '6G CN'." ^[23]

It handed the harder naming job to a working group with a date on it: "SA WG2 were asked to develop 6G interface names and naming convention, especially for RAN -CN interfaces and report to TSGs in September 2026." ^[24] And then, in the very next sentence of the record, it wrote down that the decision was not unanimous: "Qualcomm objected to this decision." ^[1]

The outcome went outwards as a letter SP-260697, so that the other two TSGs' working groups use the same words. SA WG2's own account of where the 6G architecture study stands came in the other direction and was noted SP-260372.

5.11 The work plan

The other standing piece of calendar business is the work plan review SP-260606, handled with the rest of the housekeeping under item 21. It ended revised, which means the version that stands is a different document number.

5.12 Where this leads

The calendar says when. The next chapter is what: the work items and study items this meeting let start, and the two arguments it could not settle quietly — The new work — what the plenary let start.