3 What a Release is, and what freezing one costs

3.1 Why anything is grouped at all

An operator buying equipment needs to name what it is buying. A vendor tendering needs to name what it is selling. Neither can name "the current state of about four thousand documents".

So 3GPP cuts the moving text into named blocks. Specifications are grouped into Releases, and a mobile system can be built from the set of all specifications that make up one Release §4.0B. That is the whole idea: a Release is a set you can build from without asking further questions.

A Release differs from the one before it by having functionality added as a result of the standardisation work in between §4.0B.

3.2 Which digit says the Release

There is no separate Release field. The first digit of the version number is the Release §4.0B, and table 4 of the same clause is the mapping from that digit to the Release name, back through the GSM phases.

The consequence is the odd jump that catches every newcomer. A document approved for Release 4 goes from version 2.0.0 straight to 4.0.0, and no 3.y.z of it ever exists, because there was no Release 1999 version of that document §4.1.1. Reading a 3GPP number — the series, the version, the file name takes the three digits apart properly.

The catalogue on this machine names 19 releases, from R99 and Rel-4 up to Rel-21 ^[1]. Across them it holds 20,793 pairings of one specification with one release ^[2] — which is what "one specification exists in several Releases at once" looks like when you count it.

3.3 The four principles a Release has to satisfy

Clause 4.10.3 states them flatly, and every later rule about freezing, mirrors and corrections falls out of these four §4.10.3.

The other two are about direction of travel. Essential corrections to a stable or frozen Release shall be included in the applicable Release, and new or changed functionality shall go into a new Release rather than retrospectively into an old one §4.10.3.

Those two pull opposite ways on purpose:

• Corrections travel backwards. If an essential change to old functionality is made in a new Release, the same error shall be corrected in every previous Release that is not closed §4.10.3.1.

• Features travel forwards only. New functionality goes into the latest Release that is not frozen. Putting it into a frozen Release would cause incompatibility among systems built to that Release §4.10.3.2.

The mechanism that makes the backwards direction work is the mirror Change Request: where several Releases are affected, an independently numbered Change Request is written for each affected version, and the whole family is put to the plenary together §4.10.2. The Change Request, field by field follows one through.

3.4 Creating a new Release version of a document

A Release is only complete if every document in it exists at that Release. So a specification with nothing to change still needs a new version — and clause 4.10.1.1 says that version shall be created as late as possible, when the TSG is about to declare the Release complete and has satisfied itself that no technical change is needed §4.10.1.1.

Where a technical change is needed, the new Release version arrives the ordinary way, through a Change Request whose resulting version number carries the new Release §4.10.1.2.

A document that is carried forward by neither route is simply not part of the new Release, and the responsible group then has to go through the rest of that Release removing references to it §4.10.1.3.

3.5 Frozen, closed, withdrawn

Three words, three different amounts of finality. Clause 2 defines the first two, and the procedure clauses spell out what each costs §2.

Frozen. A TSG may decide a specification is stable enough to be frozen.

Normally the whole Release is frozen at once, when the TSGs decide its functionality is stable — that every feature is defined and every change needed to implement those features is in the text §4.7.

What survives a freeze is a short list §4.7:

• an essential correction, where a frequently occurring case is mishandled because of an error or a significant ambiguity — the document's own nickname for this is a FASMO, "Frequent And Serious MisOperation";

• a correction that repairs the incorrect implementation of a previously approved Change Request;

• a category B or C change used only to align the specification with functionality already agreed elsewhere in the same Release, or to make one document internally consistent.

There is also a deliberate escape hatch: a TSG may approve a category B or C change to a frozen specification if it is the consensus of the meeting that such an exceptional action is justified §4.6.2.

Closed. A step further. No further Change Requests at all, not even corrective ones to align with a later Release. The document stays available for reference, but nothing more happens to it §4.8. A Release can only be closed if the previous Releases are closed already.

Withdrawn. The document leaves the set. Before that can happen the TSG has to satisfy itself that no other 3GPP specification still refers to it, raising change requests to remove any reference it finds §4.9. Functionality can be withdrawn the same way, without the whole document going §4.9A.

Withdrawal has its own procedure and it is deliberately slow §4.9B.2. The decision may only be taken after thorough consideration; it has to be an explicit objective of a work item, not a side effect of one; a general-purpose "technical enhancements" work item may not be used for it; and a notice goes on the 3GPP site inviting comment from outside parties, naming the affected documents and the date the decision will be taken.

3.6 Freeze dates, and the date this course will not give you

Freezing is driven by the 3GPP work plan. Target completion dates for work items are estimated by the responsible groups, and from those a target freeze date for the next Release is calculated §4.10.3.4. The work plan then has to show the estimated freeze date of forthcoming Releases and what is in each of them.

The document also asks the TSGs to look one Release ahead: on freezing stage 2 of Release x, they should propose target freeze dates for stages 1, 2 and 3 of Release x+1 §4.10.3.4. Releases are not annual and are named after the major version field — Release 4, Release 5 and so on §4.10.3.3.

If a feature will not make the date, clause 6.4.5 gives exactly two ways out §6.4.5:

• W1. The TSG judges the late part not vital, and it is abandoned or moved to a later Release — which may mean raising change requests to remove half-built pieces so no unworking stub is left behind.

• W2. The overrun looks like a few months, generally no more than two plenary cycles, and the responsible Working Group raises an exception sheet asking for a delay until the next or next-but-one meeting.

3.7 Early implementation, and where a Release is described in plain words

3GPP can mark a feature as suitable for "early implementation" — being built on a platform of an earlier Release than the one that contains it. The choice is made at TSG level §4.10.3.5, and the deliverables then include an early implementation Technical Report giving guidance to implementers. That report defines no new requirements; it says which parts of the specifications matter and how to handle them §6.4.4.

Two other kinds of document exist to make a Release legible from outside. A Release description summarises what the Release's work items delivered TR 21.919 v19.0.0. A list document per kind of system says which specifications you actually need to build it TS 21.101 v19.0.0, TS 21.201 v19.0.0, TS 21.202 v19.1.0, TS 21.205 v19.0.0.

3.8 Where this leads

Reading a 3GPP number — the series, the version, the file name reads the three digits properly, including what happens to them on approval. The Change Request, field by field is the form that moves a document inside a Release, and Work Items and Study Items — how the work is authorised is how the work was authorised in the first place.