3GPP 21.900 v20.0.0 — the document's own text
4.6.2 Change Request forms
Taught in 5. The Change Request, field by field (How standards actually get made, in depth), 4. The change request and the release (How standards actually get made, overview), 6. Two ways of deciding (How standards actually get made, overview), 3. One idea, from proposal to published text (How standards actually get made, quick start).
To ensure an appropriate and consistent way of presenting and documenting Change Requests, there exist standardized front covers (forms) for CRs as well as rules on how to accurately identify the modified parts of the specification.
The purpose of the CR form itself is to provide the relevant management information of the proposed changes, e.g. such as:
- Target specification with its version number (i.e. the original version to which CR is drafted),
- Source of the CR,
- Reason for the proposed change and consequences if not accepted,
- Category of proposed change (i.e. correction, Change Request corresponding to an earlier release Change Request, addition of feature, functional modification of feature, or editorial modification),
- Cross-phase compatibility aspects.
A CR to a major version of a specification can fall into any of the categories quoted below.
Table 4A: Categories of Change Requests
| Category | Meaning | Remarks |
|---|---|---|
| A | Corresponds to a change to an earlier Release | Used to reflect functionally equivalent changes made to an earlier Release of the same Specification.NOTE: The proposed change to the later Release of the Specification need not be absolutely identical to the proposed change to the earlier Release, since it is possible that, due to earlier change requests, the affected text is not identical in each Release. Category A should be used when the functional objective of the proposed changes is equivalent in the earlier and later Releases. |
| B | Addition or deletion of feature | The new feature is to be added to the Release; the reference is not to the Specification itself. This will normally correspond to an identified Work Item. This category shall not be used for a frozen Release, except for alignment CRs as described in clause 4.7. |
| C | Functional modification of feature | Any functional modification shall correspond to an identified Work Item. However backward compatibility shall be ensured when the issue has an impact on the UE. This category shall not be used for a frozen Release, except for alignment CRs as described in clause 4.7. |
| D | Editorial modification | Editorial modifications shall have no impact on an implementation. An editorial modification CR to a frozen Release shall not be permitted. |
| E | (not used) | |
| F | Correction | Used:1 to correct an error in the specification (i.e. a clear instruction in the specification which leads to incorrect operation of the system); or 2 to correct an ambiguity in the specification which could lead to different implementations which cannot inter-operate; or3 (void); or4 to remedy the incorrect implementation of a previously approved CR; or5 to correct a misalignment between the specifications (stage 1, stage 2 & stage 3) for a feature or service when not introducing a new function or functional change. |
Notwithstanding the provisions of table 4A, a TSG may approve a CR of category B or C to a frozen specification if it is the consensus of the meeting that such an exceptional action is justified; see clause 4.7.
On successful reservation of a Change Request TDoc, the 3GPP portal will push the completed CR cover page to the user. This cover page has all the relevant metadata already filled in, thus eliminating transcription errors on the part of the author. It is strongly recommended that the author make use of this facility rather than filling in a blank CR cover from the stock template. Tips on how to complete the remaining fields of the CR form can be found at https://www.3gpp.org/specifications-technologies/specifications-by-series/change-requests-step-by-step.For reference, the CR database is available from the 3GPP file server (https://www.3gpp.org/ftp/Information/Databases/Change_Request/).. Alternatively, the CRs for a given specification or from a given meeting can be consulted on the 3GU portal (https://portal.3gpp.org).
When a CR is presented for approval, the classification into which it falls shall be identified. If this cannot be done then the CR shall be automatically rejected.
The CR form bears a field to indicate the Release number to which the CR pertains. This field shall show the Release of the intended resulting specification – that is, the Release of the specification after implementation of the CR. The Release shown on the CR form is not related to the Release of the feature to which the change relates, but to the Release of the specification being changed.