Tài liệu GSM and UMTS (P20) pptx

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 doc

Chapter 20: Working Methods

Ansgar Bergmann1

SMG2has 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.

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

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 Review6 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 abbreviadefini-tions, 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

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.7The 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

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 condipre/post-condi-tions 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)8do 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

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)9is 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].10This 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,11and 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)12has 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

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 quesinforma-tionnaire) 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 pseudo-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 GDMO13has 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

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).15This phased development meant

a first phase, to be implemented and operated, followed by an upgraded phase 2 with addi-tional services and improved funcaddi-tionalities

In order to concentrate on the introduction of phase 1, specifications were functionally frozen.16This 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).17The 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

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 specificaelabora-tions 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.18By 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

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 descripspecifica-tions (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,

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).