GSM GSM 04.

07
TECHNICAL December 1995

SPECIFICATION Version 5.0.0

Source: ETSI TC-SMG Reference: TS/SMG-030407Q

ICS: 33.060.50

Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)

Digital cellular telecommunications system (Phase 2+);

Mobile radio interface signalling layer 3;
General aspects
(GSM 04.07)

ETSI
European Telecommunications Standards Institute
ETSI Secretariat
New presentation - see History box

Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE

Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [email protected]
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16

Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 1995. All rights reserved.

Page 2
GSM 04.07 Version 5.0.0 December 1995

Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.
 Page 3
GSM 04.07 Version 5.0.0 December 1995

Contents

Foreword ........................................................................................................................................... 7

1 Scope ...................................................................................................................................... 9

2 Normative references ................................................................................................................ 9

3 Abbreviations .......................................................................................................................... 10

4 Introduction............................................................................................................................. 11
4.1 General .................................................................................................................... 11
4.2 Objectives ................................................................................................................ 11
4.3 General characteristics.............................................................................................. 11
4.3.1 Technique of description ......................................................................... 11
4.3.2 Primitives............................................................................................... 12
4.3.3 Peer-to-peer communication ................................................................... 12
4.3.4 Contents of signalling layer 3 related Technical Specifications.................... 12

5 Structure of signalling layer 3 functions...................................................................................... 12

5.1 Basic groups of functions........................................................................................... 12
5.2 Protocol architecture ................................................................................................. 14

6 Services provided by signalling layer 3 at the Mobile Station side ................................................ 14

6.1 Registration services ................................................................................................. 14
6.1.1 Service state diagram............................................................................. 15
6.1.2 Service primitives ................................................................................... 16
6.1.2.1 MMR_REG_REQ ........................................................... 16
6.1.2.2 MMR_REG_CNF............................................................ 16
6.1.2.3 [reserved] ...................................................................... 16
6.1.2.4 MMR_NREG_REQ ......................................................... 16
6.1.2.5 MMR_NREG_IND........................................................... 16
6.2 Call Control services.................................................................................................. 16
6.2.1 Service state diagram............................................................................. 16
6.2.2 Service primitives ................................................................................... 19
6.2.2.1 MNCC_SETUP_REQ...................................................... 20
6.2.2.2 MNCC_SETUP_IND........................................................ 20
6.2.2.3 MNCC_SETUP_RES ...................................................... 20
6.2.2.4 MNCC_SETUP_CNF....................................................... 20
6.2.2.5 MNCC_SETUP_COMPL_REQ ........................................ 20
6.2.2.6 MNCC_SETUP_COMPL_IND.......................................... 20
6.2.2.7 MNCC_REJ_REQ .......................................................... 20
6.2.2.8 MNCC_REJ_IND ............................................................ 20
6.2.2.9 MNCC_CALL_CONF_REQ ............................................. 20
6.2.2.10 MNCC_CALL_PROC_IND............................................... 20
6.2.2.11 MNCC_PROGRESS_IND................................................ 21
6.2.2.12 MNCC_ALERT_REQ ...................................................... 21
6.2.2.13 MNCC_ALERT_IND........................................................ 21
6.2.2.14 MNCC_NOTIFY_REQ .................................................... 21
6.2.2.15 MNCC_NOTIFY_IND ...................................................... 21
6.2.2.16 MNCC_DISC_REQ......................................................... 21
6.2.2.17 MNCC_DISC_IND .......................................................... 21
6.2.2.18 MNCC_REL_REQ .......................................................... 21
6.2.2.19 MNCC_REL_IND ............................................................ 21
6.2.2.20 MNCC_REL_CNF ........................................................... 21
6.2.2.21 MNCC_FACILITY_REQ.................................................. 22
6.2.2.22 MNCC_FACILITY_IND.................................................... 22
6.2.2.23 MNCC_START_DTMF_REQ........................................... 22
Page 4
GSM 04.07 Version 5.0.0 December 1995

6.2.2.24 MNCC_START_DTMF_CNF............................................ 22
6.2.2.25 MNCC_STOP_DTMF_REQ............................................. 22
6.2.2.26 MNCC_STOP_DTMF_CNF ............................................. 22
6.2.2.27 MNCC_MODIFY_REQ.................................................... 22
6.2.2.28 MNCC_MODIFY_IND ..................................................... 22
6.2.2.29 MNCC_MODIFY_RES .................................................... 22
6.2.2.30 MNCC_MODIFY_CNF .................................................... 22
6.2.2.31 MNCC_SYNC_IND ......................................................... 22
6.3 Call independent Supplementary Services Support....................................................... 23
6.3.1 Service state diagram............................................................................. 23
6.3.2 Service primitives ................................................................................... 24
6.3.2.1 MNSS_BEGIN_REQ ....................................................... 24
6.3.2.2 MNSS_BEGIN_IND......................................................... 24
6.3.2.3 MNSS_FACILITY_REQ .................................................. 24
6.3.2.4 MNSS_FACILITY_IND .................................................... 24
6.3.2.5 MNSS_END_REQ .......................................................... 24
6.3.2.6 MNSS_END_IND ............................................................ 24
6.4 Short Message Services Support ............................................................................... 24

7 Services provided by signalling layer 3 on the Network side ........................................................ 25

7.1 Call control services .................................................................................................. 25
7.1.1 Service state diagram............................................................................. 25
7.1.2 Service primitives ................................................................................... 28
7.1.2.1 MNCC_SETUP_REQ ...................................................... 29
7.1.2.2 MNCC_SETUP_IND........................................................ 29
7.1.2.3 MNCC_SETUP_RSP....................................................... 29
7.1.2.4 MNCC_SETUP_CNF....................................................... 29
7.1.2.5 MNCC_SETUP_COMPL_REQ ........................................ 29
7.1.2.6 MNCC_SETUP_COMPL_IND .......................................... 29
7.1.2.7 MNCC_REJ_REQ........................................................... 29
7.1.2.8 MNCC_REJ_IND ............................................................ 29
7.1.2.9 MNCC_CALL_CONF_IND ............................................... 29
7.1.2.10 MNCC_CALL_PROC_REQ ............................................. 29
7.1.2.11 MNCC_PROGRESS_REQ .............................................. 30
7.1.2.12 MNCC_ALERT_REQ ...................................................... 30
7.1.2.13 MNCC_ALERT_IND ........................................................ 30
7.1.2.14 MNCC_NOTIFY_REQ..................................................... 30
7.1.2.15 MNCC_NOTIFY_IND ...................................................... 30
7.1.2.16 MNCC_DISC_REQ ......................................................... 30
7.1.2.17 MNCC_DISC_IND........................................................... 30
7.1.2.18 MNCC_REL_REQ .......................................................... 30
7.1.2.19 MNCC_REL_IND ............................................................ 30
7.1.2.20 MNCC_REL_CNF ........................................................... 30
7.1.2.21 MNCC_FACILITY_REQ .................................................. 31
7.1.2.22 MNCC_FACILITY_IND.................................................... 31
7.1.2.23 MNCC_START_DTMF_IND............................................. 31
7.1.2.24 MNCC_START_DTMF_RSP............................................ 31
7.1.2.25 MNCC_STOP_DTMF_IND .............................................. 31
7.1.2.26 MNCC_STOP_DTMF_RSP ............................................. 31
7.1.2.27 MNCC_MODIFY_REQ.................................................... 31
7.1.2.28 MNCC_MODIFY_IND ..................................................... 31
7.1.2.29 MNCC_MODIFY_RES .................................................... 31
7.1.2.30 MNCC_MODIFY_CNF .................................................... 31
7.2 Call independent Supplementary Services Support....................................................... 32
7.2.1 Service state diagram............................................................................. 32
7.2.2 Service primitives ................................................................................... 33
7.2.2.1 MNSS_BEGIN_REQ ....................................................... 33
7.2.2.2 MNSS_BEGIN_IND......................................................... 33
7.2.2.3 MNSS_FACILITY_REQ .................................................. 33
7.2.2.4 MNSS_FACILITY_IND .................................................... 33
7.2.2.5 MNSS_END_REQ .......................................................... 33
7.2.2.6 MNSS_END_IND ............................................................ 33
7.3 Short Message Services Support ............................................................................... 33
 Page 5
GSM 04.07 Version 5.0.0 December 1995

8 Services assumed from signalling layers 1 and 2 ....................................................................... 34

8.1 Priority ..................................................................................................................... 34
8.2 Unacknowledged information transfer ......................................................................... 34
8.3 Acknowledged information transfer............................................................................. 34
8.4 Random access ........................................................................................................ 34
8.5 Channel management and measurements ................................................................... 34

9 Interlayer service interfaces on the Mobile Station side .............................................................. 35

9.1 Services provided by the Radio Resource Management entity ...................................... 35
9.1.1 Service state diagram............................................................................. 36
9.1.2 Service primitives ................................................................................... 37
9.1.2.1 RR_EST_REQ ............................................................... 37
9.1.2.2 RR_EST_IND................................................................. 37
9.1.2.3 RR_EST_CNF ................................................................ 37
9.1.2.4 RR_REL_IND................................................................. 37
9.1.2.5 RR_SYNC_IND .............................................................. 38
9.1.2.6 RR_DATA_REQ ............................................................. 38
9.1.2.7 RR_DATA_IND............................................................... 38
9.1.2.8 RR_UNIT_DATA_IND ..................................................... 38
9.1.2.9 RR_ABORT_REQ .......................................................... 38
9.1.2.10 RR_ABORT_IND ............................................................ 38
9.2 Services provided by the Mobility Management entity................................................... 39
9.2.1 Service state diagram............................................................................. 40
9.2.2 Service primitives ................................................................................... 41
9.2.2.1 MMXX_EST_REQ .......................................................... 41
9.2.2.2 MMXX_EST_IND............................................................ 41
9.2.2.3 MMXX_EST_CNF........................................................... 41
9.2.2.4 MMXX_REL_REQ .......................................................... 42
9.2.2.5 MMXX_REL_IND............................................................ 42
9.2.2.6 MMXX_DATA_REQ........................................................ 42
9.2.2.7 MMXX_DATA_IND ......................................................... 42
9.2.2.8 MMXX_UNIT_DATA_REQ .............................................. 42
9.2.2.9 MMXX_UNIT_DATA_IND ................................................ 42
9.2.2.10 MMCC_SYNC_IND......................................................... 42
9.2.2.11 MMXX_REEST_REQ ..................................................... 42
9.2.2.12 MMXX_REEST_CNF ...................................................... 42
9.2.2.13 MMXX_ERR_IND ........................................................... 42

10 Interlayer service interfaces on the Network side ....................................................................... 43

10.1 Services provided by the Radio Resource Management entity ...................................... 43
10.1.1 Service state diagram............................................................................. 44
10.1.2 Service primitives ................................................................................... 45
10.1.2.1 RR_EST_REQ ............................................................... 45
10.1.2.2 RR_EST_IND................................................................. 45
10.1.2.3 RR_EST_CNF ................................................................ 45
10.1.2.4 RR_REL_REQ ............................................................... 46
10.1.2.5 RR_REL_IND................................................................. 46
10.1.2.6 RR_SYNC_REQ............................................................. 46
10.1.2.7 RR_SYNC_CNF ............................................................. 46
10.1.2.8 RR_DATA_REQ ............................................................. 46
10.1.2.9 RR_DATA_IND............................................................... 46
10.1.2.10 RR_UNIT_DATA_REQ.................................................... 46
10.1.2.11 RR_UNIT_DATA_IND ..................................................... 46
10.1.2.12 RR_ABORT_REQ .......................................................... 46
10.1.2.13 RR_ABORT_IND ............................................................ 46
10.2 Services provided by the Mobility Management entity................................................... 47
10.2.1 Service state diagram............................................................................. 48
10.2.2 Service primitives ................................................................................... 49
10.2.2.1 MMXX_EST_REQ .......................................................... 49
10.2.2.2 MMXX_EST_IND............................................................ 49
10.2.2.3 MMXX_EST_CNF........................................................... 49
10.2.2.4 MMXX_REL_REQ .......................................................... 49
10.2.2.5 MMXX_REL_IND............................................................ 49
Page 6
GSM 04.07 Version 5.0.0 December 1995

10.2.2.6 MMXX_DATA_REQ........................................................ 49
10.2.2.7 MMXX_DATA_IND ......................................................... 50
10.2.2.8 MMXX_UNIT_DATA_REQ............................................... 50
10.2.2.9 MMXX_UNIT_DATA_IND ................................................ 50
10.2.2.10 MMCC_SYNC_REQ ....................................................... 50
10.2.2.11 MMCC_SYNC_CNF........................................................ 50

11 Standard L3 Messages............................................................................................................ 51
11.1 Components of a standard L3 message...................................................................... 51
11.1.1 Format of information elements ............................................................... 51
11.1.1.1 Information element type and value part ........................... 51
11.1.1.2 Length indicator .............................................................. 51
11.1.1.3 Information element identifier ........................................... 52
11.1.1.4 Categories of IEs; order of occurrence of IEI, LI, and
value part....................................................................... 52
11.2 Imperative part of a standard L3 message .................................................................. 55
11.2.1 Protocol discriminator ............................................................................. 55
11.2.2 Skip indicator ......................................................................................... 55
11.2.3 Transaction identifier............................................................................... 56
11.2.4 Message type ........................................................................................ 57
11.2.5 Further information elements of the imperative part ................................... 58
11.3 Non-imperative part of a standard L3 message............................................................ 58
11.4 Presence requirements of information elements........................................................... 59
11.5 Handling of superfluous information............................................................................. 59
11.5.1 Information elements that are unnecessary in a message .......................... 59

Annex A (informative): MN-Services arrow diagram......................................................................... 60

History ............................................................................................................................................. 67
 Page 7
GSM 04.07 Version 5.0.0 December 1995

Foreword

This Global System for Mobile communications Technical Specification (GTS) has been produced by the
Special Mobile Group (SMG) Technical Committee (TC) of the European Telecommunications Standards
Institute (ETSI).

This GTS defines the architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface
between mobile station and network within the digital cellular telecommunications system
(Phase 2/Phase 2+).

This GTS is a TC-SMG approved GSM technical specification version 5, which contains GSM Phase 2+
enhancements/features to the version 4 GSM technical specification. The European Telecommunications
Standard from which this Phase 2+ GTS has evolved is Phase 2
GSM ETS 300 556 (GSM 04.07 version 4.3.1).

GTS are produced by TC-SMG to enable the GSM Phase 2+ specifications to become publicly available,
prior to submission for the formal ETSI standards approval procedure to become European
Telecommunications Standards (ETS). This ensures the earliest possible access to GSM Phase 2+
specifications for all Manufacturers, Network operators and implementors of the Global System for Mobile
communications.

The contents of this GTS are subject to continuing work within TC-SMG and may change following formal
TC-SMG approval. Should TC-SMG modify the contents of this GTS it will then be republished by ETSI
with an identifying change of release date and an increase in version number as follows:

Version 5.x.y

where:
y the third digit is incremented when editorial only changes have been incorporated in the
specification;

x the second digit is incremented for all other types of changes, i.e. technical enhancements,
corrections, updates, etc.

The specification from which this GTS has been derived was originally based on CEPT documentation,
hence the presentation of this GTS may not be entirely in accordance with the ETSI rules.

Reference is made within this GTS to GSM-TSs (note).

NOTE: TC-SMG has produced documents which give the technical specifications for the
implementation of the digital cellular telecommunications system. Historically, these
documents have been identified as GSM Technical Specifications (GSM-TSs). These
TSs may have subsequently become I-ETSs (Phase 1), or ETSs/ETSI Technical
Reports (ETRs) (Phase 2). TC-SMG has also produced ETSI GSM TSs which give the
technical specifications for the implementation of Phase 2+ enhancements of the digital
cellular telecommunications system. These version 5.x.x GSM Technical Specifications
may be referred to as GTSs.
Page 8
GSM 04.07 Version 5.0.0 December 1995

Blank page
 Page 9
GSM 04.07 Version 5.0.0 December 1995

1 Scope

This Global System for Mobile communications Technical Specification (GTS) defines the architecture of
layer 3 and its sublayers on the GSM Um interface, i.e. the interface between Mobile Station and network.
It also defines the basic message format and error handling applied by the layer 3 protocols.

The corresponding protocols are defined elsewhere:

- the Radio Resource (RR) management protocol is defined in TS GSM 04.08;

- the Mobility Management (MM) protocol is defined in TS GSM 04.08;

- the Call Control (CC) protocol is defined in TS GSM 04.08;

- the Supplementary Services (SS) protocol is defined in TS GSM 04.10, TS GSM 04.8x series and
TS GSM 04.9x series;

- the Short Message Service (SMS) protocol is defined in TS GSM 04.11.

The communication between sublayers and adjacent layers and the services provided by the sublayers are
distributed by use of abstract service primitives. But only externally observable behaviour resulting from the
description is normatively prescribed by this Technical Specification.

2 Normative references

This GTS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply
to this GTS only when incorporated in it by amendment or revision. For undated references, the latest
edition of the publication referred to applies.

[1] GSM 01.04 (ETR 100): "European digital cellular telecommunications system
(Phase 2); Abbreviations and acronyms".

[2] GSM 03.01 (ETS 300 521): "European digital cellular telecommunications
system (Phase 2); Network functions".

[3] GSM 04.01 (ETS 300 550): "European digital cellular telecommunications
system (Phase 2); Mobile Station - Base Station System (MS - BSS) interface
General aspects and principles".

[4] GSM 04.05 (ETS 300 554): "European digital cellular telecommunications
system (Phase 2); Data Link (DL) layer General aspects".

[5] GSM 04.06 (ETS 300 555): "European digital cellular telecommunications
system (Phase 2); Mobile Station - Base Station System (MS - BSS) interface
Data Link (DL) layer specification".

[6] GSM 04.08 (ETS 300 557): "European digital cellular telecommunications
system (Phase 2); Mobile radio interface layer 3 specification".

[7] GSM 04.10 (ETS 300 558): "European digital cellular telecommunications
system (Phase 2); Mobile radio interface layer 3 Supplementary services
specification General aspects".
Page 10
GSM 04.07 Version 5.0.0 December 1995

[8] GSM 04.11 (ETS 300 559): "European digital cellular telecommunications
system (Phase 2); Point-to-Point (PP) Short Message Service (SMS) support on
mobile radio interface".

[9] GSM 04.80 (ETS 300 564): "European digital cellular telecommunications
system (Phase 2); Mobile radio interface layer 3 supplementary services
specification Formats and coding".

[10] GSM 04.81 (ETS 300 565): "European digital cellular telecommunications
system (Phase 2); Line identification supplementary services - Stage 3".

[11] GSM 04.82 (ETS 300 566): "European digital cellular telecommunications
system (Phase 2); Call Forwarding (CF) supplementary services - Stage 3".

[12] GSM 04.83 (ETS 300 567): "European digital cellular telecommunications
system (Phase 2); Call Waiting (CW) and Call Hold (HOLD) supplementary
services - Stage 3".

[13] GSM 04.84 (ETS 300 568): "European digital cellular telecommunications
system (Phase 2); MultiParty (MPTY) supplementary services - Stage 3".

[14] GSM 04.85 (ETS 300 569): "European digital cellular telecommunications
system (Phase 2); Closed User Group (CUG) supplementary services -
Stage 3".

[15] GSM 04.86 (ETS 300 570): "European digital cellular telecommunications
system (Phase 2); Advice of Charge (AoC) supplementary services - Stage 3".

[16] GSM 04.88 (ETS 300 571): "European digital cellular telecommunications
system (Phase 2); Call Barring (CB) supplementary services - Stage 3".

[17] GSM 04.90 (ETS 300 572): "European digital cellular telecommunications
system (Phase 2); Unstructured supplementary services operation - Stage 3".

[18] CCITT Recommendation X.200: "Reference Model of Open systems

interconnection for CCITT Applications".

3 Abbreviations

Abbreviations used in this specification are listed in GSM 01.04.

 Page 11
GSM 04.07 Version 5.0.0 December 1995

4 Introduction

4.1 General

The signalling layer 3 provides the functions to establish, maintain and terminate circuit-switched
connections across a GSM PLMN and other networks to which the GSM PLMN is connected. It provides
the necessary supporting functions related to supplementary services control and short messages service
control. Furthermore it includes the functions necessary for mobility management and radio resource
management.

The term "Layer 3" or "Signalling Layer 3" is a general term used to refer to the procedures described in
TS GSM 04.08, 04.10 and 04.11.

The layer 3 is composed of three sublayers comprising:

- the Radio Resource Management (RR) functions;

- the Mobility Management (MM) functions; and
- the Connection Management (CM) functions.

The Connection Management (CM) sublayer is composed of:

- Call Control (CC);

- Short Message Service Support (SMS); and
- Supplementary Services Support (SS).

4.2 Objectives

The objectives of the layer 3 are to provide the means for:

- the establishment, operation and release of a dedicated radio channel connection (RR);
- for location updating, authentication and TMSI reallocation (MM);
- for establishment, maintaining and termination of circuit-switched calls (CC);
- supplementary services support (SS);
- short messages service support (SMS).

4.3 General characteristics

4.3.1 Technique of description

The signalling layer 3 is described in terms of:

- services provided by the signalling layer 3;

- services assumed from the signalling layer 2;
- functions of the signalling layer 3.

The functions of the signalling layer 3 are performed by means of the signalling layer 3 protocols between
two systems which represent the Mobile Station side and the Network side of the radio interface as
viewed by the Mobile Station. This Technical Specification does not consider the distribution of signalling
functions among the different network equipments. The functions of layer 3 and its supporting lower layers,
therefore, provide the Mobile Network Signalling (MNS) Service to the upper layers.

The service interfaces to the upper layers and to the data link layer 2 are described by means of primitives
and parameters as recommended in CCITT Recommendation X.200.

The same technique of description is used for the three sublayers.

Page 12
GSM 04.07 Version 5.0.0 December 1995

4.3.2 Primitives

The services provided by the various sublayers are described in this Technical Specification. The
elementary interactions among adjacent sublayers are described by primitives. The primitives consist of
requests, responses, indications and confirmations. The general syntax of a primitive is specified in
TS GSM 04.01.

4.3.3 Peer-to-peer communication

Exchange of information between two peers of the signalling layer 3 is performed by means of the three
sublayer protocols. A protocol is a set of rules and formats by which the control information and user data
are exchanged between the two peers.

4.3.4 Contents of signalling layer 3 related Technical Specifications

TS GSM 04.08 specifies the protocols for Call Control, Mobility Management and Radio Resource
Management.

TS GSM 04.10 specifies the protocols for Supplementary Services Support.

TS GSM 04.11 specifies the protocols for Short Message Services Support.

5 Structure of signalling layer 3 functions

5.1 Basic groups of functions

Signalling Layer 3 comprises the following groups of signalling functions:

- Call Control (CC);

- Short Message Service Support (SMS);
- Supplementary Services Support (SS);
- Mobility Management (MM);
- Radio Resource Management (RR).

These functional groups are realized by separate protocol control entities.

In addition, other functions are contained in layer 3 which are related to the transport of messages, e.g.
multiplexing and splitting. Those functions are defined in the Radio Resource Management and Mobility
Management. They have the task to route the messages according to the protocol discriminator (PD) and
transaction identifier (TI) which are part of the message header. In the uplink direction, the MM routing
function shall route the messages of the CM entities as well as of the MM entity of its own sublayer
towards the service access point of RR and multiplex them in case of parallel transactions. The routing
function of Radio Resource Management shall distribute the messages to be sent according to their
protocol discriminator (PD) and the actual channel configuration. In the downlink direction the messages
provided at the different service access points of layer 2 are split by the RR routing function according to
the protocol discriminator (PD). Messages with a PD equal to RR are passed to the RR entity of the own
sublayer, all other messages are provided to the MM sublayer at the service access point RR-SAP.

The routing function of MM passes the messages according to the protocol discriminator (PD) and the
transaction identifier (TI) towards the MM entity or towards the CM entities via the various MM-SAP's. The
message header or parts of it are not removed by the RR routing function before passing it to the MM
sublayer because further routing has to be done by MM using the same criteria. This is not in line with the
rules of the ISO reference model but it reduces the number of message octets.
 Page 13
GSM 04.07 Version 5.0.0 December 1995

MOBILE
NETWORK MNCC-SAP MNSS-SAP MNSMS-SAP
SERVICE

CC SS SMS

MMSS-SAP

MMCC-SAP MMSMS-SAP
MMREG-SAP

TI TI TI
CC SS SMS
LAYER 3 SIGNALLING

MM
MM

PD

RR-SAP

RR =RR

PD

RR

SAPI 0 SAPI 3
AGCH+PCH

SDCCH

SAC CH
SDCCH

SACCH

FACCH
BCCH
RACH

Figure 5.1/GSM 04.07 Protocol Architecture of Signalling Layer 3 - Mobile Station side
Page 14
GSM 04.07 Version 5.0.0 December 1995

5.2 Protocol architecture

As shown in figure 5.1/GSM 04.07 a hierarchy of 3 sublayers is defined:

- the RR sublayer provides services to the MM sublayer and utilizes the services of signalling layer 2;
- the MM sublayer provides common services to the entities of the Connection Management (CM)
sublayer;
- the CM sublayer includes the CC, SS, and SMS entities, which are independent entities.

6 Services provided by signalling layer 3 at the Mobile Station side

The different classes of services provided by signalling layer 3 at the Mobile Station side are accessible at
the following service access points:

- registration services at the MMREG-SAP;

- Call Control services for normal and emergency calls including call related Supplementary Services
Support services at the MNCC-SAP;
- Short Message Services Support services at the MNSMS-SAP;
- Call independent Supplementary Services Support services at the MNSS-SAP.

6.1 Registration services

The registration services (location updating, IMSI attach/detach) are provided at the service access point
MMREG-SAP. As opposed to all other MN-Services, these services are provided by and can be directly
accessed at the Mobility Management sublayer.
 Page 15
GSM 04.07 Version 5.0.0 December 1995

6.1.1 Service state diagram

The registration services provided at the service access point MMREG-SAP are illustrated in the state of
figure 6.1/GSM 04.07 below.

MMR-NREG -REQ
IND

NOT
UP-
DATED
MMR-REG-REQ

MMR-NREG-
REQ-IND

WAIT
MMR-REG-REQ UP-
DATING
MMR-NREG
IND

MMR-
REG-REQ

MMR-REG-CNF

UP-
DATED

MMR-REG-ING

Figure 6.1/GSM 04.07 Registration services provided at MMREG-SAP - Mobile Station side
Page 16
GSM 04.07 Version 5.0.0 December 1995

6.1.2 Service primitives

Table 6.1/GSM 04.07 Primitives and Parameters at the MMREG-SAP - Mobile Station side

PRIMITIVE PARAMETER REFERENCE

MMR_REG_REQ IMSI 6.1.2.1
MMR_REG_CNF - 6.1.2.2
MMR_NREG_REQ - 6.1.2.4
MMR_NREG_IND cause 6.1.2.5

6.1.2.1 MMR_REG_REQ

Registration request, triggered by activation of the IMSI, e.g., by activation of the mobile station with
inserted SIM, insertion of the SIM into the activated mobile station, pressing of a reset button.

6.1.2.2 MMR_REG_CNF

Registration confirmation. Indicates to the user that the Mobile Station is ready to start a transaction.

6.1.2.3 [reserved]

6.1.2.4 MMR_NREG_REQ

Request to cancel the registration, stimulated either by removing the SIM or automatically in the power off
phase.

6.1.2.5 MMR_NREG_IND

Indication that registration has been cancelled or that registration was not possible. Only emergency
services are available to the user.

6.2 Call Control services

The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP.

The Call Control service class consists of the following services:

- Mobile originated and Mobile terminated call establishment for normal calls;
- Mobile originated call establishment for emergency calls;
- call maintaining;
- call termination;
- call related Supplementary Services Support.

6.2.1 Service state diagram

The Call Control services provided at the service access point MNCC-SAP are illustrated in the state
diagram of figure 6.2/GSM 04.07.
 MNCC-SETUP-REQ
0 NULL MNCC-SETUP-IND

MNCC-REJ-IND MNCC- MNCC-REJ-REQ

REL-
CNF

MNCC- RELEASE CALL

1 CALL INIT REL- 19 REQUEST 6 PRESENT
IND
MNCC-CALL MNCC-
PROC-IND MNCC-DISC- MNCC- MNCC-REL- DISC- MNCC-CALL-
REQ DISC- REQ IND CONF-REQ
IND
MNCC-
PROGRESS- NO CALL 11 DISCONNECT DISONNECT MT CALL
12 INDICATION 9 CONFIRMED
IND REQUEST
3 PROCEEDING

MNCC- MNCC- MNCC-

MNCC- DISC- DISC- ALERT-
MNCC-REL- ALERT-
REQ REQ STATES IND REQ MNCC-
IND 3,4,7,8,9,10 SETUP-
CALL RSP
RELEASE
7
CALL MNCC- RECEIVED
19 REQUEST 4DELIVERED
SETUP-

(page 1 of 2)
CNF MNCC-SETUP- MNCC-
COMPL-IND (ERR) SETUP-RSP

8 CONNECT
REQUEST

MNCC-SETUP-
CNF 10 ACTIVE MNCC-SETUP-COMP-IND

MNCC-
ANY STATE MNCC- ANY STATE MNCC-
FACILITY- ANY STATE

Figure 6.2/GSM 04.07 Service graph of Call Control entity - Mobile Station side
EXCEPT 0 REL- 0 EXCEPT 0,19 FACILITY
IND
IND REQ
GSM 04.07 Version 5.0.0 December 1995
Page 17
Page 18
GSM 04.07 Version 5.0.0 December 1995

MNCC-DTMF-START-REQ
CNF
MNCC-DTMF-STOP-REQ
CNF
MNCC-SYNC-IND (res ass)
MNCC-SYNC-IND (channel mode
modify)
MNCC-NOTIFY-REQ
IND
MNCC-MODIFY-IND

10 ACTIVE

MNCC-MODIFY-REQ MNCC-MODIFY-CNF

28 M0
MODIFY

MNCC-SYNC-IND (res ass)

MNCC-SYNC-IND (channel mode
modify)

Figure 6.2/GSM 04.07 Service graph of Call Control entity - Mobile Station side Active state
(page 2 of 2)
 Page 19
GSM 04.07 Version 5.0.0 December 1995

6.2.2 Service primitives

Table 6.2/GSM 04.07 Primitives and parameters at MNCC-SAP - Mobile Station side

PRIMITIVE PARAMETER (message, info elements REFERENCE

of message, other parameters)

MNCC_SETUP_REQ SETUP or EMERGENCY SETUP, 6.2.2.1

MNCC_SETUP_IND SETUP 6.2.2.2

MNCC_SETUP_RSP CONNECT 6.2.2.3
MNCC_SETUP_CNF CONNECT 6.2.2.4
MNCC_SETUP_COMPLETE_REQ - 6.2.2.5
MNCC_SETUP_COMPLETE_IND - 6.2.2.6
MNCC_REJ_REQ RELEASE COMPLETE 6.2.2.7
MNCC_REJ_IND cause 6.2.2.8
MNCC_CALL_CONF_REQ CALL CONFIRMED 6.2.2.9
MNCC_CALL PROC_IND CALL PROCEEDING 6.2.2.10
MNCC_PROGRESS_IND PROGRESS 6.2.2.11
MNCC_ALERT_REQ ALERTING 6.2.2.12
MNCC_ALERT_IND ALERTING 6.2.2.13
MNCC_NOTIFY_REQ NOTIFY 6.2.2.14
MNCC_NOTIFY_IND NOTIFY 6.2.2.15
MNCC_DISC_REQ DISCONNECT 6.2.2.16
MNCC_DISC_IND DISCONNECT 6.2.2.17
MNCC_REL_REQ RELEASE 6.2.2.18
MNCC_REL_IND RELEASE 6.2.2.19
MNCC_REL_CNF RELEASE or RELEASE COMPLETE 6.2.2.20
MNCC_FACILITY_REQ facility 6.2.2.21
MNCC_FACILITY_IND facility 6.2.2.22
MNCC_START_DTMF_REQ START DTMF 6.2.2.23
MNCC_START_DTMF_CNF START DTMF ACK or 6.2.2.24
START DTMF REJ
MNCC_STOP_DTMF_REQ STOP DTMF 6.2.2.25
MNCC_STOP_DTMF_CNF STOP DTMF ACK 6.2.2.26
MNCC_MODIFY_REQ MODIFY 6.2.2.27
MNCC_MODIFY_IND MODIFY 6.2.2.28
MNCC_MODIFY_RES MODIFY COMPLETE 6.2.2.29
MNCC_MODIFY_CNF MODIFY COMPLETE 6.2.2.30
MNCC_SYNC_IND cause (res. ass., channel mode modify) 6.2.2.31
Page 20
GSM 04.07 Version 5.0.0 December 1995

6.2.2.1 MNCC_SETUP_REQ

Request to send a SETUP or EMERGENCY SETUP message to initiate Mobile originating establishment
of either a normal or an emergency call.

6.2.2.2 MNCC_SETUP_IND

Receipt of a SETUP message, the Mobile terminated call establishment has been initiated.

6.2.2.3 MNCC_SETUP_RES

Response to send a CONNECT message to indicate call acceptance by the Mobile terminated user; call
control is requested to attach the user connection (if it is not yet attached).

6.2.2.4 MNCC_SETUP_CNF

Receipt of a CONNECT message, the Mobile originated call has been accepted by the remote called user.

6.2.2.5 MNCC_SETUP_COMPL_REQ

Request to send a CONNECT ACKNOWLEDGE message, the mobile originating call has been accepted.

6.2.2.6 MNCC_SETUP_COMPL_IND

Receipt of a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has been
completed; for a data call, the user is informed that the user connection is attached.

6.2.2.7 MNCC_REJ_REQ

Request to reject a Mobile terminated call if the call is refused or if the call cannot be accepted, e.g.,
because of missing compatibility.

6.2.2.8 MNCC_REJ_IND

Indication that the Mobile originated call has been rejected, e.g. if the MM connection cannot be provided
or if the call establishment initiation has been rejected by the network.

6.2.2.9 MNCC_CALL_CONF_REQ

Request to confirm a Mobile terminated call by sending a CALL CONFIRMED message. A bearer
capability different from that given in MNCC_SETUP_IND may be offered to the remote calling user.

6.2.2.10 MNCC_CALL_PROC_IND

Indication to the Mobile originating user that call establishment has been initiated in the Network and no
more call establishment information will be accepted by the Network.
 Page 21
GSM 04.07 Version 5.0.0 December 1995

6.2.2.11 MNCC_PROGRESS_IND

Indication to the Mobile user that a PROGRESS message or a message containing a progress IE has
been received, e.g., because the call is progressing in the PLMN/ISDN environment, or because the call
has left the PLMN/ISDN environment, or because in-band tones/announcement are available.

6.2.2.12 MNCC_ALERT_REQ

Request to send an ALERTING message from the called Mobile user to the remote calling user to indicate
that user alerting has been initiated.

6.2.2.13 MNCC_ALERT_IND

Indication of the receipt of an ALERTING message, alerting to the remote called user has been initiated.

6.2.2.14 MNCC_NOTIFY_REQ

Request to send information pertaining to a call, such as user suspended, to the Network by the Mobile
user.

6.2.2.15 MNCC_NOTIFY_IND

Indication to the Mobile user that information pertaining to a call, such as remote user suspended, has
been received from the Network.

6.2.2.16 MNCC_DISC_REQ

Request to send a DISCONNECT message to the Network in order to clear the end-to-end connection.

6.2.2.17 MNCC_DISC_IND

Indication of reception of a DISCONNECT message, by which the Network indicates that the end-to-end
connection is cleared.

6.2.2.18 MNCC_REL_REQ

Request of the Mobile user to send a RELEASE message to inform the Network that the user intends to
release the call reference and the corresponding MM connection so that the Network can release its MM
connection and the correspondent call reference.

6.2.2.19 MNCC_REL_IND

Indication to the Mobile originating or terminated user that a RELEASE message has been received and
the Network intends to release its MM connection. The Mobile user is requested to release the call
reference and the corresponding MM connection.

6.2.2.20 MNCC_REL_CNF

Confirmation of the Mobile user's request to release the MM connection and call reference in the Network.
The Mobile user may release the call reference and the corresponding MM connection.
Page 22
GSM 04.07 Version 5.0.0 December 1995

6.2.2.21 MNCC_FACILITY_REQ

Request to transport a facility IE for a call related supplementary service invocation.

6.2.2.22 MNCC_FACILITY_IND

Indication that a facility IE for a call related supplementary service invocation has been received.

6.2.2.23 MNCC_START_DTMF_REQ

Request to send a START DTMF message in order to start a DTMF control operation.

6.2.2.24 MNCC_START_DTMF_CNF

Confirmation of the receipt of a START DTMF ACKNOWLEDGE or START DTMF REJECT message that
the start of a DTMF control operation has been acknowledged or rejected.

6.2.2.25 MNCC_STOP_DTMF_REQ

Request to send a STOP DTMF message in order to stop a DTMF control operation.

6.2.2.26 MNCC_STOP_DTMF_CNF

Confirmation of the receipt of STOP DTMF ACKNOWLEDGE message, the DTMF control operation has
been stopped.

6.2.2.27 MNCC_MODIFY_REQ

Request to start Mobile originating in-call modification by sending a MODIFY message.

6.2.2.28 MNCC_MODIFY_IND

RECEIPT OF A MODIFY message, a Mobile terminating in-call modification has been initiated.

6.2.2.29 MNCC_MODIFY_RES

Response to send a MODIFY COMPLETE message to indicate Mobile terminating in-call modification
completion by the Mobile user.

6.2.2.30 MNCC_MODIFY_CNF

Receipt of a MODIFY COMPLETE message, the Mobile originating in-call modification has been
completed.

6.2.2.31 MNCC_SYNC_IND

Indication that a dedicated channel assignment has been performed (res. ass. = "resource assigned")
and/or the channel mode has been changed.
 Page 23
GSM 04.07 Version 5.0.0 December 1995

6.3 Call independent Supplementary Services Support

6.3.1 Service state diagram

The primitives provided by the call independent Supplementary Services Support entity and the transitions
between permitted states are shown in figure 6.3/GSM 04.07.

MNSS-END-REQ
IND
IDLE

MNSS-BEGIN-REQ MNSS-END-REQ
IND IND

CONN

MNSS-FACILITY-REQ
IND

STATES:

IDLE - No SS signalling transaction pending

CONN - SS signalling transaction established

Figure 6.3/GSM 04.07 Service graph of the call independent Supplementary Services Support
entity - Mobile Station side
Page 24
GSM 04.07 Version 5.0.0 December 1995

6.3.2 Service primitives

Table 6.3/GSM 04.07 Primitives and Parameters at MNSS-SAP - Mobile Station side

PRIMITIVES PARAMETERS REFERENCE

Info elements of message

MNSS_BEGIN_REQ REGISTER 6.3.2.1

MNSS_BEGIN_IND REGISTER 6.3.2.2
MNSS_FACILITY_REQ FACILITY 6.3.2.3
MNSS_FACILITY_IND FACILITY 6.3.2.4
MNSS_END_REQ REL COMPLETE 6.3.2.5
MNSS_END_IND REL COMPLETE 6.3.2.6

6.3.2.1 MNSS_BEGIN_REQ

Request to send a REGISTER message in order to establish a signalling transaction for the provision of
call independent supplementary services. The request for a call independent supplementary service
invocation may be included.

6.3.2.2 MNSS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of call
independent supplementary services after receipt of a REGISTER message. The indication of a
supplementary servic e invocation may be included.

6.3.2.3 MNSS_FACILITY_REQ

Request to send a FACILITY message for the provision of a call independent supplementary service
invocation.

6.3.2.4 MNSS_FACILITY_IND

Receipt of a FACILITY message for a call independent supplementary service invocation.

6.3.2.5 MNSS_END_REQ

Request to send a RELEASE COMPLETE message in order to release the signalling transaction. The
request for transfer of a supplementary service facility may be included.

6.3.2.6 MNSS_END_IND

Receipt of a RELEASE COMPLETE message, the signalling transaction has been released. The indication
of a supplementary service facility may be included.

6.4 Short Message Services Support

The service provided by the CM sublayer to support the short message service are defined in
TS GSM 04.11.
 Page 25
GSM 04.07 Version 5.0.0 December 1995

7 Services provided by signalling layer 3 on the Network side

7.1 Call control services

The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP.

The Call Control service class consists of the following services:

- call establishment;
- call maintaining;
- call termination;
- call related Supplementary Services Support.

7.1.1 Service state diagram

The Call Control services provided at the service access point MNCC-SAP are illustrated in
figure 7.1/GSM 04.07.
 MNCC-SETUP-REQ
MNCC-SETUP-REQ
Page 26

0 NULL

MNCC-REJ-IND MNCC-REJ-IND
MNCC- MNCC-
REL-CNF DISC-
IND
MNCC-
19 RELEASE REL-
1 CALL INIT REQUEST IND 6 CALL
PRESENT
MNCC-REL
MNCC-
MNCC-CALL REQ CALL-
PROC-REQ
DISONNECT CONF-
11 DISCONNECT 12 INDICATION IND
REQUEST
MNCC-
PROGRESS- NO CALL 9 MT CALL
REQ
3 PROCEEDING CONFIRMED
GSM 04.07 Version 5.0.0 December 1995

MNCC- MNCC- MNCC-

ALERT- DISC- DISC- MNCC-
REQ IND REQ ALERT-
MNCC-
ALERT- STATES IND
4 CALL MNCC-
IND DILIVERED 4,6,8,9,10 SETUP-
7 CALL CNF
MNCC- RECEIVED
SETUP-
RSP MNCC-
28 CONNECT
INDICATION SETUP-CNF

8 CONNECT
REQUEST

10 ACTIVE MNCC-SETUP-COMPL-REQ

MNCC-
FACILITY- ANY STATE MNCC- ANY STATE MNCC-
ANY STATE 0 FACILITY

Figure 7.1/GSM 04.07 (page 1 of 2) Service graph of Call Control entity - Network side
IND EXCEPT 0 REL- EXCEPT 0,19
IND REQ
 Page 27
GSM 04.07 Version 5.0.0 December 1995

MNCC-START-DTMF-IND
RSP
MNCC-STOP-DTMF-IND
RSP
MNCC-NOTIFY-REQ
IND
MNCC-MODIFY-IND

10 ACTIVE

MNCC-MODIFY-REQ MNCC-MODIFY-CNF

27 MT
MODIFY

Figure 7.1/GSM 04.07 (page 2 of 2) Service graph of Call Control entity - Network side
Page 28
GSM 04.07 Version 5.0.0 December 1995

7.1.2 Service primitives

Table 7.1/GSM 04.07 Primitives and Parameters at MNCC-SAP - Network side

PRIMITIVE PARAMETER (message, info REFERENCE

elements of MESSAGE,
other parameters)

MNCC_SETUP_REQ SETUP 7.1.2.1

incl. Mobile ID
or EMERGENCY SETUP
MNCC_SETUP_IND SETUP 7.1.2.2
MNCC_SETUP_RSP CONNECT 7.1.2.3
MNCC_SETUP_CNF CONNECT 7.1.2.4
MNCC_SETUP_COMPL_REQ CONNECT ACKNOWLEDGE 7.1.2.5
MNCC_SETUP_COMPL_IND CONNECT ACKNOWLEDGE 7.1.2.6
MNCC_REJ_REQ RELEASE COMPLETE 7.1.2.7
MNCC_REJ_IND cause 7.1.2.8
MNCC_CALL_CONF_IND CALL CONFIRMED 7.1.2.9
MNCC_CALL PROC_REQ CALL PROCEEDING 7.1.2.10
MNCC_PROGRESS_REQ PROGRESS 7.1.2.11
MNCC_ALERT_REQ ALERTING 7.1.2.12
MNCC_ALERT_IND ALERTING 7.1.2.13
MNCC_NOTIFY_REQ NOTIFY 7.1.2.14
MNCC_NOTIFY_IND NOTIFY 7.1.2.15
MNCC_DISC_REQ DISCONNECT 7.1.2.16
MNCC_DISC_IND DISCONNECT 7.1.2.17
MNCC_REL_REQ RELEASE or DISCONNECT 7.1.2.18
MNCC_REL_IND RELEASE 7.1.2.19
MNCC_REL_CNF RELEASE or RELEASE COMPLETE 7.1.2.20
MNCC_FACILITY_REQ facility 7.1.2.21
MNCC_FACILITY_IND facility 7.1.2.22
MNCC_START_DTMF_IND START DTMF 7.1.2.23
MNCC_START_DTMF_RSP START DTMF ACK or 7.1.2.24
START DTMF REJ
MNCC_STOP_DTMF_IND STOP DTMF 7.1.2.25
MNCC_STOP_DTMF_RSP STOP DTMF ACK 7.1.2.26
MNCC_MODIFY_REQ MODIFY or 7.1.2.27
BC-parameter
MNCC_MODIFY_IND BC-parameter 7.1.2.28
MNCC_MODIFY RES MODIFY COMPLETE 7.1.2.29
MNCC_MODIFY_CNF BC-parameter 7.1.2.30
 Page 29
GSM 04.07 Version 5.0.0 December 1995

7.1.2.1 MNCC_SETUP_REQ

Request to send a SETUP message to initiate Mobile terminated establishment.

7.1.2.2 MNCC_SETUP_IND

Receipt of a SETUP or EMERGENCY SETUP message, the Mobile originating call establishment has been
initiated.

7.1.2.3 MNCC_SETUP_RSP

Response to send a CONNECT message to indicate call acceptance by the remote user.

7.1.2.4 MNCC_SETUP_CNF

Receipt of a CONNECT message, the Mobile terminated call has been accepted.

7.1.2.5 MNCC_SETUP_COMPL_REQ

Request to send a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has
been completed.

7.1.2.6 MNCC_SETUP_COMPL_IND

Indication of the receipt of a CONNECT ACKNOWLEDGE message, the Mobile originating call
establishment has been completed.

7.1.2.7 MNCC_REJ_REQ

Reject the Mobile originated call establishment if the call cannot be accepted.

7.1.2.8 MNCC_REJ_IND

A Mobile terminated call was rejected by the Mobile Station, e.g. because of missing compatibility.

7.1.2.9 MNCC_CALL_CONF_IND

Receipt of a CALL CONFIRMED message, the Mobile terminated call has been confirmed. A bearer
capability different from that given in MNCC_SETUP_REQ may be offered to the remote calling user.

7.1.2.10 MNCC_CALL_PROC_REQ

Request to send a CALL PROCEEDING message to indicate to the Mobile originating user that call
establishment has been initiated in the Network and no more call establishment information will be
accepted.
Page 30
GSM 04.07 Version 5.0.0 December 1995

7.1.2.11 MNCC_PROGRESS_REQ

Request to send a PROGRESS message or to piggy-back a progress IE in a suitable CC message in

order to give the Mobile user information about the call , e.g., that the call is progressing in the
PLMN/ISDN environment, or that the call has left the PLMN/ISDN environment, or that in-band
tones/announcement are available.

7.1.2.12 MNCC_ALERT_REQ

Request to send an ALERTING message to indicate to the Mobile originating user that remote called user
alerting has been initiated.

7.1.2.13 MNCC_ALERT_IND

Receipt of an ALERTING message from the Mobile terminated user to be sent to the remote calling user
to indicate that user alerting has been initiated.

7.1.2.14 MNCC_NOTIFY_REQ

Request to send information pertaining to a call, such as user suspended, to the Mobile originating or the
Mobile terminated user.

7.1.2.15 MNCC_NOTIFY_IND

Indication from the Mobile originating or Mobile terminated user of information pertaining to a call, such as
remote user suspended.

7.1.2.16 MNCC_DISC_REQ

Request to send a DISCONNECT message to the Mobile Station in order to clear the end-to-end
connection.

7.1.2.17 MNCC_DISC_IND

Receipt of a DISCONNECT message, the Mobile Station indicates that the end-to-end connection is
cleared.

7.1.2.18 MNCC_REL_REQ

Request to send a RELEASE message to inform the Mobile Station that the network intends to release the
MM connection and the correspondent call reference.

7.1.2.19 MNCC_REL_IND

Receipt of a RELEASE message, the Mobile Station intends to release its MM connection and call
reference. The Network is requested to release its call reference and MM connection.

7.1.2.20 MNCC_REL_CNF

The RELEASE COMPLETE message has been received, the MM connection in the Mobile Station has
been released, the Network itself shall release its MM connection and the corresponding call reference.
 Page 31
GSM 04.07 Version 5.0.0 December 1995

7.1.2.21 MNCC_FACILITY_REQ

Request to transport a facility IE for call related supplementary service invocations.

7.1.2.22 MNCC_FACILITY_IND

Indication that a facility IE for call related supplementary service invocations has been received.

7.1.2.23 MNCC_START_DTMF_IND

Indicate the receipt of a START DTMF message in order to start a DTMF control operation.

7.1.2.24 MNCC_START_DTMF_RSP

Request to send a START DTMF ACKNOWLEDGE or START DTMF REJECT message in order to
acknowledge or reject the start of a DTMF control operation.

7.1.2.25 MNCC_STOP_DTMF_IND

Indicate the receipt of a STOP DTMF message in order to stop a DTMF control operation.

7.1.2.26 MNCC_STOP_DTMF_RSP

Request to send a STOP DTMF ACKNOWLEDGE message in order to acknowledge the completion of a
DTMF control operation.

7.1.2.27 MNCC_MODIFY_REQ

Request to start the Mobile terminating in-call modification.

7.1.2.28 MNCC_MODIFY_IND

Receipt of a MODIFY message, the Mobile originating in-call modification has been initiated.

7.1.2.29 MNCC_MODIFY_RES

Response to send a MODIFY COMPLETE to indicate to the Mobile user that the mobile originating in-call
modification procedure has been completed.

7.1.2.30 MNCC_MODIFY_CNF

Confirmation that the Mobile terminating in-call modification has been completed.
Page 32
GSM 04.07 Version 5.0.0 December 1995

7.2 Call independent Supplementary Services Support

7.2.1 Service state diagram

The primitives provided by the call independent Supplementary Services Support entity and the transitions
between permitted states are shown in the service graph of figure 7.2/GSM 04.07 below.

MNSS-END-REQ
IND

IDLE

MNSS-BEGIN-IND MNSS-END-REQ
REQ IND

CONN

MNSS-FACILITY-REQ
IND

STATES:

IDLE - No SS signalling transaction pending

CONN - SS signalling transaction established

Figure 7.2/GSM 04.07 Service graph of the call independent Supplementary Services Support
entity - Network side
 Page 33
GSM 04.07 Version 5.0.0 December 1995

7.2.2 Service primitives

Table 7.2/GSM 04.07 Primitives and Parameters at MNSS-SAP - Network side

PRIMITIVES PARAMETERS REFERENCE

Info elements of message

MNSS_BEGIN_REQ REGISTER 7.2.2.1

MNSS_BEGIN_IND REGISTER 7.2.2.2
MNSS_FACILITY_REQ FACILITY 7.2.2.3
MNSS_FACILITY_IND FACILITY 7.2.2.4
MNSS_END_REQ RELEASE COMPLETE 7.2.2.5
MNSS_END_IND RELEASE COMPLETE 7.2.2.6

7.2.2.1 MNSS_BEGIN_REQ

Request to send a REGISTER message in order to establish a signalling transaction for the provision of
call independent supplementary services. The request for a supplementary service invocation may be
included.

7.2.2.2 MNSS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of call
independent supplementary services. The indication of a supplementary service invocation may be
included.

7.2.2.3 MNSS_FACILITY_REQ

Request to send a FACILITY message for the provision of a call independent supplementary service
facility.

7.2.2.4 MNSS_FACILITY_IND

Receipt of a FACILITY message, a supplementary service facility has been requested.

7.2.2.5 MNSS_END_REQ

Request to send a RELEASE COMPLETE message in order to release the signalling transaction by
sending a RELEASE COMPLETE message. The request for transfer of a supplementary service facility
may be included.

7.2.2.6 MNSS_END_IND

Indication that the signalling transaction has been released after receipt of a RELEASE COMPLETE
message. The indication of a supplementary service facility may be included.

7.3 Short Message Services Support

The service provided by the CM sublayer to support the short message service are defined in TS GSM
04.11.
Page 34
GSM 04.07 Version 5.0.0 December 1995

8 Services assumed from signalling layers 1 and 2

The services provided by layer 2 are defined in detail in TS GSM 04.05. A short summary is given below.

In addition, layer 1 communicates directly with layer 3 for information transfer related to channel
management and to measurement control. See section 8.5 below.

8.1 Priority

Messages from layer 3 can be sent with:

- no priority,
i.e. the messages are sent in first-in-first-out order;
- priority,
i.e. a message with this indication is sent as early as possible by layer 2.

8.2 Unacknowledged information transfer

Transfer of unacknowledged information using the primitives DL_UNIT_DATA_ REQUEST/INDICATION.

8.3 Acknowledged information transfer

Transfer of information in multiframe acknowledged mode including:

- establishment of data link connection between L3 entities;

- transfer of information in acknowledged mode;
- release of the data link connection.

The primitives associated with acknowledged information transfer are:

- DL_ESTABLISH_REQUEST/INDICATION/CONFIRM for establishment of acknowledged mode;

- DL_DATA_REQUEST/INDICATION for requesting the transmission of a message unit and for
indicating the reception of a message unit;
- DL_SUSPEND_REQUEST/DL_RELEASE_CONFIRM for requesting and confirming the suspension
of the acknowledged information transfer in the Mobile Station upon channel change;
- DL_RESUME_REQUEST/DL_ESTABLISH_CONFIRM for requesting and confirming the resumption
of the acknowledged information transfer in the Mobile Station after suspension at channel change;
- DL_RELEASE_REQUEST/INDICATION/CONFIRM for the termination of acknowledged mode
operation;
- DL_RECONNECT_REQUEST for requesting the re-establishment of acknowledged information
transfer in the Mobile Station on the old channel after channel change failure.

8.4 Random access

The transmission/reception of a random access burst is controlled by the primitives

DL_RANDOM_ACCESS_REQUEST/INDICATION/CONFIRM.

8.5 Channel management and measurements

The management of channels, i.e. their activation, deactivation, configuration, deconfiguration, through-
connection and disconnection is controlled by the RR sublayer in layer 3. The measurements performed by
the physical layer are also controlled by the RR sublayer of layer 3 and they are reported to layer 3.

These functions use the primitives MPH_INFORMATION_REQUEST/INDICATION/CONFIRMATION.

 Page 35
GSM 04.07 Version 5.0.0 December 1995

9 Interlayer service interfaces on the Mobile Station side

9.1 Services provided by the Radio Resource Management entity

The Radio Resource Management (RR) sublayer provides a service to the Mobility Management entity
(MM).

The RR services are used for:

- establishing control channel connections;

- releasing control channel connections;
- control-data transfer.

The Radio Resource Management services are represented by the RR-service primitives.

MS side Network side

Mobility
Management
sublayer

RR-prim itives

RR
SAP

RR sublayer peer-
to-peer protocol
Radio Resource
Management
sublayer

Figure 9.1/GSM 04.07 Services provided at RR-SAP - Mobile Station side

Page 36
GSM 04.07 Version 5.0.0 December 1995

9.1.1 Service state diagram

The primitives provided by the Radio Resource Management entity and the transition between permitted
states are shown in figure 9.2/GSM 04.07.

RR-EST- IDLE
REQ RR-UNIT-DATA-IND

RR-REL-IND RR-ABORT-IND
RR-ABORT-
REQ
CON ALL
PEND STATES
RR-EST-IND

RR-EST-CNF
DEDI- RR-SYNC-IND
CATED (ciph)
(res ass)
(channel mode modify)

RR-DATA-REQ-IND
RR-UNIT-DATA-IND

Figure 9.2/GSM 04.07 Service graph of the Radio Resource Management - Mobile Station side
 Page 37
GSM 04.07 Version 5.0.0 December 1995

9.1.2 Service primitives

Table 9.1/GSM 04.07 Primitives and parameters at the RR-SAP - Mobile Station side

PRIMITIVES PARAMETERS REFERENCE

RR_EST_REQ Layer 3 message 9.1.2.1

Transferred in the
SABM frame
RR_EST_IND - 9.1.2.2
RR_EST_CNF - 9.1.2.3
RR_REL_IND cause 9.1.2.4
RR_SYNC_IND cause (ciphering, res.ass, 9.1.2.5
channel mode modify)
RR_DATA_REQ Layer 3 message 9.1.2.6
RR_DATA_IND Layer 3 message 9.1.2.7
RR_UNIT DATA_IND Layer 3 message 9.1.2.8
RR_ABORT_REQ cause 9.1.2.9
RR_ABORT_IND cause 9.1.2.10
RR_ACT_REQ reselection mode 9.1.2.11

9.1.2.1 RR_EST_REQ

Is used by the Mobility Management entity to request establishment of a Mobile originated RR connection.
The request shall be given only in the IDLE state when the Mobile Station listens to the CCCH and the
previously selected BCCH.

9.1.2.2 RR_EST_IND

Indicates to the Mobility Management entity the establishment of a Mobile terminated RR connection. By
this indication MM is informed that a transparent connection exists and RR is in the dedicated mode.

9.1.2.3 RR_EST_CNF

Is used by RR to indicate the successful completion of a Mobile originated RR connection establishment.

RR connection exists and RR is in the dedicated mode.

9.1.2.4 RR_REL_IND

Is used by RR to indicate to the Mobility Management entity the release of a RR connection when RR has
received a CHANNEL RELEASE from the Network and has triggered a normal release of the data link
layer. It is also used to indicate that a requested RR connection cannot be established. In both cases, RR
returns to IDLE mode.
Page 38
GSM 04.07 Version 5.0.0 December 1995

9.1.2.5 RR_SYNC_IND

Is used for synchronizing RR and the Mobility Management entity after the establishment of a Mobile
originated or Mobile terminated RR connection. This indication is provided to MM in the following cases:

- ciphering has been started (ciphering);

- a traffic channel has been assigned (res. ass. = "resource assigned");
- the channel mode has been modified (channel mode modify).

9.1.2.6 RR_DATA_REQ

Is used by the Mobility Management entity to send control data to its peer entity on the Network side via
an existing RR connection.

9.1.2.7 RR_DATA_IND

Is used by RR to indicate control-data, which has been received from its peer entity on the Network side
via an existing RR connection.

9.1.2.8 RR_UNIT_DATA_IND

Is used by RR to provide MM with system info. The system info is received on the current BCCH if RR is in
the IDLE state. If a RR connection has been established, the system info is received on the SACCH.

9.1.2.9 RR_ABORT_REQ

Request to abort an existing RR connection or a RR connection in progress. The data link, if already
established, shall be released by a normal release procedure (DISC/UA) initiated by the Mobile Station.
This is the only way the Mobile Station can trigger the release of a RR connection in case of exceptional
conditions. The RR returns to the IDLE state.

9.1.2.10 RR_ABORT_IND

Indication that the RR connection has been aborted by a lower layer failure and RR has returned to the
IDLE state.
 Page 39
GSM 04.07 Version 5.0.0 December 1995

9.2 Services provided by the Mobility Management entity

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the
Supplementary Services Support (SS) entity and the Short Message Service Support (SMS) entity.

The Mobility Management services primitives are discriminated by the MMCC, MMSS and MMSMS prefix.

MS-side Network side

CC SS SMS CC SS SMS

MM-primitives
M MCC- MMSS- M MSM S-
SAP SAP SAP
MM peer-to-peer
protocol
Mobility management Mobility management
sublayer sublayer

Figure 9.3/GSM 04.07 Services provided at the MMCC-SAP, MMSS-SAP, MMSMS-SAP - Mobile
Station side
Page 40
GSM 04.07 Version 5.0.0 December 1995

9.2.1 Service state diagram

The primitives provided by the Mobility Management entity towards Call Control, call independent
Supplementary Service Support and towards Short Messages Service Support and the transition between
permitted states are illustrated in figure 9.4/GSM 04.07 below.

MMXX-UNIT-DATA-IND

IDLE
MMXX-EST-REQ
MMXX-REL-
REQ-IND
MMXX-
REL-
REQ

MMXX-REL-REQ/IND MMSS-
CON EST- CONN
PEND IND
SUSP
MMXX-
MMXX-UNIT- REEST-
DATA-IND REQ

MMXX-
ERR-
IND
MMXX-EST-CNF RE-
DEDI- EST-
CATED PEND
MMXX-REEST-CNF

MMCC-SYNC-IND
(channel mode modify)
(res ass)
MMXX-DATA-REQ IND
MMXX-UNIT-DATA-REQ IND

Figure 9.4/GSM 04.07 Service graph of the Mobility Management entity - Mobile Station side

NOTE 1: MMCC-primitives only at MMCC-SAP.

NOTE 2: The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS.
 Page 41
GSM 04.07 Version 5.0.0 December 1995

9.2.2 Service primitives

Table 9.2/GSM 04.07 Primitives and Parameters at MMCC-SAP, MMSS-SAP or MMSMS-SAP -

Mobile Station side

PRIMITIVES PARAMETERS REFERENCE

MMXX_EST_REQ 1) Parameters for the appropriate 9.2.2.1

CM SERVICE REQUEST (if any)
MMXX_EST_IND 1) First CM message 9.2.2.2
MMXX_EST_CNF 1) - 9.2.2.3
MMXX_REL_REQ 1) cause 9.2.2.4
MMXX_REL_IND 1) cause 9.2.2.5
MMXX_DATA_REQ 1) Layer 3 message 9.2.2.6
MMXX_DATA_IND 1) Layer 3 message 9.2.2.7
MMXX_UNIT_DATA_REQ 1) Layer 3 message 9.2.2.8
MMXX_UNIT_DATA_IND 1) Layer 3 message 9.2.2.9
MMCC_SYNC_IND 2) cause: res.ass 9.2.2.10
MMXX_REEST_REQ 1) 9.2.2.11
MMXX_REEST_CNF 1) 9.2.2.12
MMXX_ERR_IND 1) cause 9.2.2.13

NOTE 1: MMXX is used as substitution for MMCC, MMSS or MMSMS

NOTE 2: Only at MMCC-SAP

9.2.2.1 MMXX_EST_REQ

Request used by CC, SS and SMS respectively, to request establishment of a MM connection. Several
MM connections may be provided in parallel to the requesting entities. The primitive may contain
parameters which are relevant for the CM SERVICE REQUEST message, e.g. to distinguish a basic call
from an emergency call.

9.2.2.2 MMXX_EST_IND

Indication to CC, SS or SMS that a Mobile terminated MM connection has been established and the first
message has been received from the respective peer entity. Several MM connections may be provided in
parallel. If a MM connection already exists, a new MM connection using the same RR connection is
indicated by this primitive if MM detects a message with a new combination of Protocol Discriminator (PD)
and Transaction Identifier (TI).

9.2.2.3 MMXX_EST_CNF

Successful confirmation of the MM connection establishment by the MM sublayer to be given to the

appropriate entity which has requested the service.
Page 42
GSM 04.07 Version 5.0.0 December 1995

9.2.2.4 MMXX_REL_REQ

Used by CC, SS or SMS respectively, to request release of the MM connection. The corresponding PD/TI
will be released and may be used for a new MM connection.

9.2.2.5 MMXX_REL_IND

Indication of the release of an existing MM connection or a MM connection in progress. This primitive is

used in exceptional cases to indicate that the MM connection cannot be established or kept any longer and
PD/TI have been released.

9.2.2.6 MMXX_DATA_REQ

Request used by the CC, SS or SMS entities for acknowledged control-data transmission.

9.2.2.7 MMXX_DATA_IND

Indication used by MM to transfer the received acknowledged control-data to the CC, SS or SMS entities.

9.2.2.8 MMXX_UNIT_DATA_REQ

Request used by the CC, SS or SMS entities for unacknowledged control-data transmission.

9.2.2.9 MMXX_UNIT_DATA_IND

Indication used by MM to transfer the received unacknowledged control-data to the CC, SS or SMS
entities.

9.2.2.10 MMCC_SYNC_IND

Indication that a dedicated channel assignment has been performed and/or the channel mode has been
changed (only towards the CC entity).

9.2.2.11 MMXX_REEST_REQ

Request to establish a MM connection which has been interrupted by a lower layer failure. The interruption
must have been indicated by MMXX_ERR_IND.

9.2.2.12 MMXX_REEST_CNF

Confirmation of the successful re-establishment of the MM connection. The MM connection will continue
with PD/TI as it had before.

9.2.2.13 MMXX_ERR_IND

Indication of a lower layer failure interrupting the MM connection. The PD/TI are still kept by MM. In case
of parallel transactions this indication is passed to all CM entities for which a MM connection has been
established. It is left to the decision of the appropriate CM entity to either request the re-establishment of
the MM connection by MMXX_REEST_REQ or to release it by MMXX_REL_REQ.
 Page 43
GSM 04.07 Version 5.0.0 December 1995

10 Interlayer service interfaces on the Network side

10.1 Services provided by the Radio Resource Management entity

The Radio Resource Management (RR) sublayer provides services to the Mobility Management entity
(MM).

The RR services are used for:

- establishing control channel connections;

- establishing traffic channel connections;
- ciphering mode indication;
- releasing control channel connections;
- control-data transfer.

The Radio Resource Management services are represented by the RR service primitives.

MS side Network side

Mobility
Management
sublayer

RR-primitives

RR-
SAP

RR sublayer peer-
to-peer protocol
Radio Resource
Management
sublayer

Figure 10.1/GSM 04.07 Services provided at RR-SAP - Network side

Page 44
GSM 04.07 Version 5.0.0 December 1995

10.1.1 Service state diagram

The primitives provided by the Radio Resource Management entity and the transition between permitted
states are shown in figure 10.2/GSM 04.07 below.

RR-UNIT-DATA-REQ
RR-REL-REQ IND

IDLE
RR-EST-REQ

RR-REL-REQ IND
RR-REL-REQ IND
RR-ABOURT-REQ IND
RR-ABORT-REQ IND
CON RR-EST-IND
PEND
RR-UNIT-
DATA-REQ

RR-SYNC-CNF
RR-EST-CNF Note 1

RR-DATA-REQ IND
RR-SYNC-REQ RR-UNIT-DATA-REQ IND
(res ass)
(ciph)
(channel mode modify)
RR-DATA-REQ IND
RR-UNIT-DATA-REQ IND

STATES:

IDLE - No dedicated channel established.

CONPEND - Connection pending.
DT1 - Data transfer 1, dedicated channel established.
DT2 - Data transfer 2, dedicated channel established, ciphering mode set.

Figure 10.2/GSM 04.07 Service graph of the Radio Resource Management entity - Network side
 Page 45
GSM 04.07 Version 5.0.0 December 1995

10.1.2 Service primitives

Table 10.1/GSM 04.07 Primitives and Parameters at the RR-SAP - Network side

PRIMITIVES PARAMETERS REFERENCE

RR_EST_REQ Parameters for the 10.1.2.1

Initial layer 3 message
RR_EST_IND Initial layer 3 message 10.1.2.2
RR_EST_CNF - 10.1.2.3
RR_REL_REQ cause 10.1.2.4
RR_REL_IND cause 10.1.2.5
RR_SYNC_REQ cause (resource assign, 10.1.2.6
ciphering)
RR_SYNC_CNF cause (resource assign, 10.1.2.7
ciphering)
RR_DATA_REQ Layer 3 message 10.1.2.8
RR_DATA_IND Layer 3 message 10.1.2.9
RR_UNIT_DATA_REQ Layer 3 message 10.1.2.10
RR_UNIT_DATA_IND Layer 3 message 10.1.2.11
RR_ABORT_REQ cause 10.1.2.12
RR_ABORT_IND cause 10.1.2.13

10.1.2.1 RR_EST_REQ

Request used by the Mobility Management entity to request establishment of control channel connections.

10.1.2.2 RR_EST_IND

Indication to the Mobility Management entity that the establishment of control channel connections has
been done.

10.1.2.3 RR_EST_CNF

Confirmation used by RR to confirm the establishment of a requested control channel connection.

Page 46
GSM 04.07 Version 5.0.0 December 1995

10.1.2.4 RR_REL_REQ

Request used by the Mobility Management to release a control channel connection.

10.1.2.5 RR_REL_IND

Indication from RR to MM that the main signalling link has been released.

10.1.2.6 RR_SYNC_REQ

Request used by the Mobility Management entity for synchronization with the RR protocol.

10.1.2.7 RR_SYNC_CNF

Confirmation used by RR that the requested synchronization is done.

10.1.2.8 RR_DATA_REQ

Request used by the Mobility Management entity for acknowledged control-data transmission.

10.1.2.9 RR_DATA_IND

Indication used by RR to transfer received control-data, which should be acknowledged, to the Mobility
Management entity.

10.1.2.10 RR_UNIT_DATA_REQ

Request used by the Mobility Management entity for unacknowledged control-data transmission.

10.1.2.11 RR_UNIT_DATA_IND

Indication used by RR to transfer received control-data, which should not be acknowledged, to the Mobility
Management entity.

10.1.2.12 RR_ABORT_REQ

Request of the abandon of the RR connection.

10.1.2.13 RR_ABORT_IND

Indication that a radio link failure has occurred.

 Page 47
GSM 04.07 Version 5.0.0 December 1995

10.2 Services provided by the Mobility Management entity

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the
Supplementary Service Support (SS) entity and the Short Message Service Support (SMS) entity.

The Mobility Management services primitives are recognised by the MMCC, MMSS and MMSMS prefix.

MS-side Network side

CC SS SMS CC SS SMS

MM-primitives
MMCC- MMSS- MMSMS-
SAP SAP SAP
MM peer-to-peer
protocol

Mobility management Mobility management

sublayer sublayer

Figure 10.3/GSM 04.07 Services provided at MMCC-SAP, MMSS-SAP, MMSMS-SAP - Network side
Page 48
GSM 04.07 Version 5.0.0 December 1995

10.2.1 Service state diagram

The primitives provided by the Mobility Management entity towards Call Control, Short Messages Service
Support and call independent Supplementary Services Support as well as the transition between permitted
states are illustrated in figure 10.4.

MMXX-UNIT-DATA-REQ

MMXX-EST-REQ IDLE

MMXX-REL-REQ IND

MMCC-REL-REQ IND
CON MMXX-EST-IND
PEND

MMXX-UNIT-
DATA-REQ

MMCC-SYNC-CNF
Note 1
MMXX-EST-CNF DT DT
1 2 MMCC-DATA-REQ IND
MMCC-SYNC-REQ
(res ass) MMCC-UNIT-DATA-REQ IND
(channel mode modify)

MMXX-DATA-REQ IND
MMXX-UNIT-DATA-REQ IND

Figure 10.4/GSM 04.07 Service graph of the Mobility Management entity, towards Call Control -
Network side

NOTE 1: the parameters in RR_SYNC_CNF must correspond to the parameter in

RR_SYNC_REQ.

NOTE 2: MMCC-primitives only at MMCC-SAP.

NOTE 3: The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS.
 Page 49
GSM 04.07 Version 5.0.0 December 1995

10.2.2 Service primitives

Table 10.2/GSM 04.07 Primitives and Parameters at MMCC-SAP, MMSS-SAP, MMSMS-SAP -

Network side

PRIMITIVES PARAMETERS REFERENCE

MMXX_EST_REQ 1) Mobile ID 10.2.2.1

MMXX_EST_IND 1) First CM message 10.2.2.2
MMXX_EST_CNF 1) - 10.2.2.3
MMXX_REL_REQ 1) cause 10.2.2.4
MMXX_REL_IND 1) cause 10.2.2.5
MMXX_DATA_REQ 1) Layer 3 message 10.2.2.6
MMXX_DATA_IND 1) Layer 3 message 10.2.2.7
MMXX_UNIT_DATA_REQ 1) Layer 3 message 10.2.2.8
MMXX_UNIT_DATA_IND 1) Layer 3 message 10.2.2.9
MMCC_SYNC_REQ 2) cause (resource assign) 10.2.2.10
MMCC_SYNC_CNF 2) cause (resource assign) 10.2.2.11

NOTE 1: MMXX is used as substitution for MMCC, MMSS or MMSMS.

NOTE 2: Only at MMCC-SAP.

10.2.2.1 MMXX_EST_REQ

Request by CC, SS and SMS respectively, for the establishment of a MM connection.

10.2.2.2 MMXX_EST_IND

Indication by the MM sublayer that a MM connection is established.

10.2.2.3 MMXX_EST_CNF

Confirmation of the MM connection establishment by the MM sublayer.

10.2.2.4 MMXX_REL_REQ

Request by CC, SS or SMS respectively, for the release of the MM connection.

10.2.2.5 MMXX_REL_IND

Indication by the MM sublayer that a MM connection has been released.

10.2.2.6 MMXX_DATA_REQ

Request by the CC, SS or SMS entities for acknowledged control-data transmission.

Page 50
GSM 04.07 Version 5.0.0 December 1995

10.2.2.7 MMXX_DATA_IND

Indication used by MM to transfer the received acknowledged control-data to the CC, SS or SMS entities.

10.2.2.8 MMXX_UNIT_DATA_REQ

Request used by the CC, SS or SMS entities for unacknowledged control-data transmission.

10.2.2.9 MMXX_UNIT_DATA_IND

Indication used by MM to transfer the received unacknowledged control-data to the CC, SS or SMS
entities.

10.2.2.10 MMCC_SYNC_REQ

Request used by the CC entity to synchronize with the MM entity (resource assign).

10.2.2.11 MMCC_SYNC_CNF

Confirmation used by the MM to inform the CC entity that synchronization is completed (resource assign).
 Page 51
GSM 04.07 Version 5.0.0 December 1995

11 Standard L3 Messages

In this section the structure of standard L3 messages and their basic handling are defined. Standard L3
messages are used in layer 3 protocols of the Um interface when the relevant protocol specifications, e.g.
TS GSM 04.08, define so.

11.1 Components of a standard L3 message

A standard L3 message consists of an imperative part followed by a non-imperative part. Both imperative
and non-imperative part are composed of information elements.

NOTE: A layer 3 message consists of an integer number of octets, at least one octet, cf. TS
GSM 04.06.

11.1.1 Format of information elements

An information element (IE) occurring in a standard layer 3 message is known as a standard IE. It consists
of a half octet or one or more octets. A standard IE may have the following components:

- an information element identifier (IEI);

- a length indicator (LI);
- a value part.

A standard IE has one of the formats shown in table 11.1/GSM 04.07:

Table 11.1/GSM 04.07 Formats of information elements

Format Meaning IEI present LI present Value part present

T Type only yes no no
V Value only no no yes
TV Type and Value yes no yes
LV Length and Value no yes yes
TLV Type, Length and yes yes yes
Value

11.1.1.1 Information element type and value part

Every standard IE has an information element type which determines the values possible for the value part
of the IE.

The value part of a standard IE either consists of a half octet or one or more octets; the value part of a
standard IE with format LV or TLV may be empty, i.e. consist of zero octets; if it consists of a half octet
and has format TV, its IEI consists of a half octet, too.

The value part of a standard IE may be further structured into fields.

11.1.1.2 Length indicator

The LI of a standard IE consists of one octet. It contains the binary encoding of the number of octets of
the IE occurring after the octet containing the LI, with bit 1 as the least significant bit. The length indicator
of a standard IE with empty value part indicates 0 octets.
Page 52
GSM 04.07 Version 5.0.0 December 1995

11.1.1.3 Information element identifier

The IEI of a standard IE consists of a half octet or one octet. A standard IE with IEI consisting of a half
octet has format TV, and its value part consists of a half octet.

11.1.1.4 Categories of IEs; order of occurrence of IEI, LI, and value part

Totally five categories of standard information elements are defined:

- information elements of format V or TV with value part consisting of 1/2 octet (type 1);

- information elements of format T with value part consisting of 0 octets (type 2);

- information elements of format V or TV with value part that has fixed length of at least one octet
(type 3);

- information elements of format TLV or LV with value part consisting of zero, one or more octets
(type 4);

- information elements of format V with value part consisting of zero, one or more octets (type 5).

Type 1 standard information elements of format V provide the value in bit positions 8, 7, 6, 5 of an octet
(see figure 11.1/GSM 04.07) or bits 4, 3, 2, 1 of an octet (see figure 11.2/GSM 04.07).

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ value part ³ - - - - ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.1/GSM 04.07 Type 1 IE of format V

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ - - - - ³ value part ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.2/GSM 04.07 Type 1 IE of format V

Type 1 standard information elements of format TV have an IEI of a half octet length; they provide the IEI
in bit positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, see
figure 11.3/GSM 04.07.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ IEI ³ value part ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.3/GSM 04.07 Type 1 IE of format TV

 Page 53
GSM 04.07 Version 5.0.0 December 1995

A type 2 standard IE has format T; its IEI consists of one octet, its value part is empty, see
figure 11.4/GSM 04.07.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ IEI ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.4/GSM 04.07 Type 2 IE

A type 3 standard information element has format V or TV; if it has format TV, its IEI consists of one octet
and proceeds the value part in the IE. The value part consists of at least one octet. See
figure 11.5/GSM 04.07 and figure 11.6/GSM 04.07.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ ³ octet n
ÃÄÄÄÄ value ÄÄÄ´
. .
. .
. .
ÃÄÄÄÄ ÄÄÄ´
³ part ³ octet n + k
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.5/GSM 04.07 Type 3 IE of format V (k = 0, 1, 2, ...)

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ IEI ³ octet n
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ ³ octet n + 1
ÃÄÄÄÄ value ÄÄÄ´
. .
. .
. .
ÃÄÄÄÄ ÄÄÄ´
³ part ³ octet n + k
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.6/GSM 04.07 Type 3 IE of format TV (k = 1, 2, ...)

Page 54
GSM 04.07 Version 5.0.0 December 1995

A type 4 standard information element has format LV or TLV. Its LI precedes the value part, which
consists of zero, one, or more octets; if present, its IEI has one octet length and precedes the LI. See
figure 11.7/GSM 04.07 and figure 11.8/GSM 04.07.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ LI ³ octet n
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ ³ octet n + 1
ÃÄÄÄÄ value ÄÄÄ´
. .
. .
. .
ÃÄÄÄÄ ÄÄÄ´
³ part ³ octet n + k
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.7/GSM 04.07 Type 4 IE of format LV (k = 0, 1, 2, ...)

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ IEI ³ octet n
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ LI ³ octet n + 1
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ ³ octet n + 2
ÃÄÄÄÄ value ÄÄÄ´
. .
. .
. .
ÃÄÄÄÄ ÄÄÄ´
³ part ³ octet n + k
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.8/GSM 04.07 Type 4 IE of format TLV (k = 1, 2, ...)

A type 5 standard information element has format V. Its value part consist of zero, one or more octets. An
information element of this type can only appear as the last information element in a L3 message for which
the layer 3 length is:

- indicated by layer 2; or
- pre-determined (e.g., by the channel used).
 Page 55
GSM 04.07 Version 5.0.0 December 1995

11.2 Imperative part of a standard L3 message

The imperative part of a standard L3 message is composed of (more than one) IEs having the format V or
LV.

11.2.1 Protocol discriminator

Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) information
element. It is a type 1 IE and has always format V. The PD identifies the L3 protocol to which the standard
layer 3 message belongs. The correspondence between L3 protocols and PDs is one-to-one.

For future evolution an extension mechanism is foreseen which allows the use of protocol discriminators
with one octet length, where bits 4 to one are coded as 1 1 1 0. For such future protocols,

• it is protocol dependent whether a skip indicator or transaction identifier is defined for the messages of
the protocol, and if yes, at which position in the message;

• it is protocol dependent whether a message type is defined for the messages of the protocol, and if
yes, at which position in the message;

The PD can take the following values:

Table 11.2/GSM 04.07 Protocol discriminator values

bits 4 3 2 1
0000 reserved for group call control
0001 reserved for broadcast call control
0010 reserved for PDSS1
0011 call control; call related SS messages
0100 reserved for PDSS2
0101 mobility management messages
0110 radio resources management messages
1001 SMS messages
1011 non call related SS messages
1110 reserved for extension of the PD to one octet length
1111 reserved for tests procedures described in TS GSM 11.10

If the network receives a standard L3 message with a protocol discriminator different from those specified
in table 11.2/GSM 04.07, the network may ignore the message or initiate the channel release procedure
defined in TS GSM 04.08.

If the mobile station receives a standard L3 message with a protocol discriminator different from those
specified in table 11.2/GSM 04.07, the mobile station shall ignore the message.

11.2.2 Skip indicator

Bits 5 to 8 of octet 1 of a standard L3 message may contain the skip indicator IE (this is defined by the
protocol). Unless otherwise specified in the protocol, the skip indicator IE is a type 1 IE and has format V
in a standard L3 message. The relevant protocol specification may define that a standard L3 message
received with certain values of the skip indicator shall be ignored.

NOTE: For skip indicators in messages of future protocols with one octet PD, cf.
Subclause 11.2.1.
Page 56
GSM 04.07 Version 5.0.0 December 1995

11.2.3 Transaction identifier

A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the
transaction identifier (TI) IE. The TI IE is a type 1 IE; it always has format V in a standard L3 message.

NOTE: For transaction identifiers in messages of future protocols with one octet PD, cf.
subclause 11.2.1.

The TI IE is coded as shown in figure 11.9/GSM 04.07 and table 11.3/GSM 04.07. It is composed of the
TI value and the TI flag.

The TI value and the TI flag occupy bits 5 - 7 and bit 8 of the first octet respectively.

TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction
a free TI value (i.e. a value not yet used for the given PD and with the given originator) is chosen and
assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction
ends, the associated TI value is free and may be reassigned to a later transaction.

Two identical transaction identifier values may be used when each value pertains to a transaction
originated at opposite ends of the interface. In this case the TI flag shall avoid ambiguity. The transaction
identifier flag can take the values "0" or "1". The TI flag is used to identify which end of the radio interface
originated a TI. The origination side always sets the TI flag to "0". The destination side always sets the TI
flag to a "1".

Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI
flag is to resolve simultaneous attempts to allocate the same TI value.

The TI may in future evolutions of the L3 protocols be extended by using a combination of bits in the TI
value field that is specified as "reserved for future extension" in table 11.3.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ TI ³ TI ³ - - - - ³ octet 1
³flag ³ value ³ ³
ÀÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.9/GSM 04.07 Transaction identifier

 Page 57
GSM 04.07 Version 5.0.0 December 1995

Table 11.3/GSM 04.07. Transaction identifier

TI flag (octet 1)
Bit
8
0 The message is sent from the side that originates the TI
1 The message is sent to the side that originates the TI

TI value (octet 1)
Bits
765
000 TI value 0
001 - - 1
010 - - 2
011 - - 3
100 - - 4
101 - - 5
110 - - 6
111 Reserved for future extension.

11.2.4 Message type

By default in every standard L3 message of a L3 protocol, the third IE of the imperative part is the
message type IE which is contained in octet 2 of the message. A protocol may, however, explicitly define
departures from this rule.

NOTE: For message types in messages of future protocols with one octet PD, cf.
subclause 11.2.1.

When a standard L3 message is received that is too short to contain a complete message type information
element, that message shall be ignored.

The message type IE is coded as shown in figure 11.10/GSM 04.07.

Bit 8 is encoded as "0"; value "1" is reserved for possible future use as an extension bit. A protocol entity
receiving a standard L3 message containing a message type IE with bit 8 encoded as 1 shall treat the
message type as not defined for the PD.

The MM messages and the CM messages using SAPI=0 sent from the mobile station to the network
specify the send sequence number N(SD) in bit 7. At the time when such a message is designated for
transmission, the value of N(SD) for the message to be transferred is set equal to the value of the send
state variable.

In all other standard layer 3 messages bit 7 is set to 0 by the sending side; the receiving side shall ignore
such messages if bit 7 is set to 1.

8 7 6 5 4 3 2 1
ÚÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 0 ³N(SD)³ Message type ³ octet 1
ÀÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Figure 11.10/GSM 04.07 Message type IE

Page 58
GSM 04.07 Version 5.0.0 December 1995

The message type determines the function of a message within a protocol in a given direction. The
meaning of the message type is therefore dependent on the protocol (the same value may have different
meanings in different protocols) and direction (the same value may have different meanings in the same
protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile
Station).

The reaction of a protocol entity receiving a message with message type not defined for the PD in that
direction is defined in the relevant protocol specification.

11.2.5 Further information elements of the imperative part

The message type IE of a standard L3 message may be followed by further IEs having the format V or LV
as defined in the relevant protocol specification.

If a standard L3 message is received that is too short to contain the complete imperative part as specified
in the relevant protocol specification, an imperative message part error is diagnosed. (The same error may
be diagnosed at detection of certain contents of the imperative part of a message; this is defined in the
relevant protocol specification.) The treatment of an imperative message part error is defined in the
relevant protocol specification.

11.3 Non-imperative part of a standard L3 message

The imperative part of a standard L3 message is followed by the (possibly empty) non-imperative part.
The relevant protocol specification defines where the imperative part of a standard L3 message ends. The
non-imperative part of a standard L3 message is composed of (zero, one, or several) IEs having the
format T, TV, or TLV. The receiver of a standard L3 message shall be prepared for the non-imperative
part of the message to contain IEs that are not specified in the relevant protocol specification; the receiver
will assume that the first octet of such IEs contains the IEI.

An IEI may be known in a message or unknown in a message. Whether it is known or unknown in the
message, is defined in the relevant protocol specification.

An IEI that is known in a message designates the IE type of the IE the first part of which the IEI is. Which
IE type it designates, is specified in the relevant protocol specification. Within a message, different IEIs
may designate the same IE type if that is defined in the relevant protocol specification.

Whether the second part of an IE with IEI known in a message is the length or not (in other words,
whether the IEI is the first part of an IE formatted as TLV or not) is specified in the relevant protocol
specification.

The relevant protocol specification defines which category and format of an IE the receiving side shall
assume if the IE occurs in the non-imperative part of a received standard L3 message with IEI unknown in
the message.

A message may contain two or more IEs with equal IEI.

 Page 59
GSM 04.07 Version 5.0.0 December 1995

11.4 Presence requirements of information elements

The relevant protocol specification may define three different presence requirements (M, C, or O) for an IE
within a given message:

- M ("Mandatory") means that the IE shall be included by the sending side, and that the receiver
diagnoses a "missing mandatory IE" error when detecting that the IE is not present. An IE belonging
to the imperative part of a message has presence requirement M. An IE belonging to the non-
imperative part of a message may have presence requirement M;

- C ("Conditional") means:

* that inclusion of the IE by the sender depends on conditions specified in the relevant protocol
specification;

* that there are conditions for the receiver to expect that the IE is present and/or conditions for
the receiver to expect that the IE is not present; these conditions depend only on the
message itself, and not on the state in which the message was received; they are known as
static conditions;

* that the receiver detecting that the IE is not present when sufficient static conditions are
fulfilled for its presence, shall diagnose a "missing conditional IE" error;

* that the receiver detecting that the IE is present when sufficient static conditions are fulfilled
for its non-presence, shall diagnose an "unexpected conditional IE" error.

Only IEs belonging to the non-imperative part of a message may have presence requirement C;

- O ("Optional") means that the receiver shall never diagnose a "missing mandatory IE" error, a
"missing conditional IE" error, or an "unexpected conditional IE" error because it detects that the IE
is present or that the IE is not present. (There may however be conditions depending on the states,
resources, etc. of the receiver to diagnose other errors.) Only IEs belonging to the non-imperative
part of a message may have presence requirement O.

11.5 Handling of superfluous information

All equipment should be able to ignore any extra information present in a standard L3 message, which is
not required for the proper operation of that equipment. For example, a mobile station may ignore the
calling party BCD number if that number is of no interest to the Mobile Station when a SETUP message is
received.

11.5.1 Information elements that are unnecessary in a message

The relevant protocol specification may define certain IEs to be unnecessary in a standard L3 message. A
protocol entity detecting an unnecessary IE in a received standard L3 message shall ignore the contents of
that IE for treating the message; it is not obliged to check whether the contents of the IE are syntactically
correct.
 Mobile Station Network
CC MM RR L2 L2 RR MM CC
Page 60

MNCC-SETUP-REQ MMCC-EST-REQ RR-EST-REQ DL-RANDOM-ACC-REQ/IND (CHANN REQ)

(CM SERV REQ)

DL-UNIT-DATA-IND/REQ(IMM ASS)

DL-ASS-REQ SABM (CM SERV REQ) DL-EST-IND RR-EST-IND

(CM SERV REQ)

RR-EST-CNF DL-EST-CNF UA (CM SERV REQ)

AUTH REQ

AUTH RES

CIPH MODE CM D RR-SYNC-REQ

GSM 04.07 Version 5.0.0 December 1995

(ciph)

MMCC-EST-CNF RR-SYNC-IND CIPH MODE COM RR-SYNC-CNF

(ciph) (ciph)

SETUP MMCC-EST-IND MNCC-SETUP-IND

(SETUP)

MNCC-CALL- CALL PROC MNCC-CALL-

PROC-IND PROC-REQ

RR-SYNC-REQ
Annex A (informative): MN-Services arrow diagram

ASSIGN CMD MMCC-SYNC-REQ

(res ass) (res ass)

MMCC-SYNC-IND RR-SYNK-IND ASSIGN COM RR-SYNC-CNF MMCC-SYNC-CNF

(res ass) (res ass) (res ass) (res ass)

MNCC-ALERT-IND ALERT MNCC-ALERT-REQ

MNCC-SETUP-CNF CONNECT MNCC-SETUP-RSP

CONN ACK MNCC-SETUP-

COMPL-IND

DATA FLOW

Figure A.1 Mobile originated Call Setup. Successful case.

 Mobile Station Network

CC MM RR L2 L2 RR MM CC

DL-UNIT-DATA-IND/REQ (PAG REQ) RR-EST-REQ MMCC-EST-REQ MMCC-SETUP-REQ

(mob id) (mob id)

DL-RANDOM-ACC-REQ/IND (CHANN REQ)

DL-UNIT-DATA-IND/REQ (IMM ASS)

DL-EST-REQ SABM (PAG RES) DL-EST-IND RR-EST-CNF

RR-EST-IND DL-EST-CONF UA (PAG RES)

AUTH REQ

AUTH RES

CIPH MODE CMD RR-SYNC-REQ

(res ass)

RR-SYNC-IND CIPH MODE COM RR-SYNC-CNF MMCC-EST-CNF

(ciph) (res ass)
SETUP
MNCC-SETUP- MMCC-EST-IND
IND (SETUP)
CALL CONF MNCC-CALL-
MNCC-CALL-
CONF-REQ CONF-IND
ASSIGN CMD RR-SYNC-REQ MMCC-SYNC-REQ
(res ass) (res ass)

MMCC-SYNC-IND RR-SYNC-IND ASSIGN COM RR-SYNC-CNF MMCC-SYNC-CNF

(res ass) (res ass) (res ass) (res ass)

MNCC-ALERT- ALERT MNCC-ALE RT-IND

REQ
MNCC-SETUP-CNF
MNCC-SETUP- CONNECT
RES

MNCC-SETUP- CONN ACK MNCC-SETUP-

COMPL-IND COMPL-REQ

DATA FLOW

Figure A.2 Mobile terminated Call Setup. Successful case.

GSM 04.07 Version 5.0.0 December 1995
Page 61
 Mobile Station Network
Page 62

CC MM RR L2 L2 RR MM CC

DATA FLOW

MNCC-DISC-REQ DISCONNECT
MNCC-DISC-IND

MNCC-REL-IND RELEASE

MNCC-REL-REQ
GSM 04.07 Version 5.0.0 December 1995

RELEASE COM

MMCC-REL-REQ MNCC-REL-CNF

RR-REL-IND CHANN REL RR-REL-REQ MMCC-REL-REQ

DL-REL-REQ DISC DL-REL-IND

DL-REL-CNF UA

Figure A.3 Mobile Originating, Call Release & Channel Release Successful case
Mobile Station Network

CC MM RR L2 L2 RR MM CC

RR-EST-REQ DL-RANDOM-ACC-REQ/IND (CHANN REQ)

(LOC UPD)

DL-UNIT-DATA-IND/REQ (IMM ASS)

DL-EST-REQ SAHM (LOC UPD) DL-EST-IND RR-EST-IND

(LOC UP)
DL-EST-CNF UA (LOC UPD)

AUTH REQ

AUTH RES

CIPH MODE CMD RR-SYNC-REQ

(ciph)

CIPH MODE COM RR-SYNC-CNF

(ciph)

LOC UPD ACC

REAL COM

CHANN REL RR-REL-REQ

DL-REL-REQ DISC DL-REL-IND

DL-REL-CNF UA

Figure A.4 Location updating. Successful case.

GSM 04.07 Version 5.0.0 December 1995
Page 63
Mobile Station Network
Page 64

CC MM RR L2 L2 RR MM CC

DATA FLOW

HANDO CMD BS1

DL-SUS-REQ (local)

DL-REL-CNF (local)

BS2
GSM 04.07 Version 5.0.0 December 1995

PHYS INFO

DL-RES-REQ SAHM DL-EST-IND

DL-EST-CNF UA

HANDO COM

D AT A FLOW

Figure A.5 Handover. Successful case.

 Mobile Station Network
CM MM RR L2 L2 RR MM CM
MNX-SPECIFIC-REQ MMX-EST-REQ RR-EST-REQ CHANN REQ
(1MSG (X)) (CM SERV REQ)
IM-EST-REQ IMM ASS IM-EST-IND
(CM SERV REQ) (CM SERV REQ)
DL-EST-CNF SABM (CM SERV REL) RR-EST-IND
(CM SERV REQ)
RR-EST-CNF UA (CM SERV REQ)

AUTH REQ
Transaction X started

AUTH RES

CIPH MODE CMD NR-SYNC-REQ

(ciph)
MMX-EST-CNF RR-SYNC-IND CIPH MODE COM RR-SYNC-CNF
(ciph) (ciph)
MMX-DATA-REQ RR-DATA-RE1 1 MESSAGE (X) RR-DATA-IND MMXX-EST IND
(1MSG (X)) (1 MSG (X)) (1 MSG (X)) (1 MSG (X))
MMX-DATA-DND RR-DATA-DND 2 MESSAGE (X) RR-DATA-REQ MMX-DATA-REQ
(2MSG (X)) (2MSG (X)) 2 MSG (X)) 2 MSG (X))
ASSIGN CMD RR-SYNC-REQ MMX-SYNC-REQ
(res ass) (res ass)
MMX-SYNC-IND RR-SYNC-IND ASSIGN COM RR-SYNC-CNF MMX-SYNC-CNF
(res ass) (res ass) (res ass) (res ass)
MMX-DATA-REQ RR-DATA-REQ MESSAGE (X) RR-DATA-IND MMX-DATA-IND
(MSG (X)) (MSG (X)) (MSG (X)) (MSG (X))

MESSAG E OF T RANSAC TION X

MMY-SPECIFIC-REQ MMY-EST-REQ OM SERV REQ
(1MSG (Y)) (serv 1)
MMY-EST-CNF OM SERV ACC
(serv 2)
MMY-DATA-REQ RR-DATA-REQ 1 MESSAGE (Y) RR-DATA-IND MMY-EST-IND
(1 MSG (Y)) (1MSG (Y)) (1MSG (Y)) (1MSG (Y))
Transaction Y started

MESSAGE OF TRANSACTION X & Y

Figure A.6 Establishment of parallel transactions (General view)

GSM 04.07 Version 5.0.0 December 1995
Page 65
 Page 66

Mobile Station Network

CM MM RR L2 L2 RR MM CM

MESSAGE OF TRANSACTIONS X & Y

Last message of specific Protocol (x)

Transactio n
MMX-REL-REQ MMX-REL -R EQ released
GSM 04.07 Version 5.0.0 December 1995

MESSAGE OF TRANSA CTIONS Y

Last message of specific Protocol (y)

MMY-REL-REQ Transaction
RR-REL-IND CHANN REL MMY-REL-REQ released

DL-REL-REQ DISC DL-REL -IND

Channel
DL-REL-CNF UA released

Figure A.7 Release of parallel transactions (General view)

 Page 67
GSM 04.07 Version 5.0.0 December 1995

History

Document history
November 1995 Creation of Version 5.0.0 (Version 4.3.1 + AR04.07-002, 003, 004, 005)

December 1995 Publication of Version 5.0.0

February 1996 Converted into Adobe Acrobat Portable Document Format (PDF)

ISBN 2-7437-0436-5
Dépôt légal : Décembre 1995