Spec
download
| Titles and spec
numbers | Current
version | Releases
| Numbering
scheme |
Change Requests
Published
specifications |
Historical
information |
Work
plan
| TSG
Working methods | Drafting
rules | Delegates
corner|
ASN.1
This page gives detailed instructions on how to create a Change Request. Each field of the CR form is described, and then some general considerations are given. This information supplements that shown on the CR cover sheet itself.
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.
Obtain a CR number from the MCC Project Manager. Include leading zeros so that the CR number has four characters. CR numbers for some old GSM specifications have a leading letter A followed by four digits.
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). 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.
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.
A descriptive title for the CR. Do not include redundant wording such as "Change Request to 3GPP TS 21.456 version 3.4.0". Use the same title on all mirror CRs as used on the original (category F) CR.
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.
Note on source fields:
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
In addition, the following points are worth emphasizing:
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 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.
The date the CR is written. Remember to change this field if the CR is revised. You must render the date in a format recognizable by British English language Microsoft applications. The recommended format is:
dd/mm/yyyy
that is, using the order day - month - year, using the slash character as a separator, and a four-digit year. 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.
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: R99 or Rel-4 or Rel-5 or Rel-6, etc. Use only these codes.
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. (If the opportunity is taken to do minor editorial corrections to the Spec, the clauses affected need not be listed; the changes should, however, be indicated by revision marks in the usual way.)
Mark with an X the relevant boxes and give the Spec numbers of the associated Specs. For example, a change to a terminal Spec may have a concomitant change to a core network Spec. A change to a basic requirements Spec may well result in a change to the associated conformance test Spec.
It is normally expected that CRs to those affected Specs will also be offered at the same time, so that the complete set of specifications is kept in step.
Fee text.
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:
<specnumber_no_dot>_CR<4-character_CR_number>_(<release>)[_<WG_tdoc_number>].doc
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")
<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
Note that the <WG_tdoc_number> field (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 (no extension text).
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 the CR pertains to a Spec for which two or more TSGs
are jointly responsible
Under these rare circumstances, it is possible that (say) GERAN approves
some CRs to version (say) 7.7.0 of a Spec and immediately afterwards, CT
also approves some other CRs to the same version. (The responsible WGs
of GERAN and CT have worked in parallel on their independent CRs, basing
their work on the latest available version, say 7.7.0.) When GERAN
approves its WG's CRs, they are implemented and version 7.8.0 is produced.
Shortly afterwards, CT approves its WG's CRs, but
those are implemented not on 7.7.0 (to which they were written) but on the
newly available 7.8.0, which includes the GERAN CRs. When the CT CRs
are incorporated, the result is version 7.9.0.
This situation is increasingly rare.
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!
last updated:
2008-03-20: Figures updated
2007-12-12: Figures updated. Clarification of text relating to source fields (see SA#38, SP-070779 and associated discussion).
2007-04-31: Figures updated.
2006-10-03: New text to cater for splitting source into TSG and WG source fields.
2006-09-07: Text on filename conventions added; sundry minor text corrections and clarifications under "other considerations".
2006-06-12: Charts updated
2006-01-17: Charts updated; instructions updated
2005-07-20: Charts updated
2005-04-28: Charts updated
2005-03-21: Charts updated
2005-01-19: Charts updated
2004-11-03: CR error rate chart updated
2004-08-02: Charts updated
2004-04-14: Charts updated
2004-01-27: CR implementation workload and error charts added
2003-07-02: minor corrections and improvements
2002-05-15: original issue