Change Requests - Step-by-Step

Edit the header to show the Working Group meeting details and the Tdoc number for that meeting. If the CR is revised, remember to change the Tdoc number on the revised version. For revised CRs, it is useful to include a line below the header indicating the previous Tdoc number e.g. "revision of S3-129786".

Include the TS or TR number only, with no preceding "TS" or "TR". Remember to include any leading zeros in part numbers, where appropriate.

Obtain a CR number from the 3GPP portal. Include leading zeros so that the CR number has four characters. Do not prefix the number with "CR"

This field should originally contain a hyphen, signifying "revision zero". If the CR is revised subsequently to allocation of a formal CR number, this field should be incremented to show the revision. That is, the first revision (i.e. second version) of the CR should show "1" in this field, and so on. 

This shows the version of the underlying TS or TR to which the CR is written. Ensure that this is the latest version (i.e. the version including all previously agreed CRs) in the Release in question. Remember that you need to produce an independent CR for each Release of the Spec you wish to modify. Under some circumstances (see general considerations below), the CR may actually be implemented to a later version than the one you indicate here. Always use numeric values for the version number fields. That is, if the current version number were 11.14.1, enter "11.14.1" and not "b.e.1" - the alphabetic extension is used only in the Spec's filename since only three characters are used for the whole, three field, version number in that context.

One or more of these field should be ticked (by entering an X) to indicate the area of relevance of the CR and its underlying Spec. Use the UICC field to indicate a change to the (U)SIM or ISIM application.

A descriptive title for the CR. Do not include redundant wording such as "Change Request to 3GPP TS 21.456 Release 4 version 4.19.0". Use the same title on all mirror CRs as used on the original CR, even if the text being changed is not quite identical in all cases.

The organization (3GPP Individual Member) responsible for drafting the CR. (May additionally include coordinates of the author for ease of contact in case of query). Where the CR is formally supported by two or more organizations, all should be shown.

Where the CR has been agreed by the Working Group responsible for the Spec concerned, enter the identity of that WG. In the expectation that the CR will indeed be agreed, you should fill this field in when initially submitting the CR to the WG.

Where the CR has not been agreed by the WG but is brought directly by an Individual Member to the TSG, the details should be as described above for "source to WG". This case is exceptional since the normal method of working is to get the CR agreed at WG level first.

When a CR which has already been agreed at working group level and is being presented for approval at TSG level is modified to cater for changes proposed during discussions at the TSG meeting, the "Source to WG" field shall remain unchanged. That is, it will still identify the organization(s) which proposed it at WG level even those this revision of the CR has never been addressed at WG level.

The "Source to TSG" field shall be changed to reflect the actual state of the modified document. That is, it shall be modified from the Working Group name to an appropriate source such as:

• the identity of the TSG debating the matter; or
• the identity of the organization(s) proposing the revised version; or
• text such as "WG Chairman" or "WG Secretary", depending on the precise nature of the author and the author’s authority.

In addition, the following points are worth emphasizing for revisions of CRs:

• the date shown in the date field shall be changed to reflect the date the revised version was produced ;
• the header showing the original meeting and WG document number shall be preserved, but the document identity shall be modified by placing the text "revision of" before the original WG document header, and unless there is an overall cover page to the TSG document separate from the component CR(s), a header appropriate to the TSG meeting shall be inserted at the top of the page ;
• the revision number of the CR shall be incremented.

any other changes implied by the nature of the revisions shall be reflected in the revised cover sheet.

Each CR must be justified by associating it with a work item, as used in the Work Plan. A full list of available WI codes is available. Use only codes taken from this list!

In the case of mirror CRs, you must use the same work item code for each Release’s CR. This will be the code pertaining the real reason for the change. The WI code chosen must have been valid at the time the earliest Release concerned was being drafted. That is, you cannot use a Release 6 work item code to introduce a change to a Release 4 spec!

Only use "TEI" (Technical Enhancement or Improvement) as a last resort. See the page on Work Items for more information on WI codes.

The "Source to TSG" field shall be changed to reflect the actual state of the modified document. That is, it shall be modified from the Working Group name to an appropriate source such as:

• the identity of the TSG debating the matter; or
• the identity of the organization(s) proposing the revised version; or
• text such as "WG Chairman" or "WG Secretary", depending on the precise nature of the author and the author’s authority.

In addition, the following points are worth emphasizing for revisions of CRs:

• the date shown in the date field shall be changed to reflect the date the revised version was produced ;
• the header showing the original meeting and WG document number shall be preserved, but the document identity shall be modified by placing the text "revision of" before the original WG document header, and unless there is an overall cover page to the TSG document separate from the component CR(s), a header appropriate to the TSG meeting shall be inserted at the top of the page ;
• the revision number of the CR shall be incremented.

any other changes implied by the nature of the revisions shall be reflected in the revised cover sheet.

The date on which the CR is written. Remember to change this field if the CR is revised. You must render the date in the format: yyyy-MM-dd that is, using the order year, month, day, using the hyphen character as a separator, and a four-digit year. Use leading zeros for month and day values less than ten. Other formats may not be correctly interpreted by the tool used to parse CR cover sheets to create their database records.

The categories are explained in TR 21.900 and on the cover sheet itself. For a CR to be considered a "mirror" of a CR to a previous Release version of the same Spec, it is not necessary that the revised text be identical to the original, merely that the intention of the change be the same. This reflects the fact that the passage of text in question may already have been subject to change in the later Release, and therefore identical changes cannot be wrought.

Indicate one (and only one) Release to which the CR applies. Remember that where a Spec is maintained in several parallel Releases, each needs a separate CR. Do not assume that the text of one Release version is the same as in another Release; write each CR from first principles, extracting the text from the correct base Spec.

The format for the text to be used is: Rel-4 or Rel-5 or Rel-6, etc. Use only these codes. Note that early Releases are "closed" - that is, no further CRs to Specs of those Releases will be entertained.

If a CR adds functionality for a new Release, and the Spec in question does not yet exist in that Release, enter the new Release but use as the "current version" the latest version in the previous Release. For example, a Release 11 CR to a spec which has no Release 11 version but which does exist at Release 10 (at, say, version 10.4.0) would show "Rel-11" in the Release field and "10.4.0" in the "current version" field.

Free text explanation of why the change is necessary.

Brief summary!

Free text describing the consequences of not approving the CR - for example, incompatibility between terminal and radio access network operation.

List all clauses / subclauses affected by the change. List each individual subclause: for example, if the CR affects clauses 6.1, 6.2, and 6.3, list these individually, do not write simply clause 6.

If the opportunity is taken to do minor editorial corrections to the Spec, the clauses affected should also be listed and the changes be indicated by revision marks in the usual way. The introduction of editorial changes on the back of a technical change is deprecated: it is preferable to provide a stand-alone CR (Cat D) for this purpose.

At Working Group level, name the Word™ file according to the conventions laid down in the 3GPP Working Procedures, but you may include extension text describing its nature. The Zip™ file into which the .doc file is packaged must be named simply as the TDoc number, that is, structured according to 3GPP Working Procedures with no extension text.

When presented to the appropriate TSG for approval, Word™ files containing CRs are to be named as follows:

where:

• <specnumber_no_dot> is the identity of the TS or TR to which the CR applies, with the dot following the series part omitted (eg for TR 21.900, this field would be "21900")
• <4-character_CR_number> is the CR number padded with leading zeros if necessary to yield four characters (eg "0012")
• <revision_number> is included only when the file contains a revised CR; the revision number is a single digit (very rarely, two digits) and is separated from the four-digit CR number by a lower case "r"
• <release> is the Release identity in the usual format (eg R99, Rel-4, Rel-5)
• <WG_tdoc_number> is the TDoc identity under which the CR was previously agreed at working group level
• <free_text> is an optional field included at the discretion of the author, and can be used, for example, to give an abbreviated title

Square brackets indicate optional fields. Text in this font indicates characters which are to be rendered literally. The file type for CRs is discussed in the 3GPP drafting rules, TR 21.801, annex H §H.5.

Note that the field <WG_tdoc_number> (and its preceding underscore) are to be omitted if the CR has not previously been presented to the responsible working group. Note in particular that this field shall be omitted if the CR is modified from that agreed by the WG (eg if it is revised by email agreement following the WG meeting, or if it is revised as a result of discussion during the TSG plenary itself).

It is usual to package several related CRs in the same TDoc to the plenary TSG meeting, and the above convention helps quickly identify the relevant file for a given CR. The Zip™ file into which the CR .doc files are packaged must bear a cover sheet listing the included CRs. The Zip™ file itself is to be named according to the conventions laid down in the 3GPP Working Procedures.

A CR pertains to one and only one underlying document. If a given Spec exists in several Releases, each must be maintained separately. If the modification you are proposing applies to all currently maintained Release versions, you must produce a CR to each of those Specs. By convention, a CR which is corrective in nature is applied to the earliest Release version to which it applies, and this CR is of category F. All subsequent Release versions have "mirror CRs" which are marked category A. Generally, a TSG will approve (or reject) all such CRs at the same time.

Sometimes a CR will actually be implemented on a version other than the one indicated in the CR cover sheet. This happens under any of the following circumstances:

• when the CR has accidentally been written to an out of date version. This situation should be avoided by checking the current status list before downloading the Spec on which you write the CR. The responsible TSG will seldom approve a CR written to an old version, and will insist that it is re-written to the latest available version.
• When an editorial update has been made to the Spec (by MCC), producing a "dot-one" version (i.e. an increment in the editorial field of the version). Since the modification is purely editorial, any CR written to the unmodified version can still be easily implemented.
• when several CRs are written to a given (latest) version and one or more of them upgrade the Spec to a later Release. Consider a corrective Release 7 CR being written to (say) version 7.2.0 of a Spec. At the same time, other CRs are written (to the same version) to include Release 8 functionality. All are approved. Rather than implement the Release 8 CRs to version 7.2.0 to generate version 8.0.0, it is conventional that the corrective Release 7 CR is first implemented on 7.2.0 to produce 7.3.0. Then version 7.3.0 is used as the basis for the implementing the Release 8 CRs to produce 8.0.0.

Remember, the more accurate a Change Request is, the more likely it is to be approved, and the less likely the MCC Project Manager is to misinterpret it!