The Mobile
Broadband Standard










LTE-Advanced Pro

Change Requests

The Change Request (CR) procedure is used by 3GPP to create revised versions of 3GPP specifications after their initial approval. The three main reasons why a change might be required are to:

  • Add a new feature
  • Correct / clarify / enhance an existing feature of a Release still under development
  • Correct an error in a spec which is functionally frozen


What is a CR?

A CR is a document (a "temporary document" - tdoc - to a meeting) which specifies in precise detail changes which are proposed to the specification. It consists of a CR coversheet which, amongst other things, describes why a change is needed and summarizes how the change is made. Attached to this are the parts of the specification affected by the change, with the changes being identified using the Microsoft Word(TM) "Track Changes" (revision marks) feature.

 How are change requests proposed, developed and approved?

A Change Request can be proposed by any 3GPP member organization. It is normally submitted for discussion to the Working Group (WG) responsible for the specification (see the page pertaining to the individual spec concerned, via the table on the numbering page, to determine the relevant WG). Once the WG has agreed that the Change Request is both valid and required (often it may be revised several times before reaching this stage), it is presented, on behalf of the WG (rather than the originating member organization) as an agreed proposal to the parent TSG plenary for final approval. After approval at TSG level, the 3GPP Support Team (MCC) incorporates it and any other CRs into a new version of the specification, and makes the new version of the specification available.

The full CR procedure is to be found in TR 21.900 "Technical Specification Group working methods". A comprehensive introduction to the lifecycle of a specification, including change requests, can be found in this PowerPoint presentation, "The change control cycle". Consult the whole process in a second presentation, "The life cycle of a spec".

 Can I search the 3GPP CR database?

We have an agreement with Netovate LTD to provide you with a free CR database search tool...more details

 Where to find step-by-step instructions about how to write a CR?

Step by Step Instructions describing how to actually write a CR can be found here.

 Where to find status or other information about CRs?

CRs are normally identified by a specification number and a CR number. e.g. CR 31.102-0095 is CR number 0095 to specification 31.102. Every change request which is presented to a TSG plenary meeting for approval is recorded in the CR database. This database, in Microsoft Access(TM) format, lists the status of each Change Request, and, if was approved, indicates which version of the specification was subsequently created. The CR database contains records about every change request to specifications from GSM phase 1 onwards.

Alternatively, there is a link from the web page for each individual spec to the CRs pertaining that spec, below the Release and version history. The pages for each spec can be reached via the table on the numbering page.

In addition, each spec contains a history box of every CR which has been approved for that particular specification.

The table below shows the meanings of the status values used for CRs and also indicates whether or not each value can be used at TSG level and at WG level ...

CR status valueTSGWGuse
- YES YES not yet seen, no decision reached
agreed NO YES no sustained objection to its being forwarded to the TSG for approval
approved YES NO no sustained objection to its being implemented into the corresponding TS/TR. (final decision)
rejected YES YES sustained objection to progressing the CR further; this status deemed not politically correct in some groups
not pursued YES YES the politically correct version of "rejected"
revised YES YES modified to new revision of same CR
merged YES YES combined with (a revision of) one or more other CRs
postponed YES YES decision deferred to later date; when used at TSG level, normally indicates that WG will re-examine the issue
endorsed NO YES consensus at WG level that CR is technically correct, but there may be other solutions (which may be presented in parallel to TSG) [formerly "technically endorsed"]
withdrawn YES YES either never produced, or retracted by author prior to WG/TSG discussion
reissued YES NO of CRs in multiple CR packs to TSG: recast unchanged into another TSG document due to modifications to other CRs in the original pack
noted YES YES not presented for decision at the present time, therefore just taken as information. This status is deprecated, since the term "noted" is ambiguous ("We have noted its contents, and will act accordingly" vs "We have noted its contents and will take no further action.").

 Where to find the CRs themselves

As an example, to find CR 31.102-095. First, look in the CR database (or the web page for that spec’s CRs); find the the record for the CR and read the "meeting-1st-level" field (TP-12 in this example) and the "Document-1st-level" field (TP-010107 in this example). Then do the following steps:

  • "TP" indicates that the CR was presented a TSG-T meeting, so go to:
  • "12" indicates that it was meeting number 12, so from this above directory, find the subdirectory called TSGT_12 (i.e.
  • "TP-010107" indicates that the CR is contained in document TP-010107, which can be found under the docs directory (i.e. in ZIP (compressed Word(TM)) or PDF(TM) format. Inside TP-010107, you will find the actual CR. (Several related CRs may be contained in the same tdoc.)

Note that the starting URLs for the other four TSGs are as follows:

Using the web interface to the spec makes this process a little easier, since hyperlinks are provided to the relevant meeting document directories.

Is the number of CRs increasing or decreasing? - is a given Release stable?

As a new system, or a new Release of a system is developed, so the rate of change of its specifications increases. It might be thought that the rate of change would be an indication of stability of the system specifications, but this is not necessarily the case... The number of changes actually increases dramatically around the time that the Release is frozen (for the definition of the term "frozen", see TR 21.900) because it is at this stage that active development of equipment starts. With implementation of real systems and development of the actual protocols, many improvements and corrections are identified, and the number of CRs submitted increases.

The criteria for deciding when the specifications for a given Release are "stable" are naturally subjective. The earlier you implement, the higher the risk of essential technical modifications being needed, but the better placed you are for early market penetration. And vice versa. For you to decide!


Change Requests - Step-by-Step

Table of contents Header Spec number CR number CR Revision number Current version (U)SIM - ME/UE - Radio Access Network - Core Network Title Source to WG Source to TSG Note on source fields Work item Date Category Release Reason for change Summary of changes Consequences if not approved Clauses affected Other specs affected - core / test / O&M Other comments Filename (...)


More news...

New CT Leadership;

ct leaders
News Feeds