# 3gpp Change Request > 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. - Skill: `jr2804/3gpp-change-request` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jr2804/3gpp-change-request` - Raw SKILL.md: https://api.skillmd.com/api/skills/jr2804/3gpp-change-request/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: jr2804 (https://skillmd.com/u/jr2804) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/jr2804/3gpp-change-request --- # 3GPP Change Requests - Reference > **Quick Start**: For workflow overview and submission checklist, see [workflow.md](workflow.md). ## Overview 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. ## What is a CR? 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: - **CR Cover Sheet**: Describes why a change is needed and summarizes how the change is made - **Attached Parts of Spec**: Word™ "Track Changes" (revision marks) identifying affected sections - **Summary of Changes**: Brief explanation of the proposed modification ## Why Changes Are Needed Three main reasons for creating a CR: 1. **Add a new feature** to a Release still under development 2. **Correct / clarify / enhance** an existing feature in a Release still under development 3. **Correct an error** in a spec which is functionally frozen ## CR Development and Approval ### Submission Process 1. **WG Level**: Any 3GPP member organization can propose a CR to the Working Group responsible for the spec 2. **WG Agreement**: WG discusses and agrees CR is valid and required 3. **TSG Approval**: WG presents CR to parent TSG plenary for final approval 4. **MCC Incorporation**: After TSG approval, 3GPP Support Team (MCC) incorporates CR into new spec version ### CR Status Meanings | 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) | ## CR Number Format ```text *_CR*<4-character_CR_number>*[r**] ``` **Components:** - ``: 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**]`: Lowercase 'r' + revision number (only for revised CRs) - ``: Release identifier (Rel-4, Rel-5, etc.) **Examples:** - Initial: `31.102_0095` - CR 0095 to spec 31.102 - First revision: `31.102_0095_r1` - Revision 1 of spec 31.102 - Mirror CR: `31.103_0095` - Mirrored CR to spec 31.103 ## CR Database ### Netovate Search Tool 3GPP has an agreement with Netovate to provide a free CR database search: - **URL**: - **Access**: Free web-based search tool - **Features**: Search by spec number, CR number, or status ### 3GPP CR Database Available on 3GPP FTP: - **Directory**: `/ftp/Information/Databases/Change_Request/` - **Format**: MS Access™ (.mdb) database - **Access**: Direct download or via portal ### CR Status Tracking Each spec maintains a history box listing all CRs that have been approved for that specification. ## Step-by-Step Instructions 3GPP provides detailed step-by-step instructions for writing CRs: - **URL**: **Key Sections:** 01. Header (meeting details, WG document number) 02. Spec number, CR number 03. CR revision number (for revised CRs only) 04. Current version 05. Title 06. Source to WG 07. Source to TSG 08. Work item code 09. Date 10. Category 11. Release 12. Consequences if not approved 13. Clauses affected 14. Other specs affected 15. Other comments 16. CR revision history 17. Filename convention 18. Body of CR 19. Other considerations ## CR Categories CRs are classified by category to indicate their nature: - **Category F (Corrective)**: Corrective CRs, typically to earliest Release version - **Category A (Mirror)**: Mirrors of CRs to previous Release versions - **Mirror CRs require**: Same WI code per Release - **Mirror CRs are marked**: Category A in spec history ### Category Definitions | 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 | ## Important CR Concepts ### Mirror CRs For specs maintained in multiple parallel Releases: - Each Release needs its own mirror CR - Use same WI code (Work Item code) for all mirror CRs - Example: Spec 21.456 has mirror CRs in Release 4, Release 5, etc. ### Corrective Release 7 CRs Special category for early LTE (Release 7) features that need to work on both Release 4 and Release 5 specs. ### Editorial Updates 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. ## Work Items Each CR must be associated with a **Work Item (WI) code**: - Obtained from official WI list: - **Format**: 6-digit numeric code (e.g., `123456`) - **Purpose**: Justifies the new feature or modification ## CR Submission Checklist 01. [ ] Unique_ID value from Work Item 02. [ ] TDoc number of Work Item Description (WID) document 03. [ ] Name of rapporteur for TS/TR (or contact coords for TR) 04. [ ] Target date from WID (approval date) 05. [ ] Source to WG (responsible 3GPP member) 06. [ ] Source to TSG (if presented directly to TSG) 07. [ ] Work item code (from WI list) 08. [ ] Release (one only) 09. [ ] Category (TEI for technical enhancements) 10. [ ] Title (descriptive, not redundant) 11. [ ] Reason for change 12. [ ] Summary of changes 13. [ ] Consequences if not approved 14. [ ] Clauses affected (list individually) 15. [ ] Other specs affected 16. [ ] Other comments (optional) 17. [ ] Date (format: yyyy-MM-dd) 18. [ ] Release (Rel-4, Rel-5, etc.) 19. [ ] (U)SIM - ME/UE - Radio Access Network - Core Network checkboxes 20. [ ] UICC field (change to (U)SIM or ISIM) ### CR Revision History Optional field in CR document to track changes as CR passes through revisions: - Revision 1: Initial CR - Revision 2: First revision of CR - Revision 3: Subsequent revisions ### File Naming Convention **Word™ files for CRs** follow 3GPP naming: ```text **_CR*<4-character_CR_number>*[r**] ``` **Zip™ archive** containing CRs: - Word™ files (CR cover sheet + body + attachments) - Zip™ file named according to convention - Contains multiple CRs packaged together for a TSG meeting ### CR Lifecycle ```text Draft → WG Agreement → TSG Approval → MCC Incorporation → Published Spec ``` ## Change Request Workflow ### 1. Draft CR Member organization creates CR document ↓ ### 2. Submit to WG WG discusses and agrees CR is valid ↓ ### 3. WG Presents to TSG WG presents CR at TSG plenary for approval ↓ ### 4. TSG Approval TSG approves CR (becomes decision) ↓ ### 5. MCC Incorporates MCC incorporates CR into new spec version ↓ ### 6. Publish New spec version becomes available ## Common Pitfalls 1. **Multiple Releases**: One spec may be maintained in multiple Releases 2. **Parallel CRs**: Need separate CRs for each Release with same WI code 3. **Editorial Changes**: Use "dot-one" versions, not full CRs 4. **Wrong Release**: Can't use Release 6 WI code for Release 4 spec 5. **Out-of-date Specs**: Writing CR to old version that's been updated ## Best Practices 1. **Always use WI codes** from official list 2. **Check spec version** before writing CR (is it in Release 4, Release 5, or current?) 3. **Target correct Release**: Each CR should target only one Release (unless mirror CR) 4. **Use proper categories**: TEI for technical enhancements, F for correctives 5. **Mirror CR requirements**: Include mirror CRs for all affected Releases if maintaining parallel versions 6. **Document revisions**: Use CR revision history field for tracking changes 7. **Format dates correctly**: Use `yyyy-MM-DD` format ## Cross-References - `3gpp-basics` - 3GPP organization and structure - `3gpp-working-groups` - Working Group responsibility for specs - `3gpp-tdocs` - CRs as meeting documents (tdocs) - `3gpp-releases` - Understanding Release structure - `3gpp-portal-authentication` - Some CR documents may require EOL access ## Resources - 3GPP Official: - 3GPP Portal: - Step-by-step: - CR Database: /ftp/Information/Databases/Change_Request/ - WI List: - Netovate: