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;
†

†
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,

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.

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

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-

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.

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