Change Request procedure, workflow, status tracking, CR database, and step-by-step instructions. Use when working with 3GPP Change Requests to modify specifications, understanding CR lifecycle, or querying CR status.
Quick Start: For workflow overview and submission checklist, see workflow.md.
Change Requests (CRs) are documents submitted to 3GPP Working Groups to create revised versions of specifications. They represent the formal mechanism for modifying 3GPP specs after initial approval.
A CR is a temporary document (tdoc) to a meeting which specifies in precise detail changes to be made to a specification. It consists of:
Three main reasons for creating a CR:
| Status | TSG | WG | Meaning |
|---|---|---|---|
| use | YES | YES | Valid for use |
| agreed | - | YES | WG agreed, forward to TSG |
| approved | YES | NO | Final decision (implemented) |
| rejected | YES | YES | Sustained objection |
| revised | YES | YES | Modified to new revision |
| merged | YES | YES | Combined with other CRs |
| postponed | YES | YES | Deferred to later date |
| endorsed | NO | YES | WG consensus, technically correct |
| withdrawn | YES | YES | Retracted before discussion |
| reissued | NO | NO | Recast unchanged in another TSG |
| noted | NO | NO | Deprecated (ambiguous term) |
<specnumber_no_dot>*_CR*<4-character_CR_number>*[r*<revision_number>*]
Components:
<specnumber_no_dot>: Spec number without dot (e.g., 21.456 for TS 21.456)*: Literal asterisk<4-character_CR_number>: 4-digit CR number padded with leading zeros (e.g., 0095)[r*<revision_number>*]: Lowercase 'r' + revision number (only for revised CRs)<release>: Release identifier (Rel-4, Rel-5, etc.)Examples:
31.102_0095 - CR 0095 to spec 31.10231.102_0095_r1 - Revision 1 of spec 31.10231.103_0095 - Mirrored CR to spec 31.1033GPP has an agreement with Netovate to provide a free CR database search:
Available on 3GPP FTP:
/ftp/Information/Databases/Change_Request/Each spec maintains a history box listing all CRs that have been approved for that specification.
3GPP provides detailed step-by-step instructions for writing CRs:
Key Sections:
CRs are classified by category to indicate their nature:
| Category | Description |
|---|---|
| F | Corrective CRs applied to earliest Release version |
| A | Mirror CRs of same spec to different Release version |
| TEI | Technical Enhancement or Improvement |
For specs maintained in multiple parallel Releases:
Special category for early LTE (Release 7) features that need to work on both Release 4 and Release 5 specs.
CRs for pure editorial changes (no technical content) are typically implemented by MCC as "dot-one" versions (e.g., 21.456.1) rather than full CRs.
Each CR must be associated with a Work Item (WI) code:
123456)Optional field in CR document to track changes as CR passes through revisions:
Word™ files for CRs follow 3GPP naming:
*<specnumber_no_dot>*_CR*<4-character_CR_number>*[r*<revision_number>*]
Zip™ archive containing CRs:
Draft → WG Agreement → TSG Approval → MCC Incorporation → Published Spec
Member organization creates CR document ↓
WG discusses and agrees CR is valid ↓
WG presents CR at TSG plenary for approval ↓
TSG approves CR (becomes decision) ↓
MCC incorporates CR into new spec version ↓
New spec version becomes available
yyyy-MM-DD format