Content for  TR 21.900  Word version:  18.1.0

A TSG may decide that a specification is sufficiently stable that it may be considered "frozen". That is, only CRs for essential corrections of errors shall be considered except as discussed below (see clause 4.6.2 and in particular the derogation statement below Table 4A). (At the same time, a new major version may be developed for inclusion of new features). Normally, all specifications of a Release will be frozen when the TSGs decide that the functionality of the Release is stable - i.e that all new features to be included in the Release have been defined and that all new or modified functionality required to implement those features has been incorporated into the specifications. At this point, the Release as a whole shall be declared to be "frozen", and its constituent specifications shall likewise be "frozen". A CR of category B or C (and any associated category A mirrors) to a frozen version of a specification (in a given Release) shall only be an alignment of the specification with the agreed functionality of the Release as provided for in other specifications of that Release, or for internal consistency of an individual specification. Such a CR may add to, remove from, or modify the functionality of a frozen specification to ensure a consistent specification set across a particular Release. Correction CRs (category F and any associated category A mirrors) to a frozen version of a specification (in a given Release) shall fit into one of the following classifications:

• A CR to introduce an essential correction, i.e. where a frequently occurring case is not handled properly because there is some error or significant ambiguity in the specification.
• A CR to remedy the incorrect implementation of a previously approved CR (of any category).

A TSG may decide that a specification will no longer be maintained. That is, no further Change Requests should be considered. The specification remains available, but no further Change Requests should be produced, even corrective ones to align with the equivalent specification of a subsequent Release. (At the same time, higher major versions of the specification may be under development.)

A TSG may decide to withdraw a specification which is obsolete if its remaining available would confuse implementors (for example, if it contained provisions which were contradictory to provisions of other, later, specifications). Before withdrawing a specification, the TSG shall ensure that no references are made to it from any other 3GPP specification (and raise appropriate Change Requests to eliminate any such references discovered). A TSG shall use the procedure in clause 4.9B to withdraw specifications and functionality.

A TSG may decide to withdraw functionality. Before withdrawing functionality, the TSG shall:

• raise Change Requests to eliminate any references made to this functionality from any 3GPP specifications; and
• move text within specifications which were created for the functionality, that is applicable to other functionality as well, to other appropriate specifications.