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?
- Can I search the 3GPP CR database?
- Where to find step-by-step instructions about how to write a CR?
- Where to find status or other information about CRs?
- Where to find the CRs themselves
- Is the number of CRs increasing or decreasing? - is a given Release stable?
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 value | TSG | WG | use |
|---|---|---|---|
| - | 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: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...
- "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... 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 www.3gpp.org/ftp/tsg_geran/tsg_geran/
- "NP" indicates a TSG-CN meeting, so start at www.3gpp.org/ftp/tsg_cn/tsg_cn/
- "RP" indicates a TSG-RAN meeting, so start at www.3gpp.org/ftp/tsg_ran/tsg_ran/
- "SP" indicates a TSG-SA meeting, so start at www.3gpp.org/ftp/tsg_sa/tsg_sa/
- "CP" indicates a TSG-CT meeting, so start at www.3gpp.org/ftp/tsg_ct/tsg_ct/
- "SMG" indicates an old ETSI SMG meeting (requires ETSI On-line Id).
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
