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

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