05 Tm3101eu01tm 0001 Tcap Map

TCAP and MAP Siemens
TCAP and MAP
Contents
1 TCAP and MAP 3
2 Call Sequences 17
3 Formatting Rules of TCAP and MAP 45
4 Exercise 75
5 Solution 81
TM3101EU01TM_0001
1
Siemens TCAP and MAP
2 TM3101EU01TM_0001
1 TCAP and MAP
TM3101EU01TM_0001
3
The SSS subunits (i.e. the Mobile Switching Center MSC, the Visitor Location
Register VLR, the Home Location Register HLR and the Equipment Identity Register
EIR - the Authentication Center AC is not considered here) are interconnected in
various ways. Whereas the MSCs are connected with each other via speech circuits
and in parts (Gateway-MSCs) have connections to other networks, there are only
signaling channels to the registers (HLR, VLR, EIR). The signaling on these channels
employs the Common Channel Signaling System No. 7 (CCS7) with Signaling
Connection Control Part (SCCP). Here, the connectionless SCCP services are used
exclusively (protocol class 0 and 1). As a consequence, all signaling messages
treated in this chapter are contained in the SCCP message UDT (Unitdata). If a UDT
cannot be delivered to the receiver, the possibility exist to return it to the sender with
UDTS (Unitdata Service). This is a basic SCCP function and will not be discussed
here.
The reason for the confinement to the connectionless SCCP services is that all
messages must be transmitted with a Global Title in order to enable the information
transfer between different networks (e.g. international). With connection oriented
SCCP services, a Global Title translation is possible only during the connection set
up; during the existence of the SCCP connection, the messages are transmitted
without a Global Title and are routed by the Destination Point Code (DPC) to the
receiving exchange.
Nevertheless, even with the signaling between SSS subunits, we cannot help
introducing signaling connections (logical connections). For example, it can happen
that several Mobile Stations of HLR x roam in the area of VLR y at the same time,
and that several proceedings for different Mobile Stations are going on between HLR
x and VLR y. In each signaling message, it must become clear to which proceeding it
is related. Therefore, signaling connections (transactions) must be set up between
HLR x and VLR y, and every signaling message is related to one transaction.
Because the SCCP is used connectionless only, the signaling connections are
controlled by the TCAP (Transaction Capabilities Application Part). The TCAP is
transmitted in the SCCP message UDT as contents of the mandatory parameter
"Data"; at the interfaces between SSS subunits, no other content of this parameter is
possible.
The TCAP has been specified by CCITT in the recommendations Q.771 to Q.775. It
has three tasks:
l Transaction control (Set up, clear down and identification of signaling connections)
l Control of dialogues ( = call sequences within a transaction)
l Control of operations within a dialogue.
Accordingly, the TCAP consists of three parts: the Transaction Portion, the
Dialogue Portion and the Component Portion.
4 TM3101EU01TM_0001
SCCP message type UDT
Pointer to Data
Length Data
- TCAP message type Transaction
- Transaction Identities portion
- Dialogue PDU
Dialoge
- Application context portion
MAP
- MAP Dialogue PDU (optional)
Component 1:
- Type of Component
- Invoke Identifier
TCAP - Operation Type
MAP
- Parameter
Component
Component 2: portion
- Type of Component
- Invoke Identifier
- Operation Type
MAP
- Parameter
Fig. 1 Layout of TCAP and MAP
TM3101EU01TM_0001
5
6 TM3101EU01TM_0001
The TCAP begins with the Transaction portion. Here, we have a message type (e.g.
transaction set up - transaction clear down - information exchange over an existing
transaction) and - depending on the message type - one or two transaction
identifier(s). The TCAP transactions contain - similar to the SCCP transactions - two
identifiers (one for each connection side); they correspond to the local references of
the SCCP transactions. Whereas the messages for the transaction set up and clear
down need only one transaction identity, both transaction identities are sent with the
information exchange over an existing transaction.
The next portion is the Dialogue Portion, which is optional. It contains a Process
Data Unit (PDU) for establishment, confirmation and termination of a dialogue within
a transaction. It contains an identification of an application context (location update,
interrogation, Handover etc.) characteristic for the dialogue. Besides the TCAP-
specific PDU, a MAP-specific PDU is included as well.
After the Transaction portion, the Component portion ensues. This portion consists of
one or several component(s) in which either an operation (i.e. an action by the
partner side) is requested or else a previously received operation request from the
partner side is acknowledged (positively or negatively). As long as a transaction
exists, both parties have the right to request operations from the partner side and to
have them acknowledged. Each operation request or acknowledgment comprises a
component of its own, but one TCAP message can include several components.
TM3101EU01TM_0001
7
Let us consider now the individual TCAP messages and message sequences. There
are four TCAP message types:
l Begin for the set up of a signaling connection (transaction)
l End for the regular clear down of a transaction
l Continue for the component transmission over an existing transaction
l Abort for the disruption of a transaction due to irregularities. We distinguish
between U-Abort (User-Abort, i.e. abort caused by the TCAP user, e.g. due to
supervision time expiry with class 1 operations, or due to illegal operation
requests) and P-Abort (Provider-Abort, i.e. abort caused by the TCAP transaction
layer). The message type, however, is the same.
A fifth TCAP message type (Unidirectional for the transmission of components

without transaction) is identified by CCITT but not employed for a GSM-PLMN.
At any rate, the TCAP message type is part of the transaction portion (see Fig. 1).
Furthermore, the transaction portion contains the transaction identities (TRID), which
identify the transaction in the two affected network nodes. The TRIDs can be
understood as local addresses used by the network nodes to address the transaction
specific memory area.
The TCAP message Continue contains two transaction identities: one for the
origination (O-TRID) and one for the destination (D-TRID). Of course, the message
Begin only contains the transaction identity of the origination (O-TRID) since the
partner identity is not known yet. The messages End for the regular and Abort for
the irregular transaction cleardown both contain the transaction identity of the
destination (D-TRID) only.
In order to set up a transaction, one network node (A) sends to the other (B) the
TCAP message Begin, thus delivering its own transaction identity. If Continue
messages are required, the first Continue serves as an answer to the Begin; with
this, B communicates its transaction identity to A. From now on, both sides can
exchange Continue messages in an arbitrary sequence. From the point of view of
the transaction control, it is not necessary that each Continue is answered by
another Continue in the opposite direction; rather, it can happen that two or more
Continue are sent in the same direction consecutively. The transaction is cleared
down in such a way that one of the two sides (A or B) sends End or Abort to the
partner side; there is no response. Sometimes, a transaction is cleared down locally
(i.e. without End/Abort) if both sides know that the transaction is not needed any
longer (pre-arranged end).
The shortest possible transaction consists of a Begin message from A to B which is
answered immediately by an End or Abort from B to A (or by a local transaction
cleardown). Begin contains the origination transaction identity only, End and Abort
have the destination transaction identity only; as a consequence, no transaction
identity of B is required. The transaction is identified by a single identification number
(selected by A).
8 TM3101EU01TM_0001
A B
Begin (O-TRID)
Continue (O-TRID, D-TRID)
End / Abort (D-TRID)
Minimal sequence
A B
Begin (O-TRID)
Fig. 2 TCAP Transaction Control
TM3101EU01TM_0001
9
All TCAP messages with the exception of Abort can contain components where
certain operations are requested from the partner side or where a reaction to a
received operation request is transmitted. There are four types of components:
l Invoke for the request of an operation from the partner side.
l Return Result (Last) for the transmission of the results of an executed operation
which had been requested by the partner side previously
l Return Error for the transmission of errors which have happened during the
execution of a requested operation
l Reject for the rejection of a received component.
A fifth type of component (Return Result (Not Last) for the transmission of
intermediate results) is defined by CCITT but not used with a GSM-PLMN.
As was already discussed, a TCAP message can contain several components (see
Fig. 1). It is perfectly clear that a Begin can contain Invoke components exclusively.
On the other hand, an End message can contain Invoke components only if the
requested operations belong to class 4 (see Fig. 4). In Continue operations, all types
of components are permitted.
For the distinction of different operations within the same transaction, each operation
obtains an invoke identifier which is selected by the requesting side and transmitted
to the partner side in the Invoke component. The partner side repeats the invoke
identifier in the reply components (Return Result (Last), Return Error or Reject).
It can happen that the reaction to an operation request consists of another request in
the opposite direction, i.e. that an Invoke is answered with Invoke (as, in the daily
conversation, a question is answered with a counter-question). In this case, the
second Invoke contains besides its own invoke identifier the so-called linked
identifier, i.e. the identifier of the previous Invoke. Thus, the second Invoke replaces
an explicit acknowledgment of the original request (with Return Result (Last) or
Return Error), and the linked identifier provides a relation between the two Invokes.
It should be pointed out that, with Reject, not only Invoke components can be
rejected (e.g. due to an unknown operation code) but Return Result (Last) or
Return Error components as well (e.g. due to an unknown invoke identifier).
A Reject component contains a problem code, which indicates the reason for the
rejection. This problem code is defined in the TCAP. The components Invoke,
Return Result (Last) and Return Error contain data of the TCAP user (i.e. MAP
data with a GSM-PLMN). These data are
l with Invoke: the code of the operation to be executed and further parameters
l with Return Result (Last): the code of the executed operation and the execution
results
l with Return Error: the sort of error the has happened.
These data are defined in the GSM guideline 09.02.
10 TM3101EU01TM_0001
A B
Invoke (Invoke-Id=1)
Return Result(Last) (Invoke-Id=1)
A B
Invoke (Invoke-Id=3, Linked-Id=2)
Return Error (Invoke-Id=4)
A B
Reject (Invoke-Id=5)
Fig. 3 TCAP operation control
TM3101EU01TM_0001
11
There are four possibilities (classes) to acknowledge operations:

Class 1: These operations must be acknowledged at any rate; it is an error if no
answer has arrived after the expiry of a supervision time.
Class 2: These operations are acknowledged in the negative case only (no news -
good news). It is a sort of positive acknowledgment if, after the expiry of a
supervision time, no answer has arrived.
Class 3: These operations are acknowledged in the positive case only (no news -
bad news). It is a negative acknowledgment (and not an error as with class
1) if, after the expiry of a supervision time, no answer has arrived.
Class 4: These operations are never acknowledged.
It is not transmitted in the components themselves to which class a given operation

belongs; rather, the TCAP user determines this. With the classes 1, 2 and 3, the
TCAP user defines the duration of the supervision time, too.
The TCAP user also defines which operations exist and which parameters are
contained in the requests and acknowledgments for the individual operations. With a
GSM-PLMN, the TCAP user is the Mobile Application Part (MAP).
Thus, a TCAP component contains the invoke identifier and the type of component
(operation request - positive acknowledgment - negative acknowledgment).
Furthermore, the operation identification and one or several parameter(s) are
contained, but these data do not belong to the TCAP itself but to its user (i.e. with
GSM to the MAP).
12 TM3101EU01TM_0001
Class 1 Class 2
Request Request
t Acknowledgment (good or bad) t Acknowledgment (bad)
Request Request
t
t
Timeout: Error! Timeout: positive acknowl.
Class 3 Class 4
Request Request
no time supervision,
t Acknowledgment (good)
no acknowledgment
Request
Timeout: negative acknowl.
Fig. 4 Classes of Operation of the TCAP
TM3101EU01TM_0001
13
Let us consider now the interfaces where the TCAP with the user MAP is employed.
These are logical interfaces throughout. The affected SSS subunits can be
distributed in an arbitrary way over the network nodes. It can come to pass that both
SSS subunits lie in the same network node; in this case, there is no physical
interface. The other extreme occurs if the two SSS subunits lie in remote network
nodes; here, the physical interface consists of several signaling links.
The B-interface exists between the MSC and the assigned VLR. It is used whenever
the MSC requires or obtains data about a Mobile Station roaming in its area.
However, since this is - with the D900 realization - an internal interface, we shall not
discuss it from the TCAP / MAP point of view.
The C-interface lies between an MSC and an arbitrary HLR. The MSC uses this
interface for the interrogation during a mobile terminating call (MTC) in order to obtain
data from the HLR about the actual location of the called mobile subscriber.
Furthermore, the MSC can transmit this way call charge data to the HLR.
The D-interface is defined between a VLR and an arbitrary HLR for the purposes:
l Location update and cancellation
l Control of supplementary services
l during call set up: access to subscriber data which are not stored in the VLR
l Request for a roaming number (MSRN)
l Reconstruction of the location registers after recovery
l Transfer of authentication data (triples)
The E-interface is located between two MSCs. It is the only interface where, besides
SCCP, TCAP and MAP, user channel related User Parts can be employed, too, since
for a call set up and clear down, user channels must be seized and released. At this
interface, TCAP and MAP are used for Inter-MSC-Handovers exclusively.
The F-interface can be found between an MSC and an EIR. It is used during a call
set up so that the MSC can have the IMEI of the terminal in use checked.
The G-interface finally exists between two arbitrary VLRs. During a location update,
it enables the communication between the old and the new VLR. This way, the new
VLR obtains the IMSI of the mobile subscriber (who has registered using the TMSI)
as well as the unused authentication triples.
In the subsequent sections, the TCAP message sequences and MAP operations at
these interfaces will be described. All MAP operations under consideration belong to
class 1 if not explicitly stated otherwise.
Generally, we are going to confine ourselves to examples of positive cases since a
detailed discussion of all special and error cases would exceed the scope of this
training documentation considerably. For a complete treatment even of these cases,
we refer to the GSM guideline 09.02.
14 TM3101EU01TM_0001
D G
HLR VLR VLR
(B)
D
MSC MSC EIR

E F
Fig. 5 MAP interface
TM3101EU01TM_0001
15
16 TM3101EU01TM_0001
2 Call Sequences
TM3101EU01TM_0001
17
Three SSS subunits are concerned with the location registration:

l the MSC/VLR in whose area the MS roams (called "new VLR" from now on)
l the VLR where the MS was registered hitherto (called "old VLR" from now on)
l the HLR where the subscriber is registered permanently.
It can happen that the old and the new VLR are identical; then, location update is an
internal affair of the MSC/VLR, and no external TCAP/MAP messages are involved.
The relevant interfaces are
l the G-interface between the old and the new VLR
l the two D-interfaces between the HLR and the two VLRs.
As soon as the Mobile Station notices that the conditions for a location update are
met (e.g. change of the location area without an existing call), it sends to the MSC
the message "Location Update Request" via the air interface and the A-interface. The
message contains the TMSI and the old and the new Location Area Identification
(LAI). Thereupon, the MSC/VLR checks whether the old LAI belongs to the own MSC
area. We suppose that this is not the case.
The VLR (= the new VLR) determines from its data base by means of the old LAI the
address (Global Title) of the old VLR and sets up a transaction to the old VLR with
the TCAP message Begin. The message contains an Invoke component for the
MAP operation "Send Identification" with the received TMSI.
The old VLR determines from the TMSI the IMSI and the unused authentication
triples; both is sent with the Return Result (Last) component for the "Send
Identification" operation to the new VLR. The component is contained in an End
message. This is an example for a short-term transaction where the Begin message
is answered with End immediately and where one transaction identity is sufficient.
Now, the MSC/VLR can perform an authentication for the Mobile Station. Afterwards,
the new VLR informs the HLR by determining the LMSI (= the index of the transient
subscriber data record) and setting up a transaction VLR-HLR with Begin; this
message contains an Invoke component for the MAP operation "Update Location".
With this, the VLR communicates to the HLR
l the IMSI (for the identification of the affected mobile subscriber)
l the LMSI (for the storage in the transient HLR subscriber data record)
l the VLR and MSC numbers (Global Titles; for the storage in the transient HLR
subscriber data record so that the HLR can later address the VLR and the MSC,
e.g. during the interrogation).
The VLR reaches the HLR over the IMSI, which operates as a Global Title. Thus, the
IMSI is contained twice in the integral message: once in the SCCP section (Global
Title for the determination of the HLR) and once as a MAP parameter in the Invoke
component (so that the HLR can identify the mobile subscriber).
18 TM3101EU01TM_0001
D
VLR
G D HLR
new VLR old
Begin
Invoke (Send Identification)
(TMSI)
End
RRLast (Send Identification)
(IMSI, Auth.-Triples)
Begin
Invoke (Update Location)
(IMSI, LMSI, VLR number, MSC number)
Continue
Invoke (Insert Subscriber Data) ( Service Data)
Invoke (Insert Subscriber Data) ( Service Data)
Continue
RRLast (Insert Subscriber Data) ( Service Data)
RRLast (Insert Subscriber Data) ( Service Data)
End
RRLast (Update Location) (HLR number)
Begin
Invoke (Cancel Location)
(IMSI, old LMSI)
End
RRLast (Cancel Location)
Fig. 6 Location Registration
TM3101EU01TM_0001
19
On reception of the Invoke, the HLR determines from the IMSI the mobile subscriber
and stores the received data (IMSI and VLR address). Afterwards, the HLR
determines the data of the basic and supplementary services of the mobile
subscriber as far as they are relevant for the VLR.
The HLR communicates the service data are to the VLR with Invoke components for
the MAP operation "Insert Subscriber Data", sending each Basic Service (with its
MSISDN and all supplementary services) in a component of its own (with own invoke
identifier). The components are sent in Continue messages; the mobile subscriber is
determined by the transaction identities so that linked identifiers are not required.
Several of these Invoke components can be transmitted in a single Continue.
The VLR enters the service data into the transient subscriber data record and
confirms each single Invoke with Return Result (Last) in Continue messages.
Once again, one Continue can summarize several components.
As soon as the last Invoke for "Insert Subscriber Data" is acknowledged, the HLR
terminates the transaction with an End message containing the Return Result (Last)
component for the MAP operation "Update Location". Here, the HLR communicates
its number (= Global Title) to the VLR.
Thereupon, the MSC/VLR can encipher the air interface, assigns to the mobile
subscriber a new TMSI and send it to the MS.
The HLR, after cleardown of the transaction to the new VLR, performs the location
cancellation to the old VLR. For this purpose, the HLR sets up a transaction to the old
VLR with a Begin containing an Invoke for the MAP operation "Cancel Location" with
the IMSI and the old LMSI. The old VLR now cancels its subscriber data record,
releases TMSI and LMSI and sends the Return Result (Last) in an End message.
Again, this is a short-term transaction with a single transaction identity.
Now, the cancellation is completed, too, and the whole proceeding is finished.
The used application contexts are
l "Inter-VLR Info Retrieval Context - v2" between old and new VLR
l "Network Loc. Up. Context - v2" between the new VLR and the HLR
l "Location Cancellation - v2" between the old VLR and the HLR.
The procedure "MS Purging" is invoked either because of administrative actions or

because the MS has been inactive for an extended period of time. If this is the case,
then the VLR sends to the HLR a Begin with an Invoke component for the MAP
operation "Purge MS". As parameters, the IMSI and the VLR number are contained.
This operation belongs to the class 3, i.e. there is no negative response. In the
positive case, the HLR answers with an End containing the Return Result (Last) for
this operation. No further data are contained in this Return Result (Last) component.
The application context of this procedure is "MS Purging Context - v2".
20 TM3101EU01TM_0001
D
VLR HLR
Begin
Invoke (Purge MS) (IMSI, VLR number)
End
RRLast (Purge MS)
Fig. 7 MS purging
TM3101EU01TM_0001
21
With mobile terminating calls (MTC), however, the interrogation is performed

between MSC, HLR and VLR by means of TCAP and MAP. The MSC is the
Gateway-MSC (either the MSC where the incoming call reaches the mobile network
or - with a call between two mobile subscribers of the same network - the MSC where
the call originates). The HLR is where the called subscriber is registered, and the
VLR is where the called subscriber has announced himself during the last location
update (i.e. associated with the visited MSC). The affected interfaces are
l the C-Interface between MSC and HLR
l the D-Interface between HLR and VLR.
The MSC initiates the interrogation with a Begin to the HLR containing an Invoke
component for the MAP procedure "Send Routing Info". Further data in this Invoke
are
l the MSISDN
l membership of the calling subscriber in a Closed User Group, CUG (optional)
l how often the call has already been forwarded (optional)
l received signaling information (optional, e.g. identification of a Basic Service).
In the positive case (when no CUG membership or another obstacle prevents the call
set up), the HLR sends a Begin to the VLR containing an Invoke component for the
MAP procedure "Provide Roaming Number". There are delivered
l the IMSI
l the MSC number
l the MSISDN
l the LMSI (optional - for a faster addressing of the VLR data)
l the GSM-Bearer Capability belonging to the MSISDN
l and/or signaling information about the requested service as received from the
MSC.
The VLR allocates a MSRN and returns it with the Return Result (Last) for "Provide
Roaming Number" to the HLR. The component is contained in an End message.
The HLR forwards the MSRN, the IMSI and the result of the CUG-check with Return
Result (Last) for "Send Routing Information" in an End to the Gateway-MSC.
Both transactions are short-termed and need just one transaction identity each.
The application contexts are
l "Location Info Retrieval Context - v2" between Gateway-MSC and HLR
l "Roaming Number Enquiry Context - v2" between HLR and VLR.
22 TM3101EU01TM_0001
C D
MSC HLR VLR
Begin
Invoke (Send Routing Info)
(MSISDN,
CUG Check Info,
Number of Forw.,
Network Signal Info)
Begin
Invoke (Provide Roaming No.)
(IMSI, MSC number,
MSISDN, LMSI,
GSM-Bearer Cap.,
Network Signal Info) Sel.
MSRN
End
RRLast (Provide Roaming No.)
(MSRN)
End
RRLast (Send Routing Info)
(IMSI, MSRN,
CUG Check Info)
Fig. 8 Interrogation
TM3101EU01TM_0001
23
Next, let us consider two cases of call forwarding.

Call Forwarding Unconditional is recognized during the interrogation in the HLR
already. As usual, the Gateway-MSC sends to the HLR the Invoke for the MAP
operation "Send Routing Info" with the MSISDN and further data. If now the HLR
sees that a Call Forwarding Unconditional exists for the service in question, no
contacts to the VLR are necessary. Rather, the HLR sends the Return Result (Last)
for "Send Routing Info" directly to the Gateway-MSC and communicates in it the call
forwarding destination (=B2 number) instead of the MSRN. Now, it is for the
Gateway-MSC to set up a call to the forwarding destination.
Call Forwarding Conditional is normally executed in the visited MSC after the call
routing from the Gateway MSC to the visited MSC. However, there is a case for Call
Forwarding on Not Reachable being executed in the Gateway MSC already: this is
if the Mobile Station is deregistered with "IMSI-Detach" (explicit or implicit). When the
HLR sends to the VLR the Invoke for "Provide Roaming Number", and if the VLR
now recognizes that the Mobile Station is deregistered, the VLR answers with Return
Error and the error code "Absent Subscriber". The HLR checks whether a Call
Forwarding is foreseen for this case; if it is, it sends the forwarding number (=B2
number) instead of the MSRN in the Return Result (Last) for "Send Routing Info" to
the Gateway-MSC.
The application contexts are the same ones as with a "normal" interrogation.
24 TM3101EU01TM_0001
C D
MSC HLR VLR
Begin
(MSISDN,
CUG Check Info,
Number of Forw.,
End
RRLast (Send Routing Info)
(IMSI, B2 number,
CUG Check Info)
Fig. 9 Call Forwarding Unconditional
C D
MSC HLR VLR
Begin
(MSISDN, Begin
CUG Check Info, Invoke (Provide Roaming No.)
Number of Forw., (IMSI, MSC number,
Network Signal Info) MSISDN, LMSI,
GSM-Bearer Cap.,
End
End RetError (Provide Poaming No.)
RRLast (Send Routing Info) (Absent Subscriber)
(IMSI, B2-Number,
CUG Check Info)
Fig. 10 Call Forwarding on not reachable after IMSI Detach
TM3101EU01TM_0001
25
If the VLR has lost the mobile subscribers data due to a recovery, the mobile
subscriber is still reachable for an MTC. It is during the interrogation (Invoke for
"Provide Roaming Number" with IMSI from the HLR) that the VLR first learns about
the subscribers existence. The VLR now assigns a MSRN in the usual manner and
returns it to the HLR with the Return Result (Last) for "Provide Roaming Number";
this component is contained, as always, in an End message. Furthermore, the VLR
reserves an idle data record for this subscriber; the index of this subscriber data
record is the LMSI.
Afterwards, the VLR retrieves authentication triples for this subscriber. To this end, it
sets up a new transaction (with Begin) to the HLR; this Begin message contains an
Invoke for the operation "Send Authentication Info" with the IMSI (from the previous
Invoke for "Provide Roaming Number") as parameter. The HLR replies with an End
message containing the Return Result (Last) for "Send Authentication Info" with five
authentication triples. This triples the VLR stores in the reserved subscriber data
record.
Next, the VLR sets up a third transaction to the HLR with a Begin message
containing an Invoke for the MAP operation "Restore Data". Parameters are IMSI
and LMSI of the subscriber. The HLR stores the new LMSI (the old one - prior to the
data loss in the VLR - could have been a different one) and, as with Location Update,
transmits the subscribers service data to the VLR by means of "Insert Subscriber
Data". Each Basic Service requires an own Invoke for "Insert Subscriber Data", and
the VLR must acknowledge each Invoke with Return Result (Last). The HLR can
combine several Invoke components within one Continue message, and the HLR
can do the same thing with several Return Result (Last) components. Finally, the
HLR terminates the transaction with an End, containing the Return Result (Last)
component for "Restore Data" with the HLR number as parameter.
Now, the VLR has reconstructed all the subscribers data as far as they come from
the HLR. When now the call from the gateway MSC with the assigned MSRN arrives,
the visited MSC performs searching (i.e. paging with the IMSI in each cell of the MSC
area). As soon as the subscriber replies, the VLR knows the location area of the
subscriber and can now assign a new TMSI as well, so that all the data are
successfully retrieved, and the call is set up.
The relevant application contexts are
l "Roaming Number Enquiry Context - v2" for the first transaction
l "Info Retrieval Context - v2" for the second transaction
l "Network Loc. Up Context - v2" for the third and last transaction.
When the mobile subscribers first call after the VLR data loss is a mobile originating
one, then it is not successful. In this case, the call fails due to the reason "Unknown
Subscriber" which causes the Mobile Station to do a Location Update, so that a
second MOC attempt will be successful.
26 TM3101EU01TM_0001
D
HLR VLR
Begin
Invoke (Provide Roaming Number)
(IMSI, MSC number, MSISDN, LMSI,
GSM-Bearer Capability, Network Signal Info) Sel.
MSRN
End
RRLast (Provide Roaming Number) (MSRN)
Begin
Invoke (Send Authentication Info) (IMSI)
End
RRLast (Send Authentication Info) (5 Triples)
Begin
Invoke (Restore Data) (IMSI, LMSI)
Continue
Invoke (Insert Subscriber Data) (Service Data)
Invoke (Insert Subscriber Data) (Service Data)
Continue
RRLast (Insert Subscriber Data)
RRLast (Insert Subscriber Data)
End
RRLast (Restore Data) (HLR number)
Fig. 11 Data Restoration VLR
TM3101EU01TM_0001
27
The transient HLR subscriber data belong to a memory section, which is normally not
overwritten during a recovery (noload-segment). Furthermore, the HLR stores these
data at regular time intervals in a backup file on the disk. If, during a recovery, the
data are destroyed nevertheless (e.g. due to a memory formatting), the secured data
are reloaded from the backup file into the memory. Because the data are not secured
perpetually in the backup but only periodically, all changes are lost that have
occurred since the last backup transfer. Therefore, all affected VLRs must be
informed about the failure so that they can mark the affected subscriber records
correspondingly. These are
l all VLRs of the own PLMN
l those foreign VLRs in whose areas subscribers of the affected HLR roam.
Thus, the HLR maintains an address list of these VLRs in another disk file.
If an HLR recovery with loss of the transient data base occurs, the HLR reloads from
the disk the transient HLR data (which, as mentioned, might not contain the latest
changes) and the list of the addresses of the affected VLRs. To these VLRs, the HLR
sends an Invoke for the MAP operation "Reset". This is a MAP operation of class 4
(no direct confirmation), and the Invoke component contains the HLR number which
corresponds to the address given during location update and VLR data restoration
(Return Result (Last) of "Update Location" and "Restore Data", cf. Fig. 6 and Fig.
11). This Invoke is delivered in a Begin message.
This transaction does not contain any further message; rather, VLR and HLR clear
down the transaction locally afterwards.
A VLR, on reception of such an Invoke for "Reset", rummages through its subscriber
data records and compares for each subscriber the stored HLR number with the
received value. Whenever the addresses coincide, it is a subscriber from the affected
HLR, and the VLR sets a mark in this subscribers data record.
If a subscriber thus marked gives any sign of life (e.g. normal location update [even
within the same MSC area], periodic location update, IMSI attach, mobile originating
call), the VLR performs a location update with the HLR corresponding to Fig. 6 so
that the HLR gets an actualized data record again. Thereupon, the VLR deletes the
mark for the mobile subscriber in the data record.
The application context of the "Reset" operation is "Reset Context - v2".
The treatment of an HLR recovery is of the utmost importance since an HLR data
loss endangers the accessibility of the affected mobile subscribers.
28 TM3101EU01TM_0001
D
VLR HLR
Begin
Invoke (Reset) (HLR number)
local local
transaction transaction
release release
Fig. 12 Data Restoration HLR
TM3101EU01TM_0001
29
Let us consider an example for an Inter-MSC-Handover within a PLMN. The mobile

station in Fig. 13 has originally set up a call in the area of MSC A. During the call it
moves from the area of MSC A into the area of MSC B. After the Inter-MSC-
Handover the mobile station will be connected to a BSS of MSC B (for the speech
and for the signaling channel). The control of the call, however, is still at the MSC A.
The access from MSC A to the mobile station is realized by a so-called long-term
TCAP-transaction between MSC A and MSC B.
Possibly the mobile station moves from the area of MSC B into a new area of MSC C
(probably a fast Porsche-driver). Then, there happens another Inter-MSC-Handover
to MSC C and again the control of the call is held at MSC A. The mobile station is
now connected to a BSS of MSC C (speech and signaling channel). The access from
l MSC A to the mobile station is again realized by a TCAP-connection (MSC A to
MSC C).
l The former TCAP-connection to MSC B is cleared down.
And finally, it could be the case, that the mobile station arrives again in the area of
MSC A. This would lead to a clear down of the long-term TCAP-transaction (in our
example: MSC A to MSC C) and the mobile station is from now on connected to a
BSS of MSC A (for the speech and for the signaling channel) and MSC A has the call
control anyhow.
30 TM3101EU01TM_0001
TCAP
MSCB
SCCP
RR
BSS
Remote
MSCA
party
BSS
RR
BSS
SCCP
TCAP
MSCC
Fig. 13 Inter-MSC-Handover
TM3101EU01TM_0001
31
TCAP and MAP are concerned with Handover only if it is a Handover between
different MSCs (MSC-MSC-Handover or Inter-MSC-Handover). The concerned units
are
l the MSC which had set up the call originally (MSC A)
l the MSC into whose area the Handover leads (MSC B)
Accordingly, the proceedings occur at the E-interface between both MSC.

It should be observed that the VLR of MSC B is required for the allocation of the
Handover Number (HON) only. No subscriber data record will be generated in this
VLR. The VLR doesn't learn the identity of the mobile subscriber either (IMSI or
MSISDN) moving into the new MSC area.
A typical feature of the Inter-MSC-Handover is that the old MSC "speaks directly"
with the new Base Station, i.e. the BSSMAP messages for Handover are carried
transparently in the MAP components.
Lets begin with the consideration of a first Handover. This is to say, the Mobile
Station changes during the call from the area of MSC A (where the connection has
been set up originally) into the area of MSC B. The Base Station decides when a
Handover to a new radio cell must be performed, and it is MSC A who recognizes
that the target cell belongs to the area of MSC B.
Now, MSC A sets up a transaction to MSC B with a Begin containing an Invoke
component for the MAP operation "Prepare Handover". In the component, MSC A
tells to MSC B the identity of the new (target) cell as well as whether a Handover
Number (HON) is required (this is not the case if the Mobile Station has no TCH
assigned but works with the SDCCH). Furthermore, the component contains the
complete BSSMAP-message "Handover Request". This BSSMAP message contains
the identity of the old and of the new cell, the channel type and the valid ciphering
key (Kc) for the air interface.
On reception of this message, MSC B transmits the "Handover Request" to the Base
Station, which administers the new cell; if a HON is required, the MSC B also selects
a terrestrial channel to the Base Station and includes its CIC into "Handover
Request". The Base Station selects a channel at the air interface and composes a
message "Handover Command" to the Mobile Station in which the Mobile Station
learns the new cell and the new channel. Furthermore, the message contains the
Handover reference number (selected by the Base Station, too) for the first radio
contact of the Mobile Station in the new cell. This "Handover Command" the Base
Station returns to the MSC with the BSSMAP-message "Handover Request
Acknowledge". (The Base Station cannot radiate this message at the air interface
because the Mobile Station receives in the old cell and on the old channel hitherto.)
32 TM3101EU01TM_0001
E
MSC MSC
A B
Begin
Invoke (Prepare Handover)
(Target cell, HON required?,
BSSMAP-message „Handover Request“)
HO Request
HO Request
Acknowledge
Continue
RRLast (Prepare Handover)
(Hon, BSSMAP-message
„Handover Request Acknowledge“)
Call Setup
to MSC B,
3-Conf.,
Command HO Detect
for MS
Continue
Invoke (Process Access Signalling)
(BSSMAP-message „Handover Detect“)
HO Complete
Continue
Invoke (Send End Signal)
(BSSMAP-message „Handover Complete“)
End
3-Conf.,
Release to
Base
Station
Fig. 14 First Handover MSC A ® MSC B
TM3101EU01TM_0001
33
34 TM3101EU01TM_0001
Now, MSC B selects an Handover Number and acknowledges to MSC A the MAP
operation "Prepare Handover" with Return Result (Last) in a Continue. The
component contains the allocated Handover Number (if applicable) and received
"Handover Request Acknowledge", containing the air interface message "Handover
Command" to the Mobile Station.
MSC A uses the Handover Number to set up a user connection to MSC B (with a
user channel related User Part, or with channel associated signaling) and to switch it
to a three-party conference with the former user connection. Thereupon, MSC A
requests the (old) Base Station to radiate "Handover Command" (as composed by
the new Base Station) to the Mobile Station.
With this message, the Mobile Station is asked to switch to the new cell and to the
new channel and to report there with the Handover reference number. As soon as
this has happened, the new Base Station sends the BSSMAP-message "Handover
Detect" which MSC B relays to MSC A in a Continue with the Invoke for the MAP
operation "Process Access Signaling". It is an operation of class 4, i.e. no
acknowledgment is required on the part of MSC A.
When the Mobile Station has sent "Handover Complete", the Base Station sends a
BSSMAP message of the same name to MSC B, and MSC B transmits this BSSMAP
message to MSC A Continue with the Invoke for the MAP operation "Send End
Signal".
Now, MSC B clears down the three-party conference, releases the user channel to
the old Base Station and requests the old Base Station to release the former channel
at the air interface. The Handover is completed.
The transaction between MSC A and MSC B remains stable until either the user
connection is cleared down or a second Handover to another MSC occurs.
With the call sequences discussed hitherto, transactions were set up for proceedings
within a restricted period of time (location registration or call set up) and were
released after the completion of the proceeding. The Handover between MSCs is the
only case were transactions are maintained beyond the actual proceeding over a
longer period of time. The reason is that MSC B and its VLR do not "know" which
Mobile Station is roaming in their area. If a subsequent Handover or other events
occur, MSC B can tell to MSC A by means of the transaction identities, which Mobile
Station is concerned.
The MAP procedure, which was initiated last ("Send End Signal" MSC B --> MSC A)
belongs to class 3, i.e. ultimately, it is acknowledged positively, but its supervision
time amounts to several hours (project and implementation dependent: up to 38
hours). The aim is to prevent that the user channels between MSCs remain blocked
for an incongruously long period of time. After expiry of the time supervision, the
transactions and user connections are cleared down.
The application context for Handover is "Handover Control Context - v2"
TM3101EU01TM_0001
35
Let us investigate now the case of a subsequent Handover into the area of a third
MSC (=MSC C). The Base Station where the Mobile Station roams recognizes that a
Handover to another radio cell is necessary, and MSC B finds out that the new cell
does not belong to the own area. Therefore, MSC B sends to MSC A in a Continue
the Invoke for the MAP Procedure "Prepare Subsequent Handover" and informs
MSC A about the identity of the target cell as well as about the number (=Global
Title) of the new MSC. Furthermore, the Invoke contains the BSSMAP-message
"Handover Request".
When MSC A now finds out that the target cell doesn't belong to the own area either
but is administered by a third MSC (=MSC C), it performs a Handover procedure to
MSC C which corresponds exactly to the first Handover (cf. Fig. 14). Thus, MSC A
sends to MSC C an Invoke for "Prepare Handover" (with the "Handover Request"
message received from MSC B). MSC C has a channel of the air interface assigned
and a message of the air interface composed by the Base Station. Furthermore, MSC
C selects a Handover Number (if necessary). Now, MSC C sends the Handover
Number to MSC A in the Return Result (Last) for "Prepare Handover" (including the
BSSMAP message "Handover Request Acknowledge" containing the air interface
message "Handover Command").
MSC A employs the Handover Number to set up a user connection to MSC C and to
switch it to a three-party conference with the former user connection. Thereupon,
MSC A sends to MSC B in a Continue the Return Result (Last) component for the
MAP procedure "Prepare Subsequent Handover". Here, MSC A transmits to MSC B
the BSSMAP message "Handover Request Acknowledge" as received from MSC C.
MSC B forwards the air interface message "Handover Command" to the (old) Base
Station where it is radiated. The Mobile Station is requested to switch to the new cell
and to the new channel (in the area of MSC C). As soon as the Mobile Station has
found contact there, MSC C sends to MSC A the Invoke for "Process Access
Signaling" (with "Handover Detected"). When the new Base Station has sent
"Handover Complete", MSC C relays this BSSMAP message to MSC A with an
Invoke for the MAP operation "Send End Signal".
Now, MSC A clears down the three-party conference and releases the user
connection to MSC B. Afterwards, MSC A releases the transaction to MSC B with an
End containing the Return Result (Last) for the operation "Send End Signal".
Now, MSC B, in its turn, releases the user channel to the Base Station and requests
the Base Station to release the former channel of the air interface.
36 TM3101EU01TM_0001
E
MSC MSC MSC
C A B
Continue
Invoke (Prepare Subsequent Handover)

Begin (Target cell, Target MSC number,
Invoke BSSMAP-mess. „HO Request“)
(Prep. HO)
Continue
RRLast
(Prep. HO)
Call Setup,
to MSC B,
3-Conf. Continue
RRKast (Prepare Subsequent Handover)

(BSSMAP-message HO Command
„HO Request Acknowledge“)
Continue
Invoke
(Process
Access
Sign.)
Continue
Invoke
(Send End
Sign.)
End
3-Conf.
Release
End
to MS´C B
Release
RRLast (Send End Signal)
to Base
Station
Fig. 15 Subsequent Handover MSC B ® MSC C
TM3101EU01TM_0001
37
The case can happen, of course, that a subsequent Handover leads back into the
area of the original MSC. The sequence begins as in the former case. Again, the
Base Station recognizes the necessity of a Handover to another radio cell, and MSC
B (= the MSC in whose area the Mobile Station roams) finds out that the target cell
does not belong to the own area. Therefore, MSC B sends to MSC A in a Continue
the Invoke for the MAP procedure "Prepare Subsequent Handover" and informs
MSC A about the identity of the new cell as well as about the number (=Global Title)
of the new MSC, and the BSSMAP-message "Handover Request".
Now, MSC A recognizes - unlike the former case - that the target cell lies in the own
area. Thus, no communication with a third MSC is required, but MSC A directly
transmits "Handover Request" to the Base Station, which is responsible for the new
cell. (Before so doing, MSC A selects a user channel to this Base Station and
includes the CIC into "Handover Request".) The Base Station selects an air interface
channel and composes the air interface message "Handover Command" which it
communicates to MSC A in the BSSMAP message "Handover Request
Acknowledge".
No Handover Number is required; therefore, the VLR is not involved. Instead, MSC A
switches the user channel to the Base Station to a three-party conference with the
former user connection. Now, MSC A sends to MSC B in a Continue the Return
Result (Last) for the MAP procedure "Prepare Subsequent Handover". In the
component, MSC A transmits to MSC B the BSSMAP message "Handover Request
Acknowledge" including the air interface message "Handover Command" as
composed by the Base Station.
Next, MSC B has "Handover Command" radiated by its Base Station. The Mobile
Station is requested to switch to the new cell and to the new channel. When the
Mobile Station registers there, the MSC A is informed by its Base Station with
"Handover Detect" and later with "Handover Complete".
The further processing is as with a Handover to a third MSC: MSC A clears down the
three-party conference and releases the user connection to MSC B. Next, MSC A
also releases the transaction to MSC B with an End containing the Return Result
(Last) for the operation "Send End Signal".
Now, an MSC B release, in its turn, the user channel to the Base Station and
requests the Base Station to release the old air interface channel.
Again, the application content is "Handover Control Context - v2".
38 TM3101EU01TM_0001
E
MSC MSC
A C
Continue
Invoke (Prepare Subsequent Handover)

HO Request (Target cell, Target MSC number,
BSSMAP-mess. „HO Request“)
HO Request
Acknowledge
3-Conf.
Continue
RRLast (Prepare Subsequent Handover)

(BSSMAP-message HO Command
„HO Request Ackowledge“)
HO Detect
HO Complete
End
3-Conf.
Release
to MSC C End
RRLast (Send End Stgnal)

Release
to Base
Station
Fig. 16 Subsequent Handover MSC B (MSC C) ® MSC A
TM3101EU01TM_0001
39
The Mobile Station changes with a Handover its RR connection only; MM and CM
connections (between Mobile Station and MSC) depending on it are not affected.
With RR connections, the Base Station is the partner of the Mobile Station, with MM
and CM connections, however, it is the MSC. With a Handover, MSC B sets up an
SCCP connection to the new BSC but does not evaluate any DTAP message
received over this SCCP connection; rather, DTAP messages are forwarded to MSC
A without any modification. For this, the MAP operation "Process Access Signaling"
exists whose Invoke is sent by MSC B in a Continue to MSC A. It contains the
received DTAP message. This MAP operation belongs to class 4; thus, there is no
acknowledgment to MSC B.
Vice-versa, if MSC A wants to send an MM or CM message to a Mobile Station which
has changed by Handover into the area of MSC B, it sends the DTAP data to MSC B
in an Invoke component for the operation "Forward Access Signaling"; the
component is contained in a Continue message. The MSC B forwards these DTAP
data over the existing SCCP connection to the BSC whence they are transmitted to
the Mobile Station. Again, the operation "Forward Access Signaling" belongs to class
4; thus, there is no reply from MSC B.
With each subsequent Handover within MSC B, MSC B sets up an SCCP connection
to the new BSC (and releases the SCCP connection to the former BSC) so that the
described proceedings for CM and MM messages are still operable.
Finally, lets consider the case of the call clear down of a Mobile Station which has set
up its call in the area of MSC A but which has changed later into the area of MSC B.
Whether the call clear down is initiated by the Mobile Station itself or by the partner
side: at any rate, the Mobile Station and the MSC exchange messages like
"Disconnect", "Release" and "Release Complete" in the DTAP. As discussed right
now, these messages are sent from the Mobile Station to MSC A and vice-versa;
MSC B just forwards the data transparently.
As soon as this message exchange with the Mobile Station is terminated, MSC A
releases the user connection with MSC B and clears down the transaction to MSC B
with an End containing the Return Result (Last) for the MAP operation "Send End
Signal". Now, MSC B releases the SCCP connection and the user connection to the
Base Station. This being done, all user connections and all transactions are cleared
down, and all MAP procedures are acknowledged - as far as required. Thus, all
physical and logical resources are idle again.
The application context is "Handover Control Context - v2" for everything.
40 TM3101EU01TM_0001
MSC MSC
A B
Continue DTAP
Invoke (Forward Access Signaling)

(DTAP-message)
Continue DTAP
Invoke (Process Access Signaling)

(DTAP-message)
Fig. 17 Exchange of MM and CM Signaling between MSC A and Mobile Station
E
MSC MSC
A B
Release
to MSC B
End
RRLast (Send End Signal) Release

to Base
Station
Fig. 18 Call clear down after Handover
TM3101EU01TM_0001
41
The last MAP operation we discuss concerns the check of the IMEI. This is the only
MAP operation, which involves the F interface.
The IMEI Check can be activated project and installation specifically in the MSC. If
this is the case, the MSC interrogates during the call set up the IMEI of the called or
calling equipment (BSSMAP procedure identification). Thereupon, the MSC sets up a
transaction at the F-interface to the responsible EIR with a Begin containing the
Invoke for the MAP operation "Check IMEI"; the IMEI is included. The EIR checks
the IMEI and answers with the Return Result (Last) for this MAP operation in an
End message. Here, the EIR informs the MSC whether the equipment was found on
the white, gray or black list.
42 TM3101EU01TM_0001
MSC EIR
Begin
Invoke (Check IMEI) (IMEI)
Continue
RRLast (Check IMEI) (white/grey/black list)
Fig. 19 IMEI Check
TM3101EU01TM_0001
43
44 TM3101EU01TM_0001
3 Formatting Rules of TCAP and MAP
TM3101EU01TM_0001
45
The formatting rules for TCAP and MAP correspond to the standard of the Abstract
Syntax Notation 1 (ASN.1) as defined in the CCITT / ITU recommendations X.208
and X.209. In this standard, the data to be transmitted consist of elements whose
layout is illustrated in Fig. 20. Such an element comprises
l a Tag in the length of one or several byte(s). The tag does not reflect the meaning
of the element but its syntactical structure. Thus, the tag should not be compared
with an identifier as it appeared in the formatting rules described thus far; rather,
the tag corresponds to an indication of the data type which is known from higher
programming languages. Only if two elements of the same data type must be
distinguished from each other (e.g. two optional parameters of the same
syntactical structure), the tag indicates which element is meant.
l a Length indicator comprising one or several byte(s).
l as many bytes of Contents as indicated by the length indicator.
The contents may consist, in their turn, of one or several element(s) with tag, length
indicator and contents; in this case, we speak of a Constructor element. The
members of a constructor element can be constructor elements again, etc.; the depth
of interlocking is not restricted. If an element is not a constructor element, i.e. if its
contents do not consist of other elements, we speak of a Primitive element.
46 TM3101EU01TM_0001
Tag Tag
Length Length Tag
Contents Length
Contents Contents
Primitive Constructor
Fig. 20 Elements of ASN.1 (CCITT / ITU X.209)
TM3101EU01TM_0001
47
The entire TCAP part of a message (i.e. the contents of the SCCP parameter "Data",
cf. Fig. 1) is one element of this sort, obviously a constructor. The tag indicates the
message type (that is, Begin, Continue, End or Abort). The length indicator for the
entire TCAP message ensues. The contents of the element consist, in their turn, of
several elements (with tag, length indicator and contents), e.g. the transaction
identities. The penultimate element is the dialogue portion, and the last element is the
component portion; both are marked as such by their tags. Again, these elements
have a length indicator and contents.
The dialogue portion is a constructor element. For the sake of simplicity, we shall not
discuss in this training documentation the structure of the dialogue portion, which
contains many fields not relevant for a GSM-PLMN.
The component portion is a constructor element, too. Its contents consist of zero, one
or several component(s). Each component is an element in the contents of the
component portion.
Each component is a constructor element. Its tag indicates which type of component
it is (Invoke, Return Result (Last), Return Error or Reject). The contents of a
component consist of elements, which can be primitive or constructor. We mention
l the invoke identifier, possibly the linked identifier, too
l the (requested or acknowledged) MAP operation
l the delivered parameters, depending on the operation (e.g. IMSI, service data,
MSISDN etc.).
The ITU recommendation Q.773 defines for each message type and for each
component type which elements are mandatory or optional in the contents. Here, the
possible refusal causes of the Reject are declared, too. The GSM guideline 09.02,
however, defines the possible MAP application contexts and MAP operations and
describes which parameters are mandatory or optional for a given MAP operation in
Invoke, Return Result (Last) and Return Error.
48 TM3101EU01TM_0001
Tag = Message Type
Length
Transaction
Element of the transaction portion Portion
( e.g. transaction identity)
Tag = Dialogue Portion
Length Dialogue
Portion
Elements of the Dialogue Portion
Tag = Component Portion
Length
Tag = Component Type
Length
Component
Element of the Component
Portion
(e.g. invoke identifier, parameter
Component
Fig. 21 Layout of the TCAP according to ASN.1 (CCITT/ITU Q.773)
TM3101EU01TM_0001
49
The coding rules for the tag are given in Fig. 22. As you see, the first two bits indicate
the class of the tag. There are four tag classes defined:
l universal (code = 00): data types for all applications. These data types are defined
in the CCITT recommendation X.209; in this training documentation, they are
listed in fig. 24.
l application specific (code = 01): with GSM, this class applies for the TCAP tags
(e.g. the message type) as they appear in the CCITT recommendation Q.773.
l context specific (code = 10): these tags have a meaning only at a given position
within a given constructor element (e.g. within a given TCAP message type, a
component type, a MAP operation).
l private (code = 11): not used with a GSM-PLMN.
After the class, a bit for the determination of the form ensues, i.e. for the distinction
between primitive (P; code = 0) and constructor (C; code = 1).
Their now follows the tag value. If the value is less than 31, it is given in the 5 bits to
follow; thus, the tag as a whole has a length of one byte. If, however, the value is 31
or more, the five least significant bits of the first byte are set to 11111 as an escape
code. In this case, the tag value extends over the next bytes, but the most significant
bit of each byte does not count. Rather, the most significant bit indicates whether the
tag is completed with this byte (0) or extends to the following byte (1).
In this manner, arbitrarily large tag values can be coded.
50 TM3101EU01TM_0001
Value 30:
Class PC Value =/ 11111
Value 31:
Class PC 1 1 1 1 1
1
= Value
Class Form
Class Meaning PC Meaning

00 universal (X.209) 0 Primitive
01 application specific 1 Constructor
10 context specific
11 private
Fig. 22 Coding of the Tag (CCITT / ITU X.209)
TM3101EU01TM_0001
51
The coding of the length indicator is illustrated in Fig. 23. Mostly, the indicator does
not exceed the value 127; in this case, one byte is sufficient whose most significant
bit is set to 0 as a mark.
If the contents comprise 128 bytes or more, the length indicator must extend over
several bytes. In this case, the most significant bit of the first byte is set to 1 as a
mark, and the remaining 7 bits indicate how many length indicator bytes are going to
follow ("length indicator of the length indicator"). In the following bytes, the length
indicator value is coded. As this "length indicator of the length indicator" has a length
of 7 bits, its maximal value is 127. Therefore, the length indicator itself comprises up
to 127 bytes = 8*127 bits. Thus, the maximal value of length indicator itself is 28*127-
1, and the contents can comprise up to 28*127-1 bytes. This is much, much more
than the estimated amount of atoms in the universe, and the transmission of such an
element with 64 kbit/s would take much, much longer than the expected remaining
lifetime of the solar system. In other words: it will never happen that an element is too
long for its length indicator to be coded by this method.
Of course, the first byte of the length indicator cannot have the binary value 1000
0000, for this would mean that the length indicator value extends over the following 0
bytes, which is absurd.
Finally, with constructor elements, an indefinite length indicator is possible, namely if
the sender at the time of the length indicator generation cannot predict the total
length. The indefinite length indicator is always one byte long and has a binary value
of 1000 0000; this, as was explained right now, can never be the value of the first
byte of a definite length indicator, so that errors are excluded. Now there follow the
elements the constructor consists of (with their own tag, length indicator and
contents). At the end, a pseudo-element follows with the tag B’0000 0000 (universal
tag 0: undefined acc. to Fig. 24) and the length indicator 0000 0000 (length 0 byte) as
a mark of the end of the constructor element.
It is quite clear that no general rules can be given here for the coding of the element
contents, for this depends on the element type (i.e. on the tag).
52 TM3101EU01TM_0001
Value 127:
0 Value
Value 127:
1 length of the length indicator = 0000000
Value
Indefinite
value: 1 0 0 0 0 0 0 0
(Constructor
only)
Element
Element
Tag 0 0 0 0 0 0 0 End of
Constructor
Length 0 0 0 0 0 0 0
Fig. 23 Coding of the Length Indicator (CCITT / ITU X.209)
TM3101EU01TM_0001
53
Fig. 24 shows the universal tags. Not all of them are relevant for a GSM-PLMN. The
following tags apply for TCAP and MAP:
l Boolean (1): CONTENTS "TRUE" (1) OR "FALSE" (0); LENGTH 1 BYTE
l INTEGER (2): an integer number; the first bit indicates the sign
l BITSTRING (3) occurs in the dialogue portion
l OCTETSTRING (4): a string of bytes which are evaluated individually
Examples: IMSI, MSISDN
l NULL (5): a dummy; length 0 byte
l OBJECT IDENTIFIER (6) occurs in the dialogue portion
l EXTERNAL (8) occurs in the dialogue portion
l ENUMERATED (10): a list of possibilities, represented symbolically by numbers
Example (from the IMEI check, see Fig. 19):
Equipment Status ::= ENUMERATED (whiteListed (0),
greyListed (1),
blackListed (2))
l SEQUENCE (16): a sequence of elements in pre-defined order
Example: SEQUENCE (IMSI OCTETSTRING,
TMSI OCTETSTRING)
l SEQUENCE OF (16): a sequence of an amount of elements of the same type.
Example: the Component Portion is a SEQUENCE OF components.
Of these tags, EXTERNAL (8) and SEQUENCE / SEQUENCE OF (16) are

constructor; the others are primitive.
In a SEQUENCE (16), some of the members can be marked with the addendum
OPTIONAL; these parts then may be omitted. Here, it can happen that context
specific tags must be used to ensure uniqueness (see Fig. 27).
With a CHOICE type, two or more possibilities stand for selection which are
distinguished by their tags. Again, context specific tags must be used occasionally to
obtain uniqueness (see Fig. 27).
Example: CHOICE (LAI OCTETSTRING,
NULL)
It is recognized from the tag whether a location area identity is transmitted or not
(B'0000 0100 = OCTETSTRING = LAI present, B'0000 0101 = NULL = no LAI).
54 TM3101EU01TM_0001
Value Meaning
1 BOOLEAN
2 INTEGER
3 BITSTRING
4 OCTETSTRING
5 NULL
6 OBJECT IDENTIFIER
7 OBJECT DESCRIPTOR
8 EXTERNAL
9 REAL
10 ENUMERATED
16 SEQUENCE, SEQUENCE-OF
17 SET, SET-OF
18-22, 25-27 CHARACTER STRING
23-24 TIME
Fig. 24 Universal Tags (CCITT / ITU X.208 and X.209)
TM3101EU01TM_0001
55
In the TCAP, both application and context specific tags are used. The message types
are application specific tags; the values are listed in Fig. 25. As you see (cf. Fig. 22),
all of them are constructor tags (B'011... = application specific, constructor) which is
obvious according to Fig. 21.
Further application specific tags concern the transaction identities; the elements are
primitive. The length may be 1 to 4; thus, it is not fixed - unlike the local references of
the SCCP. In Abort messages, the abort cause is given and has an application
specific tag, and it is distinguished as to whether the abort was caused by the lower
layers (provider, i.e. transaction portion, SCCP or MTP) or by the upper layers (user,
i.e. MAP). The elements are primitive. Finally, there is an application specific
constructor tag for the dialogue portion as a whole, and another one for the
component portion (cf. Fig. 21).
Within the component portion, context specific tags are defined, e.g. the component
types (B'011... = context specific, constructor). The "linked identifier" in the Invoke
has a context specific primitive tag whilst the invoke identifier has the universal tag
B'0000 0010 = H'02 = Integer.
Further context specific primitive tags exist in Reject components only. They indicate
whether the reject was due to a general problem (e.g. a component of an unknown
type was received) or whether an Invoke, a Return Result or a Return Error was
pinpointed as erroneous.
56 TM3101EU01TM_0001
Value Tag Coding Meaning
2 B’0110 0010 = H’62 Begin
4 B’0110 0100 = H’64 End
5 B’0110 0101 = H’65 Continue
7 B’0110 0111 = H’67 Abort
8 B’0100 1000 = H’48 Orig. Transaction ld.
9 B’0100 1001 = H’49 Destin. Transaction ld.
10 B’0100 1010 = H’4A Abort Cause (Provider)
11 B’0100 1011 = H’4B Abort Cause (User)
11 B'0110 1011 = H'6B Dialogue Portion
12 B’0110 1100 = H’6C Component Portion
Fig. 25 Application-specific Tags of the TCAP
Value Tag Coding Meaning
1 B’1010 0001 = H’A1 Invoke
2 B’1010 0010 = H’A2 Return Result (Last)
3 B’1010 0011 = H’A3 Return Error
4 B’1010 0100 = H’A4 Reject
0 B’1000 0000 = H’80 Linked Identifier
0 B’1000 0000 = H’80 General Problem
1 B’1000 0001 = H’81 Invoke Problem
2 B’1000 0010 = H’82 Return Result Problem
3 B’1000 0011 = H’83 Return Error Problem
Fig. 26 Context specific Tags of the Component Portion
TM3101EU01TM_0001
57
Frequently, the tags described hitherto are insufficient for a clear identification.
1st example: SEQUENCE (IMSI OCTETSTRING,
TMSI OCTETSTRING OPTIONAL,
LAI OCTETSTRING OPTIONAL).
On reception of two elements with the tag "OCTETSTRING", the receiver cannot
identify whether it is IMSI and TMSI or IMSI and LAI.
2nd example: CHOICE (IMSI OCTETSTRING,
MSISDN OCTETSTRING).
The tag "OCTETSTRING" does not tell whether it is the IMSI or the MSISDN.
In such cases, so-called Tagged Types are introduced, i.e. the elements get a new
(as a rule context specific) tag to ensure uniqueness. Here, the tag really assumes
the role of an identifier and not just of a type indication. In the definition, the new tag
is given in square brackets.
There are two kinds of Tagged Types: explicit and implicit. With the implicit
representation (keyword IMPLICIT), the new tag replaces the old one completely.
The form of the new tag is constructor or primitive, depending on whether the old tag
was constructor or primitive.
With this, the above examples are modified as follows:
1st example: SEQUENCE (IMSI OCTETSTRING,
TMSI [1] IMPLICIT OCTETSTRING OPTIONAL,
LAI [2] IMPLICIT OCTETSTRING OPTIONAL).
Still, the IMSI has the universal primitive tag 4, but the TMSI gets the context specific
tag 1 and the LAI the context specific tag 2. Both tags have the form primitive
because OCTETSTRING is primitive.
2nd example: CHOICE (IMSI [1] IMPLICIT OCTETSTRING,
MSISDN [2] IMPLICIT OCTETSTRING).
The receiver recognizes from the context specific tag 1 or 2 (primitive) whether he
has received an IMSI or an MSISDN.
With the explicit representation (keyword EXPLICIT, or no keyword at all [default]),
the new tag is added to the old one, and the new type surrounds the old one as a
frame. The new tag has the form constructor, and the only member of the constructor
element is the element to be represented with its (former) tag.
Example: IMSI [1] OCTETSTRING (or IMSI [1] EXPLICIT OCTETSTRING).
A constructor element with the context specific tag 1 whose only member is a
primitive element with the universal tag 4 (= OCTETSTRING).
58 TM3101EU01TM_0001
[1] INTEGER
Context, Constr., 1
1 0 1 0 0 0 0 1
Length 3 0 0 0 0 0 0 1 1
Universal, Prim., 2 (= INTEGER) 0 0 0 0 0 0 1 0
Length 1 0 0 0 0 0 0 0 1
Integer Value
[1] IMPLICIT
INTEGER
Context, Prim., 1 1 0 0 0 0 0 0 1
Length 1 0 0 0 0 0 0 0 1
Integer Value
[1] SEQUENCE
Context, Constr., 1 1 0 1 0 0 0 0 1
Length 17 0 0 0 1 0 0 0 1
Universal, Constr., 16 ( = Sequence) 0 0 1 1 0 0 0 0
Length 15 0 0 0 0 1 1 1 1
15 bytes contents
[1] IMPLICIT
SEQUENCE
Context, Constr., 1 1 0 1 0 0 0 0 1
Length 15 0 0 0 0 1 1 1 1
15 bytes contents
Fig. 27 Tagged Types - Context specific
TM3101EU01TM_0001
59
Each component of a TCAP message is related to an operation of the TCAP user,

i.e. with GSM to a MAP operation. It must be indicated in the Invoke which operation
it is; in the Return Result (Last), this information can be repeated although it could
be derived from the invoke identifier, too, for the identifier was assigned to a fixed
operation by the preceding Invoke. Thus, the type of operation is mandatory in the
constructor Invoke and optional in the constructor Return Result (Last).
The type of operation is always coded as a number; thus, it has the tag B'0000 0010
(universal primitive 2 = Integer). The user (i.e. with GSM the MAP) defines which
types of operation exist and how they are coded. Fig. 28 displays some MAP
operation types together with their numerical values; the list is confined to the
operations discussed in section 2.
In the GSM guideline 09.02, a complete list of all MAP operations with their values is
found. There are 46 different operations, and the values range up to 69. Thus, for the
MAP operation code, a length of 1 byte is sufficient.
60 TM3101EU01TM_0001
Operation Value
Cancel Location 3
Check IMEI 43
Forward Access Signalling 34
Insert Subscriber Data 7
Prepare Handover 68
Prepare Subsequent Handover 69
Process Access Signalling 33
Provide Roaming Number 4
Purge MS 67
Reset 37
Restore Data 57
Send Authentication Info 56
Send End Signal 29
Send Identification 9
Send Routing Info 22
Update Location 2
Fig. 28 MAP operations (GSM 09.02 - excerpt)
TM3101EU01TM_0001
61
As an example, we study the MAP operation "Update Location" whose Invoke is sent
from the VLR to the HLR when a mobile station registers in a new MSC area (cf. Fig.
6). Fig. 29 shows the excerpts from the GSM guideline 09.02, which are relevant for
this MAP operation.
UpdateLocation is defined as an OPERATION. The keyword ARGUMENT is related
to the Invoke of this operation and indicates what must be transmitted besides the
operation code. This is always one ASN.1 element; if several data must be sent, the
element is a SEQUENCE consisting of mandatory and optional members. Each
member has a name and a type (e.g. name = vlrNumber, type = ISDN-
AddressString); if it is a Tagged Type, the tag is given in square brackets (e.g. for the
LMSI). If the keyword ARGUMENT is amiss in the definition of an OPERATION, it
means that, in the Invoke, nothing must be transmitted after the operation code.
RESULT is related to the Return Result (Last) and indicates what must be
transmitted in this component beyond the invoke identifier and (possibly) the
operation code. Again, this is one ASN.1-Element, maybe a Sequence. If the
keyword RESULT is written alone, no further data must be transmitted in the Return
Result (Last); in this case the operation code is omitted, too. If, however, further data
are required in the Return Result (Last), the operation code will be included in this
component, too.
ERRORS is related to the Return Error and indicates the possible error codes of this
component. The error codes are - similar to the operation codes - integer numbers
with the tag B'0000 0010 (Universal Primitive 2 = INTEGER) and the length 1.
The class a given operation belongs to can be deducted from the keywords RESULT
and ERRORS. If both RESULT and ERRORS are present, there are both positive
and negative acknowledgments, and the operation belongs to class 1. If there is only
ERRORS but no RESULT, there are no positive acknowledgments and it is an
operation of class 2. If RESULT is present but ERRORS is not, the class is 3. If both
RESULT and ERRORS are amiss, we have an operation of class 4.
62 TM3101EU01TM_0001
Update Location :: = OPERATION

ARGUMENT
updateLocationArg UpdateLocationArg
RESULT
updateLocationRes UpdateLocationRes
ERRORS {
SystemFailure,
DataMissing
- DataMissing must not be used in version 1
UnexpectedDataValue,
UnknownSubscriber,
RoamingNotAllowed}
UpdateLocationArg :: = SEQUENCE {
imsi IMSI,
locationInfo LocationInfo,
vlrNumber ISDN-AddressString,
Imsi [10] IMPLICIT LMSI OPTIONAL,
. . .}
UpdateLocationRes ::= CHOICE {
{hlr-Number ISDN-AddressString,
-hlr-Number must not be used in version greater 1
extensibleUpdateLocationRes ExtensibleUpdateLocationRes}
- extensible UpdateLocationRes must not be used in version 1
SystemFailure ::= localValue 34

DataMissing ::= localValue 35
UnexpectedDataValue ::= localValue 36
UnknownSubscriber ::= localValue 1
RoamingNotAllowed ::= localValue 8
Fig. 29 Example: Update Location VLR ® HLR (GSM 09.02)
TM3101EU01TM_0001
63
At another place of the guideline 09.02, the definition of the data types in use is found
with an reduction to the standard types of Fig. 24. According to Fig. 29, the type
"TBCD-String" is defined as an OCTETSTRING (universal, tag value = 4) whose
bytes consist of decimal digits coded in half bytes. The explanations say that the
distribution of the digits to the bytes is done as follows:
1st byte: less significant 4 bits = first digit, more significant 4 bits = second digit
2nd byte: less significant 4 bits = third digit, more significant 4 bits = fourth digit
and so on. If the amount of digits is odd, the more significant four bits of the last byte
are filled with 1111.
The type TBCD-STRING is applied to the IMSI and the length lies between 3 and 8
(i.e. 5 to 16 digits). The digits comprise MCC, MNC and MSIN.
A second application of the OCTETSTRING is the type "AddressString" with a length
between 1 and 20. The explanations say that the first byte gives information about
the type of the transmitted number. The most significant bit is 1; the three following
bits contain the Nature of Address as follows:
Nature of Address Value
international 001
national 010
network specific 011
dedicated PAD access 100
The four least significant bits contain the numbering plan:

Numbering Plan Value
ISDN/Telephony Numbering Plan (E.164) 0001
Data Numbering Plan (X.121) 0011
Telex Numbering Plan (F.69) 0100
National Numbering Plan 1000
Private Numbering Plan 1001
The subsequent bytes contain the digits in the same coding as with a TBCD-
STRING. Since the length is at most 20 bytes, and since one byte is spent for the
Nature of Address and for the Numbering Plan, 19 bytes remain for the digits so that
up to 38 digits can be transmitted.
A special case of the type "AddressString" is the "ISDN-AddressString"; here, the
length is restricted to 9 (= at most 16 digits). This type applies for the VLR address (in
the Invoke) and for the HLR address (in the Return Result (Last)). The Location
Info is another such ISDN-AddressString but as a Tagged Type with the context
specific tag 0 or 1, depending on whether it is a roaming number or an MSC number.
64 TM3101EU01TM_0001
IMSI :: = TBCD-STRING (SIZE (3..8))

-- digits of MCC, MNC, MSIN concatenated in this order
TBCD-STRING ::= OCTETSTRING

-- This Type (Telephony Binary Coded Decimal String) is used to
-- represent several digits from 0 through 9, *, #, a, b, c, two di gits
-- per octet, each digit encoded 0000 to 1001 (0 to 9), 1010 (*),
-- 1011 (#), 1100 (a), 1101 (b), or 1110 (c); 1111 used as filler when
-- there is an odd number of digits.
LocationInfo :: = CHOICE {
roamingNumber [0] IMPLICIT ISDN-AddressString,
-- roamingNumber must not be used in version greater 1
mscNumber [1] IMPLICIT ISDN-AddressString}
ISDN-AddressString :: = AddressString (SIZE (1..maxISDN-AddressLength))
maxISDN-AddressLength INTEGER ::=9
AddressString :: = OCTETSTRING (SIZE (1..maxAddressLength))

-- this type is used to represent a number for addressing
-- purposes. It is composed of
-- a) one octet for nature of address and numbering plan indicator
-- b) digits of an address encoded as TBCD-String.
maxAddressLength INTEGER ::= 20
LMSI :: = OCTETSTRING (SIZE (4))
ExtensibleLocationUpdateRes ::= SEQUENCE {

hlr-Number ISDN-AddressString
...}
Fig. 30 MAP data types necessary for Update Location
TM3101EU01TM_0001
65
Finally, the LMSI is an OCTETSTRING with the length 4. Because it appears as an

optional member in the Invoke for "Update Location" and confusions with other
OCTETSTRINGs must be avoided, the LMSI is a Tagged Type with the context
specific tag 10.
At still another place of the guideline 09.02, the error codes for the possible negative
cases are listed. Fig. 29 shows the values relevant for "Update Location" . The values
are local, i.e. the tag is INTEGER.
Lets consider now a special "Update Location". The Invoke is sent from the VLR to
the HLR, and its argument is a SEQUENCE according to Fig. 29; thus, it has the
universal constructor tag 16. The total length is given (in the example) with 30 bytes.
An alternative is the length indication B'1000 0000 (= indefinite); in this case, after the
last element (= after the LMSI), a pseudo element with the tag B'0000 0000 and the
length 0 would have to be added (cf. Fig. 23).
According to Fig. 30, the IMSI ensues. Indeed, the next element has the universal
primitive tag 4; thus, it is an OCTETSTRING. The length is 8 and the digits (as a
TBCD-String) are 262017708154711, which is combined from the MCC (262), the
MNC (01) and the MSIN (7708154711). The last half byte is filled with B'1111.
The example illustrates that the tag only indicates the type (in our case:
OCTETSTRING) but not the meaning. The facts that the OCTETSTRING is the IMSI,
must be read as a TBCD-String and comprises MCC, MNC and MSIN results from
the study of the guideline (here: GSM 09.02) only.
As it can be seen from Fig. 30, the Location Info ensues. The Location Info is a
CHOICE type; the context specific primitive tag 1 reveals that it is the MSC number.
The length is 5. The following bytes identify the number as an international number
according to the ISDN Number Plan E.163 / 164. The digits are 35112345 (this is a
number in Portugal because of the country code 351).
66 TM3101EU01TM_0001
Universal, Constr., 16 (= Sequence) 0 0 1 1 0 0 0 0
Length 30 0 0 0 1 1 1 1 0
Universal, Prim., 4 (=OCTETSTRING) 0 0 0 0 0 1 0 0
IMSI Length 8 0 0 0 0 1 0 0 0
MCC 262 0 1 1 0 0 0 1 0
MNC 01 0 0 0 0 0 0 1 0
MSIN 7708154711 0 1 1 1 0 0 0 1
0 0 0 0 0 1 1 1
0 0 0 1 1 0 0 0
0 1 0 0 0 1 0 1
0 0 0 1 0 1 1 1
Filler 1 1 1 1 0 0 0 1
Context, Prim., 1 (= MSC Number) 1 0 0 0 0 0 0 1
Length 5 0 0 0 0 0 1 0 1
International; ISDN Number Plan 1 0 0 1 0 0 0 1
Number 35112345 0 1 0 1 0 0 1 1
Location Info 0 0 0 1 0 0 0 1
0 0 1 1 0 0 1 0
Continuation see fig. 32 0 1 0 1 0 1 0 0
Fig. 31 Argument of the Invoke of "Update Location" - Example
TM3101EU01TM_0001
67
Next, the VLR number (an ISDN-Address-String) ensues according to Fig. 30. The
tag is universal, primitive, and its value is 4; thus, it is again an OCTETSTRING. The
length is 5 bytes. Once again, it is an international ISDN number. This time, the digit
sequence is 35112345 (Portugal again).
The last member of the Sequence is the optional member "LMSI". As a mark for its
presence, we find the context specific primitive tag 10. The length is 4. In the
subsequent 4 bytes, the value of the LMSI is contained.
With this, the SEQUENCE is terminated. It can be seen that the four members (IMSI,
Location Info, VLR-Address and LMSI) have a total length (including tags and length
indicators) of 30 bytes, as was indicated initially.
68 TM3101EU01TM_0001
Universal, Prim., 4 (=OCTETSTRING) 0 0 0 0 0 1 0 0
Lenght 5 0 0 0 0 0 1 0 1
International; ISDN Number Plan 1 0 0 1 0 0 0 1
VLR Number Number 35112345 0 1 0 1 0 0 1 1
0 0 0 1 0 0 0 1
0 0 1 1 0 0 1 0
0 1 0 1 0 1 0 0
Context, Prim., 1 (= LMSI) 1 0 0 0 1 0 1 0
Length 4 0 0 0 0 0 1 0 0
LMSI
Value
of the
LMSI
Fig. 32 Argument of the Invoke of "Update Location" - Continuation of the example
TM3101EU01TM_0001
69
The entire Invoke component for "Update Location" is displayed on Fig. 33; the
layout meets the demands of the ITU recommendation Q.773. The component has a
context specific constructor tag according Fig. 26, which marks it as an Invoke. In
our example (Fig. 31and Fig. 32), a component length of 38 bytes results. Again, it is
possible to use an indefinite length indicator.
The component is constructed like a Sequence and has the following members:
l Mandatory member Invoke Identifier with universal primitive tag 2 (= INTEGER);
length 1 byte
l Optional member Linked Identifier with context specific primitive tag 0; length 1
byte
l Mandatory member Operation Code with universal primitive tag 2 (= INTEGER);
length 1 byte
l Optional member Argument; Tag according to the parameter type (here:
SEQUENCE).
In Fig. 33, after the length indicator, the invoke identifier of one byte length can be
seen. No linked identifier is required; thus, the following element has not the context
specific tag 0 but the universal primitive tag 2 (INTEGER, here: Operation Code). The
value is 2, which identifies the operation "Update Location" (see Fig. 28).
Finally, the argument according to Fig. 31and Fig. 32 ensues with its tag (universal,
constructor, 16, i.e. SEQUENCE), its length indicator (30) and its members.
70 TM3101EU01TM_0001
Context, Constr., 1 (= Invoke) 1 0 1 0 0 0 0 1
Lenght 38 0 0 1 0 0 1 1 0
Invoke Identifier Length 1 0 0 0 0 0 0 0 1
Value of the invoke identifier
Operation Code Length 1 0 0 0 0 0 0 0 1
Value 2 (= Update Location) 0 0 0 0 0 0 1 0
Argument Argument: tag, length

indicator and 30 bytes
contents
(see fig. 32)
Fig. 33 Complete Invoke component for "Update Location" - Example
TM3101EU01TM_0001
71
Let us consider, at long last, the entire message Begin from the HLR to the VLR
containing the Invoke for "Update Location". The tag, which characterizes the
message as a Begin is an application specific one; its value corresponds to Fig. 25.
This time, for the sake of variation, we employ a representation with indefinite length,
i.e. the length indicator is B'1000 0000.
The Begin is structured like a Sequence, too. It has two members: the mandatory
member Origination Transaction Identity (application specific primitive tag 8, cf. Fig.
25) and the optional member Component Portion (application specific constructor tag
12, cf. Fig. 25).
The transaction identities have a length between 1 and 4 bytes. We take an
origination transaction identity of two bytes.
Their now follows the component portion with a length indicator of 40 bytes (again, an
indefinite length indicator would be possible). The element contains the Invoke
component from Fig. 33 with its tag, its length indicator (38) and its contents.
Finally, the Begin is terminated with "End of Constructor" because an indefinite
length indicator was used.
This Begin message is built as "Data" parameter of 50 bytes total length into an
SCCP message "Unitdata" (UDT).
72 TM3101EU01TM_0001
Application, Constr., 2 (= Begin) 0 1 1 0 0 0 1 0
indefinite length 1 0 0 0 0 0 0 0
Application., 8 (= Orig. Trans. Id.) 0 1 0 0 1 0 0 0
Length 2 0 0 0 0 0 0 1 0
Orig. Trans. Id.

Value of the Origination
Transaction Identity
Application, Constr., 12 (=Comp. Portion) 0 1 1 0 1 1 0 0
Length 40 0 0 1 0 1 0 0 0
Invoke compoenent
Component with tag, length, indicator,
Portion invoke identifier,
operation code
and argument
(see fig. 33)
Universal, Prim., 0 (End of Constructor) 0 0 0 0 0 0 0 0
End of Constructor Length 0 0 0 0 0 0 0 0 0
Fig. 34 Begin message with Invoke component for "Update Location" (Example without Dialogue Portion)
TM3101EU01TM_0001
73
74 TM3101EU01TM_0001
4 Exercise
TM3101EU01TM_0001
75
76 TM3101EU01TM_0001
Exercise
1. What is the difference between transaction identity and invoke identifier?
2. Which transactions need only one transaction identity?
3. Mark which components can exist for the four classes of operation!
class 1 2 3 4
component
Invoke
Return Result (Last)
Return Error
Reject
4. For a mobile station, a Handover from MSC A to MSC B has been executed.
How can MSC A still exchange MM and CM messages with the mobile
station?
TM3101EU01TM_0001
77
5. What is the difference between a constructor element and a primitive

element?
6. A given type gets a new tag as a "Tagged Type" (explicit or implicit). Is the
new type formed in this manner constructor or primitive?
7. To which class do belong the tags

a) of the TCAP messages (Begin, End, Continue, Abort)
b) of the TCAP components (Invoke, Return Result (Last), Return Error,
Reject)?
8. What does it mean if, with the definition of a MAP operation,

a) the keyword ARGUMENT is amiss
b) the keyword RESULT is amiss
c) the keyword ERRORS is amiss?
78 TM3101EU01TM_0001
9. Evaluate the following TCAP message with MAP
65 5F 48 04 A3 20 00 1C 49 04
B7 69 35 0F 6C 51 A1 35 02 01
02 02 01 07 30 2D 30 2B 81 07
91 94 71 92 78 56 34 A6 06 04
01 11 04 01 62 A7 18 A0 16 04
01 2B 30 11 30 0F 83 01 11 85
07 91 94 98 27 42 31 71 86 01
80 A1 18 02 01 03 02 01 07 30
10 30 0E A7 0C A1 0A 04 01 93
30 05 30 03 83 01 62
TM3101EU01TM_0001
79
80 TM3101EU01TM_0001
5 Solution
TM3101EU01TM_0001
81
82 TM3101EU01TM_0001
Solution
1. What is the difference between transaction identity and invoke identifier?
Transaction Identity:
(up to) two per transaction; valid for the whole duration of the
transaction; length 1 to 4 bytes
Invoke Identifier:
one per invoke; valid only for the invoke and its response; length 1 byte
2. Which transactions need only one transaction identity?

Transactions without a Continue message: after Begin, either End
follows at once, or the transaction is released locally.
3. Mark which components can exist for the four classes of operation!
class 1 2 3 4
component
Invoke X X X X
Return Result X X
(Last)
Return Error X X
Reject X X X X
4. For a mobile station, a Handover from MSC A to MSC B has been executed.
How can MSC A still exchange MM and CM messages with the mobile
station?
MSC A sends MM and CM messages with Invoke "Forward Access
Signaling" to MSC B; MSC B forwards the messages to the mobile
station.
MSC B uses Invoke "Process Access Signaling" to forward to MSC A all
MM and CM messages received from the mobile station.
TM3101EU01TM_0001
83
5. What is the difference between a constructor element and a primitive element?

The contents of a constructor consists of complete elements (with tag,
length indicator and contents) whereas the contents of a primitive have
another layout.
6. A given type gets a new tag as a "Tagged Type" (explicit or implicit). Is the
new type formed in this manner constructor or primitive?
Explicit: constructor always
Implicit: depends on whether the original type was constructor or
primitive
7. To which class do belong the tags

a) of the TCAP messages (Begin, End, Continue, Abort)
b) of the TCAP components (Invoke, Return Result (Last), Return Error,
Reject)?
a) application specific
b) context specific
8. What does it mean if, with the definition of a MAP operation,

a) the keyword ARGUMENT is amiss
b) the keyword RESULT is amiss
c) the keyword ERRORS is amiss?
a) In the Invoke, no data beyond the operation code are required
b) The operation belongs to class 2 or 4
c) The operation belongs to class 3 or 4
84 TM3101EU01TM_0001

05 Tm3101eu01tm 0001 Tcap Map

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

05 Tm3101eu01tm 0001 Tcap Map

Hochgeladen von

Copyright:

Verfügbare Formate

TCAP and MAP Siemens

TCAP and MAP

1 TCAP and MAP

SCCP message type UDT

Fig. 1 Layout of TCAP and MAP

A fifth TCAP message type (Unidirectional for the transmission of components

Continue (O-TRID, D-TRID)

Continue (O-TRID, D-TRID)

Continue (O-TRID, D-TRID)

End / Abort (D-TRID)

End / Abort (D-TRID)

End / Abort (D-TRID)

Fig. 2 TCAP Transaction Control

Return Result(Last) (Invoke-Id=1)

Invoke (Invoke-Id=3, Linked-Id=2)

Return Result(Last) (Invoke-Id=3)

Return Error (Invoke-Id=4)

Fig. 3 TCAP operation control

There are four possibilities (classes) to acknowledge operations:

It is not transmitted in the components themselves to which class a given operation

t Acknowledgment (good or bad) t Acknowledgment (bad)

Timeout: negative acknowl.

Fig. 4 Classes of Operation of the TCAP

MSC MSC EIR

Fig. 5 MAP interface

Three SSS subunits are concerned with the location registration:

Fig. 6 Location Registration

The procedure "MS Purging" is invoked either because of administrative actions or

With mobile terminating calls (MTC), however, the interrogation is performed

Next, let us consider two cases of call forwarding.

Fig. 9 Call Forwarding Unconditional

Fig. 10 Call Forwarding on not reachable after IMSI Detach

Fig. 11 Data Restoration VLR

Fig. 12 Data Restoration HLR

Let us consider an example for an Inter-MSC-Handover within a PLMN. The mobile

Accordingly, the proceedings occur at the E-interface between both MSC.

Fig. 14 First Handover MSC A ® MSC B

Invoke (Prepare Subsequent Handover)

RRKast (Prepare Subsequent Handover)

Fig. 15 Subsequent Handover MSC B ® MSC C

Invoke (Prepare Subsequent Handover)

RRLast (Prepare Subsequent Handover)

RRLast (Send End Stgnal)

Fig. 16 Subsequent Handover MSC B (MSC C) ® MSC A

Invoke (Forward Access Signaling)

Invoke (Process Access Signaling)

Fig. 17 Exchange of MM and CM Signaling between MSC A and Mobile Station

RRLast (Send End Signal) Release

Fig. 18 Call clear down after Handover

Invoke (Check IMEI) (IMEI)

RRLast (Check IMEI) (white/grey/black list)

Fig. 19 IMEI Check

3 Formatting Rules of TCAP and MAP

Length Length Tag

Fig. 20 Elements of ASN.1 (CCITT / ITU X.209)

Tag = Message Type

Tag = Dialogue Portion

Tag = Component Portion

Tag = Component Type

Fig. 21 Layout of the TCAP according to ASN.1 (CCITT/ITU Q.773)

Class Meaning PC Meaning

Fig. 22 Coding of the Tag (CCITT / ITU X.209)