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 MS Word™ "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. 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 (not 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".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 MS Access™ format, lists the status of each Change Request, and, if was approved, indicates which version of the specification was subsequently created.
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 3GPP Series web 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 | NO | NO | 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."). |