Content for  TR 21.900  Word version:  18.1.0

Once a specification has been approved by the TSG and version x.0.0 (where x ≥ 3, corresponding to the Release - see Table 4) has been produced, it shall be considered to be under change control. Any technical change which may be identified for inclusion in the specification from this point on shall be accomplished by means of a Change Request (CR). A CR may be raised by any individual member and brought to the attention of the responsible Group. A Change Request shall relate to a specific version of a specification. A unique (for that specification) reference number shall be allocated to the CR by the 3GPP portal or the Support Team. CR details shall be entered into a CR database maintained by the Support Team and made available on the 3GPP file server. CR numbers shall not be re-used, even if a CR is ultimately rejected by the TSG (see note). A CR may undergo one or more revisions before a final decision is made on it. The database shall show all revisions of each CR. The TSG WG Secretary shall collate all CRs agreed by the WG and shall send them to the parent TSG for approval. For specifications which are directly under the control of a TSG, the CR shall be brought directly to the attention of the TSG. Following approval at TSG level, the Support Team person responsible for the specification shall edit the original specification to incorporate the changes of all Change Requests approved by the TSG. The new version of the specification shall then be made available on the 3GPP file server. The TSG should approve, reject or postpone a CR in its entirety (after revision, if necessary). That is, the modifications proposed by the CR should either be accepted without change, or unconditionally rejected. For ease of management, a single Change Request should therefore pertain to a single technical topic only. Each topic can thus be cleanly accepted or rejected by the TSG. Where two or more CRs pertain to the same (version of a) specification, the responsible Group shall check for potential interaction amongst those CRs to ensure that, if all are approved by the TSG, each is implementable without contradicting any other. The TSG Secretary shall record the TSG's decisions (see Table 9.2-1) on each CR in the meeting report and those decisions shall be reflected in the CR database and on the 3GPP portal.

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.

  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 http://www.3gpp.org/specifications/change-requests/85-change-requests-step-by-step. For reference, the CR database is available from the 3GPP file server (http://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.

Although the CR form shall indicate the details of change, each CR shall have attached the clauses of the specification that are affected by the CR, using the latest version of the major version. These clauses shall have the proposed modifications clearly marked, by means of the word processor's "revision mode". In case there are more than one independent CR to the same part of the specification, neither of them should contain the proposed modifications from the other(s), however any potential interaction between the modifications should of course be resolved before presentation. If the CR proposes changes to stage 3 specification files which are normatively documented in the 3GPP Forge repository according to clause 5C, then the proposed modifications shall be documented in the 3GPP Forge repository. In this case the cover page of the CR form shall contain a reference to a Forge Merge-Request clearly listing the proposed modifications in the "Other comments:" field, and excerpts of all affected stage 3 specification files clearly showing the proposed changes shall be appended to the cover page of the CR form.

Entry to the TSG WG: A proposed CR should be brought to the relevant Group primarily responsible for the specification concerned and discussed there, before presentation to the TSG. Comments from secondarily responsible Groups (if any) shall have been sought and comments shall have been taken into account before presentation to the TSG for approval. To ease the work of the Group and of the Support Team , a proposed CR should be presented in a form suitable for TSG WG agreement and TSG approval. If a CR is not immediately accepted the originator shall update the CR taking into account comments and other guidelines from the relevant groups, including change of reference version if needed, and to re-present it to the Group. All CRs shall be presented in electronic form. CR identification: During the course of its development, a CR may be modified, and the CR's progress shall be indicated by allocation of a revision number: rev. 1, 2, and so on. A given revision of a CR is uniquely defined by

• the specification to which it belongs, and
• the CR number (an alphanumeric string) and
• the revision number (default, i.e. the value if no number is given, is '-', i.e. the original, unrevised, CR).

A CR number shall be allocated by the 3GPP portal or the Support Team. For a given Specification, CR numbers shall be unique and shall never be reused (see clause 4.6.1). Numbers used for rejected CRs shall not be reused. If a CR is rejected, and the responsible Group considers it useful to bring a modification of the CR to a subsequent TSG for approval, the new CR shall be allocated a new CR number. That is, it shall not be presented as a revision of the same CR number previously rejected. Impact on other specifications: If the content of the CR is such that, in isolation, it makes the whole set of approved Specifications inconsistent, corresponding CRs shall also be considered and produced. This should be carried out by the originators of the CR (and their colleagues in other Groups) in advance. The Support Team is co-responsible for identifying and communicating cross-TSG and cross-TSG-WG impacts. If a CR (or set of CRs) causes an inconsistency with an existing/approved test or O&M specification, the corresponding CRs should be presented together with the core specification CR in the same TSG cycle. Otherwise they may follow in a later TSG cycle. Handling of the CR in the TSG: When the TSG WG has agreed to a CR and comments from secondarily responsible Groups (if any) have been taken into account, the Support Team shall ensure that it is correctly formatted and assembled, and shall submit the CR to the primarily responsible TSG for formal approval. The Support Team shall collate agreed CRs in CR packs. The Support Team shall make available to the TSG summary lists of all CRs presented for decision. This list shall be updated to show the decision reached for each and every CR. Decisions on CRs, and results: The TSG shall consider and conclude on each CR independently; the verdict on each CR shall be one of the values listed in clause 9.2

  Control and notification of CR decisions: At the end of each TSG meeting, the Support Team shall issue lists containing the detailed result of the CRs presented at the meeting, including information about the consequential new version numbers of the concerned specifications. These lists shall form an annex to the meeting report (and hence are part of a permanent document). These lists, being the evidence of which specifications have changed and how, are important management tools for both TSG delegates and the Support Team since it takes some time before the new versions of the specifications can be compiled and released.

If there is at least one Approved CR to a given specification, a new version number of the specification shall be allocated (see clause 4.2.3), and the Support Team shall produce and issue a new version of the specification.

The Support Team may update a specification to correct purely editorial deficiencies brought to its attention. In this case, only the "editorial" field (third digit) of the version number shall be incremented. Such changes should be avoided if possible: normally, they should be held over for inclusion next time a technical change is made to the specification. All such changes shall be clearly explained in the "change history" annex of the specification.