The Mobile Broadband Standard


3GPP uses a system of parallel "releases" - to provide developers with a stable platform for implementation and to allow for the addition of new features required by the market.

Features and contents of each Release

The list of specifications needed for each 2G, 3G and 4G release is listed in the TR mentioned in Release description below.

A simple list of Features per Release can be found here

The 3GPP Specification Release version matrix is a listing (with links) of the Specifications - showing the Release in which each Specification was first developed.

Freeze Dates:

Future dates are proposals, subject to change.


see Work Plan for Features in each Release

Spec version number
(see note 4)

Functional freeze date including stable protocols

For future, indicative only (see note 3)

Rel-13 13.x.y March 2016
Rel-12 12.x.y December 2014
Rel-11 11.x.y June 2013
Rel-10 10.x.y September 2011 - Introduction of LTE-Advanced
Rel-9 9.x.y March 2010
Rel-8 8.x.y March 2009 - Introduction of LTE
Rel-7 7.x.y March 2008
Rel-6 6.x.y March 2005
Rel-5 5.x.y June 2002
Rel-4 4.x.y March 2001
R00 9.x.y (GERAN) - initial See note 1 below.
R99 8.x.y (GERAN) 3.x.y (UTRAN) March 2000 (closed June 2011)
R98 7.x.y early 1999 (closed December 2007)
R97 6.x.y early 1998 (closed December 2007)
R96 5.x.y early 1997 (closed June 2006)
Ph2 4.x.y 1995 (closed June 2006)
Ph1 3.x.y 1992 (closed prior to creation of 3GPP)

Note 1: The term "Release 2000" was used only temporarily and was eventually replaced by "Release 4" and "Release 5" (most elements originally in Release 2000 were renamed Release 4, but some were deferred until Release 5).

Note 2: A Specification with a version number of 0.x.y, 1.x.y or 2.x.y indicates that it is a new, draft, specification which has not yet been approved. The anticipated release is normally shown on the cover of the document.

Note 3: After "freezing", a Release can have no further additional functions added. However, detailed protocol specifications (stage 3) may not yet be complete. The date shown in the table above is indicative only, since for each Release, a considerable number of refinements and corrections can be expected for at least two years following this date.  In addition, OA&M specs and test specs may lag by some considerable time. A "frozen" Technical Specification is one which can have no further category B or C (new or modified functionality) Change Requests, other than to align earlier stages with later stages.

Note 4: In the version number, the field "x" is incremented at each change in the spec resulting from one or more Change Requests approved by the responsible TSG. Field "y" is incremented whenever an editorial change is made to a specification; editorial changes are those which cannot in any way change the technical interpretation of the spec, and are introduced at the discretion of the Support Team. Exceptionally, field "y" is incremented when a newly-provided version of a spec is found to be flawed due to, for example, misimplementation of a newly-approved CR; however, this circumstance is only permitted during the three-week period following the end of a TSG plenary round, during which new versions of specs are produced. Every change of version is documented in the "change history" annex of the spec. When "x" is incremented, field "y" is reset to zero. When the Release field (the first digit) is incremented, fields "x" and "y" are reset to zero.

Other associated terms


The term "stage" derives from the ITU-T (originally CCITT) method for categorizing specifications (Recommendation I.130).

  • "Stage 1" refers to the service description from a service-user’s point of view.
  • "Stage 2" is a logical analysis, devising an abstract architecture of functional elements and the information flows amongst them across reference points between functional entities.
  • "Stage 3" is the concrete implementation of the functionality and of the protocols appearing at physical interfaces between physical elements onto which the functional elements have been mapped.

In addition, 3GPP often performs feasibility studies the results of which are made available in Technical Reports (normally 3GPP-internal TRs, numbered xx.8xx, not intended for transposition by the Organizational Partner SDOs). The feasibility study might be considered as a sort of "Stage 0". Furthermore, some Stage 3 specifications require test specifications to be prepared: effectively a "Stage 4".


This term has two distinct usages within the 3GPP:

  • in reference to GSM specifications, Phase 1, Phase 2 and Phase 2+ referred to releases of specifications (see table above);
  • some features within GSM/3G specifications have been enhanced over the years. For example, enhancements to the original CAMEL functionality are referred to as CAMEL phase 2, CAMEL phase 3 and CAMEL phase 4.

Further information

The mechanisms for creating and maintaining specifications are described in TR 21.900. A presentation outlining the release and change request process can be found here.



This page reviewed:

2013-12-19 by JMM

Latest Video
News Feeds
12171average visitors per day
111 people currently on the site