You are on page 1of 62

S-72.

260
Laboratory Exercises in Communication Engineering

Lab # 2

Signalling of the GSM system

Version 1.21
Previous versions
Date Version Changes
7.9.1998/JSa 1.00d Ensimmäinen draft
2.10.1998/JSa 1.04d Korjauksia ja selvennyksiä testiryhmän kommenttien perusteella
14.3.2000/MJu 1.2 First English version
11.9.2000/JSa 1.21 Revised, except for the introductory text, which remains horrible.

Student laboratory is in room SE306.

Check the links and latest instructions in the course home page. You might (or might not) find
some extra information.

Grading: Accepted/not accepted.

Return pencil-and-paper preliminary exercises at the beginning of your lab shift.

This material in this document does not cover GSM basics, for instance. It is assumed that
students have acquired prerequisites from previous courses, or books etc.

Some prerequisite courses for this laboratory work (not all required!):

Tik-109.350 Telecommunication signaling protocols (Recommended)


S-72.xxx Mobile Communication Systems and Services

Literature:

Mouly M., Pautet M., “The GSM System for Mobile Communications”, published by the
authors, 1992

Redl, Siegmund M., Weber, Matthias K., Oliphant, Malcolm W., “An Introduction to GSM”
Artech House, 1995

Carg, V.J., Wilkes, J.E., Principles and applications of GSM, Prentice-Hall Inc., Upper Saddle
River 1999
Lab #2: Signalling of the GSM system

1 Introduction

In this laboratory exercise signalling and protocols of the GSM system are investigated.

Preliminary exercises include examination of the GSM system signalling on all interfaces. The
laboratory work concentrates on examining interface A because the laboratory doesn’t at the moment
(09/2000) have a protocol analyzer to examine also Abis interface.

To examine the A interface we use NetHawk-program. It is designed by a company from Oulu called
X-Net OY and it works in Windows95. We also need a PRI/AT-card manufactured by the same
company to take make sure that the physical interface of 2,048 Mbit/s PCM-link is towards the base
station control.

Next we deal shortly with GSM signalling protocols and the system’s different interfaces and
signalling between them. Then the properties and the use of the lab’s simulator system are depicted.

There is plenty of material on GSM protocols and signalling in the Internet, books and specifications.
This document gives a brief overview and an example of the anatomy of a certain A interface’s signal.
The examining of the signals on bit level can be a bit too precise but the goal is to understand the
relations between protocols and the principle of layer model. The most precise information is always
found in specifications. ETSI updates these specifications constantly.

WARNING: This material is lousy. You should consult other background material than this, if
possible. See links and instructions from the course home page.

2 An overview signalling protocols in the GSM system


GSM-system has numerous interfaces each including a protocol. Appendix 1 introduces most common
interfaces and appendix 2 the protocol stacks of the interfaces examined in this work. The picture is not
perfect and it lacks for example network-controlling protocol BSSOMAP that belongs to base station
control (BSC) and mobile phone exchange (MSC) and it also lacks SMS protocols. N-ISDN networks
user part ISUP and applying protocol TCAP are also missing. This narrow report is completely limited
to be from interface A to mobile communications.

ITU-T has defined a common channel signalling-system #7 that is used on A interface (and in network
subsystem, NSS) to transfer messages. Above this are part of GSM applying protocol such as
BSSMAP, CM and RSM. These are commonly called GSM L3 what means the third layer of GSM
protocol (but it means layer 7 in OSI-model).

2.1 SS#7

As Mouly and Pautet [Mou98] express this, is SS#7 a glue keeping NSS parts (VLR, HLR, EIR, AuC,
GMSC,..) together. SS#7 is also a straight link to N-ISDN-network because the same signalling system
is used. Applying layers (layer 7 in OSI-model) are different in PLMN- and N-ISDN-networks. This is
also valid in PSTN-structure that is slowly going out of use.
SS#7 is a common channel signalling-system what means that signalling runs in its own channel. This
is not necessarily the same physical wire as the route on traffic channel from a subscriber to another.
Signalling occurs in messages whose structure is accurately defined in ITU-T specifications Q.7xx.
Next we get a brief description of the four lowest layers of SS#7 that are used on the interface A of
GSM-system.

2.1.1 MTP1 or the Physical Layer (Layer 1 in OSI-model)

This includes the physical connection or the PCM-wire whose entire bit-speed is 2048 kbit/s divided in
32 time intervals. The first interval is reserved for frame timing and passing alarms but the rest 31
intervals can include signalling channels or traffic channels. The time interval #16 is usually reserved
for signalling but this not necessarily always the case. The choice depends on the operator and in
Finland’s SS#7-network time interval #1 is always reserved for signalling [Tie98].

2.1.2 MTP2 or the Link Connection Layer (Layer 2 in OSI-model)

This layer includes the actions between two signalling points. Such are acknowledging the received
message and request for transmitting over again. To be able to separate the messages HDCL-based
(High level Data Link Control) protocol is used. It separates messages with a frame-mark 01111110.
The word link means a connection between two points. MTP2 layer takes care of supervising the mode
of the link by sending frames continuously. Because each moment can‘t have information to be
signalled a conclusion has been made that three different types of message units are used. These
message units are MSU, LSSU and FISU:
• MSU (Message Signal Unit) is the most important type of message unit because it
transports the actual payload, or the signalling messages. MSU includes SIO field (Service Information
Octet) that has information on the payload SIF (Service Information Field). SIF begins always with
routing label that consists of DPC (Destination Point Code) and OPC (Originating Point Code) and
SLS-field (Signalling Link Selection) that can be used for distributing message units to different routes
depending on the loading-conditions. These four octets are MTP3. Signalling messages that include a
single phone call or a data link run the sane route anyway. The maximum length of a SIF-field is 272
octets of which the length of the routing label is four octets. The maximum length of the payload is
then 268 octets.
• LSSU (Link Status Signal Unit) transforms information of for example processor
defects between two signalling points.
• FISU (Fill-In Signal Unit) is a unit with no payload. It is needed because signalling
link has traffic continuously. This is how the status of the signalling link is supervised and defects are
noticed quickly.

Figure 1. The structure of MSU OPC+DPC+SLS (4 octets)

LI-part indicates which message unit is concerned. This happens according to the table below:
Table 1. The differences between message units
LI SU
0 FISU
1 or 2 LSSU
>2 MSU

LI field declares how many octets are there between itself and check-sum.

Each message unit is numbered to FSN-field (Forward Sequence Number). When the other end
receives a message unit successfully it places the FSN just read instead of BSN-frame (Backward
Sequence Number) to go backwards. It is called acknowledging procedure when the end which sent the
message gets a reassurance in return mail that the original message did go through.

Using BIB- and FIB-bits (Backward/Forward Indicator Bit) is more complicated but it is described in
particular in ITU-T recommendations Q.703 [ITU703].

2.1.3 MTP3/SCCP or the Network Layer (Layer 3 in OSI-model)

The distinguishing of network protocols can be confusing. ITU-T has numerous precise specifications
on the subject (Q.704-Q.714) but knowing them is not necessary to comprehend the basics. SCCP is
often considered to be the fourth layer protocol of OSI. For example when it serves TCAP (figure 2).
SS#7 networks can be divided into signalling network and national/operator selective networks. This is
required because 14-bit address field is not enough to distribute addresses globally.

MTP3 is a network level protocol that handles routing in national networks. It also takes care of
rerouting the defective links (MPT2 monitors the status of a link) and in case of overloading it can
transfer the message flow to go to a less congested route (SLS-bits). MTP3 does not know how to
perform routing in international level but it needs help from SCCP. SCCP updates information on
signalling points in international SS#7-network. Signalling messages can be directed through these
points to international signalling network. This enables a call from N-ISDN network in Indonesia to a
mobile phone in Finland, or vice versa.

Another difference to MTP3 is that SCCP is able to direct messages to a higher level protocol such as
BSSAP. SCCP uses a sub field SSN (Subsystem Number, not in the picture) for this purpose. SSN
includes specifications of GSM network elements. For example, SSN=254d means BSSAP, and
SSN=11d means ISUP which is an applying protocol of N-ISDN network (Layer 7 in OSI-model).

It is worth mentioning that TCAP (hierarchically above SCCP) is able to distinguish and supervise
single transactions between network elements, for example MAP/VLR <-> MAP/HLR. MAP-protocol
and TCAP are not discussed any further in this laboratory work because they are not needed on A
interface but only on the inner interfaces of NSS (B, C, D, E, F, G).
Figure 2. The correspondence of OSI-model and SS#7 [mic98]

2.2 The Protocols of GSM Link Layer (Layer 2 in OSI-model)

SS#7 is a system whose users are for example N-ISDN, NMT, PSTN and off course GSM. Specific
protocols for GSM are viewed next. In fact, LAPD is modified directly from the protocol used by
channel D in N-ISDN and LAPDm is a variation of LAPD. There are suitable parts chosen from other
protocol architectures in GSM. This is probably reasonable for there is no point in inventing a wheel
over again.

2.2.1 LAPD

Also LAPD is HDLC-based protocol. N-ISDN network’s channel D uses LAPD from where the
abbreviation is derived, Link Access Protocol on the D-channel. Interface Abis has speed 64 kbit/s in
use (in signalling) channelled to a 2,048 Mbit/s PCM-channel. Signalling distribution and traffic
channels distribution in a 2 Mbit/s frame is operation selective. The traffic channels use 16 kbit/s sub
channels. This means that one 64 kbit/s time interval cancontain four full speed GSM traffic channels.

The maximum length of a LAPD frame is 264 octets from which the actual signalling payload gets 260
octets. Because LAPD does not distribute messages into new frames and furthermore because the radio
interfaces do not have the maximum length for the message (the message can further in many bursts),
260 octets is the longest possible L3-level signalling message length (MTP2 has the maximum length
of 268 octets) in GSM-system. The maximum length is for one reason or other defined to be 251 octets
[GSM0406].

Figure 3 (next page) represents the structure of frame types A and B.


Format A Format B
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

Flag Flag
Octet 1 Octet 1
0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0
Address Address
2 2
(high order octet) (high order octet)
Address Address
3 3
(low order octet) (low order octet)

Control (Note 2) 4 Control (Notes 1 and 2) 4

Control (Note 2) Control (Notes 1 and 2) 5


5 .
.
Information .

FCS (first octet) N–2 FCS (first octet) N–2

FCS (second octet) N–2 FCS (second octet) N–1

Flag Flag
0 1 1 1 1 1 1 0 N 0 1 1 1 1 1 1 0 N

T1161580-94

NOTE 1 – For unacknowledged operation, format B applies and one octet control field is used.
NOTE 2 – For multiple frame operation, frames with sequence numbers contain a two-octet control field and frames without sequence
numbers contain a one-octet control field. Connection management information transfer frames contain a one-octet control field.

Figure 3. The LAPD frame types A and B [ITU921]

2.2.2 LAPDm

LAPDm is a modified version of LAPD. For example, the frame marks have been removed for the
TDMA-frame structure of radio interface takes care of framing the messages. Also the error correction
bits have been withdrawn for the same reason: physical layer of GSM air interface takes care of error
correction functions.

LAPDm has different kinds of frames: A, Abis, B and Bbis are the most typical frame types. A/Abis
frames are used to transfer supervisory information and to be filling frames. B/Bbis frames transfer
information. Bis frames attached with appendices are used in unacknowledged mode.
Bitti 8 7 6 5 4 3 2 1
Oktetti
1

: Address field :

k
Control field k+1
k+2

: Length indicator field :

n
n+1

: Fill bits :

N201+n

Figure 4. Type A LAPDm frame [GSM0406]

N201 is a parameter that defines the maximum size of information field in octets. If LI (Length
Indicator) is smaller than N201 are the rest of the octets filled with fill bits. The precise meanings for
the different fields are given in specifications [GSM0406].
Bitti 8 7 6 5 4 3 2 1
Oktetti
1

: Address field :

k
Control field k+1
k+2

: Length indicator field :


n
n+1

: Information field :

N
N+1

: Fill bits :

N201+n

Figure 5. Type B LAPDm frame [GSM0406]

The fill bits are sent if a frame otherwise isn’t full or if there is nothing else to be sent. The frame has
though always the same length. If the message is too long it can be divided into several frames. This is
done for example in sending short messages. There are certain mechanisms set into the frame structure
for this purpose but it is not covered here.

The following table includes some of the full speed channel parameters.

Table 2. Full speed logical channel parameters


Logical Frames/ Channel coding Block Block Bits LAPDm Frame Information
channel super speed size before frame type bits in a
frame (blocks/ (bits) coding size (bits frame
frames) (octets) in octet) (octets)
FACCH 24/26 Fire-code 6/24 456 184(23) 184(23) B/A 160(20)
Convolution ½
SDCCH/4 4/51 Fire-code 1/51 456 184(23) 184(23) B/A 160(20)
Convolution ½
SACCH 1/26 Fire-code 1/104 456 184(23) 168(21) B/A 144(18)
Convolution ½
BCCH 4/51 Fire-code 1/51 456 184(23) 184(23) Bbis 184(23)
Convolution ½
PAGCH 36/51 Fire-code 9/51 456 184(23) 184(23) Bbis 184(23)
Convolution ½
SCH 5/51 Parity (10bits) 5/51 78 25 - - -
Convolution ½
RACH 51/51 Parity (10bits) 51/51 36 8(1) - - -
Convolution ½
2.3 GSM L3 (Layer 7 in OSI-model)

2.3.1 General

The layer above the physical and link layer of GSM is often called the third layer of GSM. It includes
adaptive protocols. The physical layer and the link layer are often defined to be layers one and two.
The network level protocol (layer 3 in OSI-model) is not actually included in GSM protocol stack.
Comparing L3 to OSI-model it is included in adaptive layer (layer 7 in OSI-model). The precise
knowledge of protocols is needed when working with signalling programs but being familiar with the
basics is useful for anyone working with GSM. Radio interface may be the most critical part in terms of
performance but its share in the whole system is relatively small.

The main parts of L3 are RR (Radio Source Management), MM (Mobility Management) and CM
(Connection Management). CM is also divided into smaller parts of which the most important for this
laboratory work is CC (Call Control). Other sub parts are SMS and SS that are used for processing
short messages and controlling extra services. Appendix 2 includes the GSM protocols introduced so
far. CM, MM and RR can be considered to be a bunch of functions that control each their own section
of GSM operations. Each includes a number of messages that contain parameters changing according
to situations and decrees.
CC SS SMS

CM

MM

RR
Protocol discriminator

DTAP BSSMAP

01d 00d

Distribution function BSSAP

SSN = 254d

SCCP

Figure 6. BSSAP

RR protocol controls radio channels allocation, detection and handover.

MM protocol controls activity. It means that the location of the phone has to be known. For example
trying to make contact with a phone is impossible if its whereabouts is not known.

CM protocol controls setting up contact, sustaining and ending it. Contact stands for a data phone call,
sending a short message or an ordinary phone call.

Abis interface has a protocol RSM (Radio Subsystem Management) that is sometimes called BTSM
(Base Station Subsystem Management). Its purpose is to distribute radio resources and controlling
handovers.

The following table gives a few examples of messages that can be sent by L3 protocols.

Table 3. Example messages


The protocol and the message ? <-> ? Description
RR PAGING RESPONSE MS -> MSC The phone’s response to PAGING-request with which the phone is
searched in the network
MM AUTHENTICATION MS <- MSC MAS sends MS a recognising request that includes a random
REQUEST number RAND. MS replies with MM AUTHENTICATION
RESPONSE
CC SETUP MS <-> MSC Includes information to set up connection to the phone such as the
number
RSM ESTABLISH BTS -> BSC The base station sends this message after the connection to MS has
INDICATION been set up. It includes MS’s first message BSSMAP COMPLETE
L3 INFO
RR messages are appointed usually to BSC or BTS such as RR MEASUREMENT REPORT that
includes results from measuring the quality of speech and power levels measured from neighbouring
cells (for handover decisions in BSC).

Hierarchy RR -> MM -> CM can be interpreted that the lower level matters have to be in order before
higher level tasks can be performed. This leads to RR who controls distributing radio resources (i.e.
distributing traffic- and signalling channels) to perform signalling before MM. On the other hand, MM
must authenticate the subscriber before CC can start making the phone connection.

A mobile phone exchanges messages with several network elements. The message can so be
transparent to the element in between and the message can remain unread. This happens for instance
when MSC sends an acknowledging request AUTHENTICSTION REQUEST. This leaves the base
station and its controller in between and they relay the message without interfering the contents. The
phone on the other hand sends MSC the response AUTHENTICATION RESPONSE. This is a very
simple example and there are many exceptions. Transmitting messages between MS <-> MSC is
controlled by DTAP (Direct Transfer Application Part). DTAP is the other part of BSSAP (Base
Station Subsystem Application Part) and it is divided into RR, CM and MM.

BSSAP consists of two parts (figure 6). The other part of BSSAP is BSSMAP (Base Station Subsystem
Mobile Application Part). When the message sent by the phone arrives in MSC some sort of a
mechanism is needed to separate BSSMAP- and DTAP-messages from each other. SCCP does not do
this operation but instead a “layer” called the d-function (distribution function) does. Literature calls
the distribution function sometimes a layer sometimes a protocol. “A function” may actually be the
best word to describe this concept. The essential part is that the d-function separates BSSMAP- and
DTAP-messages from each other immediately after SCCP has transmitted GSM L3-message to it.

More separation mechanisms are needed inside DTAP because CM (including several sub parts) and
MM must be able to be separated from each other. For this purpose includes DTAP-message an octet
bit that separates the protocols. This is called the PD-syllable (Protocol Discriminator). There is also an
unpleasant exception for the first message (COMPLETE L3 INFO) from MS to MSC is actually
appointed to BSSMAP and DTAP. So the d-function indicates the message to BSSMAP who knows
how to forward the right part of the message to DTAP. DTAP-part of the message is split normally
according to PD-syllable.

2.3.2 The structure of a message

Next example is a BSSMAP-message ASSIGNMENT REQUEST which MSC sends to BSC when it
wants BSC to allocate radio resources for example to connect a call (Mobile Terminating Call). The
point is to achieve a picture of the message structure that was used. DTAP-messages are alike.
A brief part of signalling is introduced later.

The structure of BSSMAP-messages on interface A is accurately defined in specifications [GSM0808].


The structure of DTAP-messages is defined in other specifications [GSM0408, GSM0858]. These
messages travel transparently in BSS which means that BSS doesn’t interfere with these messages.

The messages consist of information elements that are stacked one after the other and then they form a
whole message. Phase 2+ specification 08.08 defines 67 different BSSMAP-messages that use 59
different information elements. The structure of the messages does not apply a certain rule (except
during the first octet) and the resolution of the information elements is one octet i.e. eight bits. The first
information element of BSSMAP-message is Message Type and uniformly the first section of
information element is an identifier (IEI) that indicates which information element is concerned. So the
shortest possible message includes only one information element (at the shortest two octets) and so the
minimum length is three octets.
Table 4. A diagram of a L3-message ASSIGNMENT REQUEST [GSM0808]
Information Element Type Length
Message Type M 1
Channel Type M 5-10
Layer 3 Header Information O 4
Priority O 3
Circuit Identity Code O 3
Downlink DTX Flag O 2
Interference Band To Be Used O 2
Classmark Information 2 O 4-5
Group Call Reference O 3-8
Talker Flag O 1
Configuration Evolution Indication O 2

This message can in principle be from 6 to 40 octets in length.

Some explanations:
M -mandatory element
O -optional element

For Example information element Classmark Information 2 which describes the properties of the phone
to BSC is formed according to picture 2.5 [GSM0408].

8 7 6 5 4 3 2 1
Information element identifier
Length of element contents
Spare Revision level ES IND A5/1 RF power capability
Spare PS capab. SS screen indicator SM capab. spare Spare FC
CM3 Spare Spare Spare spare spare A5/3 A5/2

Figure 7. Information element of Classmark Information 2 [GSM0408].

A field that informs the length of the element is needed because the fifth octet is optional or the length
of the element can vary.

Some explanations:
PS -Pseudo-synchronization
SS -Supplementary Services
SM -Short Message
CM3 -Classmark 3
FC -Frequency Capability
ES IND – Early Sending Indication

3 An Example of Signalling - BSSMAP COMPLETE L3


INFORMATION
Next is an example of signalling introduced. There are connective messages between different
network-elements introduced in the picture below. The vertical axis depicts time.

At the beginning MS calls the base station and the base station control admit MS signalling channel
SDCCH. Then MS sends a SABM frame which includes also (this is called piggypagging in literature)
the message COMPLETE L3 INFORMATION. This message includes information on MS and
services included in the linkage. The message travels unattached “inside” another message (RSM
ESTABLISH INDICATION). BSC has not yet set up a connection to MSC but it does it now by saying
SCCP CONNECTION REQUEST that includes the original message sent by MS. Let’s examine this
message (the circled one) more closely next. The example is taken from references [Tel98].

MS BTS BSC MSC


RR channel request
RACH
RSM channel required

RSM channel activation

RSM channel activ. ack

RSM immediate assign cmd

RR immediate assignment
AGCH

LAPDm SABM
SDCCH (COMPLETE L3 INFO)

RSM establish indication


(COMPLETE L3 INFO)

LAPDm UA SCCP connection request


SDCCH (COMPLETE L3 INFO) (BSSMAP COMP. L3 INFO)

SCCP connection confirm

Figure 8. Signalling scheme of setting up connection. The circled message is studied more closely.

3.1 MTP2 part

The figure below shows the composition of SCCP CONNECTION REQUEST-message by octets. The
different parts have been marked by different shades of grey. The frame marks 01111110 and the check
bits are missing.
DTAP

SCCP

BSSMAP
MTP2
(MTP3)

B2 B4 31 83 91 43 10 18 01 00 06 01 02 02 04
02 42 FE 04 04 43 41 20 FE 0F 19 00 17 57 05
05 01 00 47 1B BD 17 0D 05 24 31 03 20 18 01
05 F4 00 00 2D 88 00
d-function
Figure 9. SCCP CONNECTION REQUEST almost in its entirety.
MTP2 part is coloured grey (in figure 9) in MSU-frame. MTP2 passes the rest to the upper level, in this
case to SCCP.
BSN/BIB

FSN/FIB

LI

SIO+SSF

B2 B4 31 83 91 43 10 18 01 00 06 01 02 02 04
02 42 FE 04 04 43 41 20 FE 0F 19 00 17 57 05
05 01 00 47 1B BD 17 0D 05 24 31 03 20 18 01
05 F4 00 00 2D 88 00

Figure 10. MTP2-part

The first two octets are not decoded; they are assumed to be random as regards to this example.

LI=31h=00110001=49d i.e. the payload (SCCP-part) of MSU is 48 octets in length. The first two zeros
are reserved bits and their value is a fixed ‘0’.

SIO=83h=10000011 of which SSF is the first two bits and SIO the four last bits (two bits are reserved).
The value of SIO is 0011=3d what means SCCP.

Table 5. The possible values of SIO [mic98]


SIO MTP user
0 Signalling Network Management Message (SNM)
1 Maintenance Regular Message (MTN)
2 Maintenance Special Message (MTNS)
3 Signalling Connection Control Part (SCCP)
4 Telephone User Part (TUP)
5 ISDN User Part (ISUP)
6 Data User Part (call and circuit-related messages)
7 Data User Part (facility registration/cancellation messages)

Table 6. Decoding Subservice Field-bits

0 International Network
1 International spare
2 National network
3 Reserved National
3.2 SCCP part

Calling Party Address


Subsystem Number (ensimmäinen oktetti,
element identifier) Message Type

Source Local Reference


Protocol Class

Routing label (MTP3) M1 O1


Called Party Address
(ensimmäinen oktetti)

91 43 10 18 01 00 06 01 02 02 04
02 42 FE 04 04 43 41 20 FE 0F 19 00 17 57 05
05 01 00 47 1B BD 17 0D 05 24 31 03 20 18 01
05 F4 00 00 2D 88 00

Figure 11. SCCP part

The first four octets in SCCP’s own part indicate always the routing label and load distribution between
links. These can be assumed to be random from this point of view. In fact, these four octets belong
actually to MTP3.

SLS OPC DPC

4 14 14
Figure 12. Routing label [ITU704]

The binary value of the routing label in this example (according to figure 12):
00011000 00010000 01000011 10010001
DPC= 00001110010001=913d=39h, OPC= 10000001000001=8257d=2041h and SLS=0001=1h.

MTP routing label


Message type code
Mandatory fixed part SCCP SIF
Mandatory variable part
Optional part

Figure 13. General structure of SCCP-message + routing label of MTP [ITU713].


Order of octet
8 7 6 5 4 3 2 1 transmission

Message type code

Mandatory parameter A
Mandatory
fixed part
Mandatory parameter F
Pointer to parameter M

Pointer to parameter P
Pointer to start of optional part
Length indicator of parameter M
Mandatory
Parameter M variable part

Length indicator of parameter P

Parameter P
Parameter name = X
Length indicator of parameter X

Parameter X

Optional part
Parameter name = Z
Length indicator of parameter Z

Parameter Z

End of optional parameters T1178720-96

Figure 14. The structure of SCCP-message [ITU713]

The fifth octet expresses which message is concerned. In this case its value is 01h=01d which decoded
[Net96] means the message CONNECTION REQUEST. The format of each message is accurately
defined and after acknowledging the octet of the message type SCCP knows what elements come next.

Table 7. Some values for decoding Message Type-field [Net96]


Value Message
01h CR-Connection Request
02h CC-Connection Confirm
03h CREF-Connection Refused
04h RLSD-Released
05h RLC-Release Complete
06h DTI-Data Form 1
09h UDT-Unit Data
The next three octets include in this message a reference number (Source Local Reference) that has
been given to this particular connection. SCCP uses this to recognise different parallel connection
processes of the connectional basic service. See next octet.

The ninth octet (Protocol Class) describes the manner of the connection which in this particular case is
02h= connectional basic service. After this (in this message) follows two bits that indicate to elements:
the called party address (M1) and the calling party address (O1). The called party address is optional.
Indicating octets used in SCCP express how many octets are there between itself and the element to be
indicated, including the routing label octet.

Table 8. Values for decoding Protocol Class-octet [Net96]


Value The Connection Type
0 Connectionless, discard msg on error
1 Connectionless, not GSM, discard msg on error
2 Connection oriented
3 Connection oriented, not GSM
80h Connectionless, return msg on error
81h Connectionless, not GSM, return msg on error

The following octets include a more complicated information element: Called/Calling Party Address of
SCCP. The structure is indicated in the following figure and it will be studied more closely.

8 7 6 5 4 3 2 1
Length Indicator
Nat. use Rtgi Global Title indicator SSNi PCi
Signalling point code, low part
Spare Signalling point code, high part
Subsystem Number
Global Title (variable length)
.
.
.

Figure 15. Called/Calling Party Address- information element

02h=02d i.e. There are two octets after LI-element (Length Indicator).

The other octet is 42h=01000010. The following values are derived from this:

The most significant bit is reserved for national use.

Rtgi= Routing Indicator =1 what means that routing is based on the routing label of MTP and SNN
inside the signalling point. The general address (Global Title) of SCCP is not used in this case. But it is
useful to be familiar with some basics. Any signalling point can be found globally with the help from
general address (Global Title). The Global Title may be [Tie98] IMSI, MSISDN or a mixture of these
two. This does not yet indicate the location of the target signalling point but a transform function
needed. This transfer function belongs to main SCCP functionality. The transfer function converts the
Global Title into Routing Label after which the routing to targeting point can begin normally.

Global Title indicator = 0 = the message doesn’t have SCCP general address.
SNNi =1 informs only whether SNN-field belongs to the element (‘1’) or not (‘0’). In this case the
information element includes Subsystem Number.
Pci =Signalling Point code indicator informs whether SPC-field is included in the message. In this case
not (‘0’).

The third octet is important. It indicates the adapting layer of the Destination Point Code that the
message belongs to. With this indicating mechanism SCCP knows to which upper layer the payload
should be passed. Now the value of the FEh=254d. This means BSSAP. So SCCP can not distinguish
BSSMAP-and DTAP-messages from each other (or the protocols inside DTAP). GSM-signalling has
been included own information elements in upper layers.

Table 9. Some values for decoding SSN-field [Net96]


Value Subsystem
0h Not known/not used
1h SCCP management
3h ISUP
4h OMAP
5h MAP
FDh O&M
Feh BSSAP

Next comes the calling address which is an optional field. Instead of LI-octet the first octet is Element
Identifier that expresses the element at hand. The message is the same than previous called address by
decoding but it differs in the values of the fields.

04 04 43 41 20 FE

- Routing is based on the routing label of MTP and SSN (RTGi =’1’).
- Subsystem Number is included in the message (SSNi =’1’).
- The originating address of the message is included in the message (Pci =’1’).
- The address of the origin is 2041h.
- The message was sent by BSSAP (SSN=FEh) from the address above.

There are still three SCCP-protocol octets left: 0F 19 00. All of these are included in the optional part.

0Fh This syllable indicates the next optional element (0Fh =SCCP user data).
19h Indicates the SCCP user part length in octets (the payload)
00h Comes only after the user part and it indicates the ending of the optional part. Afterwards
come MSU check bits and the frame mark 01111110. These are not described in the figures.
The decoding of SCCP user part (the payload) is introduced next.
2.4.3.3. The D-function

The following octet in the message is the d-function (distribution function). This very important
function defines whether the message is transferred to BSSMAP (‘0’) or to DTAP (‘1’). Seven most
significant bits are reserved and they are fixed to be zeros.

IEI d-function LI Message Type


IEI
LI
(Cell Identifier)

00 17 57 05
05 01 00 47 1B BD 17 0D 05 24 31 03 20 18 01
05 F4 00 00 2D 88 00

Figure 16. The d-function and BSSMAP part

3.3 BSSMAP COMPLETE L3 INFORMATION

The original message sent by the phone has arrived in the destination.
The first octet (Length Indicator) indicates the length of the BSSMAP message (17h =23d) the length is
23 octets.

The second octet indicates which message is concerned. 57h means BSSMAP COMPLETE L3
INFORMATION which is the first message to be sent by the phone when it requests services from
MSC.

Cell Identifier is of the following form:

8 7 6 5 4 3 2 1
Information Element Identifier (IEI)
Length Indicator
Cell Identifier Discriminator
Cell Identification
(variable length)
.
.

Figure 17. Cell Identifier-information element

BSSMAP messages include IEI-octet (Information Element Identifier) that comes before each
Information Element. 05h corresponds to Cell Identifier that indicates the location the phon in a cell.

The second octet is 5h or the whole length of the element is seven octets.

The third octet is 01h. This indicates more precisely what kind of an identifier is concerned. There are
four different of these defined [GSM0808]. The length of the type 01h is four octets which could have
been concluded after the previous field.

The actual identifier part has been included four octets that are LAC (two octets) and CI (two octets).
This is not decoded here.

The previous element ended and a new one begins. IEI =17h and this means element L3 Message
Contents that includes upper layer data. 0Dh expresses the length of the element (=13).

3.3.1 MM CM SERVICE REQUEST

This is the highest level in this GSM message.

MS Classmark 2
(ensimmäinen oktetti)

Mobile identity
(ensimmäinen oktetti) Service Type +
CKSN
Message Type
pd + TI

TMSI
05 24 31 03 20 18 01
05 F4 00 00 2D 88 00

Figure 18. CM SERVICE REQUEST part

The first octet includes pd-information (protocol discriminator) as follows:


8 7 6 5 4 3 2 1
Tif TI value Protocol discriminator

Figure 19. Protocol discriminator-octet

The value of Protocol discriminator becomes 0101. This equals to protocol MM. Other possible values
have presented in appendix 4.

TI (Transaction Identifier) informs which part of the connection event the message is from.

Message type 24h is decoded CM SERVICE REQUEST. This is how the phone requests MM-protocol
to begin tasks such as ciphering so that CM (including CC) can begin.

The third octet includes a service type that in this case is MOC (Mobile Originating Call) and the
number of the ciphering key (Ciphering Key Sequence Number) that was installed on the SIM-card of
the phone at the end of the previous connection event. The binary value is 00110001 of which the last
four bits belong to service types and the first three to the sequence number of ciphering key (not the
same as Kc !).

The next information element is several octets in length. It includes information of the phone’s
properties such as power class and the ciphering algorithms regulated by the phone. The first octet
indicates the information part (Value Part) length of the element. The following three octets include the
information.

The last element is Mobile Identity that includes one of the following: IMSI, IMEI, TMSI or IMEISV.
The first octet indicates the length of the element and the second octet what type of an identifier is
concerned. In this case, the four following octets include the actual identifier (now TMSI).

The last octet of the whole message unit is 00h and it indicates the ending of the optional part of SCCP.
This was introduced earlier.

This should be known: COMPLETE L3 INFORMATION is the only message that goes both BSSMAP
and DTAP. Other messages end up in either one of these, not both. This arrangement is used because
the first message from the phone is now able to transfer all information needed to set up a connection.
So, only one message is needed instead of two separate messages. Even the name of the message
implies this property; it includes all L3 level information in one message. BSSMAP protocol interprets
its own part first that includes information of the cell, then DTAP part is interpreted normally. The
message of the DTAP-part could be one of the following:

• RR PAGING RESPONSE
• MM LOCATION UPDATING REQUEST
• MM CM RE-ESTABLISHMENT REQUEST
• MM CM SERVICE REQUEST
• MM IMSI DETACH

4 The MSC/A simulator software


The construction of the equipment in the laboratory is presented in the following figure. The phones are
missing.
BTS 1

BSC/TRAU MSC-simulator

BTS 2

Figure 20. The architecture of the equipment in the laboratory

The base stations are Siemens BS-11 micro base stations whose capacity is 1 TRX. NetHawk MSC-
simulator is able to perform 25 simultaneous call signalling. In addition the equipment includes an
ISDN phone that is connected directly to the PRI/AT card of the simulator-PC. This can accomplish
phone calls from a solid network to a mobile phone. The simulator controls automatically all actions
such as connecting the calls.

NetHawk-program consists of three parts: the actual simulator, configuration tools and a monitor-
program that decodes the signalling on interface A. The monitor-program is the most important tool in
this laboratory work.

4.1 MSC simulator

The simulator is controlled by a command interpreter or by macros. The console window shows real
time the messages that travel on interface A, excluding test-messages and fill-messages. The
commands can be given by transferring to command-mode. Simulation sequences can be written into
files that can be run at one time. The simulator itself is not very interesting as regard to the laboratory
work because the signalling messages on interface A are shown in console-window as heksa message
and they are not so fun to read. In addition, controlling the simulator must be done from a completed
macro because it is not useful to start learning the specialties of commander interpreter for the purpose
of this laboratory work. This is why programming accomplishment is not explained any more than this.
You’ll find more about it in course Tik-109.350. However, the following figure presents the
simulator’s protocol stack. Each box is its own CVOPS-process except actions accomplished by
PRI/AT-card.
CC

MM

BSSMAP BSSMAP
(sis. RR)

SCCP

SCCP
MTP3

MTP3
MTP2if

MTP2if
MTP2

PRI/AT -kortti
MTP2 PCM-linja 2

PCM-linja 1

Figure 21. The structure of NetHawk MSC-simulator’s processes [Net96]. Only the other PCM-link is
in use in the laboratory equipment.

4.2 Configuration tool

The MSC parameters can be set and users to GSM-network can be created by using configuration
program. For example the following parameters are set:

• SS#7 addresses of MSC and BSS, used signalling- and speech-channels, SS#7
standard (ANSI or ITU-T), GSM protocol version (1 or 2), synchronizing.
• Information on BSS cells, the addresses.
• Information on the phones. Such as MSISDN-numbers, frequency region, IMSI,
security parameters, speech code, short message parameters. In addition, information
on the phones of a solid network can be configurated.

Configuration information can be saved in a file and load later. When MSC-simulator program is
started it requires the user the configuration to be used. If the configuration of a network is changed,
must the simulator first be shut down and then restarted.
4.3 The Monitoring Program

The monitoring program is able to decode the messages on interface A beginning from MTP2 level.
The program offers numerous possibilities to do this. You can choose for example a print of messages
in heksa-form or the whole message decoded in English without the hex-form. The protocol layers of
which the decoding is wanted can also be chosen. The MTP2 layer, for example, is not worth decoding
in practise because the constant flow of fill-message units cover all useful information. The connection
events can be picked from the flow by using TMSI and it is also possible to set ‘traps’. ‘A trap’ stands
for an action that is launched by a predefined stimulator such as the Location update sent by a certain
phone (TMSI/IMSI). The functioning of the trap can be specified after the stimulator has been
launched. Using traps is useful in testing, for example in ‘over-night’- tests.

Most important in regards to this laboratory work is the versatile interpretation of the messages. It
enables us to examine signalling events very accurately. The messages from different protocol layers
are printed on the screen in different colours which eases the interpretation of the messages. Appendix
3 states an example on signalling on A interface that has been captured by the monitoring program.
Different monitor settings can be saved in a file to be reloaded later again.

The monitor program has two functioning modes: real-time mode and buffer mode. In real-time mode
almost real-time signalling data is printed on the screen. When switching to history mode, the messages
are forwarded to memory buffer and again when switching to real-time mode they appear on the
screen. When the wanted part of the signalling has been captured it is possible to transfer to the buffer
mode and study the messages. At this point, new windows can be opened and messages from different
protocol layers can be printed on them. The text from the screen can be copied to Wordpad (for
example).

Appendices

1) GSM-system interfaces
2) The protocol stacks of MSC-BSS
3) An example of signalling on interface A (NetHawk-print)
4) Some extracts from specifications GSM 04.08
5) Some extracts from specifications GSM 08.08 and 04.08 (Laboratory exercise 3)

References

[Mou92] Mouly M., Pautet M., “The GSM System for Mobile
Communications”, published by the authors, 1992

[Tie98] S-38.110 Tiedonvälitystekniikka I, opetusmoniste K-98, TKK 1998

[ITU703] Q.703, “Signalling system No. 7- signalling link”, ITU-T, March 1993
[GSM0406] GSM 04.06, “Mobile Station – Base Station System interface (phase
2+); Data Link (DL) layer specification”, version 5.2.0, ETSI, May
1998

[GSM0858] GSM 08.58, “Base Station Controller – Base Transceiver Station


interface (phase 2+); Layer 3 specification”, version 5.7.0, ETSI, May
1998

[GSM0808] GSM 08.08, “Mobile-services Switching Centre – Base Station System


interface (phase 2+); Layer 3 specification”, version 7.0.0, ETSI,
March 1998

[GSM0408] GSM 04.08, “Mobile radio interface layer 3 specification (phase 2+)”,
version 6.1.1, ETSI, August 1998

[Net96] “NetHawk MSC/A Simulator”, training material, X-Net OY, 1996

[mic98] “MicroLegend SS7 Tutorial”,


http://www.microlegend.com/whatss7.htm, 1998

[ITU921] Q.921, “ISDN user-network interface – Data link layer specification”,


September 1997, ITU-T

[ITU704] Q.704, “Specifications of Signalling System No.7 – Message transfer


part”, July 1996, ITU-T

[ITU713] Q.713, “Signalling Connection Control Part Formats and Codes”, July
1996, ITU-T

[Tel 98] Tik-109.350 Televerkon signalointiprotokollat ja –ohjelmistot,


opetusmoniste K-98, TKK 1998
Appendix 1: Interfaces of the GSM system

D
C

G
HLR VLR
GMSC
B

VLR

Asub
Air Abis A

MS
BTS
TRAU (=TC)
BSC
MSC

E F

MSC
EIR
O&M
OSI Appendix 2: MSC-BSS protocol stack

CM CM

DTAP DTAP

MM MM
DTAP
7
pd
RR

RR BSSMAP BSSMAP

RR’ RSM RSM

pd

d- function d- function
SCCP SCCP

3
MTP3 MTP3

LAPD MTP2 MTP2


LAPDm LAPDm LAPD
2

1 Radio channels 64kbps PCM line

MS BTS BSC MSC

Abis
Air interface A
Appendix 3: An example of A interface signalling

Conn:1 Card:1 TS:16 Subch:0 21083 16:41:14.585 - SS screening indicator 10h


CR - CONNECTION REQUEST - A5/2 algorithm available Message number
Routing Label Information - A5/3 algorithm not available
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - no additional MS capabilities available
- SLC : 15 (0Fh)
element Mobile Identity
Source Local Reference - length : 5h ID row, indicates the
- CF0400h - TMSI : 15e1bcd beginning of a message,
Protocol Class Conn:1 Card:1 TS:16 Subch:0 21086 16:41:14.654 time stamp, PCM time
- protocol class : 2h, connection oriented CC - CONNECTION CONFIRM slot, etc
Called Party Address Routing Label
- length 4 (04h) - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Message name
SCCP

- no global title present - SLC : 15 (0Fh)


- routing based on SSN and MTP routing label Destination Local Reference (in this case SCCP
- point code : 1513 (05E9h) - CF0400h messages)
- subsystem is BSSAP Source Local Reference
Calling Party Address - 002B01h
- length 4 (04h) Protocol Class
- no global title present - protocol class : 2h, connection oriented
- routing based on SSN and MTP routing label End of Optional Parameters
- point code : 1515 (05EBh) Conn:1 Card:1 TS:16 Subch:0 21090 16:41:14.819
- subsystem is BSSAP DT1 - DATA FORM 1
SCCP User Data BSSÄMSC Routing Label
- length 30 (1Eh) messages - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
End of Optional Parameters
are
- SLC : 15 (0Fh) NOTE! In this signalling
- BSSMAP (length : 28, 1Ch) Destination Local Reference
tabulated print only SCCP, BSSMAP,
COMPLETE L3 INFORMATION - CF0400h
Cell Identifier Segmenting/Reassembling and DTAP are decoded.
- length : 8 (08h)
d function - no more data
- cell global identification is used SCCP User Data
- MCC : 123 - length 22 (16h)
BSSMAP

- MNC : 45 - DTAP (length : 19, 13h)


- location area code : 11 (000Bh) - SAPI : 0, main DCCH is used
- cell identifier : 2 (0002h) AUTHENTICATION REQ (MM)
Layer 3 Information Ciphering Key Seq. Nr DTAP messages are
- length : 13 (0Dh) - value : 0h between MS<->MSC
Chosen Channel Auth. Parameter RAND
- SDCCH 30FD3033098AB0C98D8230980928342C
CM SERVICE REQUEST (MM) Conn:1 Card:1 TS:16 Subch:0 21092 16:41:15.538
CM Service Type DT1 - DATA FORM 1
- value : 1h Routing Label
Ciphering Key Seq. Nr - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- value : 7h - SLC : 15 (0Fh)
MS Classmark 2 Destination Local Reference
DTAP

- length : 3 (03h) BSSÅMSC - 002B01h


- revision level : used by phase 2 MSs Segmenting/Reassembling
- No autonomous early sending - no more data
- encryption algorithm A5/1 available SCCP User Data
- class 1, vehicle and portable - length 9 (09h)
- MS does not support ext. band G1 - DTAP (length : 6, 06h)
- short message capability present - SAPI : 0, main DCCH is used
- PS capability not present AUTHENTICATION RSP (MM)
Appendix 3: An example of A interface signalling

Auth. Parameter SRES : 22C9664B - SAPI : 0, main DCCH is used


Conn:1 Card:1 TS:16 Subch:0 21098 16:41:15.597 CALL PROCEEDING (CC)
DT1 - DATA FORM 1 Conn:1 Card:1 TS:16 Subch:0 21105 16:41:16.428
Routing Label DT1 - DATA FORM 1
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) Routing Label
- SLC : 15 (0Fh) - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Destination Local Reference - SLC : 15 (0Fh)
- CF0400h Destination Local Reference
Segmenting/Reassembling - CF0400h
- no more data Segmenting/Reassembling
SCCP User Data - no more data
- length 5 (05h) SCCP User Data
- DTAP (length : 2, 02h) - length 15 (0Fh)
- SAPI : 0, main DCCH is used - BSSMAP (length : 13, 0Dh)
CM SERVICE ACCEPT (MM) ASSIGNMENT REQUEST
Conn:1 Card:1 TS:16 Subch:0 21099 16:41:16.256 Channel Type
DT1 - DATA FORM 1 - length : 3 (03h)
Routing Label - speech
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - TCH/FR or HR, FR preferred, changes allowed
- SLC : 15 (0Fh) - speech full rate version 1
Destination Local Reference L3 Header Information
- 002B01h - length : 2 (02h)
Segmenting/Reassembling - protocol discr. : Radio Resources
- no more data - transaction id. : 0 (0h)
SCCP User Data - message send from originating side
- length 14 (0Eh) Circuit Identity Code
- DTAP (length : 11, 0Bh) - pcm multiplex : 0 (000h)
- SAPI : 0, main DCCH is used - pcm timeslot : 13 (0Dh)
SETUP (CC) Conn:1 Card:1 TS:16 Subch:0 21109 16:41:17.375
Bearer Capability DT1 - DATA FORM 1
- length : 1 (1h) Routing Label
- info xfer cap : speech - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- xfer mode : circuit - SLC : 15 (0Fh)
- coding std : GSM standardized Destination Local Reference
- radio ch req: full rate ch required - 002B01h
Called Party BCD Nr Segmenting/Reassembling
- nr type : 0 - no more data
- nr plan : 1 SCCP User Data
- nr : 737765 - length 7 (07h)
Conn:1 Card:1 TS:16 Subch:0 21103 16:41:16.326 - BSSMAP (length : 5, 05h)
DT1 - DATA FORM 1 ASSIGNMENT COMPLETE
Routing Label RR Cause
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) - normal
- SLC : 15 (0Fh) Chosen Channel
Destination Local Reference - full rate TCH
- CF0400h Conn:1 Card:1 TS:16 Subch:0 21112 16:41:17.444
Segmenting/Reassembling UDT - UNIT DATA
- no more data Routing Label
SCCP User Data - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- length 5 (05h) - SLC : 4 (04h)
- DTAP (length : 2, 02h) Protocol Class
Appendix 3: An example of A interface signalling

- protocol class : 0h, conn.less, discard msg - routing based on SSN and MTP routing label
Called Party Address - point code : 1515 (05EBh)
- length 2 (02h) - subsystem is BSSAP
- no global title present SCCP User Data
- routing based on SSN and MTP routing label - length 33 (21h)
- subsystem is BSSAP End of Optional Parameters
Calling Party Address - BSSMAP (length : 31, 1Fh)
- length 4 (04h) COMPLETE L3 INFORMATION
- no global title present Cell Identifier
- routing based on SSN and MTP routing label - length : 8 (08h)
- point code : 1513 (05E9h) - cell global identification is used
- subsystem is BSSAP - MCC : 123
SCCP User Data - MNC : 45
- length 30 (1Eh) - location area code : 11 (000Bh)
- BSSMAP (length : 28, 1Ch) - cell identifier : 2 (0002h)
PAGING Layer 3 Information
IMSI - length : 16 (10h)
- length : 8 (08h) Chosen Channel
- identity contains an IMSI - SDCCH
- mobile country code : 123 PAGING RESPONSE (RR)
- mobile network code : 45 Ciphering Key Seq. Nr
- MSIN : 0000000001 - value : 0h
Cell Identifier List MS Classmark 2
- length : 15 (0Fh) - length : 3 (03h)
- cell global identification is used - revision level : used by phase 2 MSs
- MCC : 123 - No autonomous early sending
- MNC : 45 - encryption algorithm A5/1 available
- location area code : 11 (000Bh) - class 1, vehicle and portable
- cell identifier : 2 (0002h) - MS does not support ext. band G1
- MCC : 123 - short message capability present
- MNC : 45 - PS capability not present
- location area code : 11 (000Bh) - SS screening indicator 10h
- cell identifier : 1 (0001h) - A5/2 algorithm available
Conn:1 Card:1 TS:16 Subch:0 21114 16:41:18.355 - A5/3 algorithm not available
CR - CONNECTION REQUEST - no additional MS capabilities available
Routing Label Mobile Identity
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - length : 8h
- SLC : 0 (00h) - IMSI : 123450000000001
Source Local Reference Conn:1 Card:1 TS:16 Subch:0 21116 16:41:18.423
- D00400h CC - CONNECTION CONFIRM
Protocol Class Routing Label
- protocol class : 2h, connection oriented - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Called Party Address - SLC : 0 (00h)
- length 4 (04h) Destination Local Reference
- no global title present - D00400h
- routing based on SSN and MTP routing label Source Local Reference
- point code : 1513 (05E9h) - 000202h
- subsystem is BSSAP Protocol Class
Calling Party Address - protocol class : 2h, connection oriented
- length 4 (04h) End of Optional Parameters
- no global title present Conn:1 Card:1 TS:16 Subch:0 21119 16:41:18.578
Appendix 3: An example of A interface signalling

DT1 - DATA FORM 1 - length : 5h


Routing Label - TMSI : 1822c18
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) Conn:1 Card:1 TS:16 Subch:0 21128 16:41:20.025
- SLC : 0 (00h) DT1 - DATA FORM 1
Destination Local Reference Routing Label
- D00400h - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
Segmenting/Reassembling - SLC : 0 (00h)
- no more data Destination Local Reference
SCCP User Data - 000202h
- length 22 (16h) Segmenting/Reassembling
- DTAP (length : 19, 13h) - no more data
- SAPI : 0, main DCCH is used SCCP User Data
AUTHENTICATION REQ (MM) - length 5 (05h)
Ciphering Key Seq. Nr - DTAP (length : 2, 02h)
- value : 0h - SAPI : 0, main DCCH is used
Auth. Parameter RAND TMSI REALLOC COMPL. (MM)
30FD3033098AB0C98D8230980928342C Conn:1 Card:1 TS:16 Subch:0 21131 16:41:20.086
Conn:1 Card:1 TS:16 Subch:0 21123 16:41:19.307 DT1 - DATA FORM 1
DT1 - DATA FORM 1 Routing Label
Routing Label - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - SLC : 0 (00h)
- SLC : 0 (00h) Destination Local Reference
Destination Local Reference - D00400h
- 000202h Segmenting/Reassembling
Segmenting/Reassembling - no more data
- no more data SCCP User Data
SCCP User Data - length 8 (08h)
- length 9 (09h) - DTAP (length : 5, 05h)
- DTAP (length : 6, 06h) - SAPI : 0, main DCCH is used
- SAPI : 0, main DCCH is used SETUP (CC)
AUTHENTICATION RSP (MM) Bearer Capability
Auth. Parameter SRES : 22C9664B - length : 1 (1h)
Conn:1 Card:1 TS:16 Subch:0 21125 16:41:19.369 - info xfer cap : speech
DT1 - DATA FORM 1 - xfer mode : circuit
Routing Label - coding std : GSM standardized
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) - radio ch req: dual rate/full rate preferred
- SLC : 0 (00h) Conn:1 Card:1 TS:16 Subch:0 21135 16:41:20.755
Destination Local Reference DT1 - DATA FORM 1
- D00400h Routing Label
Segmenting/Reassembling - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- no more data - SLC : 0 (00h)
SCCP User Data Destination Local Reference
- length 16 (10h) - 000202h
- DTAP (length : 13, 0Dh) Segmenting/Reassembling
- SAPI : 0, main DCCH is used - no more data
TMSI REALLOC COMMAND (MM) SCCP User Data
Location Area Id. - length 5 (05h)
- MCC : 123 - DTAP (length : 2, 02h)
- MNC : 45 - SAPI : 0, main DCCH is used
- LAC : 11 (bh) CALL CONFIRMED (CC)
Mobile Identity Conn:1 Card:1 TS:16 Subch:0 21137 16:41:20.823
Appendix 3: An example of A interface signalling

DT1 - DATA FORM 1 SCCP User Data


Routing Label - length 5 (05h)
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) - DTAP (length : 2, 02h)
- SLC : 0 (00h) - SAPI : 0, main DCCH is used
Destination Local Reference ALERTING (CC)
- D00400h Conn:1 Card:1 TS:16 Subch:0 21146 16:41:22.619
Segmenting/Reassembling DT1 - DATA FORM 1
- no more data Routing Label
SCCP User Data - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- length 15 (0Fh) - SLC : 15 (0Fh)
- BSSMAP (length : 13, 0Dh) Destination Local Reference
ASSIGNMENT REQUEST - CF0400h
Channel Type Segmenting/Reassembling
- length : 3 (03h) - no more data
- speech SCCP User Data
- TCH/FR or HR, FR preferred, changes allowed - length 5 (05h)
- speech full rate version 1 - DTAP (length : 2, 02h)
L3 Header Information - SAPI : 0, main DCCH is used
- length : 2 (02h) ALERTING (CC)
- protocol discr. : Radio Resources Conn:1 Card:1 TS:16 Subch:0 21149 16:41:23.322
- transaction id. : 0 (0h) DT1 - DATA FORM 1
- message send from originating side Routing Label
Circuit Identity Code - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- pcm multiplex : 0 (000h) - SLC : 0 (00h)
- pcm timeslot : 14 (0Eh) Destination Local Reference
Conn:1 Card:1 TS:16 Subch:0 21140 16:41:21.872 - 000202h
DT1 - DATA FORM 1 Segmenting/Reassembling
Routing Label - no more data
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) SCCP User Data
- SLC : 0 (00h) - length 5 (05h)
Destination Local Reference - DTAP (length : 2, 02h)
- 000202h - SAPI : 0, main DCCH is used
Segmenting/Reassembling CONNECT (CC)
- no more data Conn:1 Card:1 TS:16 Subch:0 21152 16:41:23.393
SCCP User Data DT1 - DATA FORM 1
- length 7 (07h) Routing Label
- BSSMAP (length : 5, 05h) - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
ASSIGNMENT COMPLETE - SLC : 0 (00h)
RR Cause Destination Local Reference
- normal - D00400h
Chosen Channel Segmenting/Reassembling
- full rate TCH - no more data
Conn:1 Card:1 TS:16 Subch:0 21143 16:41:22.029 SCCP User Data
DT1 - DATA FORM 1 - length 5 (05h)
Routing Label - DTAP (length : 2, 02h)
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - SAPI : 0, main DCCH is used
- SLC : 0 (00h) CONNECT ACKNOWLEDGE (CC)
Destination Local Reference Conn:1 Card:1 TS:16 Subch:0 21155 16:41:23.503
- 000202h DT1 - DATA FORM 1
Segmenting/Reassembling Routing Label
- no more data - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Appendix 3: An example of A interface signalling

- SLC : 15 (0Fh) 53 49 45 4D 45 4E 53 5F 54 45 4C 45 43 4F 00
Destination Local Reference Conn:1 Card:1 TS:16 Subch:0 21167 16:41:37.595
- CF0400h SLTA - SIGNALLING LINK TEST ACKNOWLEDGE
Segmenting/Reassembling - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- no more data - SLC : 0 (00h)
SCCP User Data - test pattern length : 15 (Fh)
- length 5 (05h) 53 49 45 4D 45 4E 53 5F 54 45 4C 45 43 4F 00
- DTAP (length : 2, 02h) Conn:1 Card:1 TS:16 Subch:0 21170 16:41:40.041
- SAPI : 0, main DCCH is used DT1 - DATA FORM 1
CONNECT (CC) Routing Label
Conn:1 Card:1 TS:16 Subch:0 21158 16:41:23.817 - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
DT1 - DATA FORM 1 - SLC : 0 (00h)
Routing Label Destination Local Reference
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - 000202h
- SLC : 15 (0Fh) Segmenting/Reassembling
Destination Local Reference - no more data
- 002B01h SCCP User Data
Segmenting/Reassembling - length 8 (08h)
- no more data - DTAP (length : 5, 05h)
SCCP User Data - SAPI : 0, main DCCH is used
- length 5 (05h) DISCONNECT (CC)
- DTAP (length : 2, 02h) Cause
- SAPI : 0, main DCCH is used - length : 2
CONNECT ACKNOWLEDGE (CC) - coding standard : GSM
Conn:1 Card:1 TS:16 Subch:0 21161 16:41:24.043 - location : user
DT1 - DATA FORM 1 - normal event
Routing Label - cause: normal clearing
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) Conn:1 Card:1 TS:16 Subch:0 21173 16:41:40.109
- SLC : 0 (00h) DT1 - DATA FORM 1
Destination Local Reference Routing Label
- 000202h - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Segmenting/Reassembling - SLC : 0 (00h)
- no more data Destination Local Reference
SCCP User Data - D00400h
- length 9 (09h) Segmenting/Reassembling
- DTAP (length : 6, 06h) - no more data
- SAPI : 0, main DCCH is used SCCP User Data
STATUS (CC) - length 9 (09h)
Cause - DTAP (length : 6, 06h)
- length : 2 - SAPI : 0, main DCCH is used
- coding standard : GSM RELEASE (CC)
- location : user Cause
- service or option not available - length : 2
- cause: incompatible with control state - coding standard : GSM
Call State - location : user
- value : 202 (cah) - normal event
Conn:1 Card:1 TS:16 Subch:0 21164 16:41:37.581 - cause: normal clearing
SLTM - SIGNALLING LINK TEST MESSAGE Conn:1 Card:1 TS:16 Subch:0 21176 16:41:40.219
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) DT1 - DATA FORM 1
- SLC : 0 (00h) Routing Label
- test pattern length : 15 (Fh) - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Appendix 3: An example of A interface signalling

- SLC : 15 (0Fh) - protocol discr. : Radio Resources


Destination Local Reference - transaction id. : 0 (0h)
- CF0400h - message send from originating side
Segmenting/Reassembling Cause
- no more data - length : 1 (01h)
SCCP User Data - radio interface message failure
- length 8 (08h) Conn:1 Card:1 TS:16 Subch:0 21185 16:41:40.535
- DTAP (length : 5, 05h) DT1 - DATA FORM 1
- SAPI : 0, main DCCH is used Routing Label
DISCONNECT (CC) - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
Cause - SLC : 15 (0Fh)
- length : 2 Destination Local Reference
- coding standard : GSM - 002B01h
- location : user Segmenting/Reassembling
- normal event - no more data
- cause: normal clearing SCCP User Data
Conn:1 Card:1 TS:16 Subch:0 21179 16:41:40.439 - length 9 (09h)
DT1 - DATA FORM 1 - DTAP (length : 6, 06h)
Routing Label - SAPI : 0, main DCCH is used
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) RELEASE (CC)
- SLC : 0 (00h) Cause
Destination Local Reference - length : 2
- 000202h - coding standard : GSM
Segmenting/Reassembling - location : user
- no more data - normal event
SCCP User Data - cause: normal clearing
- length 9 (09h) Conn:1 Card:1 TS:16 Subch:0 21188 16:41:40.590
- DTAP (length : 6, 06h) DT1 - DATA FORM 1
- SAPI : 0, main DCCH is used Routing Label
RELEASE COMPLETE (CC) - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
Cause - SLC : 0 (00h)
- length : 2 Destination Local Reference
- coding standard : GSM - 000202h
- location : user Segmenting/Reassembling
- normal event - no more data
- cause: normal clearing SCCP User Data
Conn:1 Card:1 TS:16 Subch:0 21182 16:41:40.507 - length 3 (03h)
DT1 - DATA FORM 1 - BSSMAP (length : 1, 01h)
Routing Label CLEAR COMPLETE
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) Conn:1 Card:1 TS:16 Subch:0 21191 16:41:40.604
- SLC : 0 (00h) DT1 - DATA FORM 1
Destination Local Reference Routing Label
- D00400h - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
Segmenting/Reassembling - SLC : 15 (0Fh)
- no more data Destination Local Reference
SCCP User Data - CF0400h
- length 10 (0Ah) Segmenting/Reassembling
- BSSMAP (length : 8, 08h) - no more data
CLEAR COMMAND SCCP User Data
L3 Header Information - length 9 (09h)
- length : 2 (02h) - DTAP (length : 6, 06h)
Appendix 3: An example of A interface signalling

- SAPI : 0, main DCCH is used Release Cause


RELEASE COMPLETE (CC) - end user originated
Cause End of Optional Parameters
- length : 2 Conn:1 Card:1 TS:16 Subch:0 21202 16:41:41.217
- coding standard : GSM RLSD - RELEASED
- location : user Routing Label
- normal event - DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- cause: normal clearing - SLC : 15 (0Fh)
Conn:1 Card:1 TS:16 Subch:0 21193 16:41:40.604 Destination Local Reference
DT1 - DATA FORM 1 - CF0400h
Routing Label Source Local Reference
- DPC : 1515 (05EBh) OPC : 1513 (05E9h) - 002B01h
- SLC : 15 (0Fh) Release Cause
Destination Local Reference - end user originated
- CF0400h End of Optional Parameters
Segmenting/Reassembling Conn:1 Card:1 TS:16 Subch:0 21206 16:41:41.296
- no more data RLC - RELEASE COMPLETE
SCCP User Data Routing Label
- length 10 (0Ah) - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- BSSMAP (length : 8, 08h) - SLC : 0 (00h)
CLEAR COMMAND Destination Local Reference
L3 Header Information - 000202h
- length : 2 (02h) Source Local Reference
- protocol discr. : Radio Resources - D00400h
- transaction id. : 0 (0h) Conn:1 Card:1 TS:16 Subch:0 21207 16:41:41.296
- message send from originating side RLC - RELEASE COMPLETE
Cause Routing Label
- length : 1 (01h) - DPC : 1513 (05E9h) OPC : 1515 (05EBh)
- radio interface message failure - SLC : 15 (0Fh)
Conn:1 Card:1 TS:16 Subch:0 21197 16:41:40.700 Destination Local Reference
DT1 - DATA FORM 1 - 002B01h
Routing Label Source Local Reference
- DPC : 1513 (05E9h) OPC : 1515 (05EBh) - CF0400h
- SLC : 15 (0Fh)
Destination Local Reference
- 002B01h
Segmenting/Reassembling
- no more data
SCCP User Data
- length 3 (03h)
- BSSMAP (length : 1, 01h)
CLEAR COMPLETE
Conn:1 Card:1 TS:16 Subch:0 21200 16:41:41.217
RLSD - RELEASED
Routing Label
- DPC : 1515 (05EBh) OPC : 1513 (05E9h)
- SLC : 0 (00h)
Destination Local Reference
- D00400h
Source Local Reference
- 000202h
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

The following excerpts are from GSM 04.08.

9.2.9 CM service request

This message is sent by the mobile station to the network to request a service for the connection management sublayer entities, e.g.
circuit switched connection establishment, supplementary services activation, short message transfer. See table 9.45/GSM 04.08.
Message type: CM SERVICE REQUEST
Significance: dual
Direction:mobile station to network

IEI Information element Type / Reference Presence Format Length


Mobility management Protocol discriminator M V ½
protocol discriminator 10.2
Skip Indicator Skip Indicator M V ½
10.3.1
CM Service Request Message type M V 1
message type 10.4
CM service type CM service type M V ½
10.5.3.3
Ciphering key sequence Ciphering key sequence M V ½
number number
10.5.1.2
Mobile station Mobile station M LV 4
classmark classmark 2
10.5.1.6
Mobile identity Mobile identity M LV 2-9
10.5.1.4

Table 9.45/GSM 04.08


CM SERVICE REQUEST message content

10 General message format and information elements coding

The figures and text in this section describe the Information Elements contents.

10.1 Overview
Within the Layer 3 protocols defined in GSM 04.08, every message with the exception of the messages sent on the BCCH, downlink
CCCH, SCH, RACH, and the HANDOVER ACCESS message, is a standard L3 message as defined in GSM 04.07. This means that the
message consists of the following parts:
a) protocol discriminator;
b) transaction identifier;
c) message type;
d) other information elements, as required.

This organization is illustrated in the example shown in figure 10.1/GSM 04.08.


8 7 6 5 4 3 2 1

7UDQVDFWLRQLGHQWLILHU 3URWRFROGLVFULPLQDWRU RFWHW


or Skip Indicator 
0HVVDJHtype RFWHW
2WKHULQIRUPDWLRQHOHPHQWVDVrequired HWF

FIGURE 10.1/GSM 04.08
General message organization example
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

Unless specified otherwise in the message descriptions of section 9, a particular information element shall not be present more than once
in a given message.
The term "default" implies that the value defined shall be used in the absence of any assignment, or that this value allows negotiation of
alternative values in between the two peer entities.
When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least
significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.

Table 11.1: 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 Value yes yes yes

NOTICE !

….
The order of the information elements within the imperative part of messages has been chosen so that information elements with ½ octet
of content (type 1) go together in succession. The first type 1 information element occupies bits 1 to 4 of octet N, the second bits 5 to 8
of octet N, the third bits 1 to 4 of octet N + 1 etc. If the number of type 1 information elements is odd then bits 5 to 8 of the last octet
occupied by these information elements contains a spare half octet IE in format V.
….

10.2 Protocol Discriminator


The Protocol Discriminator (PD) and its use are defined in GSM 04.07. GSM 04.08 defines the protocols relating to the PD values
bits 4321
0011 Call Control; call related SS messages
0101 Mobility Management messages
0110 Radio Resource management messages

except the call related SS procedures, which are defined in GSM 04.10.

10.3 Skip indicator and transaction identifier


10.3.1 Skip indicator

Bits 5 to 8 of the first octet of every Radio Resource management message and Mobility Management message contains the skip
indicator. A message received with skip indicator different from 0000 shall be ignored. A message received with skip indicator encoded
as 0000 shall not be ignored (unless it is ignored for other reasons). A protocol entity sending a Radio Resource management message or
a Mobility Management message shall encode the skip indicator as 0000.

10.3.2 Transaction identifier

Bits 5 to 8 of the first octet of every message belonging to the protocol "Call Control; call related SS messages" contain the transaction
identifier (TI). The transaction identifier and its use are defined in GSM 04.07.

Seuraava kohta on spesifikaatiosta 04.07.

8 7 6 5 4 3 2 1
TI TI octet 1
flag value
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

Figure 11.9: Transaction identifier

Table 11.3. Transaction identifier

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

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

10.4 Message Type


The message type IE and its use are defined in GSM 04.07. Tables 10.3/GSM 04.08, 10.4/GSM 04.08, and 10.5/GSM 04.08 define the
value part of the message type IE used in the Radio Resource management protocol, the Mobility Management protocol, and the Call
Control protocol.

1

0 1 1 1 - - - Channel establishment messages:
1 - ADDITIONAL ASSIGNMENT
1 1 - IMMEDIATE ASSIGNMENT
0 1 - IMMEDIATE ASSIGNMENT EXTENDED
,00(',$7($66,*10(17REJECT

0 1 1 0 - - - Ciphering messages:
&,3+(5,1*02'(COMMAND
&,3+(5,1*02'(COMPLETE

0 1 0 1 - - - Handover messages:
1 0 - ASSIGNMENT COMMAND
0 1 - ASSIGNMENT COMPLETE
1 1 - ASSIGNMENT FAILURE
1 - HANDOVER COMMAND
0 - HANDOVER COMPLETE
0 0 - HANDOVER FAILURE
3+<6,&$/INFORMATION

0 0 0 1 - - - Channel release messages:
&+$11(/RELEASE
3$57,$/RELEASE
1 1 - PARTIAL RELEASE COMPLETE

0 1 0 0 - - - Paging messages:
0 1 - PAGING REQUEST TYPE 1
3$*,1*5(48(677<3(2
0 - PAGING REQUEST TYPE 3
1 1 - PAGING RESPONSE


Table 10.1/GSM 04.08 (page 1 of 2)


Message types for Radio Resource management
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

1

0 0 1 1 - - - System information messages:
0 0 - SYSTEM INFORMATION TYPE 8
0 1 - SYSTEM INFORMATION TYPE 1
6<67(0,1)250$7,217<3(2
1 - SYSTEM INFORMATION TYPE 3
0 - SYSTEM INFORMATION TYPE 4
6<67(0,1)250$7,217<3(5
1 0 - SYSTEM INFORMATION TYPE 6
1 1 - SYSTEM INFORMATION TYPE 7

0 0 0 0 - - - System information messages:
6<67(0,1)250$7,217<3(2bis
1 - SYSTEM INFORMATION TYPE 2ter
6<67(0,1)250$7,217<3(5bis
1 0 - SYSTEM INFORMATION TYPE 5ter

0 0 1 0 - - - Miscellaneous messages:
0 0 - CHANNEL MODE MODIFY
RR STATUS
1 1 - CHANNEL MODE MODIFY ACKNOWLEDGE
0 - FREQUENCY REDEFINITION
0($685(0(17REPORT
1 0 - CLASSMARK CHANGE
1 - CLASSMARK ENQUIRY

Table 10.1/GSM 04.08 (page 2 of 2)


Message types for Radio Resource management

Bit 8 is reserved for possible future use as an extension bit, see GSM 04.07.


1

[0 - - - - Registration messages:
0 0 1 - IMSI DETACH INDICATION
0 1 0 - LOCATION UPDATING ACCEPT
0 - LOCATION UPDATING REJECT
0 0 - LOCATION UPDATING REQUEST

[- Security messages:
0 0 1 - AUTHENTICATION REJECT
0 1 0 - AUTHENTICATION REQUEST
0 - AUTHENTICATION RESPONSE
0 0 - IDENTITY REQUEST
0 1 - IDENTITY RESPONSE
TMSI REALLOCATION COMMAND
1 - TMSI REALLOCATION COMPLETE

[- Connection management messages:
0 0 1 - CM SERVICE ACCEPT
0 1 0 - CM SERVICE REJECT
0 1 1 - CM SERVICE ABORT
0 - CM SERVICE REQUEST
0 0 - CM RE-ESTABLISHMENT REQUEST
0 1 - ABORT

[1 - - - - Miscellaneous messages:
0 0 1 - MM STATUS

Table 10.2/GSM 04.08


Message types for Mobility Management

Bit 8 is reserved for possible future use as an extension bit, see GSM 04.07.
Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bit 7 is
coded with a "0". See GSM 04.07.
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

1
[0 0 0 0 0 escape to nationally specific
message types ; see 1) below

[0 - - - - Call establishment messages:
0 0 1 - ALERTING
0 0 - CALL CONFIRMED
0 1 0 - CALL PROCEEDING
1 1 - CONNECT
1 1 1 - CONNECT ACKNOWLEDGE
1 1 0 - EMERGENCY SETUP
0 1 1 - PROGRESS
SETUP

[- Call information phase messages:
1 1 - MODIFY
1 1 1 - MODIFY COMPLETE
0 1 1 - MODIFY REJECT
0 0 0 - USER INFORMATION
0 0 - HOLD
0 1 - HOLD ACKNOWLEDGE
+2/'REJECT
1 0 0 - RETRIEVE
1 0 1 - RETRIEVE ACKNOWLEDGE
1 1 0 - RETRIEVE REJECT

[- Call clearing messages:
DISCONNECT
1 0 1 - RELEASE
5(/($6(COMPLETE

[1 - - - - Miscellaneous messages:
0 1 - CONGESTION CONTROL
1 1 0 - NOTIFY
1 0 1 - STATUS
0 - STATUS ENQUIRY
67$57DTMF
0 0 1 - STOP DTMF
0 1 0 - STOP DTMF ACKNOWLEDGE
1 0 - START DTMF ACKNOWLEDGE
1 1 - START DTMF REJECT
FACILITY

Table 10.3/GSM 04.08


Message types for Call Control and call related SS messages

1): When used, the message type is defined in the following octet(s), according to the national
specification.

Bit 8 is reserved for possible future use as an extension bit, see GSM 04.07.
Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In messages sent from the network, bit 7 is
coded with a "0". See GSM 04.07.
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

10.5.3.3 CM service type

The purpose of the CM Service Type information element is to specify which service is requested from the network.
The CM Service Type information element is coded as shown in figure 10.63/GSM 04.08 and table 10.63/GSM 04.08.
The CM Service Type is a type 1 information element .
8 7 6 5 4 3 2 1

&0VHUYLFHW\SHIEI VHUYLFHW\SH RFWHW

FIGURE 10.63/GSM 04.08


CM Service Type information element

6HUYLFHW\SH RFWHW)
Bits
1
0 0 1 Mobile originating call establishment
or packet mode connection establishment
0 1 0 Emergency call establishment
0 Short message service
0 0 Supplementary service activation

$OORWKHUYDOXHVDUHUHVHUYHG

Table 10.63/GSM 04.08


CM Service Type information element

10.5.1.2 Ciphering Key Sequence Number

The purpose of the Ciphering Key Sequence Number information element is to make it possible for the network to identify the ciphering
key Kc which is stored in the mobile station without invoking the authentication procedure. The ciphering key sequence number is
allocated by the network and sent with the AUTHENTICATION REQUEST message to the mobile station where it is stored together
with the calculated ciphering key Kc.
The Ciphering Key Sequence Number information element is coded as shown in figure 10.3/GSM 04.08 and table 10.6/GSM 04.08.
The ciphering key sequence number is a type 1 information element.
8 7 6 5 4 3 2 1

 &LSKHULQJKey  NH\VHTXHQFH RFWHW


 6HTXHQFHNumber  
 IEI VSDUH 

FIGURE 10.3/GSM 04.08


Ciphering Key Sequence Number information element

.H\VHTXHQFH RFWHW)

Bits
1

0 0
through Possible values for the ciphering key
1 0 sequence number

1 1 No key is available (MS to network);
5HVHUYHG QHWZRUNWR06)

Table 10.6/GSM 04.08


Ciphering Key Sequence Number information element
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

10.5.1.6 Mobile Station Classmark 2

The purpose of the Mobile Station Classmark 2 information element is to provide the network with information concerning aspects of
both high and low priority of the mobile station equipment. This affects the manner in which the network handles the operation of the
mobile station. The Mobile Station Classmark information indicates general mobile station characteristics and it shall therefore, except
for fields explicitly indicated, be independent of the frequency band of the channel it is sent on.
The Mobile Station Classmark 2 information element is coded as shown in figure 10.7/GSM 04.08, table 10.10a/GSM 04.08 and
table 10.10b/GSM 04.08.
The Mobile Station Classmark 2 is a type 4 information element with 5 octets length.
8 7 6 5 4 3 2 1

 Mobile station classmark 2 IEI RFWHW



/HQJWKRIPRELOHVWDWLRQclassmark 2 contents RFWHW
0 5HYLVLRQ (6 $ RF power
spare OHYHO IND  FDSDELOLW\ RFWHW
0 36 666FUHHQ 60FD 0 0 FC
spare FDSD Indicator pabi. spare  RFWHW
CM3 0 0 0 0 0 $ $
 spare   RFWHW

FIGURE 10.7/GSM 04.08


Mobile Station Classmark 2 information element

NOTE: Owing to backward compatibility problems, bit 8 of octet 4 should not be used unless it is also
checked that the bits 8, 7 and 6 of octet 3 are not "0 0 0".
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

Revision level (octet 3)


Bits
76
0 0 Reserved for phase 1
0 1 Used by phase 2 MSs

All other values are reserved for future use

ES IND (octet 2, bit 5) "Controlled Early Classmark Sending" option implementation

0 "Controlled Early Classmark Sending" option is not implemented


1 "Controlled Early Classmark Sending" option is implemented

A5/1 algorithm supported (octet 3, bit 4)

0 encryption algorithm A5/1 available


1 encryption algorithm A5/1 not available

When the GSM 900 band is used (for exceptions see 3.4.12):
Bits
321
0 0 0 class 1
0 0 1 class 2
0 1 0 class 3
0 1 1 class 4
1 0 0 class 5

All other values are reserved.

When the DCS 1800 band is used (for exceptions see 3.4.12):
Bits
321
0 0 0 class 1
0 0 1 class 2
0 1 0 class 3

All other values are reserved.

PS capability (pseudo-synchronization capability) (octet 4)


Bit 7
0 PS capability not present
1 PS capability present

SS Screening Indicator (octet 4)


Bits
65
0 0 defined in GSM 04.80
0 1 defined in GSM 04.80
1 0 defined in GSM 04.80
1 1 defined in GSM 04.80

SM capability (MT SMS pt to pt capability) (octet 4)


Bit 4
0 Mobile Station does not support mobile terminated point to point SMS
1 Mobile Station supports mobile terminated point to point SMS

Table 10.10a/GSM 04.08


Mobile Station Classmark 2 information element
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

FC Frequency Capability (octet 4)


When the GSM 900 band is used (for exceptions see 3.4.12):
bit 1
0 The mobile station does not support the extension band G1 in addition to the primary GSM
band. (For definition of frequency bands see GSM 05.05)
1 The mobile station does support the extension band G1 in addition to the primary GSM band. (For
definition of frequency bands see GSM 05.05)

When the DCS 1800 band is used (for exceptions see 3.4.12):
bit 1
0 Reserved for future use (for definition of frequency bands see GSM 05.05)

Note: This bit conveys no information about support or non support of the G1 extension band when transmitted on a
DCS 1800 channel.

Classmark 3 (octet 5, bit 8)


0 No additional MS capability information available
1 Additional MS capabilities are described in the Classmark 3 information element

A5/3 algorithm supported (octet 5, bit 2)


0 encryption algorithm A5/3 not available
1 encryption algorithm A5/3 available

A5/2 algorithm supported (octet 5, bit 1)


0 encryption algorithm A5/2 not available
1 encryption algorithm A5/2 available

Table 10.10b/GSM 04.08


Mobile Station Classmark 2 information element

NOTE: Additional mobile station capability information might be obtained by invoking the classmark
interrogation procedure.

10.5.1.4 Mobile Identity

The purpose of the Mobile Identity information element is to provide either the international mobile subscriber identity, IMSI, the
temporary mobile subscriber identity, TMSI, the international mobile equipment identity, IMEI or the international mobile equipment
identity together with the software version number, IMEISV.
The IMSI shall not exceed 15 digits, the TMSI is 4 octets long, and the IMEI is composed of 15 digits, the IMEISV is 16 digits (see
GSM 03.03).
For all transactions except emergency call establishment, emergency call re-establishment, mobile terminated call establishment, the
identification procedure, and the ciphering mode setting procedure, the mobile station and the network shall select the mobile identity
type with the following priority:
1- TMSI: The TMSI shall be used if it is available.

2- IMSI: The IMSI shall be used in cases where no TMSI is available.

For mobile terminated call establishment the mobile station shall select the same mobile identity type as received from the network in the
PAGING REQUEST message.
For emergency call establishment and re-establishment the mobile station shall select the mobile identity type with the following
priority:
1- TMSI: The TMSI shall be used if it is available.

2- IMSI: The IMSI shall be used in cases where no TMSI is available.

3- IMEI: The IMEI shall be used in cases where no SIM is available or the SIM is considered as not valid by the
mobile station or no IMSI or TMSI is available.

In the identification procedure the mobile station shall select the mobile identity type which was requested by the network.
In the ciphering mode setting procedure the mobile shall select the IMEISV.
The Mobile Identity information element is coded as shown in figure 10.5/GSM 04.08 and table 10.8/GSM 04.08.
The Mobile Identity is a type 4 information element with a minimum length of 3 octet and 10 octets length maximal. Further restriction
on the length may be applied, e.g. number plans.
Appendix 4: Decoding values for the CM SERVICE REQUEST message [GSM0408]

8 7 6 5 4 3 2 1

 Mobile Identity IEI RFWHW



/HQJWKRIPRELOHLGHQWLW\contents RFWHW
 odd/ 
,GHQWLW\GLJLW1 HYHQ 7\SHRILGHQWLW\ RFWHW
 indic 

,GHQWLW\GLJLWS1 ,GHQWLW\GLJLWS RFWHW

FIGURE 10.5/GSM 04.08


Mobile Identity information element

7\SHRILGHQWLW\ RFWHW)
Bits
1
0 1 IMSI
0 IMEI
1 IMEISV
0 TMSI
0 0 No Identity note 1)

$OORWKHUYDOXHVDUHUHVHUYHG

2GGHYHQLQGLFDWLRQ RFWHW)
Bit
4
0 even number of identity digits and also when
the TMSI is used
1 odd number of identity digits

,GHQWLW\GLJLWV RFWHWHWF)
)RUWKHIMSI, IMEI and IMEISV this field is coded using
BCD coding. If the number of identity digits is even
then bits 5 to 8 of the last octet shall be filled
with an end mark coded as "1111".

,IWKHPRELOHLGHQWLW\LVWKHTMSI then bits 5 to 8 of
octet 3 are coded as "1111" and bit 8 of octet 4 is the
most significant bit and bit 1 of the last octet the
least significant bit. The coding of the TMSI is left
open for each administration.

Table 10.8/GSM 04.08


Mobile Identity information element

NOTE 1: This can be used in the case when a fill paging message without any valid identity has to be sent on
the paging subchannel
Appendix 5: Excerpts from GSM 08.08

This appendix contains information of the structure of a COMPLETE LAYER 3 INFORMATION message,
which is the first message sent by the BSC at the beginning of a BSSMAP connection. Encapsulated in the
message, within the Layer 3 Information field, is the first MSÅMSC message, like CM SERVICE REQUEST
or PAGING RESPONSE.

3.2.1.32 COMPLETE LAYER 3 INFORMATION

The message is sent from the BSS to the MSC as described in subclause 3.1.16 (on receipt of the initial layer 3 message on a
dedicated channel, e.g. PAGING RESPONSE, LOCATION UPDATING REQUEST, CM REESTABLISHMENT REQUEST,
CM SERVICE REQUEST, IMSI DETACH).
The message is sent via the BSSAP SCCP connection established for the associated dedicated resource(s).
INFORMATION ELEMENT REFERENCE DIRECTION TYPE LEN

Message Type 3.2.2.1 BSS-MSC M 1

Cell Identifier 3.2.2.17 BSS-MSC M 3-10

Layer 3 Information 3.2.2.24 BSS-MSC M 3-n

Chosen Channel 3.2.2.33 BSS-MSC O (1) 2

1 This element is optionally used by the BSS to give the MSC a description of the channel rate/type
on which the initial layer 3 message was received.

3.2.2 SIGNALLING ELEMENT CODING

This paragraph contains the CODING of the signalling elements used.


The following conventions are assumed for the sequence of transmission of bits and bytes:
- Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first.

- In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc.

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The
least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.
- For variable length elements a length indicator is included, this indicates the number of octets following in the
element.

- All fields within Information Elements are mandatory unless otherwise specified. The Information Element
Identifier shall always be included.

All spare bits are set to 0.


The elements used and their CODING are:

Element
Identifier Element name Reference
Coding
0000 0001 Circuit Identity Code 3.2.2.2
0000 0010 Reserved *
0000 0011 Resource Available 3.2.2.4
0000 0100 Cause 3.2.2.5
0000 0101 Cell Identifier 3.2.2.17
0000 0110 Priority 3.2.2.18
0000 0111 Layer 3 Header Information 3.2.2.9
0000 1000 IMSI 3.2.2.6
Appendix 5: Excerpts from GSM 08.08

0000 1001 TMSI 3.2.2.7


0000 1010 Encryption Information 3.2.2.10
0000 1011 Channel Type 3.2.2.11
0000 1100 Periodicity 3.2.2.12
0000 1101 Extended Resource Indicator 3.2.2.13
0000 1110 Number Of MSs 3.2.2.8
0000 1111 Reserved *
0001 0000 Reserved *
0001 0001 Reserved *
0001 0010 Classmark Information Type 2 3.2.2.19
0001 0011 Classmark Information Type 3 3.2.2.20
0001 0100 Interference Band To Be Used 3.2.2.21
0001 0101 RR Cause 3.2.2.22
0001 0110 Reserved *
0001 0111 Layer 3 Information 3.2.2.24
0001 1000 DLCI 3.2.2.25
0001 1001 Downlink DTX Flag 3.2.2.26
0001 1010 Cell Identifier List 3.2.2.27
0001 1011 Response Request 3.2.2.28
0001 1100 Resource Indication Method 3.2.2.29
0001 1101 Classmark Information Type 1 3.2.2.30
0001 1110 Circuit Identity Code List 3.2.2.31
0001 1111 Diagnostic 3.2.2.32
(continued)
Element
Identifier Element name Reference
Coding
0010 0000 Layer 3 Message Contents 3.2.2.35
0010 0001 Chosen Channel 3.2.2.33
0010 0010 Total Resource Accessible 3.2.2.14
0010 0011 Cipher Response Mode 3.2.2.34
0010 0100 Channel Needed 3.2.2.36
0010 0101 Trace Type 3.2.2.37
0010 0110 Triggerid 3.2.2.38
0010 0111 Trace Reference 3.2.2.39
0010 1000 Transactionid 3.2.2.40
0010 1001 Mobile Identity 3.2.2.41
0010 1010 OMCId 3.2.2.42
0010 1011 Forward Indicator 3.2.2.43
0010 1100 Chosen Encryption Algorithm 3.2.2.44
0010 1101 Circuit Pool 3.2.2.45
0010 1110 Circuit Pool List 3.2.2.46
0010 1111 Time Indication 3.2.2.47
0011 0000 Resource Situation 3.2.2.48
0011 0001 Current Channel type 1 3.2.2.49
0011 0010 Queueing Indicator 3.2.2.50
0100 0000 Speech Version 3.2.2.51
0011 0011 Assignment Requirement 3.2.2.52

0011 0101 Talker Flag 3.2.2.54


0011 0110 Connection Release Requested 3.2.2.3
0011 0111 Group Call Reference 3.2.2.56
0011 1000 eMLPP Priority 3.2.2.56
0011 1001 Configuration Evolution Indication 3.2.2.57

* Information Element codes marked as "reserved" are reserved for use by previous versions of this
interface specification
Appendix 5: Excerpts from GSM 08.08
3.2.2.1 Message Type

Message Type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages.
Bit 8 is reserved for future extension of the code set. All unassigned codes are spare.
87654321
00000000 Reserved.
ASSIGNMENT MESSAGES
00000001 ASSIGNMENT REQUEST
00000010 ASSIGNMENT COMPLETE
00000011 ASSIGNMENT FAILURE
HANDOVER MESSAGES
00010000 HANDOVER REQUEST
00010001 HANDOVER REQUIRED
00010010 HANDOVER REQUEST ACKNOWLEDGE
00010011 HANDOVER COMMAND
00010100 HANDOVER COMPLETE
00010101 HANDOVER SUCCEEDED
00010110 HANDOVER FAILURE
00010111 HANDOVER PERFORMED
00011000 HANDOVER CANDIDATE ENQUIRE
00011001 HANDOVER CANDIDATE RESPONSE
00011010 HANDOVER REQUIRED REJECT
00011011 HANDOVER DETECT
RELEASE MESSAGES
00100000 CLEAR COMMAND
00100001 CLEAR COMPLETE
00100010 CLEAR REQUEST
00100011 RESERVED
00100100 RESERVED
00100101 SAPI “N” REJECT
00100110 CONFUSION
OTHER CONNECTION RELATED MESSAGES
00101000 SUSPEND
00101001 RESUME
GENERAL MESSAGES
00110000 RESET
00110001 RESET ACKNOWLEDGE
00110010 OVERLOAD
00110011 RESERVED
00110100 RESET CIRCUIT
00110101 RESET CIRCUIT ACKNOWLEDGE
00110110 MSC INVOKE TRACE
00110111 BSS INVOKE TRACE
TERRESTRIAL RESOURCE MESSAGES
01000000 BLOCK
01000001 BLOCKING ACKNOWLEDGE
01000010 UNBLOCK
01000011 UNBLOCKING ACKNOWLEDGE
01000100 CIRCUIT GROUP BLOCK
01000101 CIRCUIT GROUP BLOCKING
ACKNOWLEDGE
01000110 CIRCUIT GROUP UNBLOCK
01000111 CIRCUIT GROUP UNBLOCKING
ACKNOWLEDGE
01001000 UNEQUIPPED CIRCUIT
01001110 CHANGE CIRCUIT
01001111 CHANGE CIRCUIT ACKNOWLEDGE

(continued)
Appendix 5: Excerpts from GSM 08.08
(concluded)
87654321

RADIO RESOURCE MESSAGES


01010000 RESOURCE REQUEST
01010001 RESOURCE INDICATION
01010010 PAGING
01010011 CIPHER MODE COMMAND
01010100 CLASSMARK UPDATE
01010101 CIPHER MODE COMPLETE
01010110 QUEUING INDICATION
01010111 COMPLETE LAYER 3 INFORMATION
01011000 CLASSMARK REQUEST
01011001 CIPHER MODE REJECT
01011010 LOAD INDICATION
VGCS/VBS
00000100 VGCS/VBS SETUP
00000101 VGCS/VBS SETUP ACK
00000110 VGCS/VBS SETUP REFUSE
00000111 VGCS/VBS ASSIGNMENT REQUEST
00011100 VGCS/VBS ASSIGNMENT RESULT
00011101 VGCS/VBS ASSIGNMENT FAILURE
00011110 VGCS/VBS QUEUING INDICATION
00011111 UPLINK REQUEST
00100111 UPLINK REQUEST ACKNOWLEDGE
01001001 UPLINK REQUEST CONFIRMATION
01001010 UPLINK RELEASE INDICATION
01001011 UPLINK REJECT COMMAND
01001100 UPLINK RELEASE COMMAND
01001101 UPLINK SEIZED COMMAND

3.2.2.17 Cell Identifier

This element uniquely identifies a cell within a BSS and is of variable length containing the following fields:
 
(OHPHQWLGHQWLILHU RFWHW
/HQJWK RFWHW
6SDUH &HOOLGHQWLILFDWLRQ RFWHW
 GLVFULPLQDWRU 
&HOOLGHQWLILFDWLRQ RFWHWQ

The coding of octet 2 is a binary number indicating the length of the remaining element. The length depends on the Cell
identification discriminator (octet 3).
The coding of "Cell identification discriminator" (bits 1 to 4 of octet 3) is a binary number indicating if the whole or a part of Cell
Global Identification, CGI, according to GSM 03.03 is used for cell identification in octet 4-n. The "Cell identification
discriminator" is coded as follows:
0000 The whole Cell Global Identification, CGI, is used to identify the cell.
0001 Location Area Code, LAC, and Cell Identity, CI, is used to identify the cell.
0010 Cell Identity, CI, is used to identify the cell.
0011 No cell is associated with the transaction.

All other values are reserved.


Appendix 5: Excerpts from GSM 08.08
The coding of octet 4-n depends on the Cell identification discriminator (octet 3). Below the coding is shown for each Cell
identification discriminator:
Note that no coding is specified for a Cell identification discriminator value of "0011" as no additional information is required.
Coding of Cell Identification for
Cell identification discriminator = 0000
 
0&&GLJ 0&&GLJ RFWHW
 0&&GLJ RFWHW
01&GLJ 01&GLJ RFWHW
/$& RFWHW
/$&FRQW RFWHW
&,YDOXH RFWHW
&,YDOXHFRQW RFWHW

The octets 4-8 are coded as shown in GSM 04.08, Table ‘Location Area Identification information element’ .
The octets 9-10 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’ .
Coding of Cell Identification for
Cell identification discriminator = 0001
 
/$& RFWHW
/$&FRQW RFWHW
&,YDOXH RFWHW
&,YDOXHFRQW RFWHW

Coding of Cell Identification for


Cell identification discriminator = 0010
 
&,YDOXH RFWHW
&,YDOXHFRQW RFWHW

The octets 4-5 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’

3.2.2.24 Layer 3 Information

This is a variable length element used to pass radio interface messages from one network entity to another.
 
(OHPHQWLGHQWLILHU RFWHW
/HQJWK RFWHW
/D\HULQIRUPDWLRQ RFWHWQ

Octet 1 identifies the element. Octet 2 gives the length of the following layer 3 information.
Octet j (j = 3, 4, ..., n) is the unchanged octet j-2 of a radio interface layer 3 message as defined in GSM 04.08, n-2 is equal to the
length of that radio interface layer 3 message.
Appendix 5: Excerpts from GSM 08.08

3.2.2.33 Chosen Channel

This Information Element contains a description of the channel allocated to the MS.
For VGCS/VBS calls this Information Element contains a description of the channel allocated for the call in the cell.
It is coded as follows:
 
(OHPHQWLGHQWLILHU RFWHW
&KDQQHOPRGH &KDQQHO RFWHW

The channel mode field is coded as follows:

Bit 8765
0000 no channel mode indication
1001 speech (full rate or half rate)
1110 data, 14.5 kbit/s radio interface rate
1011 data, 12.0 kbit/s radio interface rate
1100 data, 6.0 kbit/s radio interface rate
1101 data, 3.6 kbit/s radio interface rate
1000 signalling only

All other values are reserved.


The channel field is coded as follows:
Bit 4321
0000 None (Note *)
0001 SDCCH
1000 1 Full rate TCH
1001 1 Half rate TCH
1010 2 Full Rate TCHs
1011 3 Full Rate TCHs
1100 4 Full Rate TCHs
1101 5 Full Rate TCHs
1110 6 Full Rate TCHs
1111 7 Full Rate TCHs
0100 8 Full Rate TCHs

NOTE *: This value may be returned in the chosen channel information for VGCS/VBS calls in the case
where the BSS has decided to de-allocate resources or allocate no resources for the call.

All other values are reserved.


Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

PRELIMINARY EXERCISES

P1
What is the difference between acknowledged state and unacknowledged state in LAPD and LAPDm
signalling? Why are there not check bits or frame marks in LAPDm signalling?

P2
Sketch a signalling diagram of the following signalling subsections: Random access and access grant (MS is
given a radio channel), ciphering and authentication, call release. These subsections are repeated over and over
again in each signalling procedure during the laboratory exercise. Include all interfaces in your signalling
diagrams.

P3
List CC, MM and RR protocol messages, at least four of each.

P4
Referring to L4: What information is saved on the SIM card when the MS is switched off?

P5
Which parts of NSS (Network Subsystem) are responsible for storing the ciphering key; when is the ciphering
key transmitted in the signalling network and where? How does authentication happen? Show the functioning of
A3, A5, and A8 algorithms (for example with a figure). In L4 you have to configure authentication and
ciphering, so it is very important to understand how they work.

P6
Answer the following questions based on the signalling example in Appendix 3.

a) What kind of a connection is established (MSÅMS, PSTNÅMS, MSÅISDN etc.)?


b) What is the first message sent by an MS over the A interface?
c) Why is the sequence number of the messages "hopping"?
d) Give an example of an SCCP message, BSSMAP message and DTAP message. Message name is enough.
e) What is the SS#7 signalling point code of the BSC? What is the signalling point code of the MSC?
f) What kind of control channel is the MS requesting from the MSC?
g) What is the cell identifier of the cell where A subscriber is located? Which message contains this
information?
h) Is ciphering used? Is authentication used?
i) What PCM time interval is used for signalling on the A interface?

-1-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

j) What is the number of the B subscriber? What is the IMSI/TMSI of the B subscriber? What is the IMSI of
the A subscriber?
k) What kind of a traffic channel is allocated on the air interface? What time slot is used on PCM line over the
A interface to transmit the traffic data?
l) In which cells is the Bsubscriber paged? In which cell is the B subscriber located?
m) What is the first message of the B subscriber to the MSC?
n) Does the B subscriber use IMSI or TMSI when replying to paging response?
o) How long does the phone call last? What is the reason of call release?
p) What is the purpose of Source/Destination Local Reference in SCCP messages?

P7
Sketch a signalling diagram of signalling between ASSIGNMENT REQUEST and ASSIGNMENT
COMPLETE messages (Include the messages from all interfaces!).

Sketch a signalling diagram of signalling between PAGING and PAGING RESPONSE messages (Include the
messages from all interfaces!).

P8
What are the layers of SS#7 in BSS and MSC?

P9
Explain (with a figure) the relation between BSSAP, BSSMAP, DTAP and d-function.

P10
Why is it useful to attach MSC and VLR together? What about HLR/AuC/EiR? Why is it useful to place TRAU
physically close to MSC?

-2-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

P11
Below is a signalling message with all layers shown separately. Decode the necessary parts of the message, and
answer the following questions. Use appendices.

a) What is OPC and DPC?


b) In which cell identifier is MS?
c) On which channel did MS sent the message?
d) What is the value for CKSN?
e) Is A5/2 algorithm in use?
f) How does the phone identifier itself to the network?

MSU
8D 8F 38 83 E9 C5 7A A1 01 AA 02 00 02 02 06 04 43 E9
05 FE 04 04 43 EB 05 FE 0F 1E 00 1C 57 05 08 00 21 F3
54 00 0B 00 01 17 0D 05 24 11 03 20 18 01 05 F4 01 5E
1B CD 21 01 00

CR-CONNECTION REQUEST
E9 C5 7A A1 01 AA 02 00 02 02 06 04 43 E9 05 FE 04 04
43 EB 05 FE 0F 1E 00 1C 57 05 08 00 21 F3 54 00 0B 00
01 17 0D 05 24 11 03 20 18 01 05 F4 01 5E 1B CD 21 01
00

COMPLETE L3 INFORMATION (BSSMAP)


57 05 08 00 21 F3 54 00 0B 00 01 17 0D 05 24 11 03 20
18 01 05 F4 01 5E 1B CD 21 01

CM SERVICE REQUEST (MM)


05 24 11 03 20 18 01 05 F4 01 5E 1B CD

-3-
General Instructions for Lab 2

• The laboratory has three Siemens S6-mobile phones and one Nokia 6150 dual band
phone. There are three SIM-cards (SeppoJ, SvenG and HeikkiPS). MISDN-numbers
are according to American style ADG = BEH =123 (A=1, D=2, G=3). The numbers
of the phones are: SeppoJ = 737765, SvenG = 78364 and HeikkiPS = 43455477.
• The phones are not at times able to form connection to the base stations; you might
have to wait a while. The other option is to turn off the phone, then turn it on again
and hope that the phone finds the net faster. Also, when the simulator is switched
off, the connection to the phones is broken and they will have to be switched on
again. The connection to the net will also be broken if authentication fails
(AUTHENTICATION REJECT).
• It would be appropriate to bring your own SIM-card to the lab if possible. If neither
of the lab partners have a small SIM-card, the assistant may kindly lend one. Your
own SIM-card is needed in lab exercise 4.

General Instructions for using NetHawk

NetHawk program consists of three parts: configuration tool, simulator and


monitoring program. Visit the web-site www.xnet.fi

MSC/A Simulator
1. The simulator has two functioning modes: active mode and command mode. In
active mode, the simulation is in progress normally and relatively automatically. If
you wish to give some of your own commands to MSC (for example to send
AUTHENTICATION REQUEST to one of the phones) you need to switch to
command mode and give the appropriate commands. In this lab work the
commands are given with macros that are prepared before hand (by clicking the
mouse). So, you’ll not have to worry about the command interpreter.
2. To make the signalling happen between MSC and BSS, the MTP-link between
MSC (NetHawk) and BSS (Siemens) has to be switched on immediately after the
simulator. This is done by using the macro called ”Start MTP-link”. The alarm-
leads of the base station should turn off.
3. NetHawk can not connect the calls if it is not told how to do it. If a phone call is
performed from one phone to another, should the macro called ”MS<->MS” be
performed first. This macro transmits the information to the simulator. Vice versa,
if a phone call PSTN/ISDN is performed, it is essential that the macro called
”Fixed” is performed first. In addition; if a call is wanted to be made from a solid
phone to mobile phone the NetHawk must be informed which one of the phones is
reached by choosing the macro called Pag 1, Pag 2 or Pag 3. The ”fixed phone”
attached to the simulator does not actually include anything but the speaker, not
the dial disk or the alarming sound.
4. Always when the configuration of the simulator is wanted to be changed, the
simulator must be switched off first and when restarting, read another new
configuration. When switching off the simulator the connection to the base station
is broken which breaks the connection between the base station and the phones in
the area. Even the phone should be switched off and restarted so that they would
find the net again in decent time.

MSC/A Configuration tool


1. Configuration tool is able to create files before hand. These files include the
information MSC needs, such as MISDN-numbers of the phones and other
information on the subscriber and the phones, ciphering parameters, the addresses
of MSC and BSS signalling points and used SS#7 protocols (ANSI or ITU-T).
Because NetHawk MSC/A-simulator does not have VLR, HLR/AuC or EiR, the
configuration files include also information on the network elements.
2. All fields are not critical to the functioning of the simulator. Some of the values
are updated when MSC and MS talk to each other and some are optional. This is
useful to notice when creating the configuration.

MSC/A Monitoring
1. The monitoring program has two modes: active mode and history mode. In active
mode, the program decodes in a defined way, almost in real time the traffic on
interface A. In history mode, the traffic on A interface in saved in memory buffer.
Nothing is seen on the screen which eases the examining of signalling. Switching
between modes is done by pressing space-key or clicking the button on right of
the mouse inside the monitoring window.
2. The program is able to choose the messages on the wanted protocol layer. For
example, the messages on MTP2-link layer are not very interesting to monitor
because it transmits also a great amount of garbage; If there are not message data
(MSU), there are filling message units (FISU). From the Monitoring-> Layer
Details (F6) menu can be chosen the wanted layers and how they are wanted to be
decoded. In the laboratory work these settings are mostly ”prepared” before hand
and they are saved in configuration files to avoid the time consuming difficulties
of the program settings.
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

LABORATORY EXERCISES

The report is to be returned one week after the laboratory shift, at the latest. You can bring a floppy disk with
you to the lab, and save signalling data on it. You should also bring your own SIM card, if possible.

NetHawk configuration files needed in this laboratory exercise can be found in the directory
c:\NetHawk3\configs\lab\

When you create your own configurations do not replace the old ones when saving, but in file
c:\NetHawk3\configs\temp\ !!!!

Mere short answers will not be enough in most of the questions. Explanations on how the conclusions were
reached are required. However, blaa blaa text is not needed.

L1

Load configuration teht1.cfg to the simulator.

This is a troubleshooting exercise. In the configuration there are two problems that prevent you from making a
call SeppoJ Å HeikkiPS. Your mission, Jim, - should you choose to accept it - is to find those errors from the
signalling. You can monitor A interface signalling with the monitoring program.

a) What kind of problems arise when trying to connect to the network and/or make the phone call? What is the
reason for these problems?

Repair/go around the problems (examine the simulator’s scripts) and make the phone call.

b) How did you go around the problems?

-1-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

L2
Load configuration teht2.cfg to the simulator.

Make a call MS<->MS. Examine signalling with the monitoring program.

Examine SS#7-signalling on SCCP level. Print the signalling of the SCCP layer.

a) Explain how SS#7-connection is formed. Explain how parallel connection SCCP connections are
distinguished from each other.

b) Explain the difference between DATA FORM 1 and UNIT DATA messages. What GSM L3 message is
encapsulated in a UNIT DATA message and why do you think this is so?

Examine GSM L3-level signalling. Print the signalling of the GSM L3 layer.

c) What is the first message sent from MS to MSC? What information elements does it include?

d) What is the first message sent from MSC to MS?

e) List the phases of L3 signalling that take place before TMSI ALLOCATION COMPLETE message.

-2-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

f) In this uplink direction what network element performs deciphering? What is the Kc used? How can you
know it if it is not supposed to be sent over the air interface?

g) At which point in the signalling procedure does the MS switch to FACCH channel? What type of radio
channel is used?

h) What information elements does the ASSIGNMENT REQUEST message include? What is the purpose of
the message?

i) What information is included in the SETUP message sent by the A subscriber?

j) Which message includes information on the MSISDN number of the B subscriber? How (with TMSI, IMSI)
is the B subscriber paged?

-3-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

L3
Call setup time is one possible QoS criterion (Quality of Service). Examine the signalling of MS ->MS call of
the previous exercise and especially the durations of different phases (between messages). Which phase takes
longest? Why? What happens during it? Draw a signalling diagram of the whole connection event, i.e. include
messages from ALL interfaces. Circle the messages displayed by NetHawk in the diagram. Write your answer
in a separate piece of paper.

L4
MSC configuration exercise. By using the MSC configuration tool, set the parameters of MSC and BSS so that
you SCCP connection between MSC and BSS is enabled. Use the file teht4.cfg as template. Your job is to
configure the parameters of MSC so that MTP link to BSS works. If the parameters are not correct the
connection cannot be established. You can use signalling data from previous exercises to make your
configuration work.

Do not save anything over the configuration you have loaded but save the fixed configuration in
c:\NetHawk3\configs\lab2\teht4\ryhmanro.cfg !!!

The parameters of the simulator’s phone (MSC/Party Numbers), such as number (1234) is already defined. Generally, all the parameters of
MSC do not necessarily have critical meaning. Experiment! You may have to iterate your configuration many times.

The addresses (Point Codes) of signalling points are given in hex form.

The synchronisation set up of the simulator must be SLAVE. PCM multiplex=0.

After you have reached the connection to BSS switch the SIM-card of your own phone to one of the other
phones. Use the configuration tool again and create yourself as one of the subscribers into the network.

Do not touch the parameters of short messages (SMS, TPDU, Priority).

Because at the beginning you will not know all the parameters of your GSM link, you will have to “guess” some
of them. Switch on the GSM1800 phone and wait until it finds one of the base stations. By using the monitoring
program, examine the signalling on interface A and answer the following questions.

a) Does the GSM1800 network you configured accept the phone equipped with your SIM card? What happens
(signalling)? Fix the possible error situation again by using the configuration tool. Configure the network so
that authentication and ciphering work. Explain how you achieved this. Notice that you will have to set the
encryption algorithm as 'no encryption'. Why is that?

Explain how you


got ciphering and
authentication to
work!

b) What is IMSI of your own SIM?

-4-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

Print the signalling that includes the following information.

c) We want to find out the cell identity of the serving cell in the network you use (your own SIM-card;
Radiolinja, Sonera, Telia etc.) in MCC MNC LAC form. Find out this information by using the BSS,
monitoring program, and your SIM card. How did you do that?

Compare with P4

d) By examining signalling, can you find out the ciphering key Kc of your own phone? How did you manage
to do that?

e) What was the ciphering key number (CKSN) given to you by your own network? It was given to you by the
operator during the connection in c)-question. Is there a security risk? Explain why.

f) What was TMSI that the operator gave during the connection of question c).

L5

What is the IMEI code of HeikkiPS? What is the IMEISV of HeikkiPS? Use the simulator (scripts maybe) and
signalling to find this out. Which message gives you this information? Use configuration teht5.cfg in the
simulator.

You are allowed to change the simulator scripts in this exercise. Destroying is forbidden. After this exercise the
scripts will have to be changed back to look exactly the same they did before changing.

-5-
Helsinki University of Technology S-72.260
Communications Laboratory Lab 2

L6

Use the same configuration as in the previous exercise. Attach the phone to the power splitter in the middle.
Turn the adjustable attenuation to its minimum. Switch the phone on. Add attenuation and examine signalling.

a) Does Location Update (LU) happen? What are the LACs of the cells?

b) Why is LU made when LAC changes but not necessarily when the cell changes?

c) Use the monitor mode of the MS and find out the received power level in which LU happens? On which
level does the MS make LU back to its old cell (hysteresis)? Why is hysteresis needed in cell reselection
when the cell LACs are different?

Call the simulator phone. Add attenuation slowly. Try to induce a handover to the other cell. Examine the
signalling with the monitoring program.

d) In which cell does the phone answer?

e) Which message indicates that handover has happened?

f) What causes handover?

g) Which network element is responsible for handover (BTS, BSC, MSC, MS)?

-6-

You might also like