SCCP Siemens

SCCP

Contents
1 Addressing and Routing 3
2 Formatting Rules 33
3 Exercise 51
4 Solution 55

TM3101EU01TM_0001
1
 Siemens SCCP

2 TM3101EU01TM_0001
SCCP Siemens

1 Addressing and Routing

TM3101EU01TM_0001
3
 Siemens SCCP

The Signaling Connection Control Part (SCCP) is a User Part of the Common
Channel Signaling System 7 (CCS7). It enables the transmission of messages, which
are not related to a user channel.
The user channel related User Parts (e.g. TUP or ISDN-UP) employ an extended
Routing Label which contains, besides the Destination Point Code (DPC), the
Origination Point Code (OPC) and the Signaling Link Selection (SLS), a number of a
speech circuit (Circuit Identity Code, CIC). The two point codes indicate the two
exchanges, which are interconnected by the speech circuit. Of course, the CIC is not
clear throughout the network, but between the same two exchanges and within the
same User Part, the same CIC value must not be used twice.
The Routing Label extended in this manner enables - together with the Service
Information Octet (SIO) - both the message routing through the network (identification
of the receiving exchange by means of the DPC and the network indicator [NI] in the
SIO) and the message routing within the receiving exchange (to the unit where the
indicated speech circuit is connected).
In contrast, the Routing Label of the SCCP consists only of DPC, OPC and SLS; no
CIC appears. Therefore, the SCCP is used whenever messages must be exchanged
which are not related to a fixed user channel. This can be the case when the sending
and the receiving exchange are not connected directly by user channels (e.g. VLR
and HLR) or when, for certain operations, no user channel must be seized (e.g.
location registration).
The message routing through the network and in the exchange, which depends for
user channel related User Parts on the extended Routing Label and the SIO, must in
part be taken over by the SCCP itself if no user channel relation exists; this, however,
does not affect the significance of the Routing Label and the SIO. Thus, the SCCP
enhances the routing functions of the Message Transfer Part (MTP). Accordingly,
MTP and SCCP together are denoted as Network Service Part (NSP).
The NSP (i.e. MTP and SCCP together) can transport signaling data for various
application purposes. The data transported by the NSP are called Application Parts
(in contrast to the User Parts, which depend directly on the MTP). As the MTP alone
can transport various User Parts, different Application Parts can be transmitted with
the NSP.

4 TM3101EU01TM_0001
SCCP Siemens

User Channel related User Parts

TUP: I SDN -UP :

DP C D PC

OP C O PC

SLS SLS

C I C C IC

User Part Data 0 0 0 0

User Part Data

S C CP : SC C P:
14 bit SPC: 2 4 b it SPC :

DP C DP C

OP C
SL S OP C

SCCP Data
SL S

SCCP Data

Fig. 1 Routing Label

TM3101EU01TM_0001
5
 Siemens SCCP

With a GSM-PLMN, the SCCP is employed in the following areas:

l At the so-called A-interface between Base Station and SSS (precisely: between
BSC and MSC), the SCCP is used with two different Application Parts:
the Base Station System Application Part (BSSAP) for call control and related
tasks
the Base Station System Operation and Maintenance Application Part
(BSSOMAP) for operation and maintenance purposes.

At the A-Interface, there are proceedings with and without user channel relation. For
example, with a call set up, several messages are exchanged before a user channel
is assigned to the call. In order to avoid unnecessary case distinctions, the SCCP is
used throughout at the A-interface (i.e. no CIC in the Routing Label). If a CIC must be
transmitted in a message, it is written into the BSSAP or BSSOMAP data,
respectively.
l The interfaces between the SSS subunits (MSC, VLR, HLR, AC and EIR) use the
SCCP with the Transaction Capabilities Application Part (TCAP). The TCAP
controls the logical signaling relations (transactions) and the procedures
performed by them. The mobile specific application data are found in the Mobile
Application Part (MAP) which depends, in due turn, on the TCAP. The
proceedings at these interfaces are never related to a user channel.

The following areas of a GSM-PLMN can dispose of the SCCP:

l The air interface between mobile and base station and the so-called Abis- interface
between BTS and BSC do not employ CCS7, especially not SCCP.
l With the proper call set up and clear down between MSCs, either a user channel
related User Part (e.g. TUP and ISDN-UP) or a method of Channel Associated
Signaling (e.g. MFC R2) is employed. The proceedings correspond to those in the
fixed network.

6 TM3101EU01TM_0001
SCCP Siemens

BSSOMAP EIR
SCCP
BSS MTP

F
A
MAP
BSSAP MSC TCAP
SCCP SCCP
MTP MTP
VLR

C
E
D
G HLR
MSC
AC
MAP
VLR TCAP
SCCP
MTP

Fig. 2 SCCP - Range of applications for a GSM-PLMN

TM3101EU01TM_0001
7
 Siemens SCCP

With the user channel related user parts, each signaling message is related - by
virtue of the CIC - to one and only one user connection. With the SCCP, no such
access point exists. Nevertheless, even here, some messages (e.g. interrogation and
handover) are related to one and only one user connection. Here, the relation must
be created in another manner: the access point is a logical (= virtual) signaling
connection, also called a transaction.
It was in the chapter about the air interface that we have come across the notion of a
signaling connection for the first time. Such a connection is established by an
agreement of both partners about identification numbers, which are henceforth
contained in each signaling message. At the air interface, the transaction identifier
(TI) has the function of such an identification number; it identifies the CM-connection.
Logical signaling connections (= transactions) are always packet switched since they
do not seize any channels. However, they occupy at both ends physical (memory
space) as well as logical (identification numbers) resources.
Typically, a transaction is set up in parallel to a user connection and remains stable
until the user connection is either released or becomes for another reason (e.g.
handover) irrelevant for the affected interface. Transactions can also exist for
proceedings other than user connections (e.g. location update). Because the
signaling messages contain the identification numbers, it is always clear to which
transaction - and thus, to which user connection, to which location update etc. - they
are related.

8 TM3101EU01TM_0001
SCCP Siemens

User connection:
- between terminals
- circuit switched
- channel seizure
- channel switching

User connection

Sender Sender
Memory Receiver Receiver Memory
Identifications Identifications

Signaling connection
(transaction)

Transaction:
• between memory areas
• packet switched
• no channel seizure
• no channel switching
• identification numbers

Fig. 3 User connections and Signaling connections (transactions)

TM3101EU01TM_0001
9
 Siemens SCCP

In the case of the SCCP, transactions exist either between SSS subunits (MSC, VLR,
HLR, AC, EIR) or between SSS and BSS (i.e. between MSC and BSC). There are
several possibilities for the transaction control.
l With some applications, the SCCP itself controls the transactions. The
identification numbers are part of the SCCP data, and the SCCP messages treat
the transaction set up and clear down as well as the information transport over the
transaction. This is called connection oriented SCCP services. With GSM,
connection oriented SCCP services occur at the A-interface (i.e. between BSS and
SSS).
l With other applications, the transactions are controlled by the Transaction
Capabilities Application Part (TCAP). Here, the SCCP has only bearer functions,
i.e. it is responsible for the message routing from one transaction end point to the
other but does not "know" the transaction the message belongs to. The SCCP
messages deal with the information transport only. This is called connectionless
SCCP services. With GSM, these connectionless services occur at the interfaces
between the SSS subunits.
l Finally, there are some applications which are not related to any transaction at all
(e.g. the reset after a failure, which affects all connections). Again, the SCCP
messages treat the message transport only. Therefore, it is another case of
connectionless SCCP services. This kind of connectionless services occurs at
the A-interface.

Thus, with connection oriented SCCP services, there are messages which treat the
transaction set up and clear down and the information exchange over a specific
transaction, whilst with connectionless services, the messages deal with the data
transport only. From the point of view of the D900 realization, it can be said in a
simplified manner that the connection oriented services are realized in the LTG but
the connectionless services in the CP; of course, there are exceptions.

10 TM3101EU01TM_0001
SCCP Siemens

TCAP transaction:
connectionless
SCCP service

MAP
BSS TCAP
SCCP
Me- MTP
mory

MSC
VLR
HLR
BSSAP
AC
SCCP MSC
MTP EIR
VLR
Me- Me- HLR
SCCP transaction: mory mory AC
connection oriented EIR
SCCP service
Me-
mory

= Identification Number

Fig. 4 Transaction Types of the SCCP and TCAP

TM3101EU01TM_0001
11
 Siemens SCCP

The distinction between connectionless and connection oriented services

differentiates the SCCP application cases as to their functional capability. A finer
graduation is given by the so-called protocol classes. CCITT defines four protocol
classes (0 to 3). The higher the protocol class, the higher the functional capacities,
i.e. protocol class n+1 can do everything what protocol class n can do, and even a
little bit more. The protocol classes 0 and 1 are the connectionless services, the
protocol classes 2 and 3 are the connection oriented services.
With protocol class 0, the SCCP only carries the information from one point to the
other. The individual messages have nothing to do with each other and are routed
independently to their destinations. This means that the Signaling Link Selection
(SLS) is selected in such a way that the load is distributed as evenly as possible over
the available signaling links. Of course, it can happen that messages overtake each
other: the later dispatched message can arrive earlier if it was fortunate enough to be
routed on a more suitable route.
With protocol class 1, no signaling connections exist either, but the user can mark
several messages as belonging together. Those messages get the same SLS so that
the MTP ensures (with a high degree of probability) that they arrive in the same order
in which they were dispatched. This protocol class is used at the interfaces between
SSS subunits only whilst protocol class 0 is employed both at the A-interface and
between the SSS subunits.
With protocol class 2, the SCCP sets up and clears down signaling connections and
transports messages in both directions over these signaling connections. Messages
of the same signaling connection always get the same SLS so that the sequence
control from protocol class 1 is ensured, too. This protocol class is used at the A-
interface.
With protocol class 3, additionally the messages are numbered and acknowledged
within each signaling connection, so that message losses can be detected, too. This
protocol class is not used for a GSM-PLMN; therefore, we shall not discuss it any
more.
With each signaling message, it must be clarified which protocol class it belongs to.
Either the protocol class is itself transmitted as a message parameter, or it can be
derived from the context.

12 TM3101EU01TM_0001
SCCP Siemens

SCCP

connection- connection-
less services oriented services

protocol protocol protocol protocol

class 0 class 1 class 2 class 3
single message signaling signaling
message groups connections connections
with with with with
individual common uniform uniform
routing routing routing routing and
message
numbering

Fig. 5 Protocol classes of the SCCP

TM3101EU01TM_0001
13
 Siemens SCCP

The connectionless services of protocol class 0 and 1 use four SCCP messages:
"Unitdata" (UDT), "Unitdata Service" (UDTS), „Extended Unitdata“ (XUDT) and
„Extended Unitdata Service“ (XUDTS). UDT serves for the connectionless transport
of a message whereas, with UTDS, a UDT, which could not be forwarded to the
receiver is returned to the sender. XUDT is used, when the message is longer than
255 byte and XUDTS has the same function as UDTS.
(X)UDT and the (X)UDTS contain the addresses of the receiver and of the sender.
With the (X)UDT, these addresses are delivered by the user whilst, when returning a
(X)UDT with (X)UDTS, sender and receiver address are simply interchanged.
Furthermore, (X)UDT and (X)UDTS contain a user message. In the case of the
(X)UDT, it is the message to be transported whereas, in the case of the (X)UDTS, it
is the message, which could not be delivered.
Additionally, it is indicated in the (X)UDT whether it belongs to protocol class 0 or 1. If
the message must be returned with (X)UDTS, the (X)UDTS belongs to the same
protocol class as the preceding (X)UDT. Therefore, an explicit indication of the
protocol class is no longer necessary.
The segmentation parameter of XUDT and XUDTS tells first, if the message is
divided into several segments at all. If yes, there is information about how many
segment are still following, which one is the first segment and a reference number,
which is common for all segments of one message. The maximum size of one
message is here 4 Kbyte.
The value of the Hop Counter is decremented on each global title translation. The
maximum value is 15. The message must arrive at its destination, before the counter
reaches the value 0.
Finally, the (X)UDTS contains the cause why the message had to be returned, (e.g.
"No translation for this specific address", "Network failure", "Network congestion"
etc.).

14 TM3101EU01TM_0001
SCCP Siemens

Positive case:

UDT
A (Sender,Receiver,
B
Protocol class,
User message)

XUDT
A (Sender,Receiver,
B
Protocol class, Hop Counter,
Segmentation,User message)

Negative case:
UDT
A (Sender,Receiver,
Protocol class,
User message)

UDTS
(Sender,Receiver,
Cause,
User message)

XUDT
A (Sender,Receiver,
Protocol class, Hop Counter,
Segmentation,User message)

XUDTS
(Sender,Receiver,
Cause, Hop Counter,
Segmentation, User message)

Fig. 6 Connectionless SCCP services

TM3101EU01TM_0001
15
 Siemens SCCP

With the connection oriented services of protocol class 2, there are the messages
"Connect Request" (CR), "Connect Confirm" (CC), "Connect Refused" (CREF), "Data
Form 1" (DT1), "Released" (RLSD) and "Release Complete" (RLC). Further
Messages (e.g. "Data Form 2" [DT2]) are defined for protocol class 3 and can be
neglected here.
The transactions always have two identification numbers: one for each side of the
signaling connection. During the connection set up, each of the connection partners
selects his identification number and tells it to his partner. Now, both sides memorize
the assignment between the own identification number and the partner side. It is for
this reason that the identification numbers of the SCCP connections are called local
references (LR), whilst for the identification numbers of the TCAP connections, the
term transaction identity is in use.
Working with two identification numbers has the advantage that no efforts are
necessary to avoid glare seizures since each side selects its own number
independent of the partner side. Furthermore, no formatting rules for the local
references must be defined: each side selects its identifier in such a way that it can
address its memory space optimally.
In order to set up an SCCP transaction, the initiating side selects a local reference
and tells it to its partner by means of the message "Connect Request" (CR). If, for
some reason or other, the connection cannot be set up, the message "Connect
Refused" (CREF) is returned. It contains the local reference of the initiating side and
the reason for the refusal (e.g. "Destination address unknown", "End user
congestion", "End user failure" etc.).
In the positive case, however, the partner side will, on reception of the CR, select its
own local reference and return the message "Connect Confirm" (CC) which contains
both local references. Thus, each side knows its own and its partners local reference,
and the SCCP transaction is established.
Both the CR and the CC contain the protocol class as a further parameter (always 2
with a GSM-PLMN). From now on, this protocol class holds for all messages of this
transaction; thus, no explicit indication of the protocol class is required in the
subsequent messages.

16 TM3101EU01TM_0001
SCCP Siemens

Connection oriented SCCP services

Positive Case:

A B
Sel CR Sel
LRA LRB
(Protocol class, LRA,
Receiver,
poss. User message)
Sel Sel
LRA LRB
CC
(LRB, Protocol class, LRA,
poss. User message)

Negative Case:

A B
Sel CR
LRA (Protocol class, LRA,
Receiver,
poss. User message)
Sel
LRA
CREF

(LRA, Cause)

Fig. 7 SCCP connection set up

TM3101EU01TM_0001
17
 Siemens SCCP

As long as the SCCP transaction exists, both sides can send user messages over the
transaction to the partner. This is done by means of the SCCP message "Data Form
1" (DT1). The message contains the user message and the local reference of the
receiving side so that the receiver can address immediately the appropriate memory
area. Furthermore, there is the segmenting, reassembling parameter included, which
tells, if the message is divided into several segments. This takes places if the
message is longer than 255 bytes.
When one of the two partners wants to clear down the SCCP transaction, he sends
the SCCP message "Released" (RLSD) to the partner side. This message contains
both local references and the cause for the clear down (e.g. "End user originated",
"Network failure" etc.). The partner side answers with "Release Complete" (RLC);
again, this message contains both local references. Thus, the SCCP connection is
cleared down, and both local references are released.
By the way: user messages can be delivered already during the transaction set up (in
the CR and/or in the CC) and still during the transaction clear down (in the RLSD, but
not in the RLC).

18 TM3101EU01TM_0001
SCCP Siemens

Connection oriented SCCP services

Message Exchange:

A B
DT1
(LRB, Segmenting/Reassembling,
User message)

LRA LRB
DT1
LRB (LRA, Segmenting/Reassembling, LRA
User message)

Transaction Cleardown:

A B
RLSD
(LRA,LRB, Cause,
poss. User message)

LRA LRB
RLC
LRB (LRA,LRB) LRA

Fig. 8 Message exchange and Transaction cleardown

TM3101EU01TM_0001
19
 Siemens SCCP

The most important task of the SCCP is the routing of user messages to the correct
receiver. As to how this is accomplished, connectionless and connection oriented
services are distinguished.
With connection oriented services, the signaling point of the receiver is determined
by means of the destination point code (DPC) in the Routing Label, and the receiver
distributes the message internally according to the local reference (see fig. 7 and 8).
No further addresses occur in the DT1, the RLSD and the RLC; just the CR contains
a receiver address. Therefore, connection oriented services can be used only if the
MTP is able to determine the message destination from the DPC.
[Let it be mentioned for the sake of completeness that the receiver address is an
optional parameter in the CC and in the CREF. But in the CR - and nowhere else -, it
is mandatory, and it is not permitted in DT1, RLSD and RLC.]
With connectionless services, however, the messages always contain a sender
and a receiver address. The addressing capacities by far exceed those of the MTP.
Especially, a destination point can be reached even if its DCP is not known in the
sending exchange. In this case, the DPC in the routing label indicates the next step
on the way, but the final destination is determined by the receiver address in the
SCCP.
A D900 application example is international roaming. If a German mobile subscriber
inserts his SIM card in Portugal, his HLR in Germany must be informed. The HLR
has a signaling point code (SPC) in the national network of Germany. But it is
impossible to use this SPC as a DPC directly from Portugal since the same SPC
value could be assigned to a Portuguese exchange. National SPCs need not be
unique beyond the borders of the country! Therefore, the HLR must be reached in
steps (via gateway exchanges).
In those situations, connectionless services must be employed always. The receiver
address (in the example: the IMSI) will be evaluated in each intermediate exchange
in order to proceed step by step towards the destination.

20 TM3101EU01TM_0001
SCCP Siemens

Portugal Germany

NAT0
DPC 799
OPC 512

VLR HLR

NAT0:
SPC=512
NAT0 NAT0 NAT0:
DPC 1683 DPC 799 SPC=799
OPC 512 OPC 360

INAT0: INAT0:
SPC=3024 INAT0 SPC=4578
DPC 4578
Gate- OPC 3024 Gate-
way way

NAT0: NAT0:
SPC=1683 SPC=360

Fig. 9 Routing example: International Roaming

TM3101EU01TM_0001
21
 Siemens SCCP

Such a receiver address is called a Global Title (GT); the address evaluation (for the
determination of the next step) is named Global Title Translation. The Global Title
Translation is comparable to a digit translation in a connection set up (in the mobile
or in the fixed network): there, as a rule, the originating exchange cannot identify from
the dialed digits the destination exchange immediately, but it determines the next
transit exchange where further digits are evaluated. In a similar way, with a Global
Title Translation, the sender of a signaling message cannot address the receiver
directly (as DPC) but he determines the next transit point on the way. In the transit
point, the Global Title is evaluated again in order to find the next point, and so on,
until the receiver is reached.
With a GSM-PLMN, the Global Title Translation is used exclusively for the
connectionless SCCP services between SSS subunits. The following digit
combinations appear as Global Titles:
1. the IMSI, if, with a Location Update, the HLR must be addressed from the VLR
2. the MSISDN, if the MSC wants to reach the HLR for the interrogation
3. dialing digits assigned to the SSS subunits. The sender
a) either has learned these digits from the receiver beforehand (e.g. the VLR
address which is communicated during Location Update to the HLR and
which serves from now on in all messages HLR --> VLR as a GT)
b) or could take the digits form his data base (e.g. during Location Update the
address of the former VLR which can be derived from the LAI, or during
MSC-MSC-Handover the new MSC address which follows from the identity of
the new cell).
In each case, the Global Title is contained in the SCCP messages "Unitdata" (UDT)
and "Unitdata Service" (UDTS) as receiver address (Called Party Address). The
Called Party Address is mandatory in the UDT and optional in the UDTS.
Furthermore, the UDT can contain a global title as sender address (Calling Party
Address) - either to communicate it to the receiver for later return messages (see
case 3a in the list above) or in order to enable a return with UDTS.

22 TM3101EU01TM_0001
SCCP Siemens

SPC x SPC y SPC z

GT GT
GT
Transl.: Transl.:
Transl.
DPC y DPC z

DPC
DPC yy DPC
DPC zz
OPC
OPC xx OPC
OPC yy
GT
GT GT
GT

Fig. 10 Principle of the Global Title Translation

TM3101EU01TM_0001
23
 Siemens SCCP

Since the same digit combination could appear (theoretically) as IMSI of one mobile
subscriber and as MSISDN of another one, it must be known for the Global Title
Translation which of the cases listed above applies for a given Global Title.
Therefore, the Called and Calling Party Address can contain besides the Global Title
digits the Translation Type (TT). According to GSM, the Translation Type contained
in an SCCP message has always the value 0 (= "unknown"). Only the VLR, when
performing the initial GT translation of the IMSI for a location update, uses the
translation type "IMSI" (but transmits the translation type "unknown" to the next
network node all right).
If the addresses do not contain a translation type, 0 = "unknown" is assumed as
default value.
Besides the translation type, there is the Numbering Plan (NP) which indicates the
numbering standard of the Global Title. The Numbering Plan distinguishes several
standards (e.g. CCITT-ITU) for numbering (e.g. E.163/164 for dialing digits, E.212 for
IMSI). The Called and Calling Party Address can contain in each case a numbering
plan independent of the translation type.
Finally, there is the Nature of Address (NA) for the distinction between international,
national and subscriber numbers. International numbers consist of country code,
network code and subscriber number; they are (within the given translation type and
numbering plan) worldwide unique. With national numbers, the country code is
omitted; they hold within the borders of the country. Finally, with subscriber numbers,
the network code is omitted, too. They are significant just within the network.
The three supplements Translation Type (TT), Numbering Plan (NP) and Nature of
Address (NA) are not transmitted with each Global Title. Rather, four types of Global
Title are defined. Global Titles of type 1 contain only the nature of address, with type
2 only the translation type is given, and with type 3 the translation type and the
numbering plan are sent. With type 4, all three supplements are included.

24 TM3101EU01TM_0001
SCCP Siemens

GT supplements GT GT GT GT
Type 1 Type 2 Type 3 Type 4

Translation Type [TT]

(Distinction between kinds of GT X X X
translation)

Numbering Plan [NP]

(Distinction between numbering plan X X
standards)

Nature of Address [NA]

(Distinction between international, X X
national and subscriber numbers)

Fig. 11 Global Title supplements

TM3101EU01TM_0001
25
 Siemens SCCP

Especially the Nature of Address can be changed during the message routing. For
example, it is conceivable that the Calling Party Address is given at first as a
subscriber number. When, during the message routing, the original network must be
left, the network code is added, and the nature of address is changed to "national". If
it turns out later that even the country must be left, the nature of address is changed
to "international", and the country code is added.
On the other hand, the Called Party Address can be changed from "international" to
"national" when the destination country is reached; with this, the country code has to
be canceled. When the destination network is entered, the network code can be
eliminated, and the nature of address changes to "subscriber number". These
modifications of the original global title are called Digit Conversion. The examples
have illustrated applications of the digit conversion both for the Calling and for the
Called Party Address.
The SCCP address fields can contain further information, which has nothing to do
with Global Titles. Here, especially the subsystem number must be mentioned
which enables a message distribution within the destination point. The most
important subsystems for a GSM-PLMN are:
l at the A-interface: BSSAP and BSSOMAP (Distinction between the two SCCP
Application Parts)
l at the interfaces between the SSS subunits: MSC, VLR, HLR, EIR and additionally
the Test User Part (TSTUP). The distinction is necessary since several SSS
subunits can be realized in the same exchange; if this is the case, they have the
same SPC.

In the above example for international roaming, the Calling Party Address contains
the subsystem number "VLR" but the Called Party Address has "HLR".
Let it be mentioned that the SCCP subsystems for the own exchange and for other
exchanges in the own area must be created by MML commands and configured to
ACT since no access is possible otherwise.
Finally, Calling and Called Party Address may contain a Signaling Point Code
(SPC). No application of this possibility is known in a GSM-PLMN.

26 TM3101EU01TM_0001
SCCP Siemens

Portugal Germany

VLR

VLR-Nr::
12345 Rec.:
E.212 HLR
internat.
2620177... Rec.:
E.214 HLR-Nr::
Subs. 77
Sender: 77.........
E.163/164
nat. Sender:
12345 E.163/164
Rec.: internat.
E.214 35112345
internat.
Gate- 17177... Gate-
way Sender: way
E.163/164
internat.
35112345

Fig. 12 Example for the Digit Conversion

TM3101EU01TM_0001
27
 Siemens SCCP

The layout of the SCCP address fields is displayed in Fig. 13. The first byte is the
address indicator and tells which address components are present (i.e. how the
subsequent bytes must be interpreted). Here, the routing indicator is found which, in
the Called Party Address, tells whether the routing must be based on the Global Title
(routing indicator = 0) or on the subsystem number (routing indicator = 1) first. In the
Calling Party Address, the routing indicator says what the routing must be based on if
sender and receiver reverse their roles (e.g. when a UDT is returned with UDTS).
Furthermore, the address indicator contains four bits for the Global Title. If all four
bits are 0, no Global Title is present; otherwise, the four bits indicate the type of the
Global Title (1 to 4) in binary representation (0001 to 0100).
Finally, the address indicator contains one bit for the subsystem number and one for
the signaling point code (SPC); the bit says whether these data are present (1) or not
(0).
If an SPC is present, it follows immediately after the address indicator in the next two
bytes; otherwise, these two bytes are omitted. Next, one byte subsystem number
ensues (if present).
If a Global Title is present, it is the last section of the address field. It begins with one
byte translation type (if present, i.e. with type 2, 3 or 4).
There now follows the numbering plan with a length of 1/2 byte. The remaining half
byte is filled by the encoding scheme for the GT digits. Here, only the case of Binary
Coded Decimals (BCD) is defined, and a distinction is made between an even and an
odd number of digits. With a Global Title of type 1 or 2, the byte consisting of nature
of address and encoding scheme is omitted.
Next, the nature of address with a length of 7 bit follows. With a Global Title of type 1,
the most significant bit of this byte is used as Odd-Even-Indicator, i.e. it says whether
the Global Title consists of an even (0) or an odd (1) number of digits. With a Global
Title of type 4, this distinction is contained in the encoding scheme; therefore, the
most significant bit of the numbering plan byte is always 0. With a Global Title of type
2 or 3, no numbering plan exists; here, the whole byte is not applicable.

28 TM3101EU01TM_0001
SCCP Siemens

Rtg. Global Title Subs. SPC

0 Address indicator
Ind. present/Type pres. pres.

SPC not applicable if no

SPC is present
0 0
not applicable if no
Subsystem Number subsystem is present
not applicable
Translation Type (TT) for Type 1
not applicable
Numbering Plan (NP) Encoding Scheme for Type 1 and 2

Spare Nature of Address (NA) not applicable

O/E*) for Type 2 and 3

2. GT-Digit 1. GT-Digit

4. GT-Digit 3. GT-Digit

*) With Typ 1 : If no Global Title is

Odd-Even-Indicator present, the GT-digits
With Typ 4: and all GT-supplements
Spare (0) are not applicable

Fig. 13 The Layout of the SCCP Address Field

TM3101EU01TM_0001
29
 Siemens SCCP

Next, the Global Title digits ensue as Binary Coded Decimals (BCD); two digits are
summarized to one byte. If the total amount of digits is odd, the last byte is filled with
a filler code (bit combination 0000). Thus, one cannot tell from the digit combination
whether it is an odd amount of digits or an even amount with last digit 0. With a
Global Title of type 3 or 4, this distinction is given by the encoding scheme, whilst
with a Global Title of type 1, the odd-even-indicator distinguishes the two cases. With
a Global Title of type 2, no distinction is possible. Therefore, type 2 can only be
applied if the total length is irrelevant (e.g. if the total length is constant and therefore
known anyway, or if only the first few digits must be evaluated).
The Fig. 14 to Fig. 18 shows how the address field components are used with D900.
A signaling point code is never used, a subsystem number always. At the A-interface,
no Global Title is used, but at the interfaces between the SSS subunits, a Global Title
of type 4 is used always. The routing at the A-interface depends on the subsystem
number (routing indicator = 1) whilst, between the SSS-subunits, the routing is based
on the Global Title (routing indicator = 0). Accordingly, the value of the address
indicator at the A-interface is 0 1 0000 1 0 = H'42, but at the interfaces between the
SSS subunits, the address indicator is 0 0 0100 1 0 = H'12.
At the A-interface, there are the two subsystems BSSAP and BSSOMAP. With
connection oriented SCCP services, the subsystem is defined in the Called Party
Address of the "Connect Request" (CR) and holds henceforth for all messages of this
SCCP connection. With connectionless services, the subsystem number is contained
in the Called Party Address of the "Unitdata" (UDT).
At the interfaces between the SSS subunits, the subsystems HLR, VLR, MSC and
EIR exist. Fig. 15, Fig. 17 and Fig. 18 show the possible values of translation type,
numbering plan and nature of address. It is defined by MML command (CR
GTDIGTR) which combinations of translation type, numbering plan and nature of
address are meaningful.

30 TM3101EU01TM_0001
SCCP Siemens

Subsystem Number
BSSAP 1111 1110 = H’FE
BSSOMAP 1111 1101 = H’FD
HLR 0000 0110 = H’06
VLR 0000 0111 = H’07
MSC 0000 1000 = H’08
EIR 0000 1001 = H’09

Fig. 14 Subsystem numbers

Translation Type Value

unknown (dialing digits) 0000 0000 = H’00
IMSI 0000 0001 = H’01

Fig. 15 Translation types

Numbering Plan Value

unknown 0000 = H’0
ISDN/Telephony Numbering Plan (E.163 / E.164) 0001 = H’1
Land Mobile Numbering Plan (E.212) 0110 = H’6
ISDN /Mobile Numbering Plan (E.214) 0111 = H’7

Fig. 16 Numbering Plans

Encoding Scheme Value

BCD, odd number of digits 0001 = H’1
BCD, even number of digits 0010 = H’2

Fig. 17 Encoding Schemes

Nature of Address Value

subscriber number 000 0001 = H’01
national number 000 0011 = H’03
international number 000 0100 = H’04

Fig. 18 Natures of Address

TM3101EU01TM_0001
31
 Siemens SCCP

32 TM3101EU01TM_0001
SCCP Siemens

2 Formatting Rules

TM3101EU01TM_0001
33
 Siemens SCCP

The SCCP messages comprise - after the Routing Label, Fig. 1 - various information
elements, also called parameters. Here, a distinction between mandatory and
optional parameters is necessary, and it can come to pass that the same parameter
is mandatory in one and optional in another message. The mandatory parameters
are classified as to whether their length is fixed (denotation F) or variable (denotation
V). There is no such distinction for the optional parameters; they are denoted with O
at any rate.

Examples for F-parameters are the local references of the connection oriented SCCP
services; they must be present and have a fixed length of 3 bytes. For V-parameters,
we find as a typical example the user message contained in "Unitdata" (UDT),
"Unitdata Service" (UDTS) and "Data Form 1" (DT1). The listed SCCP messages
must transport a user message (this is their purpose) but the length can vary, of
course. Another example of a V-parameter is the Called Party Address in the
"Connect Request" (CR) and in the "Unitdata" (UDT). The possible user messages
in "Connect Request" (CR), "Connect Confirm" (CC) and "Released" (RLSD) are
examples for O-parameters.
Each SCCP message is - after the Routing Label - structured as follows:
l at first, we have the mandatory parameters of fixed length (F)
l next, the mandatory parameters of variable length ensue (V)
l finally, the optional parameters are found (O).

The first F-parameter is always the message type with a length of one byte.
It depends on the message type which are the further F-, V- and O-parameters of the
message.

34 TM3101EU01TM_0001
SCCP Siemens

DPC
Routing
Label
OPC

SLS

Message type

Mandatory parameters
of fixed length (F)

Mandatory parameters
of variable length (V)

Optional parameters (O)

Fig. 19 Complete Format of the SCCP

TM3101EU01TM_0001
35
 Siemens SCCP

With the F-parameters, not only the length but also the sequence is defined (per
message type). Therefore, neither identifiers nor length indicators are required. After
the message type, the contents of the F-parameters ensue in the pre-defined
sequence with the pre-defined length.
To each V-parameter, there is a pointer of 1 byte length which indicates how many
bytes follow until the begin of the parameter in question. If, for example, the pointer
has the value 1, then the parameter begins in the subsequent byte; if the pointer-
value is 2, the parameter begins in the next byte but one, and so on. The pointers
follow immediately after the last F-parameter; again, their sequence is pre-arranged
(per message type), but the order of the V-parameters themselves could vary.
After the pointers to the V-parameters, the pointer to the optional part ensues. This
pointer is present whenever the message type allows the presence of optional
parameters. With message types where no optional parameters can exist (e.g. UDT),
the pointer to the optional part is not included either. On the other hand, there are
message types, which have O- but no V-parameters (e.g. CC). With these messages,
the V-section consists of the pointer to the optional part alone.
If a message type allows the presence of O-parameters but a particular message of
this type has none (e.g. a RLSD without user message), the pointer to the optional
part is present but its value is 0. If O-parameters are present, the pointer to the
optional part must have at least the value 1 (since the optional part cannot begin
earlier but in the next byte).
The message section consisting of the F-parameters, the pointers to the V-
parameters and the pointer to the optional part is distinguished by a fixed length and
order of its components. As soon as the message type is identified, each F-
parameter and each V-parameter can be accessed by a simple method, and even
the begin of the optional pert can be found without a lengthy search.
The V-parameters themselves begin with a length indicator of 1 byte length. After
this, as many bytes of parameter contents ensue as the length indicator says.
Finally, the O-parameters can be found in an arbitrary sequence. Each O-parameter
begins with an identifier of 1 byte length. Next, there follows a length indicator (again
1 byte) and as many bytes of contents as the length indicator says. The length
indicator is included even if the length is fixed.
If optional parameters are present, after the last parameter (i.e. where the next
identifier is to be expected) the end of the optional part is marked. The mark is the
byte 0000 0000 = H'00. Thus, no parameter with the identifier H'00 can exist; rather,
H'00 in the position of a parameter identifier marks the end of the optional part and
thus the end of the SCCP message as a whole.

36 TM3101EU01TM_0001
SCCP Siemens

Message type

Mandatory parameter A
F

fixed
Mandatory parameter F order
Pointer to parameter M

Pointer to parameter P
Pointer to the optional part
Length indicator parameter M
V
Mandatory parameter M

Length indicator parameter P

Mandatory parameter P

Identifier parameter X
Length indicator parameter X
Optional parameter X

O
Identifier parameter Z
Length indicator parameter Z
Optional parameter Z
End of the optional part

Fig. 20 Layout of the SCCP parameters

TM3101EU01TM_0001
37
 Siemens SCCP

Fig. 21 shows the coding of the SCCP message types (as far as they are relevant for
a GSM-PLMN).
Fig. 22 displays the identifiers of those SCCP parameters which are optional in some
of the SCCP messages listed in Fig. 21 (i.e. those parameters which require - at least
sometimes - an identifier).

38 TM3101EU01TM_0001
SCCP Siemens

Message Type Code

CR Connect Request 0000 0001 = H' 01

CC Connect Confirm 0000 0010 = H' 02

CREF Connect Refused 0000 0011 = H' 03

RLSD Released 0000 0100 = H' 04

RLC Release Complete 0000 0101 = H' 05

DT1 Data Form 1 0000 0110 = H' 06

UDT Unitdata 0000 1001 = H' 09

UDTS Unitdata Service 0000 1010 = H' 0A

XUDT Extended Unitdata 0001 0001 = H’11

XUDTS Extended Unitdata Service 0001 0010 = H’12

Fig. 21 SCCP Message Types

Parameter Code

Called Party Address 0000 0011 = H' 03

Calling Party Address 0000 0100 = H' 04

Credit 0000 1001 = H' 09

Data 0000 1111 = H' 0F

Hop Counter 0001 0001 = H’11

Fig. 22 SCCP parameters (which appear as optional)

TM3101EU01TM_0001
39
 Siemens SCCP

Let's consider as examples the "Connect Request" (CR) and the "Unitdata" (UDT).
The CR has as mandatory parameters of fixed length - besides the message type -
the source local reference and the protocol class (with a GSM-PLMN always = 2).
The only mandatory parameter of variable length is the called party address. The
optional parameters are "Credit" (only for protocol class 3, i.e. not for GSM), the
calling party address and the user message ("Data").
The F-parameters of the UDT are the message type and the protocol class (0 or 1).
The V-parameters are the called party address, the calling party address and the
user message ("Data"). There are no O-parameters in the UDT.

40 TM3101EU01TM_0001
SCCP Siemens

Parameter Type Length

Message Type F 1

Source Local Reference F 3

Protocol Class F 1

Called Party Address V min. 3

Credit O 3

Calling Party Address O min. 4

Data O 3-130

Fig. 23 Connect Request (CR)

Parameter Type Length

Message Type F 1

Protocol Class F 1

Called Party Address V min. 3

Calling Party Address V min. 2

Data V 2-129

Fig. 24 Unitdata (UDT)

TM3101EU01TM_0001
41
 Siemens SCCP

As a first example for a specific "Connect Request", we consider the set up of a

SCCP transaction between BSC and MSC for the BSSAP. The message type H'01
identifies the message as a "Connect Request". According to Fig. 23, the first three
bytes after the message type must be interpreted as local reference of the calling
side. The next byte is the protocol class (here: 2).
The next two bytes are the pointers to the called party address (the only V-parameter
in the CR) and to the optional part. The latter must be present because, according to
, a CR could have optional parameters. But since our specific CR has no optional
parameters, the pointer is 0.
The called party address begins - after the length indicator - with the address
indicator. It says that a subsystem number but neither a SPC nor a Global Title is
present. The routing indicator informs that the receiver must distribute the message
according to the subsystem. The following subsystem number identifies the
subsystem as BSSAP.
Now, all mandatory parameters are dealt with. Since our specific CR has no optional
parameters, the message is finished.

42 TM3101EU01TM_0001
SCCP Siemens

0 0 0 0 0 0 0 1 Message type CR

Source
Local
Reference

0 0 0 0 0 0 1 0 Protocol class 2

0 0 0 0 0 0 1 0 Pointer to the Called Party Address

0 0 0 0 0 0 0 0 Pointer to the optional part = 0

0 0 0 0 0 0 1 0 Length Called Party Address = 2

0 1 0 0 0 0 1 0 Address indicator

1 1 1 1 1 1 1 0 Subsystem BSSAP

Fig. 25 Example for a ”Connect Request” without a user message

TM3101EU01TM_0001
43
 Siemens SCCP

Now, we modify the above example and consider a "Connect Request" with a user
message. The message type, the local reference, the protocol class and the called
party address are identical with the former example. Only the pointer to the optional
part is now no longer 0 because, this time, optional parameters are present.
The optional part begins with the parameter identifier B'0000 1111 = H'0F which
identifies the first parameter as "Data" (= user message). Because of the subsystem
number, the user message belongs to the BSSAP. The length indicator in the next
byte gives a length of 20 bytes, so that the next 20 bytes contain the BSSAP-
message.
The following (= 21st) byte now is the place where the next identifier is to be
expected. But this byte has the value 0000 0000 = H'00. Therefore, it marks the end
of the optional part and thus the end of the whole SCCP message.

44 TM3101EU01TM_0001
SCCP Siemens

0 0 0 0 0 0 0 1 Message type CR

Source
Local
Reference

0 0 0 0 0 0 1 0 Protocol class 2

0 0 0 0 0 0 1 0 Pointer to the Called Party Address

0 0 0 0 0 1 0 0 Pointer to the optional part

0 0 0 0 0 0 1 0 Length Called Party Address = 2

0 1 0 0 0 0 1 0 Address indicator

1 1 1 1 1 1 1 0 Subsystem BSSAP

0 0 0 0 1 1 1 1 Identifier: Data

0 0 0 1 0 1 0 0 Length Data = 20

20 byte
BSSAP

0 0 0 0 0 0 0 0 End of the optional part

Fig. 26 Example for a ”Connect Request” with a user message

TM3101EU01TM_0001
45
 Siemens SCCP

Now, we consider an example for a specific "Unitdata". We take the message VLR ®
HLR for the location update with international roaming according to Fig. 9 and Fig.
12. We consider the first transmission section (i.e. between VLR and Gateway).
The message type H'09 identifies the message as UDT so that Fig. 24 applies.
Accordingly, the following 4 bytes are to be interpreted as
l the protocol class (here: 0)
l the pointer to the called party address
l the pointer to the calling party address
l the pointer to the user message ("Data").

There is no pointer to the optional part since a UDT can never have optional
parameters according to Fig. 24.
The example shows that the sequence of the V-parameters themselves is not
prescribed; only the order of the pointers is given. Here, the calling party address
precedes the called party address. The calling party address begins (after the length
indicator) with the address indicator which says that no SPC but a subsystem number
and a Global Title of type 4 are present. The routing is to be performed with the
Global Title. According to Fig. 13, there now follow
l the subsystem number (here: VLR)
l the translation type (here: unknown)
l the numbering plan (here: ISDN/Telephony Numbering Plan [E.163 and E.164])
l the encoding scheme (here: BCD, odd number of digits)
l the nature of address (here: national number).

The interpretation of the given values follows from Fig. 14 to Fig. 18.
There now ensues the digit combination "12345" as VLR address. Since the amount
of digits is odd, the last half byte must be filled with B'0000. The last half byte is
recognized as such by means of the length indicator for the whole element.

46 TM3101EU01TM_0001
SCCP Siemens

0 0 0 0 1 0 0 1 Message type UDT

0 0 0 0 0 0 0 0 Protocol class 0
0 0 0 0 1 1 0 0 Pointer to the Called Party Address
0 0 0 0 0 0 1 0 Pointer to the Calling Party Address
0 0 0 1 1 0 0 0 Pointer to Data
0 0 0 0 1 0 0 0 Length Called Party Address = 8
0 0 0 1 0 0 1 0 Address indicator
0 0 0 0 0 1 1 1 Subsystem VLR
0 0 0 0 0 0 0 0 Translation Type unknown
0 0 0 1 0 0 0 1 E.163 / E.164 - BCD odd
0 0 0 0 0 0 1 1 Nature of Address: national
0 0 1 0 0 0 0 1 Digits 1 and 2
0 1 0 0 0 0 1 1 Digits 3 and 4
0 0 0 0 0 1 0 1 Digits 5 and filler
0 0 0 0 1 1 0 1 Length Called Address = 13
0 0 0 1 0 0 1 0 Address indicator
0 0 0 0 0 1 1 0 Subsystem HLR
0 0 0 0 0 0 0 0
Translation Type unknown
0 1 1 0 0 0 0 1 E.212 - BCD odd
0 0 0 0 0 1 0 0
Nature of Address: international

Fig. 27 Example for a "Unitdata" (part 1)

TM3101EU01TM_0001
47
 Siemens SCCP

The calling party address ensues. Again, after the length indicator, the address
indicator follows. Once more, there is a Global Title of type 4 (which has to be used
for routing) and a subsystem number, but no SPC. There now follow
l the subsystem number (here: HLR)
l the translation type (here: IMSI)
l the numbering plan (here: Land Mobile Numbering Plan [E.212])
l the encoding scheme (here: BCD, odd number of digits)
l the nature of address (here: international Number).

Next, the IMSI itself follows: 262-01-77-08154711. Again, the amount of digits is odd,
and the last half byte is filled with B'0000.
Finally, the parameter "Data" follows. The length indicator is 50. The following 50
bytes contain the user message (here: TCAP and MAP data for the location update).
Since no optional parameters exist, the UDT is now finished.

48 TM3101EU01TM_0001
SCCP Siemens

- Continuation -

0 1 1 0 0 0 1 0 Digits 1 and 6

0 0 0 0 0 0 1 0 Digits 2 and 0

0 1 1 1 0 0 0 1 Digits 1 and 7

0 0 0 0 0 1 1 1 Digits 7 and 0

0 0 0 1 1 0 0 0 Digits 8 and 1

0 1 0 0 0 1 0 1 Digits 5 and 4

0 0 0 1 0 1 1 1 Digits 7 and 1

0 0 0 0 0 0 0 1 Digits 1 and filler

0 0 1 1 0 0 1 0 Length data = 50

50 byte
TCAP and MAP

Fig. 28 Example for a ”Unitdata” (part 2)

TM3101EU01TM_0001
49
 Siemens SCCP

50 TM3101EU01TM_0001
SCCP Siemens

3 Exercise

TM3101EU01TM_0001
51
 Siemens SCCP

52 TM3101EU01TM_0001
SCCP Siemens

Exercise

1. Which SCCP protocol classes are used at which GSM interfaces?

2. Channel seizure at the A interface: where is the CIC transmitted?

3. Are optional SCCP parameters with fixed length endowed with a length
indicator?

4. Evaluate the following SCCP-message, using the ITU-standard documentation.

K1103 --- CCS No. 7 - Monitor , Date: 03.02.98 , Time: 10:54:11

HH:MM:ss"m FROM TYPE BSN I FSN I LI SIO DPC OPC SLS CIC NAME

10:50:42"0 1Rx< SCCP 35 1 115 1 14 83 04-0-02-0 12-0-10-0 9

Blue Book SCCP (SCCP)
-0100011 Backward Sequence Number 35
1------- Backward Indicator Bit 1
-1110011 Forward Sequence Number 115
1------- Forward Indicator Bit 1
--001110 Length Indicator 14
00------ Spare
----0011 Service Indicator SCCP
--00---- Sub-Service: Priority Spare/priority 0 (U.S.A. only)
10------ Sub-Service: Network Ind National message
******** Destination Point Code 04-0-02-0
******** Originating Point Code 12-0-10-0
******** Signalling Link Selection 9

04
63
2C
01
02
A7
03
00

TM3101EU01TM_0001
53
 Siemens SCCP

54 TM3101EU01TM_0001
SCCP Siemens

4 Solution

TM3101EU01TM_0001
55
 Siemens SCCP

56 TM3101EU01TM_0001
SCCP Siemens

Solution

1. Which SCCP protocol classes are used at which GSM interfaces?

Interfaces between the SSS subunits: protocol classes 0 and 1
Interface between BSS and SSS (A-interface): protocol classes 0 and 2

2. Channel seizure at the A interface: where is the CIC transmitted?

In the BSSAP data. (Thus, not in the extended Routing Label !)

3. Are optional SCCP parameters with fixed length endowed with a length
indicator?
Yes, they are (only mandatory elements of fixed length are not)

4. Evaluate the following SCCP-message, using the ITU-standard documentation.

K1103 --- CCS No. 7 - Monitor , Date: 03.02.98 , Time: 10:54:11

HH:MM:ss"m FROM TYPE BSN I FSN I LI SIO DPC OPC SLS CIC NAME

10:50:42"0 1Rx< SCCP 35 1 115 1 14 83 04-0-02-0 12-0-10-0 9 RLSD

Blue Book SCCP (SCCP) Released (RLSD)
-0100011 Backward Sequence Number 35
1------- Backward Indicator Bit 1
-1110011 Forward Sequence Number 115
1------- Forward Indicator Bit 1
--001110 Length Indicator 14
00------ Spare
----0011 Service Indicator SCCP
--00---- Sub-Service: Priority Spare/priority 0 (U.S.A. only)
10------ Sub-Service: Network Ind National message
******** Destination Point Code 04-0-02-0
******** Originating Point Code 12-0-10-0
******** Signalling Link Selection 9
00000100 SCCP Message Type 0x4
******** Destination Local Ref. 0x1B
******** Source Local Reference 0x2C1029
00000010 Release Cause SCCP user originated
00000000 Ptr to optional param. 0

TM3101EU01TM_0001
57
 Siemens SCCP

58 TM3101EU01TM_0001