5 The Change Request, field by field

5.1 Why a form rather than an edit

Once a document is under change control, nobody edits it. Not the rapporteur, not the working group, not the person who found the mistake.

The reason is in the Introduction: industry is building from the text while the text is still moving, so every change has to be documented and controlled, and it has to be possible to trace backwards afterwards §Introduction. An edit leaves nothing behind. A Change Request leaves a number, a reason, a category, a decision and a meeting.

That is what a Change Request is: a formal proposal, presented on a standard form, to modify a specification which is under change control §2.

5.2 Who may raise one, and what it is attached to

The door is wide open.

There is no requirement to be the rapporteur, or to have written the clause, or to hold any office. What there is, is a rule about scope: a Change Request shall relate to a specific version of a specification §4.6.1. Not to a document in general — to one version of it.

5.3 The number

A unique reference number is allocated to the change request by the 3GPP portal or by the Support Team. Unique means unique for that specification, not across 3GPP §4.6.1, §4.6.4.

The number is then permanent, in a way that trips people up:

The note attached to that sentence is a small piece of institutional history. The status "rejected" became unacceptable in some groups and has been replaced by "not pursued"; in the document, any reference to "rejected" applies equally to "not pursued" §4.6.1. Across the recorded meeting documents, 97,521 ended with the status "approved" ^[1], and 16,137 with "not pursued" ^[2].

If a rejected proposal is worth bringing back in modified form, it comes back as a new change request with a new number — never as a revision of the old one §4.6.4.

Revisions are for the life of one proposal before its verdict. A change request may be modified as it develops, and its progress is shown by a revision number: rev 1, rev 2 and so on. A particular revision is identified by three things together §4.6.4:

• the specification it belongs to;

• the change request number, an alphanumeric string;

• the revision number, whose default is "-", meaning the original, unrevised proposal.

The change request database holds all revisions of each one §4.6.1, §7.3.

5.4 The form itself

There are standard front covers for change requests, along with rules for marking the modified parts of the text §4.6.2. The cover exists to carry the management information, and clause 4.6.2 lists what that is:

Field	What it says
Target specification and version	the original version the change was drafted against
Source	who is proposing it
Reason	why, and what happens if it is not accepted
Category	which of the letters below
Cross-phase compatibility	what it does across Releases
Release	the Release of the resulting specification

That last field is the one people fill in wrongly. It shows the Release of the specification after the change has gone in — not the Release of the feature the change relates to §4.6.2.

The portal will fill most of this in for you. On reserving a change request document number, the portal pushes back a completed cover page with the metadata already entered, and the document recommends using it rather than a blank template, precisely to stop transcription errors §4.6.2, ^[3].

5.5 The six category letters

Every change request carries a category, and if the category cannot be identified when it is presented for approval, the change request is automatically rejected §4.6.2. Table 4A gives them §4.6.2:

Letter	Meaning
A	corresponds to a change to an earlier Release
B	addition or deletion of a feature
C	functional modification of a feature
D	editorial modification
E	not used
F	correction

Each letter carries conditions:

• A is for a functionally equivalent change already made to an earlier Release. The wording need not be identical, because earlier changes may have left the text different in each Release; what has to match is the functional objective.

• B and C shall correspond to an identified Work Item, and neither may be used on a frozen Release except as an alignment change under §4.7. A functional modification must also keep backward compatibility where it affects the device.

• D must have no effect on an implementation, and an editorial change to a frozen Release is not permitted at all.

• F covers five named situations §4.6.2: correcting an error that leads to incorrect operation; correcting an ambiguity that could produce implementations which cannot work together; a slot marked void; repairing the incorrect implementation of a previously approved change request; and correcting a misalignment between the stage 1, stage 2 and stage 3 documents for one feature, where no new function is introduced.

5.6 What has to be attached

The cover page is management information. The actual change goes in as marked-up text.

Where two independent change requests touch the same part of a document, neither should contain the other's modifications — though any interaction between them should be resolved before either is presented §4.6.3. The responsible group also has to check that if all of them are approved, each remains implementable without contradicting the others §4.6.1.

Where the change touches stage 3 files stored normatively in the 3GPP Forge repository, the modifications are made there, the cover page carries a reference to the merge request, and extracts showing the changes are still appended to the form §4.6.3, §5C.

5.7 The route to a decision

The path is short and always the same §4.6.4:

• S1. The proposal goes first to the group primarily responsible for the specification, and is discussed there. Comments from secondarily responsible groups are sought and taken into account before anything goes to the plenary.

• S2. If it is not accepted immediately, the originator updates it — including changing the reference version if needed — and brings it back. Everything is submitted electronically.

• S3. Once the Working Group has agreed it, the Support Team checks the formatting and assembly and submits it to the primarily responsible TSG. The Working Group secretary collates the agreed ones and sends them up §4.6.1.

• S4. Agreed change requests are collated into CR packs, and the Support Team gives the plenary summary lists of everything presented for decision, updated with the decision reached on each.

• S5. The plenary considers and concludes on each change request independently, and the verdict on each is one of the status values in §9.2.

• S6. At the end of the meeting the Support Team issues detailed result lists, including the new version numbers that follow, and those lists become an annex to the meeting report.

The plenary is asked to take each proposal whole.

Which is why the document then advises that one change request should cover one technical topic only — so that each topic can be cleanly accepted or rejected §4.6.1.

The decisions are recorded by the TSG secretary in the meeting report and reflected in the change request database and on the portal §4.6.1.

5.8 What approval does to the document

If there is at least one approved change request against a specification, a new version number is allocated and the Support Team produces and issues the new version §4.6.5. The middle digit goes up and the last resets — 7.2.1 becomes 7.3.0 §4.1.1.

There is one route that does not involve a change request at all. The Support Team may correct purely editorial defects brought to its attention, moving only the third digit. The document discourages it: normally such fixes should be held over until the next technical change. Whatever happens, they are explained in the change history annex §4.6.6.

5.9 Before change control, and across Releases

Two variants complete the picture.

A pseudo change request, a pCR, does the same job for a document that is not yet under change control. It has no change request number and proposes new or revised text for a document still in the drafting phase; some groups call it a text proposal §2, §9.1. The record holds 159,031 pseudo change requests ^[4], against 516,786 change requests proper ^[5].

A mirror change request carries one decision across Releases. Where several Releases are affected, an independently numbered change request is created for each affected version, and they are grouped for presentation and approved together §4.10.2.

5.10 Where to look one up

Three places, all outside this course §4.6.2:

• the change request database on the 3GPP file server ^[6];

• the portal, for the change requests of one specification or one meeting, with their decisions ^[3];

• 3GPP's own step-by-step guidance on filling in the form ^[7].

5.11 Where this leads

Work Items and Study Items — how the work is authorised is what authorises a category B or C change to exist at all. How a 3GPP meeting decides, and the word it decides in is the vocabulary the verdict is written in, and Reading a 3GPP number — the series, the version, the file name reads the number that comes out the other end.