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".
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 | positive consensus at WG level |
| approved | YES | NO | positive consensus at TSG level (final decision) |
| rejected | YES | YES | negative consensus |
| revised | YES | YES | modified to new revision of same CR |
| postponed | YES | YES | decision deferred to later date; when used at TSG level, normally indicates that WG will re-examine |
| tech 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) |
| withdrawn | YES | YES | either never produced, or retracted by author prior to WG/TSG decision |
| reissued | YES | YES | of CRs in multiple CR packs to TSG: recast unchanged into another TSG document due to modifications to _other_ CRs in the original pack; most unlikely to be used at WG level, but not strictly forbidden |
| noted | YES | YES | not presented for decision at the present time, therefore just taken as information |
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!
