The specifications shall be numbered according to the following scheme:
3GPP TS aa.bbb (for Technical Specifications); or
3GPP TR aa.bbb (for Technical Reports).
The fields aa and bbb shall be selected according to the nature of the specification as given in Tables 1 and 2. The provisions of Table 1 shall be strictly enforced, but those of Table 2 should be used for guidance: it is acceptable to deviate from these provisions for backwards compatibility or other reasons.
Often transient specifications containing requirements leading to other specifications; may become obsolete when technical solutions have been fully specified; they could then, e.g., be replaced by reports describing the performance of the system, they could be deleted without replacement, or be kept for historical reasons but treated as background material.
Services, service features, building blocks or platforms for services (a service feature or service building block may provide certain generic functionality for the composition of a service, including the control by the user; a platform may comprise one or more network elements, e.g. UIM, mobile terminal, auxiliary system to the core network etc.); also appropriate stage 1 specifications; also reports defining services which can be realized by generic building blocks etc.
Mainly stage 2 specifications (or specifications of a similar nature describing interworking over several interfaces, the behaviour in unexceptional cases, etc.).
Signalling protocols (UE to CN)
Detailed and bit-exact stage 3 specifications of protocols between MS/UE and the Core Network.
Radio access aspects
UTRAN radio performance
UTRA layer 1
UTRA layers 2 & 3
UTRAN Iub, Iur & Iu interfaces
Speech and other codecs (video etc.).
Functions necessary to support data applications.
Signalling protocols (RSS to CN)
Detailed and bit-exact stage 3 specifications of protocols between radio subsystem (eg BSS) and periphery of CN (eg MSC). (Not used in Release 1999.)
Core Network signalling protocols
Detailed and bit-exact stage 3 specifications of protocols within the Core Network.
3rd Generation Mobile System, project plans / project work programme and stand-alone documents for major Work Items.
SIM / UIM
Subscriber / User Identity Module and the interfaces between it and other entities.
Charging and OAM&P (Operations, Administration, Maintenance & Provisioning)
Application of TMN for the 3GPP 3rd Generation Mobile System and other functions for operation, administration and maintenance of a 3rd Generation Mobile System network.
Regulatory test specifications. (Transferred from ETSI TC SMG to ETSI TC MSG.)
Specifications of encryption algorithms for confidentiality and authentication, etc.
Evolved Universal Terrestrial Radio Access (Network)
Introduced in Release 8 for the so-called "Long Term Evolution" of the radio technology. A similar subdivision to that used for the 25-series above is used.
Multiple radio access technology aspects
Such as handover, fallback, interworking.
5G "New Radio"
Release 14: first studies.
Column 1 refers to the original GSM specification series used up to Release 1999.
Column 2 refers to the specifications peculiar to GSM implementations for Release 4 onwards - that is, those specifications relating solely to GSM/EDGE radio access.
Column 3 refers to the specifications created by 3GPP for Release 1999 onwards implementations having a UTRAN radio access. Many of these are common to GSM/EDGE and UTRAN systems (see table 2).
Separate specifications list the specs required to implement Releases GSM/EDGE and UTRAN systems (3GPP TSs 21.101 , 01.01 / 41.101 ).
Direct equivalent to aa.bb GSM specification for previous Releases.
Specification either (a) derived from earlier 2G (GSM) specification, but with technical modification; or (b) new specifications.
aa in range 21 to 39: For most specifications in this range for a given Release, a GSM specification numbered [aa 20].[bbb 100] will have existed for earlier Releases, and may continue to exist (in parallel) for the same Release. Example: 3GPP TS 28.133 will have been based on GSM 08.33, but both specifications exist for Release 1999 onwards. aa in range 41 to 59: New GSM specification for Release 4 or later.
aa.2bb to aa.7bb
Not, in general, derived from pre-Release 4 GSM predecessors.
Note: See Table 1 for specific allocation within 25.bbb series.
Technical Reports not intended for publication.
Working documents of 3GPP Groups not intended to be transposed into publications by the Partner Organizations.
0: draft 1: presented to TSG for information (specification estimated by prime responsible Group to be at least 60% stable) 2: presented to TSG for approval (specification estimated by prime responsible Group to be at least 80% stable) 3 or greater: approved by TSG and under change control; the value indicates the Release according to Table 4.
Incremented every time a technical change is introduced into the specification. Once under change control, such changes shall only occur when the TSG approves one or more Change Requests. Reset to zero every time the "major" field is incremented.
Incremented every time a purely editorial change is introduced into the specification. Reset to zero every time the "technical" field is incremented or reset to zero.
Table 3 shows the estimated degree of stability to be used as a guideline for determining when to raise a specification to version 1.y.z and to 2.y.z. Such figures are obviously subjective, and the decision is ultimately at the discretion of the responsible Group.
A TS or TR having reached at least 60% stability and presented to the TSG for the first time shall be presented with its major version number set to 1, i.e. as version 1.y.z..
Specifications are grouped into "Releases". A mobile system can be constructed based on the set of all specifications which comprise a given Release. A Release differs from the previous Release by having added functionality introduced as a result of ongoing standardization work within the Groups.
Specifications pertaining to a given Release shall be distinguished by the first field of the version number ("x" in x.y.z) according to table 4. Table 0 also shows for comparison the equivalent significance of the GSM Releases.
For further details on Release control, see subclause 4.10.
Where appropriate, the three-stage methodology defined in ITU T Recommendation I.130 should be employed:
Stage 1 is an overall service description from the user's standpoint.
Stage 2 is an overall description of the organization of the network functions to map service requirements into network capabilities.
Stage 3 is the definition of switching and signalling capabilities needed to support services defined in stage 1.
In addition, it is often appropriate to perform a feasibility study prior to formal specification work. This is sometimes referred to as "stage 0".
Furthermore, it will often be appropriate to follow stage 3 with the production of test specifications - a stage 4.
A new specification shall be created in a Group. At creation, a rapporteur shall be appointed. The rapporteur shall produce an initial draft, version 0.0.0, and subsequent revised versions (version 0.1.0, possibly 0.1.1, 0.1.2 and so on, then version 0.2.0 etc.). Details of the role of the rapporteur are described in subclause 4.1.2.
The rules for drafting specifications, and the software tools to be used are listed in TR 21.801.
Versions 0.1.0, 0.2.0, 0.3.0 etc. should be presented to the responsible Group. Versions 0.i.1, 0.i.2 etc. may be internal to the drafting group.
Further drafts may be produced, with appropriate increments in the "technical" / "editorial" fields of the version number. Every new draft with an incremented "technical" version field shall be presented to the responsible Group. Although two or more Groups may have an interest in contributing to the development of a specification, ultimate responsibility vests in a single (responsible) Group. The responsible Group shall ensure that all other Groups which might have an interest are given the opportunity to participate in the drafting. The objectives intended to be provided or decided by a working group with secondary responsibility shall be made clear in a corresponding Work Item Description document, identifying additional rapporteurs from such secondary group(s) if necessary.
The Support Team is responsible for allocating specification numbers. As soon as title, scope and some other information on the specification is stable, the Support Team shall assign a specification number according to the provisions of subclause 4.0 and shall enter the specification into the Status List of Specifications (see clause 7). The TSG Sub-Group responsible for the specification shall inform its parent TSG that such a new specification is under construction.
When a specification is sufficiently stable (see table 3), it shall be converted to version 1.0.0 (with no technical changes with respect to the previous version 0.y.z) by the Support Team, and presented to the TSG for information. Further drafts bearing version numbers 1.y.z may be produced until the specification is sufficiently stable to be approved by the TSG. At this stage, and until formal approval by the TSG, the specification is, unless it belongs directly to a TSG, under the control of the responsible TSG Sub-Group. The modalities governing the introduction of changes shall be decided on a case by case basis by the WG concerned.
Once the responsible Group considers that the draft is sufficiently stable (see table 3) that it is desirable to place it under change control, the latest version 1.y.z shall be converted to version 2.0.0 (with no technical changes with respect to the previous version 1.y.z) by the Support Team and presented for approval at the TSG.
If the TSG does not approve the draft, further drafts version 2.y.z may be produced by the responsible Group.
If the TSG does approve the draft, the approved version (with no technical changes) shall be converted to version x.0.0 where "x" corresponds to the Release identity given in table 4.
The specification shall now be under TSG change control. Further changes shall be made by means of formal Change Requests, to be approved by the TSG. On approval of a CR, the middle number shall be incremented and the right-most number reset to 0 (e.g., from 7.2.1 to 7.3.0).
The specification may have a prime responsible TSG WG.
The specification may have one or more secondary responsible TSGs and/or TSG WGs. WIDs will express the specific objectives justifying changes to the specification or any other action by any Group with secondary responsibility.
The specification may have a prime responsible TSG Sub-Group below a Working Group as decided by the prime responsible TSG Working Group.
The specification shall have a rapporteur: a delegate from a member company (or, in exceptional cases, a Support Team expert); the delegate should participate regularly in the prime responsible TSG WG (and further TSG SG if applicable).
The specification is a Technical Report or a Technical Specification
A specification has versions which are identified by three numbers (see 4.0A).
A major version 0 or 1 or 2 of a specification has the following characteristics:
It is either a draft or withdrawn.
It is TSG internal.
A major version w > 2 of a specification has the following characteristics:
It is either under TSG WG Change Control or under TSG Change Control or closed or withdrawn.
It is either authorized for publication or TSG internal.
A major version of a specification under TSG WG Change Control is TSG internal.
A major version under TSG WG Change Control or TSG Change Control is called major version under Change Control.
A major version of a specification under TSG Change Control is