SPECIAL
`MOBILE
`GROUP
`
`Source: ETSI PT SMG
`
`procedures
`
`GSM/UMTS 01.00
`
`March 1998
`
`Version 5.2.0
`
`Reference: SMG working
`
`Working Procedures for SMG and PT SMG;
`Part 1;
`Standards Management
`
`European Telecommunications Standards Institute
`PT SMG
`Postal address: 06921 Sophia Antipolis Cedex - FRANCE
`Office address: Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
`
`Tel.: +33 4 92 94 43 22 - Fax: +33 4 93 65 28 17
`
` ETSI PT SMG 1998.
`No rights reserved.
`Any part may be reproduced except as prohibited by written proscription. The rights for reproduction extend to all media
`in which the information may be embodied.
`
`Microsoft Corporation
`
`Exhibit 1030-00001
`
`

`

`Page 2
`GSM/UMTS 01.00 version 5.2.0: March 1998
`
`Whilst some care has been taken in the preparation and publication of this document, errors in content,
`typographical or otherwise, may occur. If you have comments concerning its accuracy, please write or phone to
`ETSI PT SMG at the address shown on the title page.
`
`Microsoft Corporation
`
`Exhibit 1030-00002
`
`

`

`Page 3
`GSM/UMTS 01.00 version 5.2.0: March 1998
`
`Contents
`
`Introduction ...................................................................................................................................................................5
`
`1 Scope ..........................................................................................................................................................................5
`
`2 Definitions and Abbreviations....................................................................................................................................5
`
`3 General responsibilities of PT SMG ..........................................................................................................................5
`
`4 Development cycle of a GSM or UMTS Technical Specification .............................................................................5
`4.1 GSM specific aspects ...................................................................................................................................5
`4.2 Specification handling both applicable to UMTS and GSM........................................................................7
`4.2.1 Introduction of a new Technical Specification .........................................................................................7
`4.2 Version numbering.......................................................................................................................................7
`4.2.1 General ....................................................................................................................................7
`4.2.2 Numbering system and significance of digits ..........................................................................7
`4.2.3 Responsibility for incrementing version numbers....................................................................8
`4.3 Handling of changes to approved Technical Specifications ........................................................................8
`4.3.1 Change Requests ......................................................................................................................8
`4.3.2 Change Request forms .............................................................................................................8
`4.3.3 Contents of Change Requests...................................................................................................9
`4.3.4 Handling of the Change Requests ............................................................................................9
`4.3.4.1 In the STC responsible for the TS ..................................................................9
`4.3.4.2 In the TC ......................................................................................................10
`4.4 Updating and release of new versions of the specifications.......................................................................11
`4.4.1 New TS ......................................................................................................................................
`4.4.2 Draft preliminary ETS (Draft prETS) for PE.........................................................................11
`4.4.3 Final draft preliminary ETS (Final draft prETS) for Vote .....................................................11
`4.4.4 ETS for Publication................................................................................................................12
`4.4.5 Draft preliminary ETS (Draft prETS) for UAP......................................................................12
`4.4.6 Draft Amendment for UAP....................................................................................................12
`4.5 Availability and distribution of UMTS and GSM specifications...............................................................12
`4.5.1 Hard copies of specifications (paper form) ............................................................................12
`4.5.2 Soft copies of specifications (electronic form).......................................................................13
`
`5 GSM Phase 2+..........................................................................................................................................................13
`5.1 Creation of a Work Item ............................................................................................................................13
`5.2 Type of Work Items ...................................................................................................................................14
`5.3 Start and continuation of the work and responsibilities .............................................................................14
`5.4 Realisation of Work Items .........................................................................................................................14
`5.4.1 Planning and categorisation of the deliverables (and control thereof)...................................14
`5.4.2 Choice of deliverables............................................................................................................15
`5.4.2.1 Completely new specification.......................................................................15
`5.4.2.2 Amendments to existing specifications ........................................................15
`5.4.2.3 Delta Specifications ......................................................................................15
`5.4.3 Contents of deliverables.........................................................................................................15
`5.4.3.1 Service Requirements ...................................................................................15
`5.4.3.2 Technical realisation specifications ..............................................................16
`5.4.3.3 Mobile Station Test Specifications:..............................................................16
`5.4.3.4 Base Station Test Specifications:..................................................................16
`5.5 Closing of Work Items...............................................................................................................................16
`
`6 Management documents and tools ...........................................................................................................................16
`6.1 Status List(s) ..............................................................................................................................................16
`6.2 GSM Phase 2+ Status List (Advancement control document)...................................................................17
`6.3 Change Request data bases ........................................................................................................................17
`
`Microsoft Corporation
`
`Exhibit 1030-00003
`
`

`

`Page 4
`GSM/UMTS 01.00 version 5.2.0: March 1998
`6.4 Mailing lists data bases...............................................................................................................................17
`6.5 Electronic tools used/preferred...................................................................................................................17
`
`7 Interaction with ETSI Work Programme..................................................................................................................17
`
`Annex 1 Status List (extract) .......................................................................................................................................22
`
`Annex 3 Specification cover sheets.............................................................................................................................26
`
`Annex 4 CR forms.......................................................................................................................................................33
`
`Annex 4 Phase 2+ Work Item description sheet..........................................................................................................39
`
`Annex 5 ETSI Work Programme work item sheets ....................................................................................................41
`
`History .........................................................................................................................................................................44
`
`Microsoft Corporation
`
`Exhibit 1030-00004
`
`

`

`Page 5
`GSM/UMTS 01.00 version 5.2.0: March 1998
`Introduction
`In order to ensure correctness of the UMTS and GSM technical specifications, ETSs and ETRs, and consistency
`throughout the standard it is necessary to have clear, manageable and efficient mechanisms to handle version
`control, change control, document updating, distribution and management.
`Also, the fact that the GSM specifications are implemented by industry almost in parallel with the writing of
`them requires strict and fast procedures for handling of changes to the specifications.
`The GSM Phase 1 standard is considered as completed although there is an occasional need to correct the
`specifications, but then mainly related to the Type Approval related specifications.
`The Phase 2 standard is icompleted as well, and only corrections will be made in future to the Phase 2
`specifications, once they have reached ETS/ETR status.
`The first Phase 2+ specifications were created at SMG#16. They will continue to be updated with the evolution
`of Phase 2+.
`It is very important that the changes that are brought into the standard, in the past, at present and in the future,
`are well documented and controlled, so that technical consistency and backwards traceability are ensured.
`For the UMTS and GSM standard, the STCs together with PT SMG are responsible for the technical content and
`consistency of the specifications whilst PT SMG alone is responsible for the proper management of the entire
`GSM/SMG documentation, including specifications, meeting documents, administrative information and
`information exchange with other bodies inside and outside of ETSI.
`This document is primarily targeted to new members of the 'SMG community', be it PT SMG members
`or (S)TC delegates, to assist them in quickly acquiring an understanding of the various 'rules and
`procedures' applied in SMG and its STCs. But also, the document should serve as a reference for a all the
`involved people, making sure that the organisational and administrative part of the standardisation work
`is well understood and similarly applied throughout all the working groups.
`1
`Scope
`This document outlines the procedures and rules [to be] used by TC SMG and PT SMG in relation to document
`management, i.e. handling of specifications, updating procedures, CR procedures, version control mechanisms,
`specifications status information, mailing lists, etc. It complements the 'ETSI rule book'. This document does not
`stipulate the details of the internal working of the STCs. From TC SMG's point of view, a task and responsibility
`is given to an STC (or a Task Force) directly answering to the TC. In practice, the work/task may be carried out
`in a subgroup of the STC/TF.
`Some parts of the document are relevant for PT SMG only.
`The body text of the document is as brief as possible.
`2
`Definitions and Abbreviations
`In this document, the generic term Technical Specification (TS), or simply Specification, is used for both types
`of normal GSM deliverables, i.e. Technical Specifications (TS) and Technical Reports (TR). A distinction
`between the two is done only where relevant.
`SMG is supported by the project team(s) for GSM and by the project team(s) for UMTS. The ETSI numbers of
`project teams may change in time, therefore they are not used here. When no confusion arises, the term PT SMG
`addresses any of them. When a disctinction is to be made, the terms PT GSM and PT UMTS are used.
`
`General responsibilities of PT SMG
`3
`PT SMG is responsible for the project management of SMG. This includes editorship and management of
`specifications once they have been approved by SMG. It also includes preparation of and support for the
`meetings of SMG and its sug-groups, in descending priority
`TC > STC > {STC WP/ Task Force} > {other group, e.g. ad hoc group}.
`It furthermore includes liaison to other standardisation bodies and relevant groups and institutions, in particular
`ITU groups in case of UMTS
`
` GSM MoU groups in case of GSM
` T1P1 in case of GSM.
`4
`Development cycle of a GSM or UMTS Technical Specification
`This section describes the general procedures and events involved in, and related to, the lifetime of a GSM or
`UMTS specification.
`Definitions
`Specification, major version, platform, version: The GSM standard (the UMTS standard) consists of
`specifications. One specification may have several major versions. One major version may have several
`versions. One or more specifications, each in a defined major version, can be linked to build a platform.
`Example: The specification GSM 05.05 has major versions 3, 4, 5. Version 3.1.0 is a version of GSM 05.05.
`
`GSM specific aspects
`4.1
`GSM specifications will be further developed in packages.
`
`Microsoft Corporation
`
`Exhibit 1030-00005
`
`

`

`Page 6
`GSM/UMTS 01.00 version 5.2.0: March 1998
`
` For the time being, there is one package every year, the core specifications to be frozen typically in the last
`SMG plenary meeting of the year, the testing specifications and operations & maintenance specifications to
`be frozen 2 SMG plenary meetings later.
` The specifications of a frozen package identify clearly
` which functions belong to the package, i.e. are completely specified in the package (so that they are
`can be implemented), and
` which requirements are applicable in the package (both to mobile and network).
`
`These are called the functions and requirements of the package.
` As soon as possible, specifications are re-organised such that any new version of a specification contains the
`complete specification of all earlier phase2/2+ packages. This is achieved by provision of "hooks" in the core
`specifications and by identifying in GSM 10.01 the functions and requirements of each frozen package.
` From that time on, a new package is simply frozen by approval of the new version of the "master tables".
`Creation of a major version of a specification is decided by SMG. A major version of a specification may have
`one of the following status:
`(1)
`pre-stable draftVersion
`(2)
`pre-stable, under change control
`(3)
`stable
`(4)
`frozen
`(5)
`closed.
`
`“draft x.y of Vn.0.0”
`Vx.y.z
`Vx.y.z
`Vx.y.z
`Vx.y.z
`
`Transitions from one status to the other are top down. When a major version of a specification reaches status (2),
`(3), (4) or (5), all lower major versions of that specification should be frozen or closed.
`Actions within one status:
`(1) out of scope of this paper
`(2) any change requests
`(3) change requests for correction, clarification, editorial CRs, introduction of new options as defined in section
`6; in justified cases, introduction of new requirements from a certain date on.
`(4) essential error corrections
`(5) no CRs possible.
`A specification in status (2) stays under change control of the STC as long as SMG doesn’t decide otherwise.
`This means: Application of the whole Change Request regime, but the STC approving the CR. The status to be
`under change control of the STC has to be clearly identified in the specification. All STC approved CRs are
`available on the ETSI server and SMG CD-ROM.
`Specifications with status (1) and (2) are not published by ETSI. They are however available to SMG experts, on
`the ETSI server and the SMG CD-ROM. Specifications with status (3) are published by ETSI on decision of
`SMG and ETSI. Specifications with status (4) and (5) are published by ETSI unless otherwise decided by SMG
`and ETSI. The status as a published specification has to be clearly identified in the specification.
`
`The life cycle of a new Phase 2+ GSM Technical Specification, which is described in detail in the following
`sections, can be summarised as follows:
`
`Identification of the need for a [new] specification,
`1.
`2. Allocation of specification number (i.e. GSM xx.xx),
`3. Development of the draft specification(s) in the STCs and Working Groups,
`4. Decision of the responsible STC to put the draft specification under STC Change Control (it thereby
`becomes version 5.0.0 but remains under STC change control),
`5. Further development of the specification under STC change control.
`6. Approval of a possibly later version of the specification by SMG, typically on proposal of the STC.
`7. Publication of the approved specification by ETSI in the deliverable type decided by SMG,
`8.
`Initiation of SMG Change Control. Publication of the resulting specification by ETSI in the deliverable type
`decided by SMG
`9. On decision of the responsible STC, a new draft major version is created (it becomes version “Draft 1.0 of
`version 6.0.0”.
`10. Decision of the responsible STC to put the new draft major version under STC Change Control
`11. etc. as in 5.,6.,7.,8.
`
`SMG may decide to change the ETSI deliverable type of a specificaiton(then it may have to undergo the Public
`Enquiry/Voting procedures or the OAP procedure).
`
`Microsoft Corporation
`
`Exhibit 1030-00006
`
`

`

`Page 7
`GSM/UMTS 01.00 version 5.2.0: March 1998
`A phase 2+ specification (with version 5.0.0) may also be created by approval of a phase 2+ CR to a phase 2
`specification. The further life cycle of the phase 2+ specification is as described above.
`Evidently, each of the above steps includes a number of sub-steps and procedures (formal as well as non-
`formal). These are described in the rest of this document.
`4.2
`Specification handling both applicable to UMTS and GSM
`4.2.1
`Introduction of a new Technical Specification
`The decision to modify the list of Technical Specifications (by creation or deletion) can be done only in TC
`SMG. The need for a new Technical Specification can be identified by the experts in the STCs, by PT SMG or
`directly in TC SMG. It may be the product of a plain new work item or a complement to existing specifications
`(gap-filler or restructuration). PT SMG assigns a number (xx.xx) to the proposed specification. For a new
`specification, the proposal should contain:
`title/subject
`
`the (prime) responsible STC or task force
`
`the rapporteur(s)
`
`the corresponding phase 2+ work item(s) (see clause 5.1)
`
`a (preliminary) scope.
`
`
`The responsible STC presents the proposal to create the specification to TC SMG for approval.
`The (prime) responsible STC Task Force is then responsible for the internal consistency of the document, for the
`consistency with other documents under the responsibility of the group and to the extent possible also for the
`consistency with documents of the other STCs. The choice of responsible STC/TF is made by TC SMG, and is
`not necessarily the group issuing the proposal in the first place.
`Once the concept is approved and the above is accomplished, the work on the Technical Specification
`commences/continues within the STC. The editor/rapporteur is responsible for the TS, but all STC members are
`expected to contribute to the work.
`At a later stage, at TC approval at the latest, PT SMG takes over the editor ship and documentation
`responsibility of the Technical Specification, but the rapporteur stays on (or is replaced by a new one) as co-
`editor and technical responsible.
`4.2
`Version numbering
`4.2.1
`General
`To keep track of the progress of the work, version numbers are used [within TC SMG] that indicate the status of
`standard development and thus serve as i) a reference for industry and operators in system supply and ii) a
`document management and control tool.
`4.2.2
`Numbering system and significance of digits
`A three numbers version numbering system is used where each number represents a certain stage in the
`preparation of the document or the degree of difference to other previous versions of the document:
`First number:
`
`0.x.y
`1.x.y
`2.x.y
`3.x.y
`3.x.y
`4.x.y
`5.x.y
`
`First thoughts, skeleton of the future standard (-60 % complete) (Note 1).
`Preliminary draft within STC (30-80 % complete). (Note 1, 3)
`Final draft within STC (70- % complete). (Note 2, 3)
`UMTS Specification under STC change control.
`TC SMG Approved GSM Phase 1 Specification.
`TC SMG Approved (Phase 2).
`Under STC change control or SMG approved(Phase 2+). The specification has a clear
`identification whether it is SMG approved or not and whether and how it is published by ETSI.
`Draft x.y of 6.0.0: Draft of new major version of a specification for which a major version 5 exists.
`6.x.y
`Under STC change control or SMG approved(Phase 2+). The specification has a clear
`identification whether it is SMG approved or not and whether and how it is published by ETSI.
`
`Note 1:
`
`Note 2:
`
`TC SMG should be presented version 1.0.0 for information, and possible comments and
`further guidance.
`
`When the STC consider the version 1.x.y as ready for TC SMG approval, they request PT
`SMG to raise the version to 2.0.0. If SMG approves the specification immediately, the
`version is raised to 3.0.0 (UMTS) or 3.0.0 (GSM phase 1) or 4.0.0 (GSM Phase 2) or 5.0.0
`(GSM Phase 2+). Hence, in some cases versions 1.x.y, 2.0.0 and 3/4/5.0.0 might actually
`be the same document (but with different status). At the time being, new GSM Phase 1 or
`Phase 2 specifications are no more created. Normally, the STC will put a specification
`
`Microsoft Corporation
`
`Exhibit 1030-00007
`
`

`

`Page 8
`GSM/UMTS 01.00 version 5.2.0: March 1998
`under STC change control (so that it has already major version 5 before presentation for
`SMG approval)
`
`Note 3:
`
`Versions starting with 0, 1 and 2 are updated within the STC by the rapporteur assisted by
`PT SMG without any formal approval of the changes at TC level and without any formal
`Change Request procedures being used.
`
`Second and Third number:
`The second and third number are used to indicate revisions, updates, corrections and new releases of
`the specification. Their usage has the same significance within each first number range. The third
`number is incremented when editorial only changes have been incorporated in the specification.
`The second number is incremented for all other types of changes, i.e. technical enhancements,
`corrections, updates, etc.
`If the second number is incremented, the third number is set to '0'. Likewise, if the first number is
`incremented, the second and third ones are set to '0'.
`A change of second number can only result from modifications agreed in the STC (or TC) whilst the
`third number could result from modifications done by PT SMG or the rapporteur outside the STC.
`Responsibility for incrementing version numbers
`4.2.3
`For version numbers starting on 0, 1 and 2 and staying in that range, the STC is responsible for the updating of
`the first and second number (hence no substantial changes to the document should be done without STC
`agreement). PT SMG is responsible for keeping track of the version numbers and to give guidance to the
`rapporteur(s) and the STC.
`The transition from version 2.x.y to 3.0.0 or 4.0.0 or 5.0.0 or 6.0.0 is decided by SMG, on recommendations
`from the responsible STC. For TC approved specifications (i.e. versions 3.x.y, 4.x.y, and 5.x.y), SMG is
`responsible for allocating new version numbers when needed. In practice, PT SMG allocates new version
`numbers simultaneously to the approval of Change Requests/Amendment Requests (see clause 4.3.4.2),
`according to the formula outlined in clause 4.2.2 above. These new version numbers are normally announced,
`via a document from PT SMG, towards the end of that very same meeting at which the CRs were approved.
`Also, in addition to information on those specifications that have been subject to changes during an SMG
`meeting, PT SMG also documents at every SMG meeting the status of approved specifications, this status
`containing among other things all the necessary information about the present version numbers plus some recent
`history (appr. 2 years) for each Technical Specification (see clause 6.1 and Annex 1).
`4.3
`Handling of changes to approved Technical Specifications
`Modifications to specifications with version number 3.0.0 or higher can only be decided by SMG, on the basis
`of Change Requests (CR). These CRs, described in the following sections, shall in principle be presented to the
`TC only after having been scrutinised by the STC responsible for the concerned specification.
`4.3.1
`Change Requests
`Whenever an error or an inconsistency is discovered or when a new feature is proposed to be included, a Change
`Request is produced, normally by the one discovering the error but in consultation with the rapporteur and/or
`with PT SMG.
`4.3.2
`Change Request forms
`To ensure an appropriate and consistent way of presenting and documenting Change Requests, there exist
`standardised front covers (forms) for CRs as well as rules on how to accurately identify the modified parts of the
`specification.
`The purpose of the CR form itself is to provide the relevant management information of the proposed changes,
`e.g. such as
`
`
`
`
`
`Target specification with its version number,
`Source of the CR,
`Reason for the proposed change and consequences if not accepted,
`Category of proposed change (i.e. correction, change request corresponding to an earlier phase
`change request, addition of feature, functional modification of feature, or editorial modification),
`Cross-phase compatibility aspects.
`
`
`
`As the degree of acceptability for modifications differs between Phase 1, Phase 2, and Phase 2+, the CRs differ
`on the allowed/possible Categories: Phase 1 CRs, Phase 2 CRs, and CRs to a specification belonging to a frozen
`package can only be essential corrections whilst Phase 2+ CRs to the current package can alsofall into any other
`of the categories quoted above.
`Annex 4 contains the CR form for Phase 1, 2 and 2+, and a guidance of how to fill them in. These forms and the
`way to fill them in have to be used by those proposing changes.
`
`Microsoft Corporation
`
`Exhibit 1030-00008
`
`

`

`Page 9
`GSM/UMTS 01.00 version 5.2.0: March 1998
`4.3.3
`Contents of Change Requests
`Although the CR form shall indicate the details of change, each CR shall have attached the pages of the
`specification that are affected by the CR, using the latest version approved by SMG. These pages shall have the
`proposed modifications clearly marked, by means of the wordprocessor's "revision mode", i.e. new proposed
`text should be double underlined and proposed deletions should be, and a bar in the margin.
`In case there are more than one independent CR to the same part of the specification, neither of them should
`contain the proposed modifications from the other(s), however any potential interaction between the
`modifications should of course be resolved before presentation.
`4.3.4
`Handling of the Change Requests
`4.3.4.1
`In the STC responsible for the TS
`Entry to the STC:
`A proposed CR should be brought to the relevant STC in charge of the Technical Specification concerned and
`discussed there, before presentation to SMG. If possible it should be distributed, by the source, a.s.a.p and prior
`to the coming STC meeting to at least the rapporteur (if not the source) and PT SMG but preferably to as many
`'key delegates' as possible, for the purpose of shortening discussions in STC meetings and to try at an as early
`stage as possible to come to a widely acceptable solution.
`When the relevant STC decides to submit a CR to SMG for approval, the CR is categorized as strategic or non-
`strategic by the STC chairperson in agreement with the STC.
`To ease the work of the STC and of PT SMG, a proposed CR should be presented in a form suitable for STC
`approval and direct forwarding to SMG. If a CR is not immediately accepted it is the responsibility of the
`originator to update the CR taking into account comments and other guidelines from the STC, including change
`of reference version if needed, and to re-present it to the STC.
`Note:
`It is also highly important that the originator of the CR provides PT SMG with an
`electronic copy (Word for Windows 6.x or Word for DOS 5.x) since the contents is
`supposed to be incorporated into the specification, by PT SMG, and re-typing of CRs is
`clearly a waste of resources and a possible source of errors.
`
`CR identification:
`A CR can have different revisions: rev. 0, 1, 2, and so on. Revision 0 of a CR is the not revised CR. A given
`revision of a CR is applicable to a certain version of a specification. The CR identifies, to which specification,
`which version of the specification and which phase it applies. A given revision of a CR is uniquely defined by
`the specification it belongs to (e.g. 05.05)
`
`an alphanumeric string (the CR-number) and
`
`the revision number (default, i.e. the value if no number is given, is 0).
`
`
`Different revisions of the same CR shall not apply to versions of a specification that belong to different phases;
`they may apply to different versions of a specification in the same phase.
`Each CR is allocated an identifier by the relevant PT SMG member. A CR can have different revisions, rev.1,
`rev.2, and so on. The identifier is either a letter followed by a 3 digit number or a 3 digit number:
`CRs to phase 1 specifications (version 3.x.y) are identified by a 3 digit number, e.g.123, possibly
`
`followed by the revision.
`If a CR applies to a phase 2 or phase 2+ specification, it is identified by a letter followed by 3 digits;
`actually the letter has to be an "A". (For some phase 2+ CRs, due to historical reasons, the first letter is a
`"B".)
`
`
`
`The uniqueness is on a per specification basis, but Phase independent, i.e. CR No 001 [may] exist for each
`specification but only once (i.e. not CR No 001 for Phase 1 and CR 001 for Phase 2 for the same specification
`number). CR No A001 [may] exist for each specification but only once (e.g., not CR No A001 for Phase 2 and
`CR A001 for Phase 2+ for the same specification number).
`The complete identification of a CR including revision is given in BNF as
`CR <specification number> [ A ] <digit> <digit> <digit> [ rev. <number>]
`Example: CR 05.02-A002 rev.2.
`The CR identifier may be allocated prior, during or after the STC meeting at which it is discussed but before
`submission to SMG. Even though different STCs have different working routines it is beneficial and thus
`recommended that CR numbers are allocated no later than at STC approval.
`CR numbers are unique and shall never be reused, not even numbers used for [early] rejected CRs.
`Impact on other specifications and Joint CRs:
`If the contents of the CR is such that isolated it makes the whole set of approved Specifications inconsistent,
`corresponding CRs must also be considered and produced. This shall preferably be carried out by the originator
`of the CR (and his colleagues in other STCs) in advance. PT SMG is co-responsible for identifying and
`communicating cross-STC impacts.
`In principle, a CR shall not be forwarded to TC SMG unless the potential impact on other specifications have
`been thoroughly examined and concluded, either resulting in a 'No impact' statement or in a full and consistent
`
`Microsoft Corporation
`
`Exhibit 1030-00009
`
`

`

`Page 10
`GSM/UMTS 01.00 version 5.2.0: March 1998
`set of corresponding CRs to all affected specifications. Such set of CRs are normally combined in one single
`document, by PT SMG, before submission to SMG and called 'Joint CR' (see Annex 7.3).
`If some of the corresponding CRs are to be considered by other STCs then PT SMG is responsible for
`monitoring the result in the STCs and to submit the full set, when available, to SMG. This might mean that in
`some cases the STC approved CRs are not presented to the immediately following TC meeting due to
`outstanding CRs from other STCs.
`Other "consequential" CRs, needed for reasons