3GPP Specifications - Change Requests (CRs) - Introduction

"A Change Request is just like life,
It grips us hard until the grave:
Full of confusion, woe and strife,
And MCC its willing slave."                                            (pace Michael Powell)

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, or

• to correct / clarify / enhance an existing feature of a Release still under development, or

• to correct an error in a spec which is functionally frozen. 

This page gives a summary of:

• What is a CR?

• How Change Requests are proposed, developed and approved?

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

• Where to find status or other information about existing change requests.

• Where to find the change requests themselves.

• Is the number of CRs increasing or decreasing?

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 (most of which which meet four times a year) 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, normally within 2 weeks of the meeting.

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

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-095 is CR number 095 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 GSM or 3G 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.

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: http://www.3gpp.org/ftp/TSG_T/TSG_T
•  "12" indicates that it was meeting number 12, so from this above directory, find the subdirectory called TSGT_12 (i.e. http://www.3gpp.org/ftp/TSG_T/TSG_T/TSGT_12)
•  "TP-010107" indicates that the CR is contained in document TP-010107, which can be found under the docs directory (i.e. http://www.3gpp.org/ftp/TSG_T/TSG_T/TSGT_12/docs) 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:

• "GP" indicates a TSG-GERAN meeting, so start at http://www.3gpp.org/ftp/tsg_geran/tsg_geran/
• "NP" indicates a TSG-CN meeting, so start at http://www.3gpp.org/ftp/tsg_cn/tsg_cn/
• "RP" indicates a TSG-RAN meeting, so start at http://www.3gpp.org/ftp/tsg_ran/tsg_ran/
• "SP" indicates a TSG-SA meeting, so start at http://www.3gpp.org/ftp/tsg_sa/tsg_sa/
• "CP" indicates a TSG-CT meeting, so start at http://www.3gpp.org/ftp/tsg_ct/tsg_ct/
• "SMG" indicates an old ETSI SMG meeting, so see the historical information page for further details.

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!

Figure 1: CR statistics (cumulative)