Chapter 20: Working Methods Ansgar Bergmann 1 SMG 2 has always treated its working methods using a pragmatic approach. Working methods were discussed and agreed when problems arose or in anticipation of problems, and were adapted when practical experiences were made. The fora to elaborate working methods were: † Ad-hoc groups of the SMG plenary and of working parties; † PT SMG; 3 † SMG co-ordination group; 4 † A proper subgroup on working methods, WOME, was established in March 1998 (at SMG#25). Papers on working methods were agreed and maintained since the 1980s, but a permanent document, GSM 01.00, was only approved in 1995. The working methods were agreed in SMG as a complement to the ETSI rules of procedure, which fix for example the rules for membership, elections and voting. Major areas for working methods relate to: † Ways to write specifications, in particular the usage of description techniques, for example formal description techniques; † Handling of documents; † Phased approach; † Structure of specifications; † Change Request (CR) procedures; † Work item management. 20.1 Who Uses the Specifications? The main goal of SMG/3GPP is to produce specifications. Working methods are a means to achieve this goal. In order to understand what a good specification is, it must first be under- stood who uses the specification and for what purpose. 1 The views expressed in this chapter are those of the author and do not necessarily reflect the views of his affiliation entity. 2 Throughout this chapter, ‘‘SMG’’ is used to denote the standardisation group called GSM before 1992. The working methods of SMG are, with some modifications, also applied by 3GPP. 3 In this chapter, ‘‘PT SMG’’ is used to denote the project team earlier called PN and PT12. 4 This group existed under different names. GSM and UMTS: The Creation of Global Mobile Communication Edited by Friedhelm Hillebrand Copyright q 2001 John Wiley & Sons Ltd ISBNs: 0-470-84322-5 (Hardback); 0-470-845546 (Electronic) The GSM specifications, being the definitive description of the GSM system, are used as the basis for: † Product planning: this is the process to devise new features to be introduced into the GSM system – an activity between manufacturers and operators. † Work on GSM evolution: this is mainly triggered by the needs of product planning. Other reasons for evolution are corrections and general enhancements, for example in the field of compatibility. The publicly visible part of the work is done in the specification groups; it is based on a publicly invisible part done within the companies, with much higher efforts. † Product development: for the manufacturer this means the development of the necessary hardware and software components, for the network operator the provision of necessary functions in subscriber management, network planning, but also fields like customer care, and advertising. This area is rather complex, and keeps major parts of companies busy, and many departments are engaged. † Procurement: the technical parts of contracts typically refer directly to certain versions of the specifications, stating compliance and sometimes non-compliance – and sometimes reference is even made to single CRs. For example, Release 90 of the GSM specifications was called tender list of specifications, and was planned mainly as the reference for procurement. 5 † Testing: the GSM specifications include several test specifications, for the mobile station, base station sub-system, SIM-ME interface and for codecs. For other interfaces, testing is also important, and tests are written based on the GSM specifications. For example, major parts of MAP concern the interfaces between different networks; tests for international roaming have been prepared by the GSM association and the ETSI technical body SPS. † Network planning and operation: an obvious example is given by the radio parameters, defined in the specifications, which have to be optimised during operation. † Reference for curriculum, research and development: GSM is today’s most successful mobile communications system, and the GSM specifications are a reference for education, a starting point for research and a reference model for development – nobody would today specify a mobile communications system without studying the GSM specifications. Of course, in some of the fields mentioned above, secondary literature can be used, and an expert working on one area does certainly not have to study all specifications. 20.2 Achieving High Quality Specifications As explained in the previous section, there is a surprisingly wide readership working directly with the GSM specifications. It is not possible to satisfy the needs of all readers. For example, it would be nice if specifications were always easy to understand without any prerequisites in education and knowledge. But on the other hand, specifications should not contain unnecessary parts; in particular, they should not repeat or otherwise duplicate infor- mation; also, they should be precise, correct and complete. Unfortunately, these qualities are almost opposed to the goals of easy understanding. Quality of specifications relates to: † The described system: the system has to really work and to support the intended services with good performance; efforts of implementation must be reasonable. Ideally the system GSM and UMTS: The Creation of Global Mobile Communication464 5 See TDoc GSM 223/88. is optimised for its purposes. Methods to achieve these goals are simulations, validations, field trials, and evaluations of the running system. In order to adapt to future requirements, the system must provide means for compatible evolution. This goal is mainly achieved by (abstract) analysis. † The way in which the system is described: requirements to the description relate to criteria as completeness and absence of contradictions. † The way in which the description is developed: requirements to the development of the specification mainly relate to traceability of changes. Quality of specifications is the major goal of working methods. Among the contributions discussing the issue, a document on Dimensions of Recommendation Review 6 is a good example, and its results are still up-to-date. It gives definitions of completeness, consistency and non-ambiguity as necessary qualities of GSM specifications. Completeness: TDoc 103/87 defined completeness as the property that what was targeted is to be covered in the specifications. This is a rather laconic definition, replacing the question ‘‘ what means completeness of the specifications’’ by the question ‘‘ what content of the specifications should we target at’’ . But the area is difficult, and here are some aspects that have been stressed during discussions: † Specifications should conform to a general formal presentation and should contain defini- tions of vocabulary and abbreviations, contents list, scope and references; sentences and paragraphs should be complete. † All indications of open questions and of items for further study in the specifications should be carefully checked: in a phased approach, specifications can well contain such issues, however they must be known and intended, not simply result from oblivion. † Referenced documents should be publicly available and have the necessary quality. † For the open interfaces, the actions and reactions necessary to achieve the necessary functionality must be defined. For the sake of compatible evolution, it is often beneficial if reaction to unforeseen events is defined aswell. † In a competitive environment, a full specification of functions, applications and services is not always wanted. This point of view, however, taken to the extreme, would lead to the position that the GSM specifications should be restricted to the events on open interfaces. This is too restrictive, and problems have been experienced if behaviours were specified in GSM without the corresponding stage 1 and stage 2 descriptions. Consistency: this means the absence of contradictions and the fitting-together of concepts in the different parts of the GSM specifications. Whereas there are different views on the necessary degree of completeness, it is clear that consistency must be achieved as much as possible. When a possible inconsistency has been found, there is normally no disagreement between experts whether it is a true inconsistency or not. Consistency can be improved by systematic checks of: † logical aspects † time conditions † modularisation and layering and the restriction to defined service primitives † consistent usage of terms and concepts within a specification and between different speci- fications Chapter 20: Working Methods 465 6 See TDoc GSM 103/87. † consistency with working assumptions and general decisions † usage of well-understood and proven description models and techniques (see paragraph 20.3). Non-ambiguity: this means that experts will not interpret specifications in different ways. Similar for consistency, it is clear that a maximum non-ambiguity must be achieved. However, naturally, when a possible ambiguity has been found, even experts may disagree whether it is a real ambiguity. Therefore, an in dubio contra reum should be applied: If there is a doubt whether a specification is ambiguous, this normally shows that it is. It is sometimes difficult to discover ambiguities in a text you have written yourself. Committee work helps to discover ambiguities, because many experts discuss their under- standing. Also, during the generation of test specifications, many ambiguities of a text are identified. TDoc 103/87 of GSM#15 recognizes that completeness, consistency and non-ambiguity are not sufficient to ensure that the system functions, and sketches a verification program based on specification review (walk-through process), simulations, emulations and validation in a real system environment. Validation was an issue in the following years. 7 The validation process was mainly performed within the companies; simulations and emulations were also performed by universities and research laboratories. The role of SMG was mostly restricted to monitoring and reviewing these activities. An area where SMG took a very active role in validation, characterisation and selection is the development of speech codecs. Specification review meetings were organised many times in SMG. At these meetings, rapporteurs and other interested delegates participated. This was an occasion to check the specifications, and also to elaborate more complex improvements, for example re-structuring. For bigger, complex and central specifications, several meetings of several days could be necessary during a year. 20.3 Rigorous and Formal Descriptions For achieving high quality specifications, rigorous and formal description techniques are used. 20.3.1 Rigorous Descriptions Most parts of the GSM specifications are written in ‘‘ prose’’ (as opposed to descriptions in a formal language like TTCN). To write specifications in prose in a clear way is sometimes called a rigorous description technique. A rigorous description applies rules to the language and format, which are some- times directly opposed to good English style: † A reduced vocabulary is used. For the same item, the same designation is used whenever possible. GSM and UMTS: The Creation of Global Mobile Communication466 7 GSM#13 asked the PN to elaborate a system verification program, allowing continuous validation of the GSM specifications. But WP2 commented at GSM#14 that this would mean a delay, as several administrations had already started validations. GSM#14 decided that each administration should conduct its own verifications and that a coordinating committee should be established. Cf. also TDoc GSM 51/87, TDoc GSM 107/87, TDoc GSM 96/88, TDoc GSM 222/88 and GSM#21 Report, Section 8. † The logic is clearly expressed. Care is taken to express clearly which conditions apply in conjunction or as alternatives. † Optional and mandatory features are clearly distinguished. † Defined attributes are used. This is just what should be applied in any scientific and technical document. For ETSI and other standardisation bodies, a set of rules has been agreed fixing the details. These are the Production of Norms in Europe (PNE) rules. Behaviours are described by communicating processes. These processes are modelled as (extended) finite state machines (‘‘ extended’’ means that each state may have additional parameters), or using a procedural approach or in a combination of both (in fact, they are equivalent). When possible, a layered structure is used, where each layer uses the services provided by the lower layer, and offers services to the higher layer. Using these techniques, a rigorous specification is established. For such a specification, verifications can be carried out by proving certain ‘‘ health properties’’ like pre/post-condi- tions and invariants: pre/post conditions describe changes of attributes after a transition or the execution of a procedure; invariants define properties that remain stable during a sequence of transitions or for the lifetime of a process. Care is taken to avoid deadlocks and live-locks. Exceptional events like time-outs and lower layer failure are considered. Such verifications have been performed in GSM, mostly not in meetings but by delegates as homework. Specifications having undergone such a review process typically contain very few errors and ambiguities. 20.3.2 Formal Descriptions Several specifications make use of formal description techniques. ‘‘ Formal description tech- nique’’ means here a technique that † has a defined syntax; † has defined semantics; and † can be compiled by a computer. The following formal description techniques are used in the GSM specifications: † SDL is the most popular specification language applied in telecommunications. It is defined in ITU recommendation Z.100. SDL is supported by tools that can check the syntax and simulate the described processes. There are companies using an SDL based development environment where SDL is used from design up to implementation and can be compiled into executable code. SDL is used in many parts of the GSM specifications: in MAP, in most specifications of supplementary services, in most stage 2 descriptions and in several stage 1 descriptions. Specification 04.06 of the signalling layer 2, and specification 04.08 of the layer 3 protocols Radio Resource (RR) management, Mobility Management (MM) and Call Control (CC) 8 do not use SDL descriptions. In fact they earlier contained SDL descriptions, but these have been removed at GSM#25. Instead, state-transition diagrams for MM and CC have been introduced into 04.08. The official reason to delete the SDLs in these specifications was that GSM3 couldn’t find the necessary resources for keeping them updated. However, there were also some other reasons. One is that SDL is Chapter 20: Working Methods 467 8 From Release 99 onwards, 04.08 has been split into 04.18, later 44.018, for RR and 24.008 for MM and CC. normally applied with modified semantics (and not the one defined in Z.100). Inconsis- tencies discovered by simulations often just reveal these differences of semantics. Another is that the semantics of SDL are restricted: Whereas concurrent process languages like Lotos or Milner’s CCS [1] can simulate SDL, the converse is not true. A third point is that in order to write neat SDL specifications, some auxiliary modelling is necessary which is ‘‘ artificial’’ and not relevant for the real system (SDL doesn’t have clear notions of abstraction, encapsulation and equivalence of processes). A fourth point is that for many cases, state-transition diagrams are equivalent to SDL descriptions but are much more compact. † Abstract Syntax Notation One (ASN.1) 9 is used in many GSM specifications to define the syntax of messages and operations. As the name ‘‘ Abstract Syntax Notation’’ implies, ASN.1 itself does not specify the encoding; this is done by encoding rules attached to ASN.1. The idea behind this comes from the concept of abstract data types, proposed in the scientific field, where it is required that data structures should be first designed abstractly (as so-called initial algebras) and that the coding should be developed inde- pendently. ASN.1 however does little to support this algebraic concept, and typical ASN.1 specifications tend to use mainly bit strings as data types. Different sets of encoding rules have been defined for ASN.1. The free availability of an ASN.1 compiler, at least a syntax checker, for SMG experts was discussed on several occasions, e.g. at SMG#2. Instead, rapporteurs took over these checks using tools of their companies. In other specifications, the message contents are defined in tables, showing the position of information elements and defining the meaning of the different bit combinations. The resulting coding is a byte orientated encoding, typically with indication of type, length and value part (however, for optimisation purposes, type and length indicator can be suppressed under certain condi- tions). In GSM, it became obvious that a byte orientated encoding with type and length indication is not efficient enough for the radio interface, mainly on the common control channels. Therefore, it was proposed to use a context-free syntax description, the Backus– Naur form, at least for the radio interface. The underlying grammar of each message is bit- orientated; it has to have ‘‘ nice’’ properties that make en/decoding efficient (typically, a look-ahead 1 grammar). This scheme was then elaborated to become Concrete Syntax Notation One (CSN.1) [2]. 10 This approach gives a very powerful mechanism for efficient coding. It is mainly applied in 04.08. It allows economic coding schemes taking into account the a priori probability of occurrence of values. Context free grammars are known in computer science for a long time, 11 and play a major role in compiler building, one of the best-understood techniques in computer science. A big number of generic tools are available for the Backus–Naur form; specific tools for CSN.1 are available. † Tree and Tabular Combined Notation (TTCN) 12 has been applied since phase 2 in the mobile station test specification 11.10 for the protocol related parts. The prose test speci- fications are developed first and are then translated into TTCN. The dynamic part of TTCN uses a notation for allowed sequences of observable actions that is inspired by Hoare’s CSP [3] calculus. For the data part, a tabular notation or ASN.1 can be used. Tool environments are available and are used by experts of the ETSI secretariat for checking GSM and UMTS: The Creation of Global Mobile Communication468 9 Defined in ISO/IEC 8824. 10 Cf. also GSM 04.07. 11 Even if they have been studied first in the field of linguistics by Chomsky and others. 12 Defined in ISO/IEC 9646. the syntax and static semantics. Also, software companies are developing test implemen- tations based on TTCN, and have taken rapporteurship as the main parts of the TTCN in 11.10. Between phase 1 and phase 2, the prose test descriptions have been transformed into a rigorous format that follows a structure very close to TTCN. These have then been translated into TTCN. For TTCN, PT SMG elaborated a modified CR procedure allowing a fast debugging process. During the translation of GSM tests into TTCN, the need for several improvements of TTCN were discovered, resulting from design problems of the language, relating for example to the handling of parallel processes. Hence, GSM contrib- uted to the development of TTCN. † In the area of test specifications, ICS and IXIT are applied. Implementation Conformance Statements (ICS), and Implementation Extra Information for Testing (IXIT), were first introduced for protocols. That is why acronyms ‘‘ PICS’’ and ‘‘ PIXIT’’ (‘‘ P’’ standing for ‘‘ Protocol’’ ), are more familiar terms, sometimes also used where protocols are not engaged. ICS and IXIT are declared for equipment to be submitted to conformance tests. While PICS declare which options permitted by the standard are implemented, PIXIT declares how features and functions are realised. (In 11.10, the distinction is some- times not precise.) For example, a PICS could declare that a mobile station does not implement the optional feature ‘‘ fax transparent’’ . A PIXIT statement could, e.g. explain how a service is initiated at the user interface of the mobile station. This kind of informa- tion is essential for test houses. 11.10 specifies a proforma (a kind of questionnaire) for ICS. It also classifies features as mandatory, optional or conditional and gives logical constraints for optional and conditional features. These constraints use a kind of pseudo- formal description. It has been proposed to use instead a formal description, the well- known and proven calculus of Boolean algebra; appropriate tools could be provided easily. Discussion in this area will certainly go on. † In the area of Telecommunications Management Network (TMN), the object orientated description method GDMO 13 has been applied in the 12.xy series. In 3GPP, there are tendencies to replace GDMO by CORBA, and more recently by other description tech- niques. For the usage of formal description techniques, the availability of tools seems essential. They can check syntax and static semantics and perform simulations and thereby validate the description. Also, the implementation cycle can become shorter. A drawback is that the number of experts being able to review the description is reduced. Also, the formal descrip- tion technique may be insufficient or may require artificial auxiliary modelling. Maybe it is often the best approach to use a rigorous and a formal description in parallel. A question is often raised when this is done. In the case of contradictions, does the formal or rigorous description prevail? This question is surprising, or, more exactly, it is surprising that the question is often found adequate: Contradictions are not planned. When they are discov- ered, they must be resolved, and it is not predictable where the error has crept in. This was at least the position taken by SMG, when it was decided that both the prose and TTCN descrip- tions in 11.10 are normative. Chapter 20: Working Methods 469 13 GDMO ¼ Guidelines for the definition of managed objects; see ITU X.722 (ISO 10165-4). 20.4 Handling of Documents Handling of documents, in particular electronic handling, has been a non-trivial issue for a long time. Until 1996, documents were normally not available in electronic form. For elec- tronic documents, the limitations of file names to 8 1 3 characters were cumbersome. The introduction of fully electronic document distributions at meetings required some learning and conviction processes. But with the improvements of network facilities, these problems have gone. Today, 3GPP working groups have their e-mail groups and meeting documents are maintained on the 3GPP server at ETSI. 20.5 Phased Approach At GSM#20 (October 1988), three phases of GSM activities were distinguished: 14 † Phase 1: development of the recommendations; † Phase 2: validation and consolidation of the technical aspects; † Phase 3: revisions based on pre-operational experience. The document also remarks that it can be expected that revisions will continue once commercial service commences. These phases, however, should not be confounded with the phased development and the phased implementation of GSM as expressed at GSM#25, where it was decided to create two parallel series, version 3 (phase 1) and version 4 (phase 2). 15 This phased development meant a first phase, to be implemented and operated, followed by an upgraded phase 2 with addi- tional services and improved functionalities. In order to concentrate on the introduction of phase 1, specifications were functionally frozen. 16 This means that no new functionalities should be added to phase 1, and that phase 1 changes should be restricted to necessary corrections. For example, VLSI companies commented that specifications should be stable 2 years prior to the intended 1991 Ready For Service (RFS) date. At GSM#25 it was decided that GSM#25bis (spring 1990) should be the last opportunity for changes except ones vital for operation of the system; in other words, the core specifica- tions were frozen at GSM#25bis. Then, for some time, SMG plenary refused in principle to work on phase 2 specifications until the phase 1 specifications were stable. After the stabilisation of phase 1, option pruning was an important point. This meant to delete options in the specifications, which nobody intended to implement any more. For the introduction of phase 2, compatibility was a requirement: phase 1 mobile stations should be able to work in an evolved network without loss of quality. The concept of phase 21 and the phase 21 program were approved at SMG#7 (June 1993). 17 The basic idea was to introduce new functionalities as options, in a compatible way. CRs should be approved in a complete package so that the specifications would always be complete and consistent. GSM and UMTS: The Creation of Global Mobile Communication470 14 See TDoc GSM 222/88. 15 See TDoc GSM 482/89 rev2. 16 Cf. for example TDoc GSM 222/88 and TDoc GSM 227/88 at GSM#20. 17 See TDoc SMG 475/93. Cf. also TDoc SMG 517/93. There was a fundamental problem. To elaborate complete packages of CRs required some time. As work went on for several features in parallel, there was a danger of creating contra- dicting CRs in the piles for the different features. Another danger was to elaborate ad-hoc isolated solutions for different features, and to miss common solutions. It was proposed to create working versions or shadow versionsof specifications; these could then show the current status of specifications in preparation. It was however a common feeling that the CR procedures had to be maintained. One proposed method was to elaborate, after the freezing of versions 4, a new version 5, to apply the CRs procedure for the elabora- tion of version 5, then to agree on a set of new features the specifications of which were stable, and then to re-integrate the changes into version 4. The principle would have been to maintain a version 4 as basis for implementation, but version 4 would change from time to time to incorporate new features. At the same time, a version 5 would be used for the working versions under development. There were several reasons why this scheme was not adopted. One reason was that the re- integration would have been a difficult task; another one was that mainly for mobile station type approval, the ‘‘ original’’ phase 2 had to be kept, because it had to be possible to continue mobile station type approval on its basis. The pragmatic decision was taken to freeze the version 4 specifications and to create a new version 5; this was intended to allow some time to identify a better solution later, to be applied from version 5 onwards. In the following years, two principle alternative ways ahead were identified and discussed: 1. To create new releases from time to time, for example every year. 2. To identify new description parts in the version 5 specifications with formal markers. The markers would relate the description parts to features (one or several), and a master table would indicate when a feature was stable. The issue was complex, and discussions went on for some time. It turned out that scheme (2) was too difficult, and finally solution (1) was chosen, to create a new release, that is a full set of specifications, every year. This scheme was at least simple and easy to understand, but it meant also that the amount of specifications under maintenance increased considerably; also it became soon obvious that the scheme could not be applied as such for testing and type approval. There is a principal asymmetry in the concepts of telecommunication networks, which has consequences for version management: the terminal is considered to be the slave of the network. The GSM network should know the different types of mobile stations and know how to handle them. Therefore, there should be a clear distinction between a phase 1 mobile station and a phase 2 mobile station whereas the notion of ‘‘ phase 1 network’’ or ‘‘ phase 2 network’’ does not make much sense. 18 By the way, there are approaches to change this philosophy, and to require operators to specify their access interface, so that terminals can adapt to it. Anyhow, neither networks nor mobile stations normally fully conform to one single GSM release. Chapter 20: Working Methods 471 18 This philosophy has however not really been applied in strength. For example, new phase 2 features were step- by-step implemented in phase 1 mobile stations, before phase 2 type approval had started. 20.6 Structure of Specifications There are several grouping schemes that apply to the GSM specifications. The structure is complex, mainly due to † the complexity of a fully detailed system specification; † the need of version management; and † the integration of GSM and UMTS specifications. 20.6.1 Semantic Structure The principle structure of specifications, at that time called recommendations, was estab- lished very early, also the concept of reports versus recommendations (later called specifica- tions), preliminary drafts (version 0.x), first drafts (version 1.x) and final drafts (version 2.x). 19 The structure until Release 98 was as follows: † 01 series: requirement specifications; general documents (e.g. 01.04, abbreviations and acronyms); administrative and managerial documents, (e.g. 01.00, working procedures for SMG and 01.01, list of specifications for a given release); † 02 series: stage 1 descriptions; man-machine interface of the mobile station (02.30); † 03 series: stage 2 descriptions, network functions and architecture; † 04 series: protocols of the radio interface (the interface between the mobile station and the network); † 05 series: layer 1 of the radio interface; † 06 series: speech codecs; † 07 series: data services; † 08 series: protocols of the A and Abis interface; † 09 series: protocols of the core network; † 10 series: work item management; † 11 series: test specifications for the mobile station and base station subsystem; specifica- tions of the SIM and SIM-ME interface; † 12 series: operation and maintenance; † 13 series: harmonised standards for mobile station type approval. From Release 99 onwards, specifications were re-structured due to the integration of the GSM and UMTS core network. This is described in paragraph 20.6.4. 20.6.2 Stages For complex features, typically a stage 1 specification (in the 02 series), a stage 2 specifica- tion (in the 03 series) and several stage 3 descriptions (often in the 04 series, the 08 series, the 09 series) exist in all releases containing the feature. Possibly there is also a performance specification. Other aspects including testing, AT commands, SIM ME interface, charging, GSM and UMTS: The Creation of Global Mobile Communication472 19 See for example TDoc GSM 23/86 rev.2, the GSM action plan, a living document updated periodically; also TDoc GSM 13/86 proposing some revisions to GSM 01.01, the list of GSM recommendations; also TDoc GSM 91/ 85, partially based on earlier GSM 28/84 rev 2 (not available). [...]... localization; † global roaming between GSM 900, GSM 1800, GSM 1900 and also inter-system roaming, for example with mobile satellite systems Between 1996 and 1999, yearly releases have been issued Later, in 3GPP, this was found too restrictive, and the later releases are now called Release 4, 5, etc 20.6.4 New Structure of GSM/ UMTS Specifications From Release 99 on, the GSM and UMTS core network specifications... implementations (network and mobile stations) in the first years, roughly from 1992 to 1995 Important features of phase 1 included † telephony; † some supplementary services like call forwarding; † international roaming The GSM phase 2 specifications have been the basis for GSM implementations roughly between 1995 and 1998 GSM phase 2 added mainly Figure 20.1 Phases and Releases 474 GSM and UMTS: The Creation... GSM 09.02, Mobile Application Part (MAP) specification, was turned into a 3GPP specification, common to GSM and UMTS, and became 3GPP 29.002, Mobile Application Part (MAP) The transformation is shown in Figure 20.2 Other specifications were only relevant for GSM but not for UMTS; they kept their numbers in Release 99 The next release was Release 4, as explained above From Release 4 on, the remaining GSM- only... versions of GSM specifications are described The GSM specifications are structured in phases and releases A specification has versions in different releases For example, the protocol specification of the voice group call service, Group Call Control (GCC) protocol, has versions in Release 96 and all subsequent releases (Figure 20.1) The GSM phase 1 specifications have been the basis for the GSM implementations... Data (HSCSD)) and packet data (General Packet Radio Service (GPRS)) with data rates up to 64 kbit/s and higher; † Advanced Speech Call Items (ASCI): Voice Group Call Service (VGCS), Voice Broadcast Service (VBS) and priority, officially called enhanced Multi-Level Precedence and Preemption Service (eMLPP); † quality and capacity enhancements, in particular the enhanced full-rate codec and the adaptive... version version version of of of of of Renumbering of Specifications a specification in Release 98 is version 7.0.0; a GSM- only specification in Release 99 is version 8.0.0; a joint GSM/ UMTS specification in Release 99 is version 3.0.0; a joint GSM/ UMTS specification in Release 4 is version 4.0.0; a GSM- only specification in Release 4 is version 4.0.0 When one or more CRs to a specification have been accepted by... accepted by SMG/3GPP, a new version of the specification is created (Typically, there have been four SMG plenaries per Figure 20.3 Renumbering of GSM- only Specifications GSM and UMTS: The Creation of Global Mobile Communication 476 Table 20.1 Versions of a GSM/ UMTS Specification Release Specification number Version R96 R97 R98 R99 R4 03.67 03.67 03.67 23.067 23.067 5.1.1 6.1.0 7.2.0 3.2.0 4.0.0 year.) After... second significant digit for everything else), and the new version was issued The same procedures are – mutatis mutandis – applied in 3GPP GSM and UMTS: The Creation of Global Mobile Communication 478 20.8 Work Item Management New features are introduced into GSM depending on market demands This term ‘‘feature’’ is intentionally vague: A feature can be † directly relevant for the user (as, for example,... records, TAP records (described in GSM Association specifications), security aspects, operation and maintenance aspects, and tracing have to be covered as well, often in separate specifications, cf paragraph 20.8 on work item management For major work items, in the initial phase of the work, a requirement specification (in the 01 series) and a dedicated report on project scheduling and open issues (in the 10.xx... version 7.0.0 becomes version 7.0.1 Typically, a GSM specification exists in several, often in all releases, and parallel CRs are approved for several releases of the same specification at the same SMG/3GPP plenary 20.6.6 Examples The GSM specification Enhanced Multi-Level Precedence and Preemption Service (EMLPP); stage 2 has been created in Release 96 as GSM 03.67 version 5.0.0 As the service is supported . verifications and that a coordinating committee should be established. Cf. also TDoc GSM 51/87, TDoc GSM 107/87, TDoc GSM 96/88, TDoc GSM 222/88 and GSM# 21 Report,. always be complete and consistent. GSM and UMTS: The Creation of Global Mobile Communication470 14 See TDoc GSM 222/88. 15 See TDoc GSM 482/89 rev2. 16