GSM 04.07 - Version 5.1.0 - Digital cellular ... · GSM 04.07 Version 5.1.0 March 1996 Whilst every...

*

GSM GSM 04.07

TECHNICAL March 1996

SPECIFICATION Version 5.1.0

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

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)

ETSIEuropean Telecommunications Standards Institute

ETSI Secretariat

Postal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.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 theforegoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 1996. All rights reserved.

GSM 04.07 Version 5.1.0 March 1996

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.


Contents

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

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

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

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

4 Introduction............................................................................................................................. 114.1 General .................................................................................................................... 114.2 Applicability of functional blocks.................................................................................. 114.3 Technique of description ............................................................................................ 11

4.3.1 Service description ................................................................................. 124.3.2 Abstract service primitives ...................................................................... 124.3.3 Protocols and peer-to-peer communication............................................... 124.3.4 Contents of signalling layer 3 related Technical Specifications.................... 13

5 Structure of signalling layer 3 functions...................................................................................... 145.1 Basic groups of functions........................................................................................... 145.2 Protocol architecture ................................................................................................. 16

6 Services provided by signalling layer 3 at the Mobile Station side ................................................ 176.1 Registration services ................................................................................................. 17

6.1.1 Service state diagram............................................................................. 186.1.2 Service primitives ................................................................................... 19

6.1.2.1 MMR_REG_REQ ........................................................... 196.1.2.2 MMR_REG_CNF............................................................ 196.1.2.3 [reserved] ...................................................................... 196.1.2.4 MMR_NREG_REQ......................................................... 196.1.2.5 MMR_NREG_IND........................................................... 19

6.2 Call Control services.................................................................................................. 196.2.1 Service state diagram............................................................................. 196.2.2 Service primitives ................................................................................... 22

6.2.2.1 MNCC_SETUP_REQ...................................................... 236.2.2.2 MNCC_SETUP_IND........................................................ 236.2.2.3 MNCC_SETUP_RES ...................................................... 236.2.2.4 MNCC_SETUP_CNF....................................................... 236.2.2.5 MNCC_SETUP_COMPL_REQ ........................................ 236.2.2.6 MNCC_SETUP_COMPL_IND.......................................... 236.2.2.7 MNCC_REJ_REQ .......................................................... 236.2.2.8 MNCC_REJ_IND ............................................................ 236.2.2.9 MNCC_CALL_CONF_REQ ............................................. 236.2.2.10 MNCC_CALL_PROC_IND............................................... 236.2.2.11 MNCC_PROGRESS_IND................................................ 236.2.2.12 MNCC_ALERT_REQ ...................................................... 236.2.2.13 MNCC_ALERT_IND........................................................ 246.2.2.14 MNCC_NOTIFY_REQ .................................................... 246.2.2.15 MNCC_NOTIFY_IND ...................................................... 246.2.2.16 MNCC_DISC_REQ......................................................... 246.2.2.17 MNCC_DISC_IND .......................................................... 246.2.2.18 MNCC_REL_REQ .......................................................... 246.2.2.19 MNCC_REL_IND............................................................ 246.2.2.20 MNCC_REL_CNF........................................................... 246.2.2.21 MNCC_FACILITY_REQ.................................................. 24


6.2.2.22 MNCC_FACILITY_IND.................................................... 246.2.2.23 MNCC_START_DTMF_REQ ........................................... 246.2.2.24 MNCC_START_DTMF_CNF............................................ 246.2.2.25 MNCC_STOP_DTMF_REQ............................................. 246.2.2.26 MNCC_STOP_DTMF_CNF ............................................. 256.2.2.27 MNCC_MODIFY_REQ.................................................... 256.2.2.28 MNCC_MODIFY_IND ..................................................... 256.2.2.29 MNCC_MODIFY_RES .................................................... 256.2.2.30 MNCC_MODIFY_CNF .................................................... 256.2.2.31 MNCC_SYNC_IND ......................................................... 25

6.3 Call independent Supplementary Services Support....................................................... 266.3.1 Service state diagram............................................................................. 266.3.2 Service primitives ................................................................................... 27

6.3.2.1 MNSS_BEGIN_REQ....................................................... 276.3.2.2 MNSS_BEGIN_IND......................................................... 276.3.2.3 MNSS_FACILITY_REQ .................................................. 276.3.2.4 MNSS_FACILITY_IND .................................................... 276.3.2.5 MNSS_END_REQ .......................................................... 276.3.2.6 MNSS_END_IND ............................................................ 27

6.4 Short Message Services Support ............................................................................... 27

7 Services provided by signalling layer 3 on the Network side ........................................................ 287.1 Call control services .................................................................................................. 28


7.1.2.1 MNCC_SETUP_REQ ...................................................... 327.1.2.2 MNCC_SETUP_IND........................................................ 327.1.2.3 MNCC_SETUP_RSP....................................................... 327.1.2.4 MNCC_SETUP_CNF....................................................... 327.1.2.5 MNCC_SETUP_COMPL_REQ ........................................ 327.1.2.6 MNCC_SETUP_COMPL_IND .......................................... 327.1.2.7 MNCC_REJ_REQ........................................................... 327.1.2.8 MNCC_REJ_IND ............................................................ 327.1.2.9 MNCC_CALL_CONF_IND ............................................... 327.1.2.10 MNCC_CALL_PROC_REQ ............................................. 327.1.2.11 MNCC_PROGRESS_REQ .............................................. 327.1.2.12 MNCC_ALERT_REQ ...................................................... 327.1.2.13 MNCC_ALERT_IND........................................................ 337.1.2.14 MNCC_NOTIFY_REQ..................................................... 337.1.2.15 MNCC_NOTIFY_IND ...................................................... 337.1.2.16 MNCC_DISC_REQ......................................................... 337.1.2.17 MNCC_DISC_IND........................................................... 337.1.2.18 MNCC_REL_REQ .......................................................... 337.1.2.19 MNCC_REL_IND ............................................................ 337.1.2.20 MNCC_REL_CNF ........................................................... 337.1.2.21 MNCC_FACILITY_REQ .................................................. 337.1.2.22 MNCC_FACILITY_IND.................................................... 337.1.2.23 MNCC_START_DTMF_IND............................................. 337.1.2.24 MNCC_START_DTMF_RSP............................................ 337.1.2.25 MNCC_STOP_DTMF_IND .............................................. 337.1.2.26 MNCC_STOP_DTMF_RSP ............................................. 347.1.2.27 MNCC_MODIFY_REQ.................................................... 347.1.2.28 MNCC_MODIFY_IND ..................................................... 347.1.2.29 MNCC_MODIFY_RES .................................................... 347.1.2.30 MNCC_MODIFY_CNF .................................................... 34

7.2 Call independent Supplementary Services Support....................................................... 357.2.1 Service state diagram............................................................................. 357.2.2 Service primitives ................................................................................... 36

7.2.2.1 MNSS_BEGIN_REQ....................................................... 367.2.2.2 MNSS_BEGIN_IND......................................................... 36


7.2.2.3 MNSS_FACILITY_REQ .................................................. 367.2.2.4 MNSS_FACILITY_IND.................................................... 367.2.2.5 MNSS_END_REQ .......................................................... 367.2.2.6 MNSS_END_IND............................................................ 36

7.3 Short Message Services Support ............................................................................... 36

8 Services assumed from signalling layers 1 and 2 ....................................................................... 378.1 Priority ..................................................................................................................... 378.2 Unacknowledged information transfer ......................................................................... 378.3 Acknowledged information transfer............................................................................. 378.4 Random access ........................................................................................................ 378.5 Channel management and measurements ................................................................... 37

9 Interlayer service interfaces on the Mobile Station side .............................................................. 389.1 Services provided by the Radio Resource Management entity ...................................... 38


9.1.2.1 RR_EST_REQ ............................................................... 409.1.2.2 RR_EST_IND................................................................. 409.1.2.3 RR_EST_CNF................................................................ 409.1.2.4 RR_REL_IND................................................................. 409.1.2.5 RR_SYNC_IND .............................................................. 409.1.2.6 RR_DATA_REQ............................................................. 409.1.2.7 RR_DATA_IND............................................................... 419.1.2.8 RR_UNIT_DATA_IND ..................................................... 419.1.2.9 RR_ABORT_REQ .......................................................... 419.1.2.10 RR_ABORT_IND............................................................ 41

9.2 Services provided by the Mobility Management entity................................................... 429.2.1 Service state diagram............................................................................. 439.2.2 Service primitives ................................................................................... 44

9.2.2.1 MMXX_EST_REQ.......................................................... 449.2.2.2 MMXX_EST_IND............................................................ 449.2.2.3 MMXX_EST_CNF........................................................... 449.2.2.4 MMXX_REL_REQ.......................................................... 449.2.2.5 MMXX_REL_IND............................................................ 449.2.2.6 MMXX_DATA_REQ........................................................ 459.2.2.7 MMXX_DATA_IND ......................................................... 459.2.2.8 MMXX_UNIT_DATA_REQ .............................................. 459.2.2.9 MMXX_UNIT_DATA_IND ................................................ 459.2.2.10 MMCC_SYNC_IND......................................................... 459.2.2.11 MMXX_REEST_REQ ..................................................... 459.2.2.12 MMXX_REEST_CNF ...................................................... 459.2.2.13 MMXX_ERR_IND ........................................................... 45

10 Interlayer service interfaces on the Network side ....................................................................... 4610.1 Services provided by the Radio Resource Management entity ...................................... 46


10.1.2.1 RR_EST_REQ ............................................................... 4810.1.2.2 RR_EST_IND................................................................. 4810.1.2.3 RR_EST_CNF................................................................ 4810.1.2.4 RR_REL_REQ ............................................................... 4810.1.2.5 RR_REL_IND................................................................. 4810.1.2.6 RR_SYNC_REQ............................................................. 4810.1.2.7 RR_SYNC_CNF ............................................................. 4810.1.2.8 RR_DATA_REQ............................................................. 4810.1.2.9 RR_DATA_IND............................................................... 4910.1.2.10 RR_UNIT_DATA_REQ.................................................... 4910.1.2.11 RR_UNIT_DATA_IND ..................................................... 4910.1.2.12 RR_ABORT_REQ .......................................................... 49


10.1.2.13 RR_ABORT_IND ............................................................ 4910.2 Services provided by the Mobility Management entity................................................... 50


10.2.2.1 MMXX_EST_REQ .......................................................... 5210.2.2.2 MMXX_EST_IND............................................................ 5210.2.2.3 MMXX_EST_CNF........................................................... 5210.2.2.4 MMXX_REL_REQ .......................................................... 5210.2.2.5 MMXX_REL_IND............................................................ 5210.2.2.6 MMXX_DATA_REQ........................................................ 5210.2.2.7 MMXX_DATA_IND ......................................................... 5210.2.2.8 MMXX_UNIT_DATA_REQ............................................... 5210.2.2.9 MMXX_UNIT_DATA_IND ................................................ 5210.2.2.10 MMCC_SYNC_REQ ....................................................... 5310.2.2.11 MMCC_SYNC_CNF........................................................ 53

11 Standard L3 Messages............................................................................................................ 5411.1 Components of a standard L3 message...................................................................... 54

11.1.1 Format of information elements ............................................................... 5411.1.1.1 Information element type and value part ........................... 5411.1.1.2 Length indicator .............................................................. 5411.1.1.3 Information element identifier ........................................... 5511.1.1.4 Categories of IEs; order of occurrence of IEI, LI, and

value part ....................................................................... 5511.2 Imperative part of a standard L3 message .................................................................. 58

11.2.1 Protocol discriminator ............................................................................. 5811.2.2 Skip indicator ......................................................................................... 5811.2.3 Transaction identifier............................................................................... 5911.2.4 Message type ........................................................................................ 6011.2.5 Further information elements of the imperative part ................................... 61

11.3 Non-imperative part of a standard L3 message............................................................ 6111.4 Presence requirements of information elements........................................................... 6211.5 Handling of superfluous information............................................................................. 62

11.5.1 Information elements that are unnecessary in a message .......................... 62

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

History ............................................................................................................................................. 70


Foreword

This Global System for Mobile communications 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 interfacebetween 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 TelecommunicationsStandard from which this Phase 2+ GTS has evolved is Phase 2GSM ETS 300 556 (GSM 04.07 version 4.3.1).

GTSs 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 EuropeanTelecommunications 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 Mobilecommunications.

The contents of this GTS are subject to continuing work within TC-SMG and may change following formalTC-SMG approval. Should TC-SMG modify the contents of this GTS it will then be republished by ETSIwith 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 theimplementation of the digital cellular telecommunications system. Historically, thesedocuments have been identified as GSM Technical Specifications (GSM-TSs). TheseTSs may have subsequently become I-ETSs (Phase 1), or ETSs/ETSI TechnicalReports (ETRs) (Phase 2). TC-SMG has also produced ETSI GSM TSs which give thetechnical specifications for the implementation of Phase 2+ enhancements of the digitalcellular telecommunications system. These version 5.x.x GSM Technical Specificationsmay be referred to as ETSs.


Blank page


1 Scope

This Global System for Mobile communications Technical Specification (GTS) defines the principalarchitecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface between MobileStation and network; for the CM sublayer, the description is restricted to paradigmatic examples, callcontrol, supplementary services, and short message services. It also defines the basic message formatand error handling applied by the layer 3 protocols.

The corresponding protocols are defined in other Technical Specifications, cf. Subclause 4.3.4.

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

2 Normative references

This GTS incorporates by dated and undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to or revisions of any of these publications applyto this GTS only when incorporated in it by amendment or revision. For undated references, the latestedition of the publication referred to applies.

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

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

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

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

[5] GSM 04.06 (ETS 300 555): "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): "Digital cellular telecommunications system(Phase 2); Mobile radio interface layer 3 specification".

[7] GSM 04.10 (ETS 300 558): "Digital cellular telecommunications system(Phase 2); Mobile radio interface layer 3 Supplementary services specificationGeneral aspects".

[8] GSM 04 11 (ETS 300 559): "Digital cellular telecommunications system(Phase 2); Point-to-Point (PP) Short Message Service (SMS) support on mobileradio interface".

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

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

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


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

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

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

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

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

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

[18] CCITT Recommendation X.200: "Reference Model of Open systemsinterconnection for CCITT Applications".

3 Abbreviations

Abbreviations used in this specification are also listed in GSM 01.04.

For the purpose of this specification the following abbreviations apply:

MNS Mobile Network Signalling


4 Introduction

4.1 General

The signalling layer 3 provides the functions necessary

• for Radio Resource (RR) management,

• for Mobility Management (MM), and

• for the Connection Management (CM) functions, i.e. functions for the control, provision, and support ofservices offered by the network; among which there are, e.g.:

◊ the functions to establish, maintain and terminate circuit-switched connections across a GSMPLMN and other networks to which the GSM PLMN is connected,

◊ supporting functions for supplementary services control,

◊ supporting functions for short messages service control.

The signalling 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 functional blocks for:

- Call Control (CC);- Short Message Service Support (SMS);- Supplementary Services Support (SS);- Group Call Control;- Broadcast Call Control (BCC);- Connection Management of Packet Data on Signalling channels.

This Technical Specification does not consider the distribution of signalling functions among the differentnetwork equipments. The signalling functions are described between two systems which represent themobile station side and the network side of the radio interface of layer 3. Only the functions in the networkfor signalling communication with one mobile station is considered.

4.2 Applicability of functional blocks

Not for all functional blocks listed in subclause 4.1, support in the mobile station or in the network ismandatory:

- Support of Group Call Control is optional in the mobile station and in the network.- Support of Broadcast Call Control is optional in the mobile station and in the network.- Connection Management of Packet Data on Signalling channels. is optional in the mobile station and

in the network.

Further conditions and constraints are defined in other Technical Specifications.

4.3 Technique of description

Signalling layer 3 and its sub-layers are specified by

- their service specification, see 4.3.1- their protocol specification, see 4.3.3;- the specification of functions, see clause 5.


4.3.1 Service description

The services of signalling layer 3 and its sublayers are described in terms of:

- services provided to upper (sub-)layers at the service access points;- services assumed from lower (sub-)layers at the service access points;

Layer 3 and its supporting lower layers provide the Mobile Network Signalling (MNS) Service to the upperlayers.

The service provided/assumed at the service access points are described by means of abstract serviceprimitives and parameters as recommended in CCITT Recommendation X.200.

4.3.2 Abstract service primitives

The abstract service primitives consist of requests, responses, indications and confirmations. The generalsyntax of a primitive is specified in TS GSM 04.01.

4.3.3 Protocols and peer-to-peer communication

By use of the services provided by lower (sub-)layers, peer entities in a (sub-)layer in the mobile stationand the network exchange information. Exchange of information between two peer entities is performedaccording to the corresponding (sub-)layer protocols. A protocol is a set of rules and formats by which theinformation (control information and user data) is exchanged between the two peers. The information isexchanged by use of messages which are defined in the protocol. (Therefore, the messages are alsocalled Protocol Data Units, PDUs).

There is a protocol of the RR sublayer, a protocol of the MM sublayer, and several protocols of the CMsublayer: for each functional block of the CM sublayer as defined in subclause 4.1 there is one protocol.The CM protocols are specified in the Technical Specifications identified in subclause 4.3.4.

In the model used in this TS, there is

• one RR sub-layer entity in the mobile station and one RR sub-layer entity in the network

• one MM sub-layer entity in the mobile station and one MM sub-layer entity in the network;

• for each functional block of the CM sublayer as defined in subclause 4.1 which is supported in themobile station (in the network), there are, depending on the protocol, one or more entities in the mobilestation (in the network). Two different entities of the same functional block in the mobile station (in thenetwork) are called parallel entities. The entities of the same functional block in the mobile stationcorrespond in a one-to-one relation to the entities of the functional block in the network. Thecorresponding entities are called peer entities.

As each sub-layer entity is specified by one and only one protocol, it is also called a protocol entity orprotocol control entity.

When two peer protocol entities exchange PDUs, a transaction is said to be established (or: to be active;or: to exist). It depends from the protocol when exactly a protocol entity considers the transaction to beactive, normally this is the case

• from the moment when it has passed the first suitable message to lower (sub-) layers or received thefirst suitable message from its peer entity

up to the moment when it has released the transaction.


4.3.4 Contents of signalling layer 3 related Technical Specifications

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 and TS GSM

04.9x;the Short Message Service (SMS) protocol is defined in TS GSM 04.11;the Group Call Control (GCC) protocol is defined in TS GSM 04.68;the Broadcast Call Control (BCC) protocol is defined in TS GSM 04.69;the protocols for Packet Data on Signalling channels (PDS), PDSS1 and PDSS2, are defined in TS GSM

04.63.


5 Structure of signalling layer 3 functions

5.1 Basic groups of functions

Most functions of signalling layer 3 and its sub-layers are described by the service specifications andprotocol specifications of the (sub-)layers.

These functions are in the model realized by protocol control entities, see 4.3.3.

In addition, routing functions are contained in layer 3 which are related to the transport of messages, e.g.multiplexing and splitting. These routing functions are defined in the Radio Resource Management andMobility Management sub-layers.

1. They have the task to pass the messages from upper (sub-)layers to lower (sub-)layers.

2. They also have the task to pass messages provided by lower (sub-layers) to the appropriate sub-layerand, if applicable, entity.

The routing functions with task 2 make use of the protocol discriminator (PD) which is part of the messageheader.

A CM sublayer protocol may also define a transaction identifier (TI) as a part of the message header. Thisis at least the case if there are parallel entities of the same functional block, see 4.3.3. If it is a part of amessage, the TI is also used by the routing functions.

• The MM routing function passes the messages of the CM entities as well as of the MM entity of its ownsublayer to the service access point of RR and multiplexes them in case of parallel transactions.

• The routing function of Radio Resource Management distributes the messages to be sent according totheir protocol discriminator (PD), to the actual channel configuration, and, if applicable, to furtherinformation received from upper sub-layers to the appropriate service access point of layer 2 (identifiedby SAPI and logical channel).

• The messages provided at the different service access points of layer 2 are distributed by the RRrouting function according to their protocol discriminator (PD). Messages with a PD equal to RR arepassed to the RR entity of the own sublayer, all other messages are passed to the MM sublayer at theservice access point RR-SAP.

• The routing function of MM passes the messages according to the protocol discriminator (PD) and, ifapplicable, the transaction identifier (TI) towards the MM entity or towards the CM entities via thevarious MM-SAP's.

The message (message header or other parts of the message) are neither changed nor removed by theRR routing function or MM routing function before passing it to the appropriate service access point.


Figure 5.1/GSM 04.07 shows the protocol architecture, restricting the representation of CM sublayerprotocols to three paradigmatic examples, CC, SS, and SMS.

RAC

H

AG

CH

+P

CH

SA

CC

H

FA

CC

H

SD

CC

H

SAPI 0 SAPI 3

RR

MM

PD

MM CC SS SMS

MMREG-SAPMMCC-SAP

MMSS-SAP

MMSMS-SAP

CC SS SMS

MOBILENETWORKSERVICE MNCC-SAP MNSS-SAP MNSMS-SAP

BC

CH

SD

CC

H

SA

CC

H

RR-SAP

RR

LAY

ER

3 S

IGN

AL

LIN

G

=RR

TI TI TI

PD

Figure 5.1/GSM 04.07 Protocol Architecture of Signalling Layer 3 - Mobile Station side


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, among others, 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 atthe 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;- other services corresponding to further functional blocks of the CM sublayer at the appropriate

service access points. These services are not further described in this clause.

6.1 Registration services

The registration services (location updating, IMSI attach/detach) are provided at the service access pointMMREG-SAP. As opposed to all other MN-Services, these services are provided by and can be directlyaccessed at the Mobility Management sublayer.


6.1.1 Service state diagram

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

MMR-NREG-REQ IND

MMR-NREG-REQ IND

MMR-REG-ING

UP-DATED

NOT UP-DATED

WAIT UP-DATING

MMR-REG-CNF

MMR-REG-REQ

MMR-REG-REQ

MMR-REG-REQ

MMR-NREG-REQ-IND

Figure 6.1/GSM 04.07 Registration services provided at MMREG-SAP - Mobile Station side


6.1.2 Service primitives

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

PRIMITIVE PARAMETER REFERENCEMMR_REG_REQ IMSI 6.1.2.1MMR_REG_CNF - 6.1.2.2MMR_NREG_REQ - 6.1.2.4MMR_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 withinserted 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 offphase.

6.1.2.5 MMR_NREG_IND

Indication that registration has been cancelled or that registration was not possible. Only emergencyservices 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.


The Call Control services provided at the service access point MNCC-SAP are illustrated in the statediagram of figure 6.2/GSM 04.07.


RE

LEA

SE

RE

QU

ES

T

DIS

ON

NE

CT

IND

ICA

TIO

N

S

TA

TE

S3

,4,7

,8,9

,10

DIS

CO

NN

EC

TR

EQ

UE

ST

CA

LL IN

IT

NO

CA

LL

PR

OC

EE

DIN

G

RE

LEA

SE

R

EQ

UE

ST

CA

LLD

ELI

VE

RE

D

AC

TIV

E

CA

LLR

EC

EIV

ED

CO

NN

EC

TR

EQ

UE

ST

MT

CA

LL

CO

NF

IRM

ED

CA

LL

PR

ES

EN

T

NU

LL0

1 3 419

10

19

12

6 9

7

8

11

MN

CC

-SE

TU

P-I

ND

MN

CC

-RE

J-R

EQ

MN

CC

-RE

L-R

EQ

M

NC

C-

DIS

C-

IND

MN

CC

-R

EL-

IND

MN

CC

-RE

J-IN

D

MN

CC

-SE

TU

P-R

EQ

MN

CC

-DIS

C-

RE

Q

MN

CC

-D

ISC

-IN

DM

NC

C-C

AL

L-C

ON

F-R

EQ

MN

CC

-S

ET

UP

-R

SP

MN

CC

-A

LER

T-

RE

Q

MN

CC

-S

ET

UP

-RS

P

MN

CC

-SE

TU

P-

CO

MP

L-IN

D (

ER

R)

MN

CC

-D

ISC

-IN

D

MN

CC

-D

ISC

- R

EQ

MN

CC

-SE

TU

P-C

OM

P-I

ND

MN

CC

-SE

TU

P-

CN

F

MN

CC

-S

ET

UP

-C

NF

MN

CC

-A

LER

T-

IND

MN

CC

-RE

L-R

EQ

MN

CC

-P

RO

GR

ES

S-

IND

MN

CC

-CA

LL

PR

OC

-IN

D

MN

CC

- R

EL-

CN

F

MN

CC

-F

AC

ILIT

Y-

IND

AN

Y S

TA

TE

EX

CE

PT

0A

NY

ST

AT

EM

NC

C-

RE

L-IN

D

0A

NY

ST

AT

EE

XC

EP

T 0

,19

MN

CC

-F

AC

ILIT

YR

EQ

Figure 6.2/GSM 04.07 Service graph of Call Control entity - Mobile Station side(page 1 of 2)


10 ACTIVE

28 M0 MODIFY

MNCC-MODIFY-CNFMNCC-MODIFY-REQ

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

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)



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

PRIMITIVE PARAMETER (message, info elementsof message, other parameters)

REFERENCE

MNCC_SETUP_REQ SETUP or EMERGENCY SETUP, 6.2.2.1

MNCC_SETUP_IND SETUP 6.2.2.2MNCC_SETUP_RSP CONNECT 6.2.2.3MNCC_SETUP_CNF CONNECT 6.2.2.4MNCC_SETUP_COMPLETE_REQ - 6.2.2.5MNCC_SETUP_COMPLETE_IND - 6.2.2.6MNCC_REJ_REQ RELEASE COMPLETE 6.2.2.7MNCC_REJ_IND cause 6.2.2.8MNCC_CALL_CONF_REQ CALL CONFIRMED 6.2.2.9MNCC_CALL PROC_IND CALL PROCEEDING 6.2.2.10MNCC_PROGRESS_IND PROGRESS 6.2.2.11MNCC_ALERT_REQ ALERTING 6.2.2.12MNCC_ALERT_IND ALERTING 6.2.2.13MNCC_NOTIFY_REQ NOTIFY 6.2.2.14MNCC_NOTIFY_IND NOTIFY 6.2.2.15MNCC_DISC_REQ DISCONNECT 6.2.2.16MNCC_DISC_IND DISCONNECT 6.2.2.17MNCC_REL_REQ RELEASE 6.2.2.18MNCC_REL_IND RELEASE 6.2.2.19MNCC_REL_CNF RELEASE or RELEASE COMPLETE 6.2.2.20MNCC_FACILITY_REQ facility 6.2.2.21MNCC_FACILITY_IND facility 6.2.2.22MNCC_START_DTMF_REQ START DTMF 6.2.2.23MNCC_START_DTMF_CNF START DTMF ACK or 6.2.2.24

START DTMF REJMNCC_STOP_DTMF_REQ STOP DTMF 6.2.2.25MNCC_STOP_DTMF_CNF STOP DTMF ACK 6.2.2.26MNCC_MODIFY_REQ MODIFY 6.2.2.27MNCC_MODIFY_IND MODIFY 6.2.2.28MNCC_MODIFY_RES MODIFY COMPLETE 6.2.2.29MNCC_MODIFY_CNF MODIFY COMPLETE 6.2.2.30MNCC_SYNC_IND cause (res. ass., channel mode modify) 6.2.2.31


6.2.2.1 MNCC_SETUP_REQ

Request to send a SETUP or EMERGENCY SETUP message to initiate Mobile originating establishmentof 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; callcontrol 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 beencompleted; 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 providedor 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 bearercapability 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 nomore call establishment information will be accepted by the Network.

6.2.2.11 MNCC_PROGRESS_IND

Indication to the Mobile user that a PROGRESS message or a message containing a progress IE hasbeen received, e.g., because the call is progressing in the PLMN/ISDN environment, or because the callhas 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 indicatethat 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 Mobileuser.

6.2.2.15 MNCC_NOTIFY_IND

Indication to the Mobile user that information pertaining to a call, such as remote user suspended, hasbeen 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-endconnection 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 torelease the call reference and the corresponding MM connection so that the Network can release its MMconnection 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 andthe Network intends to release its MM connection. The Mobile user is requested to release the callreference 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.

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 thatthe 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 hasbeen 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 modificationcompletion by the Mobile user.

6.2.2.30 MNCC_MODIFY_CNF

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

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.


6.3 Call independent Supplementary Services Support


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

IDLE

CONN

MNSS-END-REQ IND

MNSS-FACILITY-REQ IND

MNSS-END-REQ IND

MNSS-BEGIN-REQ IND

STATES:

IDLE - No SS signalling transaction pendingCONN - SS signalling transaction established

Figure 6.3/GSM 04.07 Service graph of the call independent Supplementary Services Supportentity - Mobile Station side



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

PRIMITIVES PARAMETERS REFERENCEInfo elements of message

MNSS_BEGIN_REQ REGISTER 6.3.2.1MNSS_BEGIN_IND REGISTER 6.3.2.2MNSS_FACILITY_REQ FACILITY 6.3.2.3MNSS_FACILITY_IND FACILITY 6.3.2.4MNSS_END_REQ REL COMPLETE 6.3.2.5MNSS_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 ofcall independent supplementary services. The request for a call independent supplementary serviceinvocation may be included.

6.3.2.2 MNSS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of callindependent supplementary services after receipt of a REGISTER message. The indication of asupplementary service 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 serviceinvocation.

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. Therequest 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 indicationof 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 inTS GSM 04.11.


7 Services provided by signalling layer 3 on the Network side

In this clause, the services provided by signalling layer 3 on the network side are described which belongto the CM sub-layer functional blocks of CC, SMS, and SS. The services corresponding to furtherfunctional blocks of the CM sublayer are not further described in this clause.

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.


The Call Control services provided at the service access point MNCC-SAP are illustrated infigure 7.1/GSM 04.07.


RE

LEA

SE

RE

QU

ES

T

DIS

ON

NE

CT

IND

ICA

TIO

ND

ISC

ON

NE

CT

RE

QU

ES

T

CA

LL IN

IT

NO

CA

LLP

RO

CE

ED

ING

CA

LLD

ELI

VE

RE

D

AC

TIV

E

CA

LLR

EC

EIV

ED

CO

NN

EC

TR

EQ

UE

ST

MT

CA

LLC

ON

FIR

ME

D

CA

LL

PR

ES

EN

T

NU

LL0

1 3

4

10

19

12

6 9

7

8

11

MN

CC

-R

EL-

IND

MN

CC

-RE

J-IN

D

MN

CC

-SE

TU

P-R

EQ

MN

CC

-D

ISC

-IN

D

MN

CC

-D

ISC

- R

EQ

MN

CC

-A

LER

T-

IND

MN

CC

-F

AC

ILIT

Y-

IND

AN

Y S

TA

TE

EX

CE

PT

0A

NY

ST

AT

EM

NC

C-

RE

L-IN

D

0A

NY

ST

AT

EE

XC

EP

T 0

,19

MN

CC

-F

AC

ILIT

YR

EQ

MN

CC

-SE

TU

P-R

EQ

MN

CC

-RE

J-IN

D

ST

AT

ES

4,6,

8,9,

10

MN

CC

-R

EL-

CN

FM

NC

C-

DIS

C-

IND

MN

CC

-C

ALL

-C

ON

F-

IND

MN

CC

-A

LER

T-

IND

MN

CC

-S

ET

UP

-C

NF

MN

CC

-S

ET

UP

-CN

F

MN

CC

-SE

TU

P-C

OM

PL-

RE

Q

MN

CC

-CA

LLP

RO

C-R

EQ CO

NN

EC

TIN

DIC

AT

ION

28

MN

CC

-P

RO

GR

ES

S-

RE

QM

NC

C-

ALE

RT

-R

EQ

MN

CC

-S

ET

UP

-R

SP

MN

CC

-RE

LR

EQ

Figure 7.1/GSM 04.07 (page 1 of 2) Service graph of Call Control entity - Network side


10 ACTIVE

27 MT MODIFY

MNCC-MODIFY-CNFMNCC-MODIFY-REQ

MNCC-START-DTMF-IND RSPMNCC-STOP-DTMF-IND RSPMNCC-NOTIFY-REQ INDMNCC-MODIFY-IND

Figure 7.1/GSM 04.07 (page 2 of 2) Service graph of Call Control entity - Network side



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

PRIMITIVE PARAMETER (message, info REFERENCEelements of MESSAGE,other parameters)

MNCC_SETUP_REQ SETUP 7.1.2.1incl. Mobile IDor EMERGENCY SETUP

MNCC_SETUP_IND SETUP 7.1.2.2MNCC_SETUP_RSP CONNECT 7.1.2.3MNCC_SETUP_CNF CONNECT 7.1.2.4MNCC_SETUP_COMPL_REQ CONNECT ACKNOWLEDGE 7.1.2.5MNCC_SETUP_COMPL_IND CONNECT ACKNOWLEDGE 7.1.2.6MNCC_REJ_REQ RELEASE COMPLETE 7.1.2.7MNCC_REJ_IND cause 7.1.2.8MNCC_CALL_CONF_IND CALL CONFIRMED 7.1.2.9MNCC_CALL PROC_REQ CALL PROCEEDING 7.1.2.10MNCC_PROGRESS_REQ PROGRESS 7.1.2.11MNCC_ALERT_REQ ALERTING 7.1.2.12MNCC_ALERT_IND ALERTING 7.1.2.13MNCC_NOTIFY_REQ NOTIFY 7.1.2.14MNCC_NOTIFY_IND NOTIFY 7.1.2.15MNCC_DISC_REQ DISCONNECT 7.1.2.16MNCC_DISC_IND DISCONNECT 7.1.2.17MNCC_REL_REQ RELEASE or DISCONNECT 7.1.2.18MNCC_REL_IND RELEASE 7.1.2.19MNCC_REL_CNF RELEASE or RELEASE COMPLETE 7.1.2.20MNCC_FACILITY_REQ facility 7.1.2.21MNCC_FACILITY_IND facility 7.1.2.22MNCC_START_DTMF_IND START DTMF 7.1.2.23MNCC_START_DTMF_RSP START DTMF ACK or 7.1.2.24

START DTMF REJMNCC_STOP_DTMF_IND STOP DTMF 7.1.2.25MNCC_STOP_DTMF_RSP STOP DTMF ACK 7.1.2.26MNCC_MODIFY_REQ MODIFY or 7.1.2.27

BC-parameterMNCC_MODIFY_IND BC-parameter 7.1.2.28MNCC_MODIFY RES MODIFY COMPLETE 7.1.2.29MNCC_MODIFY_CNF BC-parameter 7.1.2.30


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

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 hasbeen completed.

7.1.2.6 MNCC_SETUP_COMPL_IND

Indication of the receipt of a CONNECT ACKNOWLEDGE message, the Mobile originating callestablishment 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 bearercapability 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 callestablishment has been initiated in the Network and no more call establishment information will beaccepted.

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 inorder to give the Mobile user information about the call , e.g., that the call is progressing in thePLMN/ISDN environment, or that the call has left the PLMN/ISDN environment, or that in-bandtones/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 useralerting 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 userto 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 theMobile 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 asremote 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-endconnection.

7.1.2.17 MNCC_DISC_IND

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

7.1.2.18 MNCC_REL_REQ

Request to send a RELEASE message to inform the Mobile Station that the network intends to release theMM 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 callreference. 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 hasbeen released, the Network itself shall release its MM connection and the corresponding call reference.

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 toacknowledge 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 aDTMF 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-callmodification procedure has been completed.

7.1.2.30 MNCC_MODIFY_CNF

Confirmation that the Mobile terminating in-call modification has been completed.


7.2 Call independent Supplementary Services Support


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

IDLE

CONN

MNSS-END-REQ IND

MNSS-BEGIN-IND REQ

MNSS-FACILITY-REQ IND

MNSS-END-REQ IND

STATES:

IDLE - No SS signalling transaction pendingCONN - SS signalling transaction established

Figure 7.2/GSM 04.07 Service graph of the call independent Supplementary Services Supportentity - Network side



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

PRIMITIVES PARAMETERS REFERENCEInfo elements of message

MNSS_BEGIN_REQ REGISTER 7.2.2.1MNSS_BEGIN_IND REGISTER 7.2.2.2MNSS_FACILITY_REQ FACILITY 7.2.2.3MNSS_FACILITY_IND FACILITY 7.2.2.4MNSS_END_REQ RELEASE COMPLETE 7.2.2.5MNSS_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 ofcall independent supplementary services. The request for a supplementary service invocation may beincluded.

7.2.2.2 MNSS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of callindependent supplementary services. The indication of a supplementary service invocation may beincluded.

7.2.2.3 MNSS_FACILITY_REQ

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

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 bysending a RELEASE COMPLETE message. The request for transfer of a supplementary service facilitymay be included.

7.2.2.6 MNSS_END_IND

Indication that the signalling transaction has been released after receipt of a RELEASE COMPLETEmessage. 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 GSM04.11.


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 channelmanagement 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 primitivesDL_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 bythe 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.


9 Interlayer service interfaces on the Mobile Station side

In addition to the services described in this clause, the RR entity and MM entity also provide services toCM entities which don't belong to the functional blocks of CC, SMS, and SS. (For example, the RR entityprovides service to Group Call and Broadcast Call entities.) These services are not further described inthis clause.

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

MobilityManagementsublayer

Radio ResourceManagementsublayer

RR-primitives

RR sublayer peer-to-peer protocol

RRSAP

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



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

ALLSTATES

IDLE

CONPEND

DEDI-CATED

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

RR-ABORT-IND

RR-EST-IND

RR-REL-INDRR-ABORT-REQ

RR-EST-CNFRR-SYNC-IND(ciph)(res ass)(channel mode modify)

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

Figure 9.2/GSM 04.07 Service graph of the Radio Resource Management - Mobile Station side



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.1Transferred in theSABM frame

RR_EST_IND - 9.1.2.2RR_EST_CNF - 9.1.2.3RR_REL_IND cause 9.1.2.4RR_SYNC_IND cause (ciphering, res.ass, 9.1.2.5

channel mode modify)RR_DATA_REQ Layer 3 message 9.1.2.6RR_DATA_IND Layer 3 message 9.1.2.7RR_UNIT DATA_IND Layer 3 message 9.1.2.8RR_ABORT_REQ cause 9.1.2.9RR_ABORT_IND cause 9.1.2.10RR_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 thepreviously selected BCCH.

9.1.2.2 RR_EST_IND

Indicates to the Mobility Management entity the establishment of a Mobile terminated RR connection. Bythis 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 hasreceived a CHANNEL RELEASE from the Network and has triggered a normal release of the data linklayer. It is also used to indicate that a requested RR connection cannot be established. In both cases, RRreturns to IDLE mode.

9.1.2.5 RR_SYNC_IND

Is used for synchronizing RR and the Mobility Management entity after the establishment of a Mobileoriginated 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 viaan 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 sidevia 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 inthe 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 alreadyestablished, 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 exceptionalconditions. 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 theIDLE state.


9.2 Services provided by the Mobility Management entity

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, theSupplementary 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.

CC SS SMS CC SS SMS

MMCC-SAP

MMSS- SAP

MMSMS-SAP

Mobility managementsublayer


MM-primitives

MM peer-to-peerprotocol

MS-side Network side

Figure 9.3/GSM 04.07 Services provided at the MMCC-SAP, MMSS-SAP, MMSMS-SAP - MobileStation side



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

IDLE

CONPEND

CONNSUSP

DEDI-CATED

RE-EST-PEND

MMXX-UNIT-DATA-IND

MMXX-REL- REQ-IND

MMXX- REEST- REQ

MMXX-REEST-CNF

MMXX-ERR-IND

MMSS-EST-IND

MMXX-REL-REQ/IND

MMXX-EST-REQ

MMXX-UNIT-DATA-IND

MMXX-EST-CNF

MMXX- REL- REQ

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.



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


MMXX_EST_REQ 1) Parameters for the appropriate 9.2.2.1CM SERVICE REQUEST (if any)

MMXX_EST_IND 1) First CM message 9.2.2.2MMXX_EST_CNF 1) - 9.2.2.3MMXX_REL_REQ 1) cause 9.2.2.4MMXX_REL_IND 1) cause 9.2.2.5MMXX_DATA_REQ 1) Layer 3 message 9.2.2.6MMXX_DATA_IND 1) Layer 3 message 9.2.2.7MMXX_UNIT_DATA_REQ 1) Layer 3 message 9.2.2.8MMXX_UNIT_DATA_IND 1) Layer 3 message 9.2.2.9MMCC_SYNC_IND 2) cause: res.ass 9.2.2.10MMXX_REEST_REQ 1) 9.2.2.11MMXX_REEST_CNF 1) 9.2.2.12MMXX_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. SeveralMM connections may be provided in parallel to the requesting entities. The primitive may containparameters which are relevant for the CM SERVICE REQUEST message, e.g. to distinguish a basic callfrom 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 firstmessage has been received from the respective peer entity. Several MM connections may be provided inparallel. If a MM connection already exists, a new MM connection using the same RR connection isindicated 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 theappropriate entity which has requested the service.

9.2.2.4 MMXX_REL_REQ

Used by CC, SS or SMS respectively, to request release of the MM connection. The corresponding PD/TIwill 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 isused in exceptional cases to indicate that the MM connection cannot be established or kept any longer andPD/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 SMSentities.

9.2.2.10 MMCC_SYNC_IND

Indication that a dedicated channel assignment has been performed and/or the channel mode has beenchanged (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 interruptionmust 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 continuewith 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 caseof parallel transactions this indication is passed to all CM entities for which a MM connection has beenestablished. It is left to the decision of the appropriate CM entity to either request the re-establishment ofthe MM connection by MMXX_REEST_REQ or to release it by MMXX_REL_REQ.


10 Interlayer service interfaces on the Network side

In addition to the services described in this clause, the RR entity and MM entity also provide services toCM entities which don't belong to the functional blocks of CC, SMS, and SS. (For example, the RR entityprovides service to Group Call Control and Broadcast Call Control entities.) These services are not furtherdescribed in this clause.

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-

SAP

RR-primitives

RR sublayer peer-

to-peer protocolRadio Resource

Management

sublayer

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



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

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

RR-REL-REQ IND

RR-ABORT-REQ INDRR-EST-IND

RR-SYNC-CNF Note 1

RR-EST-REQ

RR-REL-REQ IND

RR-ABOURT-REQ IND

RR-UNIT-DATA-REQ

RR-EST-CNF

IDLE

CONPEND

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

RR-DATA-REQ IND

RR-UNIT-DATA-REQ IND

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



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


RR_EST_REQ Parameters for the 10.1.2.1Initial layer 3 message

RR_EST_IND Initial layer 3 message 10.1.2.2RR_EST_CNF - 10.1.2.3RR_REL_REQ cause 10.1.2.4RR_REL_IND cause 10.1.2.5RR_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.8RR_DATA_IND Layer 3 message 10.1.2.9RR_UNIT_DATA_REQ Layer 3 message 10.1.2.10RR_UNIT_DATA_IND Layer 3 message 10.1.2.11RR_ABORT_REQ cause 10.1.2.12RR_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 hasbeen done.

10.1.2.3 RR_EST_CNF

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

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


10.2 Services provided by the Mobility Management entity

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, theSupplementary 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.

CC SS SMS CC SS SMS

MMCC-SAP

MMSS- SAP

MMSMS-SAP



MM-primitives

MM peer-to-peerprotocol

MS-side Network side

Figure 10.3/GSM 04.07 Services provided at MMCC-SAP, MMSS-SAP, MMSMS-SAP - Network side



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

IDLE

CONPEND

MMXX-UNIT-DATA-REQ

MMCC-REL-REQ IND

MMXX-EST-REQ

MMXX-REL-REQ IND

MMXX-EST-IND

MMCC-SYNC-REQ(res ass)(channel mode modify)

MMXX-DATA-REQ IND

MMXX-UNIT-DATA-REQ IND

MMCC-DATA-REQ IND

MMCC-UNIT-DATA-REQ IND

MMXX-EST-CNF

MMXX-UNIT-DATA-REQ

DT 1

MMCC-SYNC-CNF Note 1

DT 2

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

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

NOTE 3: The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS.



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


MMXX_EST_REQ 1) Mobile ID 10.2.2.1MMXX_EST_IND 1) First CM message 10.2.2.2MMXX_EST_CNF 1) - 10.2.2.3MMXX_REL_REQ 1) cause 10.2.2.4MMXX_REL_IND 1) cause 10.2.2.5MMXX_DATA_REQ 1) Layer 3 message 10.2.2.6MMXX_DATA_IND 1) Layer 3 message 10.2.2.7MMXX_UNIT_DATA_REQ 1) Layer 3 message 10.2.2.8MMXX_UNIT_DATA_IND 1) Layer 3 message 10.2.2.9MMCC_SYNC_REQ 2) cause (resource assign) 10.2.2.10MMCC_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.

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


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


11 Standard L3 Messages

In this section the structure of standard L3 messages and their basic handling are defined. Standard L3messages 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 imperativeand 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. TSGSM 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 consistsof 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

Valueyes yes yes

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 partof the IE.

The value part of a standard IE either consists of a half octet or one or more octets; the value part of astandard IE with format LV or TLV may be empty, i.e. consist of zero octets; if it consists of a half octetand 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 ofthe IE occurring after the octet containing the LI, with bit 1 as the least significant bit. The length indicatorof a standard IE with empty value part indicates 0 octets.


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 halfoctet 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 IEIin bit positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, seefigure 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


A type 2 standard IE has format T; its IEI consists of one octet, its value part is empty, seefigure 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 octetand proceeds the value part in the IE. The value part consists of at least one octet. Seefigure 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, ...)


³ IEI ³ octet nÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

³ ³ octet n + 1ÃÄÄÄÄ value ÄÄÄ´. .. .. .ÃÄÄÄÄ ÄÄÄ´


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


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


³ LI ³ octet nÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´



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


³ IEI ³ octet nÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´

³ LI ³ octet n + 1ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´



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. Aninformation element of this type can only appear as the last information element in a L3 message for whichthe layer 3 length is:

- indicated by layer 2; or- pre-determined (e.g., by the channel used).


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

11.2.1 Protocol discriminator

Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) informationelement. It is a type 1 IE and has always format V. The PD identifies the L3 protocol to which the standardlayer 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 discriminatorswith 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 ofthe 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 ifyes, 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 10 0 0 0 reserved for group call control0 0 0 1 reserved for broadcast call control0 0 1 0 reserved for PDSS10 0 1 1 call control; call related SS messages0 1 0 0 reserved for PDSS20 1 0 1 mobility management messages0 1 1 0 radio resources management messages1 0 0 1 SMS messages1 0 1 1 non call related SS messages1 1 1 0 reserved for extension of the PD to one octet length1 1 1 1 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 specifiedin table 11.2/GSM 04.07, the network may ignore the message or initiate the channel release proceduredefined in TS GSM 04.08.

If the mobile station receives a standard L3 message with a protocol discriminator different from thosespecified 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 theprotocol). Unless otherwise specified in the protocol, the skip indicator IE is a type 1 IE and has format Vin a standard L3 message. The relevant protocol specification may define that a standard L3 messagereceived 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.


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 thetransaction 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 theTI 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 transactiona free TI value (i.e. a value not yet used for the given PD and with the given originator) is chosen andassigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transactionends, 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 transactionoriginated at opposite ends of the interface. In this case the TI flag shall avoid ambiguity. The transactionidentifier flag can take the values "0" or "1". The TI flag is used to identify which end of the radio interfaceoriginated a TI. The origination side always sets the TI flag to "0". The destination side always sets the TIflag to a "1".

Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TIflag 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 TIvalue 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


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 7 6 5 0 0 0 TI value 0 0 0 1 - - 1 0 1 0 - - 2 0 1 1 - - 3 1 0 0 - - 4 1 0 1 - - 5 1 1 0 - - 6 1 1 1 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 themessage type IE which is contained in octet 2 of the message. A protocol may, however, explicitly definedepartures 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 informationelement, 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 entityreceiving a standard L3 message containing a message type IE with bit 8 encoded as 1 shall treat themessage type as not defined for the PD.

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

In all other standard layer 3 messages bit 7 is set to 0 by the sending side; the receiving side shall ignoresuch 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


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

The reaction of a protocol entity receiving a message with message type not defined for the PD in thatdirection 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 LVas defined in the relevant protocol specification.

If a standard L3 message is received that is too short to contain the complete imperative part as specifiedin the relevant protocol specification, an imperative message part error is diagnosed. (The same error maybe diagnosed at detection of certain contents of the imperative part of a message; this is defined in therelevant protocol specification.) The treatment of an imperative message part error is defined in therelevant 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. Thenon-imperative part of a standard L3 message is composed of (zero, one, or several) IEs having theformat T, TV, or TLV. The receiver of a standard L3 message shall be prepared for the non-imperativepart of the message to contain IEs that are not specified in the relevant protocol specification; the receiverwill 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 themessage, 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. WhichIE type it designates, is specified in the relevant protocol specification. Within a message, different IEIsmay 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 protocolspecification.

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

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


11.4 Presence requirements of information elements

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

- M ("Mandatory") means that the IE shall be included by the sending side, and that the receiverdiagnoses a "missing mandatory IE" error when detecting that the IE is not present. An IE belongingto 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 protocolspecification;

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

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

* that the receiver detecting that the IE is present when sufficient static conditions are fulfilledfor 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 IEis 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-imperativepart 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 isnot required for the proper operation of that equipment. For example, a mobile station may ignore thecalling party BCD number if that number is of no interest to the Mobile Station when a SETUP message isreceived.

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. Aprotocol entity detecting an unnecessary IE in a received standard L3 message shall ignore the contents ofthat IE for treating the message; it is not obliged to check whether the contents of the IE are syntacticallycorrect.


Annex A (informative): MN-Services arrow diagram

CC

M

M

RR

L

2

L2

RR

MM

CC

Mob

ile S

tatio

nN

etw

ork

MN

CC

-SE

TU

P-R

EQ

DL

-RA

ND

OM

-AC

C-R

EQ

/IND

(CHA

NN R

EQ

)

DL-

UN

IT-D

AT

A-I

ND

/RE

Q(IM

M A

SS

)

DL

-AS

S-R

EQ

DL-

ES

T-IN

D

DL

-ES

T-C

NF

UA

(C

M S

ER

V R

EQ

)

AU

TH

RE

Q

AUT

H R

ES

CIP

H M

OD

E C

MD

CIP

H M

OD

E C

OM

SE

TU

P

CA

LL P

RO

C

AS

SIG

N C

MD

AS

SIG

N C

OM

AL

ER

T

CO

NN

EC

T

CO

NN

AC

K

MN

CC

-CA

LL-

PR

OC

-IND

MN

CC

-ALE

RT

-IND

MN

CC

-SE

TU

P-C

NF

MM

CC

-ES

T-C

NF

MM

CC

-SY

NC

-IND

(

res

ass)

RR

-ES

T-C

NF

RR

-SY

NK

-IN

D

(re

s as

s)

RR

-ES

T-I

ND(C

M S

ER

V R

EQ

)

RR

-SY

NC

-RE

Q

(ci

ph)

RR

-SY

NC

-CN

F

(ci

ph)

RR

-SY

NC

-RE

Q

(

res

ass)

RR

-SY

NC

-CN

F

(

res

ass

)

MM

CC

-ES

T-IN

D

(

SE

TU

P)

MM

CC

-SY

NC

-RE

Q

(

res

ass)

MM

CC

-SY

NC

-CN

F

(r

es a

ss)

MN

CC

-SE

TU

P-I

ND

MN

CC

-CA

LL-

PR

OC

-RE

Q

MN

CC

-ALE

RT

-RE

Q

MN

CC

-SE

TU

P-R

SP

MN

CC

-SE

TU

P-

CO

MP

L-IN

D

DA

TA

FL

OW

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

MM

CC

-ES

T-R

EQ

RR

-ES

T-R

EQ

(CM

SE

RV

RE

Q)

RR

-SY

NC

-IND

(cip

h)

SA

BM

(C

M S

ER

V R

EQ

)


Mob

ile S

tatio

nN

etw

ork

DA

TA F

LOW

DL-

RA

ND

OM

-ACC

-RE

Q/IN

D (C

HANN

REQ

)

DL

-UN

IT-D

ATA

-IND

/RE

Q (

IMM

ASS

)

DL-

ES

T-R

EQ

DL-

ES

T-IN

D

DL-

ES

T-C

ON

FUA

(P

AG R

ES)

AUT

H R

EQ

AUT

H R

ES

CIP

H M

OD

E C

MD

CIP

H M

OD

E C

OM

SE

TU

P

CA

LL C

ON

F

ASS

IGN

CM

D

ASS

IGN

CO

M

ALE

RT

CO

NN

EC

T

CO

NN

AC

K

RR

-ES

T-IN

D

RR

-SY

NC

-IND

(cip

h)

RR

-SY

NC

-IND

(

res

ass)

MM

CC

-ES

T-IN

D

(S

ET

UP)

MM

CC

-SY

NC

-IND

(res

ass

)

MN

CC

-SET

UP

-IN

D

MN

CC

-CA

LL-

CO

NF

-RE

Q

MN

CC

-ALE

RT

-R

EQ

MN

CC

-SE

TUP

-R

ES

MN

CC

-SE

TUP-

CO

MP

L-IN

D

RR

-EST

-RE

Q

(mob

id)

RR

-ES

T-C

NF

RR

-SYN

C-R

EQ

(res

ass

)

RR

-SY

NC

-CN

F

(r

es a

ss)

RR

-SY

NC

-REQ

(res

ass

)

RR

-SY

NC-C

NF

(re

s as

s)

MM

CC

-ES

T-R

EQ

(m

ob id

)

MM

CC

-SE

TU

P-R

EQ

MM

CC

-ES

T-C

NF

MN

CC

-CA

LL-

CO

NF

-IND

MM

CC

-SY

NC

-RE

Q

(

res

ass)

MM

CC

-SY

NC-C

NF

(re

s as

s)

MN

CC

-ALE

RT-

IND

MN

CC

-SE

TU

P-C

NF

MN

CC

-SE

TUP

-C

OM

PL-

RE

Q

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

SA

BM

(P

AG

RE

S)

DL-

UN

IT-D

ATA

-IND

/RE

Q (

PA

G R

EQ

)

MM

CC

RR

L2L2

RR

MM

CC


Mob

ile S

tatio

nN

etw

ork

DAT

A F

LOW

MN

CC

-DIS

C-R

EQ

MN

CC

-RE

L-IN

D

MM

CC

-REL

-RE

Q

RR

-RE

L-IN

D

DIS

CO

NNEC

T

RE

LEAS

E

RE

LEAS

E C

OM

CH

AN

N R

EL

DL-

RE

L-R

EQ

DL-

RE

L-C

NF

DIS

C

UA

DL-

RE

L-IN

D

RR

-RE

L-R

EQ

MM

CC

-RE

L-R

EQ

MN

CC

-DIS

C-IN

D

MNC

C-R

EL-R

EQ

MN

CC

-REL

-CNF

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

CC

RR

L2C

CM

MM

MR

RL2


Mob

ile S

tatio

nN

etw

ork

RR

-ES

T-R

EQ

(LO

C U

PD

)

DL-

RA

ND

OM

-AC

C-R

EQ

/IND

(C

HA

NN

RE

Q)

DL-

UN

IT-D

AT

A-IN

D/R

EQ

(IM

M A

SS

)

DL-

ES

T-R

EQ

SA

HM

(LO

C U

PD

)D

L-E

ST-

IND

DL-

ES

T-C

NF

UA

(LO

C U

PD

)

AU

TH

RE

Q

AU

TH R

ES

CIP

H M

OD

E C

MD

CIP

H M

OD

E C

OM

LOC

UP

D A

CC

RE

AL

CO

M

CH

AN

N R

EL

DIS

C

UA

DL-

RE

L-R

EQ

DL-

RE

L-C

NF

DL-

RE

L-IN

D

RR

-EST

-IND

(LO

C U

P)

RR

-SY

NC

-RE

Q

(ci

ph)

RR

-SY

NC

-CN

F

(

ciph

)

RR

-RE

L-R

EQ

Figure A.4 Location updating. Successful case.

CC

MM

RR

L2

CC

MM

RR

L2


Mob

ile S

tatio

nN

etw

ork

DA

TA

FLO

W

DA

TA

FLO

W

HA

ND

O C

MD

DL-

SU

S-R

EQ

(lo

cal)

DL-

RE

L-C

NF

(loc

al)

PH

YS

INF

O

DL-

RE

S-R

EQ

DL-

ES

T-C

NF

SA

HM

UA

HA

ND

O C

OM

DL-

ES

T-IN

D

BS

1

BS2

Figure A.5 Handover. Successful case.

CC

MM

RR

L2C

CM

MR

RL2


Mob

ile S

tatio

nN

etw

ork

MN

X-S

PE

CIF

IC-R

EQ

(

1MS

G (

X))

MM

X-ES

T-R

EQ

RR

-ES

T-R

EQ

(CM

SE

RV

RE

Q)

RR

-ES

T-C

NF

MM

X-E

ST

-CN

FR

R-S

YN

C-IN

D

(ci

ph)

MM

X-D

AT

A-R

EQ

(1

MS

G (

X))

MM

X-D

AT

A-D

ND

(2

MS

G (

X))

RR

-DA

TA

-RE1

(1 M

SG

(X)

)

RR

-DA

TA

-DN

D (

2MS

G (

X))

MM

X-S

YN

C-I

ND

(

res

ass)

MM

X-D

AT

A-R

EQ

(M

SG

(X)

)

MM

Y-E

ST-

RE

Q

MM

Y-E

ST

-CN

F

MM

Y-D

AT

A-R

EQ

(

1 M

SG

(Y

))

RR

-SY

NC

-IND

(

res

ass)

RR

-DA

TA

-RE

Q (

MS

G (

X))

RR

-DA

TA

-RE

Q (

1MS

G (

Y))

CH

AN

N R

EQ

IMM

AS

S

DL-

EST

-CN

F

UA

(C

M S

ER

V R

EQ)

AU

TH

RE

Q

AU

TH

RE

S

CIP

H M

OD

E C

MD

CIP

H M

OD

E C

OM

1 M

ESS

AG

E (X

)

2 M

ES

SAG

E (

X)

AS

SIG

N C

MD

AS

SIG

N C

OM

ME

SS

AG

E (

X)

ME

SSA

GE

OF

TR

AN

SA

CT

ION

X

OM

SER

V R

EQ

(se

rv 1

)

OM

SE

RV

AC

C

(se

rv 2

)

1 M

ES

SA

GE

(Y

)

ME

SS

AG

E O

F T

RA

NS

AC

TIO

N X

& Y

R

R-E

ST

-IND

(CM

SE

RV

RE

Q)

NR

-SY

NC

-RE

Q

(

ciph

)

RR

-SY

NC

-CN

F

(

ciph

)

RR

-DA

TA

-IND

(1 M

SG

(X)

)

RR

-DA

TA

-RE

Q2

MS

G (X

))

RR

-SY

NC

-RE

Q

(re

s as

s)

RR

-SY

NC

-CN

F

(re

s as

s)

RR

-DA

TA

-IND

(M

SG

(X)

)

MM

X-D

AT

A-R

EQ

2

MS

G (

X))

MM

X-S

YN

C-R

EQ

(

res

ass)

MM

X-S

YN

C-C

NF

(res

ass

)

MM

X-D

AT

A-IN

D

(M

SG (

X))

MM

XX-E

ST

IND

(1

MS

G (

X))

RR

-DA

TA

-IND

(1M

SG

(Y

))M

MY

-ES

T-IN

D(1

MS

G (

Y))

Transaction Y started

Transaction X started

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

IM-E

ST-

RE

Q(C

M S

ER

V R

EQ

)IM

-ES

T-I

ND(C

M S

ER

V R

EQ

)S

ABM

(C

M S

ER

V R

EL)

MM

Y-S

PE

CIF

IC-R

EQ

(1M

SG

(Y

))

CM

MM

RR

L2C

MM

MR

RL2


Mo

bile

Sta

tion

Ne

twor

k

MM

X-R

EL-

RE

Q

MM

Y-R

EL-

RE

Q

RR

-RE

L-IN

D

Last

mes

sage

of s

peci

fic P

roto

col (

x)

ME

SS

AG

E O

F T

RA

NS

AC

TIO

NS

X &

Y

ME

SS

AG

E O

F T

RA

NS

AC

TIO

NS

Y

Last

mes

sage

of

spec

ific

Pro

toco

l (y)

CH

AN

N R

EL

DL-

REL

-RE

Q

DL

-REL

-CN

F

DIS

C

UA

DL-

RE

L-IN

D

MM

X-R

EL-

RE

Q

MM

Y-R

EL-

RE

Q

Tra

nsac

tion

re

leas

ed

Tran

sact

ion

re

leas

ed

Cha

nne

lre

leas

ed

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

CM

MM

RR

L2

CM

MM

RR

L2


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 Creation of Version 5.1.0 (CR 04.07-A006)

March 1996 Publication of Version 5.1.0

ISBN 2-7437-0635-XDépôt légal : Mars 1996

GSM 04.07 - Version 5.1.0 - Digital cellular ... · GSM 04.07 Version 5.1.0 March 1996 Whilst every...

Documents

Transcript of GSM 04.07 - Version 5.1.0 - Digital cellular ... · GSM 04.07 Version 5.1.0 March 1996 Whilst every...