Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TR 21.900  Word version:  16.3.0

Top   Top   Up   Prev   Next
0…   4…   4.4…   5…   6…   7…   8…   9…

 

4.4  Characteristics of a version of a specificationWord‑p. 15
0.x.y
  • draft (or withdrawn)
  • TSG internal
  • no version of the specification has been presented for information to the TSG yet
  • no major version of the specification is under TSG change control yet
1.0.0
  • draft (or withdrawn)
  • TSG internal
  • this version 1.0.0 is presented to TSG
  • for information
  • or for information and approval
  • no major version of the specification has been under TSG Change Control yet
1.x.y (x > 0 or y > 0)
  • draft (or withdrawn)
  • earlier version 1.0.0 has been presented for information to the TSG
  • no major version of the specification is under TSG Change Control yet
2.0.0
  • draft or withdrawn
  • TSG internal
  • earlier version 1.0.0 has been presented for information to the TSG
  • this version 2.0.0 is presented to the TSG for approval
  • no version of the specification has been approved yet
  • no major version of the specification has been under TSG Change Control yet
2.x.y (x > 0 or y > 0)
  • draft
  • TSG internal
  • [earlier version 1.0.0 has been presented for information to the TSG]
  • no major version of the specification is under TSG Change Control yet
  • earlier version 2.0.0 had been presented to the TSG for approval but had not been approved by the TSG
x.y.z (x ≥ 3)
  • under TSG Change Control or closed
  • TSG internal or authorized for publication
  • [earlier version 1.0.0 has been presented for information to the TSG]
  • earlier major versions of the specification, if any, shall be under TSG Change Control or closed or withdrawn
draft y.z of version x
  • under TSG WG Change Control
  • TSG internal
  • [earlier version 1.0.0 has been presented for information to TSG]
  • earlier major versions of the specification, if any, shall be under TSG Change Control or closed or withdrawn
Up

4.5Void

4.6  Change Request regime

4.6.1  Change Requests

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 and brought to the attention of the responsible Working Group. The WG Secretary shall allocate a unique (for that specification) reference number to the CR, and shall cause its details to 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 (see note) by the TSG, though 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 Secretary shall collate all CRs approved by the WGs of that TSG and shall bring them to the TSG for approval. For specifications which are directly under the control of a TSG, the CR shall be allocated a number and brought directly to the attention of the TSG by the TSG Secretary.
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.
A Change Request shall relate to a specific version of a specification. A CR may be revised by the responsible Group; thus care shall be taken that the WG-agreed revision of a CR is presented for TSG approval and subsequently implemented.
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 5) on each CR in the meeting report and those decisions shall be reflected in the CR database.
Up

4.6.2  Change Request formsWord‑p. 16
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.
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; or
3
(void); or
4
to remedy the incorrect implementation of a previously approved CR; or
5
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 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.
Up

4.6.3  Contents of Change RequestsWord‑p. 18
Although the CR form shall indicate the details of change, each CR shall have attached the pages of the specification that are affected by the CR, using the latest version of the major version. These pages 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.
Up

4.6.4  Handling of the Change Requests

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. If possible it should be distributed, by the source, as soon as possible and prior to the coming Group meeting to the relevant e-mail reflector (with a clear indication of the subject), for the purpose of shortening discussions in meetings and to try at as early a stage as possible to come to a widely acceptable solution. Comments from secondarily responsible TSGs (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
  • an alphanumeric string (the CR number) and
  • the revision number (default, i.e. the value if no number is given, is 0, i.e. the original, unrevised, CR).
The CR number shall be allocated by 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 number. That is, it shall not be presented as a revision of the same CR number previously rejected.
Impact on other specifications and Joint CRs:
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 originator of the CR (and his colleagues in other Groups) in advance. The Support Team is co-responsible for identifying and communicating cross-TSG and cross-TSG-WG impacts.
In principle, a CR shall not be forwarded to the TSG unless the potential impact on other specifications has been thoroughly examined and concluded, either resulting in a "No impact" statement or in a full and consistent set of corresponding CRs to all affected specifications. Such sets of CRs should be combined into a single document, by the Support Team , before submission to all responsible TSGs and called "Joint CRs". An approval by all primarily responsible TSGs is necessary.
If some of the corresponding CRs are to be considered by other Groups, the Support Team shall be responsible for monitoring the result in those Groups and for submitting the full set, when available, to the TSG. This might mean that in some cases the CRs agreed in the TSG WG are not presented to the immediately following TSG meeting due to outstanding CRs from other Groups.
Other "consequential" CRs, needed for reasons other than direct consistency, may be drafted, presented and agreed independently. This covers typically additions to test specifications and O&M specifications. If a CR causes an inconsistency with an existing/approved test or O&M specification, the corresponding CRs should be presented together with the core specification CR.
Handling of the CR in the TSG:
When the TSG WG has agreed to a CR and comments from secondarily responsible TSGs (WGs) 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 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, except for Joint CRs, which are handled and concluded together; the verdict on each CR shall be one of the values listed in clause 9.2
Table 5: (void)
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.
Up

4.6.5  Updating and release of new versions of the specificationsWord‑p. 19
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.

4.6.6  Other changes to specifications

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" of the specification.

4.7  "Freezing" of specifications

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).
Up

4.8  "Closing" of specificationsWord‑p. 20
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.)

4.9  "Withdrawing" of specifications

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.
Up

4.9A  "Withdrawing" of 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.

4.9B  Procedure for withdrawing of specifications and functionality

4.9B.2  Diligent assessment

The decision whether to withdraw (a) specification(s) or whether to remove functionality from within specifications shall only be taken once thorough consideration has been given to the implications and applicability of the action.
The withdrawing of a specification or functionality shall be explictly identified as one of the objectives of a work item.
The withdrawing of a specification or functionality may be documented in:
  1. a work item that defines new functionality that will obsolete the specification or functionality; or
  2. documented in a work item that is solely for the purpose of withdrawing.
Technical Enhancements and Improvement (TEI) and other similar general purpose enhancement work items shall not be used for the withdrawing of a specification or functionality.
The assessment of whether to withdraw functionality may extend beyond 3GPP TSGs and their working groups. A notice shall be placed on the 3GPP site to solicit comments from other concerned parties and shall clearly indicate which specifications and functionality are considered for withdrawal, including which versions of the specification would be affected, the date at which a decision will be taken and the responsible TSG to which third parties may send related Liaison Statements or other correspondence.
A study item may contain, as one of its objectives and/or its conclusions, consideration of whether existing functionality should be withdrawn and the identification of the impact of the withdrawing of functionality or specifications.
Up

4.9B.3  Changes to affected specificationsWord‑p. 21
Removal of functionality shall be done using the normal change request procedure (see subclause 4.6).

4.9B.4  Considerations for ongoing maintenance, enhancement and new Release versions of specifications

When a specific version or all versions in a specific Release of a specification, are withdrawn further versions of the specification in the same Release shall not be created and the specification shall not be promoted to a subsequent Release.
Evolution of specifications and functionality in Releases unaffected by the withdrawal are allowed.
A Category B or Category C CR that adds to or modifies a specification or functionality that has been withdrawn in a subsequent version shall clearly state on the CR cover sheet in the Summary of change that the subsequent version of the specification or functionality has been withdrawn.
Category A CRs for Releases in which the specification or functionality has been withdrawn shall not be produced.
Up

4.10  Release control

4.10.1  Creation of a new Release version of a specification

The concept of Releases was introduced in subclause 4.0B. A given specification may simultaneously exist in several versions, each corresponding to a different Release.
In principle, a Release of the specification can be identified as consisting of all those specifications with a "major" version field of a given value.

4.10.1.1  With no technical changes compared to the previous Release

A given Release consists of a set of specifications having a common "major" version field; therefore, for the set of specifications to be complete, a new specification needs to be produced even if its provisions are identical with those of the previous Release's version. The creation of such a specification shall be delayed until the latest possible moment - that is, until the TSG is on the point of declaring a given Release to be complete, having determined that no technical changes are needed in the specification compared with the previous Release.
The creation of the new version under these circumstances shall be via the responsible TSG's taking a decision to upgrade to the next Release of the specification.
This implies that all Groups need to conduct a rigorous review of all specifications for which they are responsible to determine which are to be propagated to the next Release and which are not.
Up

4.10.1.2  When introducing technical changesWord‑p. 22
A new version of a specification, corresponding to a new Release, shall be prepared when a technical change needs to be introduced to satisfy a requirement of a feature of that new Release. This shall be accomplished by the raising of a Change Request (see clause 4.6) in the usual way, with the version number of the resulting specification indicating the new Release. The CR shall bear the identity of the new Release (rather than the starting point Release - see subclause 4.6.2.
Up

4.10.1.3  Specifications not propagated to next Release

Specifications which are not propagated from Release N-1 to Release N in one of the above two methods shall be deemed not to form part of Release N. Under these circumstances, the responsible Group shall undertake a review of all other specifications of Release N to eliminate references to the specification concerned.

4.10.2  Mirror Change Requests

When a Group produces a Change Request changing an early Release of a specification, it shall check whether the same change also needs to be made to later Releases of the specification. Changes which are corrective or clarifying in nature will generally be applicable to such other versions.
Where it is determined that several Releases are affected, an (independently numbered) Change Request shall be created for each such affected version of the specification. Such CRs are termed "mirror Change Requests". The principal CR and its related mirror CRs should be grouped together for the purpose of presentation to the TSG (unless some other grouping is more logical).
The TSG shall approve (or postpone or reject) a CR to a given Release together with the corresponding mirror CRs to later Releases. This will provide consistency between Releases.
See also subclause 4.6.2.
Up

4.10.3  Release mechanisms

It is important that the 3GPP release structure provides a sound basis for implementations and equipment interoperation. Key principles important to ensure this are:
  • A Release shall consist of a well-defined, stable and internally consistent set of functions.
  • A Release shall be documented in a maintained, consistent stream of specifications.
  • Essential corrections to a stable or frozen release shall be included in the applicable Release.
  • New or changed functionality shall be included in a new (rather than retrospectively in an old) Release.
These principles will ensure successful interoperability (roaming) amongst different instantiations of 3GPP systems.
Up

4.10.3.1  Corrections to Releases

Each release should be consistent and implementable to ensure interworking. This implies that essential corrections become normative parts of the Release as soon as possible. If essential changes to "old" functionality are made to a new release, similar corresponding changes shall be made to correct the same error in the specifications pertaining to all previous, non-closed, Releases. This is illustrated in Figure A.

4.10.3.2  New featuresWord‑p. 23
New functionality shall be included in the latest, non-frozen, Release. New functionality shall not be included in previous, frozen, Releases. To do so would cause incompatibility amongst instantiations of those Releases. This is illustrated in Figure A.
Reproduction of 3GPP TS 21.900, Figure A: Introduction and development of new features to the latest Release; and corrections to multiple Releases (example)
Up

4.10.3.3  Release naming

GSM phase 2+ specifications were grouped into annual Releases from 1996 to 1999. The first 3rd generation specifications were grouped into an initial Release 1999.
Subsequent Releases are not necessarily annual, and shall be referred to as Release 4, Release 5, etc., according to the major field of the version number (see table 4 and subclause 4.3).

4.10.3.4  Introduction of features into Releases

Development of the 3GPP system specifications shall be controlled by means of a work plan covering the inclusion of new features (functionality). Target dates for completion of Work Items (see clause 6) shall be estimated by the responsible Groups. Milestones may be defined to monitor the progress of Work Items. Based on the estimated completion of the desired features, a target date for freezing of the specifications pertaining to the next Release can - and shall - be calculated. Feature development should be based around approximately annual Releases.
Thus the work plan shall indicate (a) the estimated freeze date of forthcoming Releases and (b) the functional content of each such Release. The work plan shall show all projected work, regardless of Release; this will ease long term planning and the packaging of features into Releases. Completed Work Items shall be removed from the plan once the Release of which they form a part has been frozen.
3GPP technical coordination should set target dates for the freezing of each individual stage (cf. clause 4.1) on all currently worked-upon Releases (i.e. non-frozen).. On freezing stage 2 of Release x, TSGs should propose a target freeze date for stages 1, 2 and 3 of Release x+1. It is possible that features of exceptional complexity may span more than one Release (eg new core network architecture, new radio interface).
The freezing date for a particular stage of a Release should insofar as is possible be adhered to, even if, due to delays, it is not possible to include all the features originally intended. Features which cannot be completed in time should be held over to the next Release. It will normally be the case that test specifications and O&M specifications will not necessarily be completed until some time after the base specifications; this shall not impede the freezing of the Release as a whole. However, if it becomes evident that, due to delays in a number of important features, a new Release would contain little new functionality, it may be preferable to delay the freezing of the stage of a Release to allow more of the originally intended features to be included.
The project plan shall clearly show the progress of each Work Item. When all component Work Items of a feature have been completed, the TSG shall declare the feature to be frozen. The only further development permitted from that point onwards shall be:
  • the essential correction of errors;
  • the completion of the test and O&M specifications; and
  • unavoidable adjustments required to cater for interworking with other features in the same Release.
See clause 6 for further information on Work Items.
Up

4.10.3.5  Early implementation of featuresWord‑p. 24
3GPP may identify certain features as being suitable for "early implementation". The selection of "early implementation" features shall be performed at the TSG level.
Additional documentation is provided for early implementation features (see subclause 6.4.4).
All documentation for early implementation features is contained in the Release where the feature is introduced. The status or specification of older Releases shall not be changed by the introduction of early implementation features.
Up


Up   Top   ToC