TCAP & MAP

TCAP and MAP Siemens

TM3101EU01TM_00011

Contents

1 TCAP and MAP 3

2 Call Sequences 17

3 Formatting Rules of TCAP and MAP 45

4 Exercise 75

5 Solution 81

TCAP and MAP

Siemens TCAP and MAP

TM3101EU01TM_00012


TM3101EU01TM_00013

1 TCAP and MAP


TM3101EU01TM_00014

The SSS subunits (i.e. the Mobile Switching Center MSC, the Visitor LocationRegister VLR, the Home Location Register HLR and the Equipment Identity RegisterEIR - the Authentication Center AC is not considered here) are interconnected invarious ways. Whereas the MSCs are connected with each other via speech circuitsand in parts (Gateway-MSCs) have connections to other networks, there are onlysignaling channels to the registers (HLR, VLR, EIR). The signaling on these channelsemploys the Common Channel Signaling System No. 7 (CCS7) with SignalingConnection Control Part (SCCP). Here, the connectionless SCCP services are usedexclusively (protocol class 0 and 1). As a consequence, all signaling messagestreated in this chapter are contained in the SCCP message UDT (Unitdata). If a UDTcannot be delivered to the receiver, the possibility exist to return it to the sender withUDTS (Unitdata Service). This is a basic SCCP function and will not be discussedhere.

The reason for the confinement to the connectionless SCCP services is that allmessages must be transmitted with a Global Title in order to enable the informationtransfer between different networks (e.g. international). With connection orientedSCCP services, a Global Title translation is possible only during the connection setup; during the existence of the SCCP connection, the messages are transmittedwithout a Global Title and are routed by the Destination Point Code (DPC) to thereceiving exchange.

Nevertheless, even with the signaling between SSS subunits, we cannot helpintroducing signaling connections (logical connections). For example, it can happenthat 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 HLRx and VLR y. In each signaling message, it must become clear to which proceeding itis related. Therefore, signaling connections (transactions) must be set up betweenHLR x and VLR y, and every signaling message is related to one transaction.

Because the SCCP is used connectionless only, the signaling connections arecontrolled by the TCAP (Transaction Capabilities Application Part). The TCAP istransmitted in the SCCP message UDT as contents of the mandatory parameter"Data"; at the interfaces between SSS subunits, no other content of this parameter ispossible.

The TCAP has been specified by CCITT in the recommendations Q.771 to Q.775. Ithas three tasks:

� Transaction control (Set up, clear down and identification of signaling connections)

� Control of dialogues ( = call sequences within a transaction)

� Control of operations within a dialogue.

Accordingly, the TCAP consists of three parts: the Transaction Portion, theDialogue Portion and the Component Portion.


TM3101EU01TM_00015

SCCP message type UDT

Pointer to Data

Length Data

- TCAP message type

- Dialogue PDU

- Application context

- MAP Dialogue PDU

- Transaction Identities

MAP

- Operation Type

- ParameterMAP

Component 1:

- Type of Component

- Invoke Identifier

Component 2:

- Type of Component

- Invoke Identifier

- Operation Type

- ParameterMAP

TCAP

Transaction

portion

Dialoge

portion

(optional)

Component

portion

Fig. 1 Layout of TCAP and MAP


TM3101EU01TM_00016


TM3101EU01TM_00017

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 existingtransaction) and - depending on the message type - one or two transactionidentifier(s). The TCAP transactions contain - similar to the SCCP transactions - twoidentifiers (one for each connection side); they correspond to the local references ofthe SCCP transactions. Whereas the messages for the transaction set up and cleardown need only one transaction identity, both transaction identities are sent with theinformation exchange over an existing transaction.

The next portion is the Dialogue Portion, which is optional. It contains a ProcessData Unit (PDU) for establishment, confirmation and termination of a dialogue withina 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 ofone or several component(s) in which either an operation (i.e. an action by thepartner side) is requested or else a previously received operation request from thepartner side is acknowledged (positively or negatively). As long as a transactionexists, both parties have the right to request operations from the partner side and tohave them acknowledged. Each operation request or acknowledgment comprises acomponent of its own, but one TCAP message can include several components.


TM3101EU01TM_00018

Let us consider now the individual TCAP messages and message sequences. Thereare four TCAP message types:

� Begin for the set up of a signaling connection (transaction)

� End for the regular clear down of a transaction

� Continue for the component transmission over an existing transaction

� Abort for the disruption of a transaction due to irregularities. We distinguishbetween U-Abort (User-Abort, i.e. abort caused by the TCAP user, e.g. due tosupervision time expiry with class 1 operations, or due to illegal operationrequests) and P-Abort (Provider-Abort, i.e. abort caused by the TCAP transactionlayer). The message type, however, is the same.

A fifth TCAP message type (Unidirectional for the transmission of componentswithout 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), whichidentify the transaction in the two affected network nodes. The TRIDs can beunderstood as local addresses used by the network nodes to address the transactionspecific memory area.

The TCAP message Continue contains two transaction identities: one for theorigination (O-TRID) and one for the destination (D-TRID). Of course, the messageBegin only contains the transaction identity of the origination (O-TRID) since thepartner identity is not known yet. The messages End for the regular and Abort forthe irregular transaction cleardown both contain the transaction identity of thedestination (D-TRID) only.

In order to set up a transaction, one network node (A) sends to the other (B) theTCAP message Begin, thus delivering its own transaction identity. If Continuemessages are required, the first Continue serves as an answer to the Begin; withthis, B communicates its transaction identity to A. From now on, both sides canexchange Continue messages in an arbitrary sequence. From the point of view ofthe transaction control, it is not necessary that each Continue is answered byanother Continue in the opposite direction; rather, it can happen that two or moreContinue are sent in the same direction consecutively. The transaction is cleareddown in such a way that one of the two sides (A or B) sends End or Abort to thepartner 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 anylonger (pre-arranged end).

The shortest possible transaction consists of a Begin message from A to B which isanswered immediately by an End or Abort from B to A (or by a local transactioncleardown). Begin contains the origination transaction identity only, End and Aborthave the destination transaction identity only; as a consequence, no transactionidentity of B is required. The transaction is identified by a single identification number(selected by A).


TM3101EU01TM_00019

A B

Begin (O-TRID)

Continue (O-TRID, D-TRID)



End / Abort (D-TRID)


A B

Minimal sequence

Begin (O-TRID)


Fig. 2 TCAP Transaction Control


TM3101EU01TM_000110

All TCAP messages with the exception of Abort can contain components wherecertain operations are requested from the partner side or where a reaction to areceived operation request is transmitted. There are four types of components:

� Invoke for the request of an operation from the partner side.

� Return Result (Last) for the transmission of the results of an executed operationwhich had been requested by the partner side previously

� Return Error for the transmission of errors which have happened during theexecution of a requested operation

� Reject for the rejection of a received component.

A fifth type of component (Return Result (Not Last) for the transmission ofintermediate results) is defined by CCITT but not used with a GSM-PLMN.

As was already discussed, a TCAP message can contain several components (seeFig. 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 therequested operations belong to class 4 (see Fig. 4). In Continue operations, all typesof components are permitted.

For the distinction of different operations within the same transaction, each operationobtains an invoke identifier which is selected by the requesting side and transmittedto the partner side in the Invoke component. The partner side repeats the invokeidentifier 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 inthe opposite direction, i.e. that an Invoke is answered with Invoke (as, in the dailyconversation, a question is answered with a counter-question). In this case, thesecond Invoke contains besides its own invoke identifier the so-called linkedidentifier, i.e. the identifier of the previous Invoke. Thus, the second Invoke replacesan explicit acknowledgment of the original request (with Return Result (Last) orReturn 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 berejected (e.g. due to an unknown operation code) but Return Result (Last) orReturn Error components as well (e.g. due to an unknown invoke identifier).

A Reject component contains a problem code, which indicates the reason for therejection. 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. MAPdata with a GSM-PLMN). These data are

� with Invoke: the code of the operation to be executed and further parameters

� with Return Result (Last): the code of the executed operation and the executionresults

� with Return Error: the sort of error the has happened.These data are defined in the GSM guideline 09.02.


TM3101EU01TM_000111

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_000112

There are four possibilities (classes) to acknowledge operations:

Class 1: These operations must be acknowledged at any rate; it is an error if noanswer 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 asupervision 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 class1) 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 operationbelongs; rather, the TCAP user determines this. With the classes 1, 2 and 3, theTCAP user defines the duration of the supervision time, too.

The TCAP user also defines which operations exist and which parameters arecontained in the requests and acknowledgments for the individual operations. With aGSM-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) arecontained, but these data do not belong to the TCAP itself but to its user (i.e. withGSM to the MAP).


TM3101EU01TM_000113

Class 2Class 1

Request

Acknowledgment (good or bad)t

Request

t

Timeout: Error!

t

t

Request

Acknowledgment (bad)

Request

Timeout: positive acknowl.

Class 3

Request

Acknowledgment (good)t

Request

t

Timeout: negative acknowl.

Class 4

Request

no time supervision,no acknowledgment

Fig. 4 Classes of Operation of the TCAP


TM3101EU01TM_000114

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 bedistributed in an arbitrary way over the network nodes. It can come to pass that bothSSS subunits lie in the same network node; in this case, there is no physicalinterface. The other extreme occurs if the two SSS subunits lie in remote networknodes; here, the physical interface consists of several signaling links.

The B-interface exists between the MSC and the assigned VLR. It is used wheneverthe 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 notdiscuss it from the TCAP / MAP point of view.

The C-interface lies between an MSC and an arbitrary HLR. The MSC uses thisinterface for the interrogation during a mobile terminating call (MTC) in order to obtaindata 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:

� Location update and cancellation

� Control of supplementary services

� during call set up: access to subscriber data which are not stored in the VLR

� Request for a roaming number (MSRN)

� Reconstruction of the location registers after recovery

� Transfer of authentication data (triples)

The E-interface is located between two MSCs. It is the only interface where, besidesSCCP, TCAP and MAP, user channel related User Parts can be employed, too, sincefor a call set up and clear down, user channels must be seized and released. At thisinterface, 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 callset 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 newVLR 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 atthese interfaces will be described. All MAP operations under consideration belong toclass 1 if not explicitly stated otherwise.

Generally, we are going to confine ourselves to examples of positive cases since adetailed discussion of all special and error cases would exceed the scope of thistraining documentation considerably. For a complete treatment even of these cases,we refer to the GSM guideline 09.02.


TM3101EU01TM_000115

HLR

MSC

VLRVLR

EIRMSC

D

FE

G

(B)

D

Fig. 5 MAP interface


TM3101EU01TM_000116


TM3101EU01TM_000117

2 Call Sequences


TM3101EU01TM_000118

Three SSS subunits are concerned with the location registration:

� the MSC/VLR in whose area the MS roams (called "new VLR" from now on)

� the VLR where the MS was registered hitherto (called "old VLR" from now on)

� the HLR where the subscriber is registered permanently.

It can happen that the old and the new VLR are identical; then, location update is aninternal affair of the MSC/VLR, and no external TCAP/MAP messages are involved.

The relevant interfaces are

� the G-interface between the old and the new VLR

� 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 aremet (e.g. change of the location area without an existing call), it sends to the MSCthe message "Location Update Request" via the air interface and the A-interface. Themessage 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 MSCarea. We suppose that this is not the case.

The VLR (= the new VLR) determines from its data base by means of the old LAI theaddress (Global Title) of the old VLR and sets up a transaction to the old VLR withthe TCAP message Begin. The message contains an Invoke component for theMAP operation "Send Identification" with the received TMSI.

The old VLR determines from the TMSI the IMSI and the unused authenticationtriples; both is sent with the Return Result (Last) component for the "SendIdentification" operation to the new VLR. The component is contained in an Endmessage. This is an example for a short-term transaction where the Begin messageis 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 transientsubscriber data record) and setting up a transaction VLR-HLR with Begin; thismessage contains an Invoke component for the MAP operation "Update Location".With this, the VLR communicates to the HLR

� the IMSI (for the identification of the affected mobile subscriber)

� the LMSI (for the storage in the transient HLR subscriber data record)

� the VLR and MSC numbers (Global Titles; for the storage in the transient HLRsubscriber 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, theIMSI is contained twice in the integral message: once in the SCCP section (GlobalTitle for the determination of the HLR) and once as a MAP parameter in the Invokecomponent (so that the HLR can identify the mobile subscriber).


TM3101EU01TM_000119

Continue

RRLast (Insert Subscriber Data) ( Service Data)

RRLast (Insert Subscriber Data) ( Service Data)

VLR

newHLR

VLR oldG

D

D

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)

EndRRLast (Update Location) (HLR number)

Begin

Invoke (Cancel Location)

(IMSI, old LMSI)

End

RRLast (Cancel Location)

Fig. 6 Location Registration


TM3101EU01TM_000120

On reception of the Invoke, the HLR determines from the IMSI the mobile subscriberand stores the received data (IMSI and VLR address). Afterwards, the HLRdetermines the data of the basic and supplementary services of the mobilesubscriber as far as they are relevant for the VLR.

The HLR communicates the service data are to the VLR with Invoke components forthe MAP operation "Insert Subscriber Data", sending each Basic Service (with itsMSISDN and all supplementary services) in a component of its own (with own invokeidentifier). The components are sent in Continue messages; the mobile subscriber isdetermined 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 andconfirms 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 HLRterminates the transaction with an End message containing the Return Result (Last)component for the MAP operation "Update Location". Here, the HLR communicatesits number (= Global Title) to the VLR.

Thereupon, the MSC/VLR can encipher the air interface, assigns to the mobilesubscriber a new TMSI and send it to the MS.

The HLR, after cleardown of the transaction to the new VLR, performs the locationcancellation to the old VLR. For this purpose, the HLR sets up a transaction to the oldVLR with a Begin containing an Invoke for the MAP operation "Cancel Location" withthe 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

� "Inter-VLR Info Retrieval Context - v2" between old and new VLR

� "Network Loc. Up. Context - v2" between the new VLR and the HLR

� "Location Cancellation - v2" between the old VLR and the HLR.

The procedure "MS Purging" is invoked either because of administrative actions orbecause 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 MAPoperation "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 thepositive case, the HLR answers with an End containing the Return Result (Last) forthis operation. No further data are contained in this Return Result (Last) component.

The application context of this procedure is "MS Purging Context - v2".


TM3101EU01TM_000121

D

Begin

Invoke (Purge MS) (IMSI, VLR number)

HLRVLR

End

RRLast (Purge MS)

Fig. 7 MS purging


TM3101EU01TM_000122

With mobile terminating calls (MTC), however, the interrogation is performedbetween MSC, HLR and VLR by means of TCAP and MAP. The MSC is theGateway-MSC (either the MSC where the incoming call reaches the mobile networkor - with a call between two mobile subscribers of the same network - the MSC wherethe call originates). The HLR is where the called subscriber is registered, and theVLR is where the called subscriber has announced himself during the last locationupdate (i.e. associated with the visited MSC). The affected interfaces are

� the C-Interface between MSC and HLR

� the D-Interface between HLR and VLR.

The MSC initiates the interrogation with a Begin to the HLR containing an Invokecomponent for the MAP procedure "Send Routing Info". Further data in this Invokeare

� the MSISDN

� membership of the calling subscriber in a Closed User Group, CUG (optional)

� how often the call has already been forwarded (optional)

� received signaling information (optional, e.g. identification of a Basic Service).

In the positive case (when no CUG membership or another obstacle prevents the callset up), the HLR sends a Begin to the VLR containing an Invoke component for theMAP procedure "Provide Roaming Number". There are delivered

� the IMSI

� the MSC number

� the MSISDN

� the LMSI (optional - for a faster addressing of the VLR data)

� the GSM-Bearer Capability belonging to the MSISDN

� and/or signaling information about the requested service as received from theMSC.

The VLR allocates a MSRN and returns it with the Return Result (Last) for "ProvideRoaming 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 ReturnResult (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

� "Location Info Retrieval Context - v2" between Gateway-MSC and HLR

� "Roaming Number Enquiry Context - v2" between HLR and VLR.


TM3101EU01TM_000123

C

Begin

Invoke (Send Routing Info)

(MSISDN,

CUG Check Info, Number of Forw.,

Network Signal Info)

VLRMSC

D

HLR

End

RRLast (Send Routing Info)

(IMSI, MSRN,

CUG Check Info)

Begin

Invoke (Provide Roaming No.)

(IMSI, MSC number,

MSISDN, LMSI,

GSM-Bearer Cap., Network Signal Info)

End

RRLast (Provide Roaming No.)(MSRN)

Sel.

MSRN

Fig. 8 Interrogation


TM3101EU01TM_000124

Next, let us consider two cases of call forwarding.

Call Forwarding Unconditional is recognized during the interrogation in the HLRalready. As usual, the Gateway-MSC sends to the HLR the Invoke for the MAPoperation "Send Routing Info" with the MSISDN and further data. If now the HLRsees that a Call Forwarding Unconditional exists for the service in question, nocontacts 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 callforwarding destination (=B2 number) instead of the MSRN. Now, it is for theGateway-MSC to set up a call to the forwarding destination.

Call Forwarding Conditional is normally executed in the visited MSC after the callrouting from the Gateway MSC to the visited MSC. However, there is a case for CallForwarding on Not Reachable being executed in the Gateway MSC already: this isif the Mobile Station is deregistered with "IMSI-Detach" (explicit or implicit). When theHLR sends to the VLR the Invoke for "Provide Roaming Number", and if the VLRnow recognizes that the Mobile Station is deregistered, the VLR answers with ReturnError and the error code "Absent Subscriber". The HLR checks whether a CallForwarding is foreseen for this case; if it is, it sends the forwarding number (=B2number) instead of the MSRN in the Return Result (Last) for "Send Routing Info" tothe Gateway-MSC.

The application contexts are the same ones as with a "normal" interrogation.


TM3101EU01TM_000125

C

Begin


(MSISDN,

CUG Check Info,

Number of Forw.,


VLRMSC

D

HLR

End

RRLast (Send Routing Info) (IMSI, B2 number,

CUG Check Info)

Fig. 9 Call Forwarding Unconditional

C

Begin


(MSISDN,

CUG Check Info,

Number of Forw.,


VLRMSC

D

HLR

Begin

Invoke (Provide Roaming No.)

(IMSI, MSC number,

MSISDN, LMSI,

GSM-Bearer Cap.,


End

RRLast (Send Routing Info)

(IMSI, B2-Number,

CUG Check Info)

End

RetError (Provide Poaming No.)

(Absent Subscriber)

Fig. 10 Call Forwarding on not reachable after IMSI Detach


TM3101EU01TM_000126

If the VLR has lost the mobile subscribers data due to a recovery, the mobilesubscriber 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 aboutthe subscribers existence. The VLR now assigns a MSRN in the usual manner andreturns 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 VLRreserves an idle data record for this subscriber; the index of this subscriber datarecord is the LMSI.

Afterwards, the VLR retrieves authentication triples for this subscriber. To this end, itsets up a new transaction (with Begin) to the HLR; this Begin message contains anInvoke for the operation "Send Authentication Info" with the IMSI (from the previousInvoke for "Provide Roaming Number") as parameter. The HLR replies with an Endmessage containing the Return Result (Last) for "Send Authentication Info" with fiveauthentication triples. This triples the VLR stores in the reserved subscriber datarecord.

Next, the VLR sets up a third transaction to the HLR with a Begin messagecontaining an Invoke for the MAP operation "Restore Data". Parameters are IMSIand LMSI of the subscriber. The HLR stores the new LMSI (the old one - prior to thedata 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 SubscriberData". Each Basic Service requires an own Invoke for "Insert Subscriber Data", andthe VLR must acknowledge each Invoke with Return Result (Last). The HLR cancombine several Invoke components within one Continue message, and the HLRcan do the same thing with several Return Result (Last) components. Finally, theHLR 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 fromthe 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 MSCarea). As soon as the subscriber replies, the VLR knows the location area of thesubscriber and can now assign a new TMSI as well, so that all the data aresuccessfully retrieved, and the call is set up.

The relevant application contexts are

� "Roaming Number Enquiry Context - v2" for the first transaction

� "Info Retrieval Context - v2" for the second transaction

� "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 originatingone, then it is not successful. In this case, the call fails due to the reason "UnknownSubscriber" which causes the Mobile Station to do a Location Update, so that asecond MOC attempt will be successful.


TM3101EU01TM_000127

Begin

Invoke (Provide Roaming Number)

(IMSI, MSC number, MSISDN, LMSI,

GSM-Bearer Capability, Network Signal Info)

VLR

D

HLR

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)

ContinueInvoke (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_000128

The transient HLR subscriber data belong to a memory section, which is normally notoverwritten during a recovery (noload-segment). Furthermore, the HLR stores thesedata at regular time intervals in a backup file on the disk. If, during a recovery, thedata are destroyed nevertheless (e.g. due to a memory formatting), the secured dataare reloaded from the backup file into the memory. Because the data are not securedperpetually in the backup but only periodically, all changes are lost that haveoccurred since the last backup transfer. Therefore, all affected VLRs must beinformed about the failure so that they can mark the affected subscriber recordscorrespondingly. These are

� all VLRs of the own PLMN

� 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 fromthe disk the transient HLR data (which, as mentioned, might not contain the latestchanges) and the list of the addresses of the affected VLRs. To these VLRs, the HLRsends 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 whichcorresponds 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 cleardown the transaction locally afterwards.

A VLR, on reception of such an Invoke for "Reset", rummages through its subscriberdata records and compares for each subscriber the stored HLR number with thereceived value. Whenever the addresses coincide, it is a subscriber from the affectedHLR, 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 [evenwithin the same MSC area], periodic location update, IMSI attach, mobile originatingcall), the VLR performs a location update with the HLR corresponding to Fig. 6 sothat the HLR gets an actualized data record again. Thereupon, the VLR deletes themark 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 dataloss endangers the accessibility of the affected mobile subscribers.


TM3101EU01TM_000129

Begin

Invoke (Reset) (HLR number)

HLR

D

VLR

local

transaction

release

local

transaction

release

Fig. 12 Data Restoration HLR


TM3101EU01TM_000130

Let us consider an example for an Inter-MSC-Handover within a PLMN. The mobilestation in Fig. 13 has originally set up a call in the area of MSC A. During the call itmoves 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 speechand 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-termTCAP-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-Handoverto MSC C and again the control of the call is held at MSC A. The mobile station isnow connected to a BSS of MSC C (speech and signaling channel). The access from

� MSC A to the mobile station is again realized by a TCAP-connection (MSC A toMSC C).

� 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 ofMSC A. This would lead to a clear down of the long-term TCAP-transaction (in ourexample: MSC A to MSC C) and the mobile station is from now on connected to aBSS of MSC A (for the speech and for the signaling channel) and MSC A has the callcontrol anyhow.


TM3101EU01TM_000131

MSCA

BSS

MSCB

MSCC

BSS

BSS

RR

SCCP

SCCP

RR

TCAP

TCAP

Remote

party

Fig. 13 Inter-MSC-Handover


TM3101EU01TM_000132

TCAP and MAP are concerned with Handover only if it is a Handover betweendifferent MSCs (MSC-MSC-Handover or Inter-MSC-Handover). The concerned unitsare

� the MSC which had set up the call originally (MSC A)

� 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 theHandover Number (HON) only. No subscriber data record will be generated in thisVLR. The VLR doesn't learn the identity of the mobile subscriber either (IMSI orMSISDN) 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 carriedtransparently in the MAP components.

Lets begin with the consideration of a first Handover. This is to say, the MobileStation changes during the call from the area of MSC A (where the connection hasbeen set up originally) into the area of MSC B. The Base Station decides when aHandover to a new radio cell must be performed, and it is MSC A who recognizesthat 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 Invokecomponent for the MAP operation "Prepare Handover". In the component, MSC Atells to MSC B the identity of the new (target) cell as well as whether a HandoverNumber (HON) is required (this is not the case if the Mobile Station has no TCHassigned but works with the SDCCH). Furthermore, the component contains thecomplete BSSMAP-message "Handover Request". This BSSMAP message containsthe identity of the old and of the new cell, the channel type and the valid cipheringkey (Kc) for the air interface.

On reception of this message, MSC B transmits the "Handover Request" to the BaseStation, which administers the new cell; if a HON is required, the MSC B also selectsa terrestrial channel to the Base Station and includes its CIC into "HandoverRequest". The Base Station selects a channel at the air interface and composes amessage "Handover Command" to the Mobile Station in which the Mobile Stationlearns the new cell and the new channel. Furthermore, the message contains theHandover reference number (selected by the Base Station, too) for the first radiocontact of the Mobile Station in the new cell. This "Handover Command" the BaseStation returns to the MSC with the BSSMAP-message "Handover RequestAcknowledge". (The Base Station cannot radiate this message at the air interfacebecause the Mobile Station receives in the old cell and on the old channel hitherto.)


TM3101EU01TM_000133

Begin

Invoke (Prepare Handover)

(Target cell, HON required?,

BSSMAP-message „Handover Request“)

MSC

B

EMSC

A

HO Request

Continue

RRLast (Prepare Handover)

(Hon, BSSMAP-message

„Handover Request Acknowledge“)

HO Request

Acknowledge

Call Setup

to MSC B,

3-Conf.,

Command

for MS

Continue

Invoke (Process Access Signalling)

(BSSMAP-message „Handover Detect“)

End

3-Conf.,

Release to

Base

Station

HO Detect

HO Complete Continue

Invoke (Send End Signal)

(BSSMAP-message „Handover Complete“)

Fig. 14 First Handover MSC A � MSC B


TM3101EU01TM_000134


TM3101EU01TM_000135

Now, MSC B selects an Handover Number and acknowledges to MSC A the MAPoperation "Prepare Handover" with Return Result (Last) in a Continue. Thecomponent contains the allocated Handover Number (if applicable) and received"Handover Request Acknowledge", containing the air interface message "HandoverCommand" to the Mobile Station.

MSC A uses the Handover Number to set up a user connection to MSC B (with auser channel related User Part, or with channel associated signaling) and to switch itto a three-party conference with the former user connection. Thereupon, MSC Arequests the (old) Base Station to radiate "Handover Command" (as composed bythe new Base Station) to the Mobile Station.

With this message, the Mobile Station is asked to switch to the new cell and to thenew channel and to report there with the Handover reference number. As soon asthis has happened, the new Base Station sends the BSSMAP-message "HandoverDetect" which MSC B relays to MSC A in a Continue with the Invoke for the MAPoperation "Process Access Signaling". It is an operation of class 4, i.e. noacknowledgment is required on the part of MSC A.

When the Mobile Station has sent "Handover Complete", the Base Station sends aBSSMAP message of the same name to MSC B, and MSC B transmits this BSSMAPmessage to MSC A Continue with the Invoke for the MAP operation "Send EndSignal".

Now, MSC B clears down the three-party conference, releases the user channel tothe old Base Station and requests the old Base Station to release the former channelat the air interface. The Handover is completed.

The transaction between MSC A and MSC B remains stable until either the userconnection is cleared down or a second Handover to another MSC occurs.

With the call sequences discussed hitherto, transactions were set up for proceedingswithin a restricted period of time (location registration or call set up) and werereleased after the completion of the proceeding. The Handover between MSCs is theonly case were transactions are maintained beyond the actual proceeding over alonger period of time. The reason is that MSC B and its VLR do not "know" whichMobile Station is roaming in their area. If a subsequent Handover or other eventsoccur, MSC B can tell to MSC A by means of the transaction identities, which MobileStation 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 supervisiontime amounts to several hours (project and implementation dependent: up to 38hours). The aim is to prevent that the user channels between MSCs remain blockedfor an incongruously long period of time. After expiry of the time supervision, thetransactions and user connections are cleared down.

The application context for Handover is "Handover Control Context - v2"


TM3101EU01TM_000136

Let us investigate now the case of a subsequent Handover into the area of a thirdMSC (=MSC C). The Base Station where the Mobile Station roams recognizes that aHandover to another radio cell is necessary, and MSC B finds out that the new celldoes not belong to the own area. Therefore, MSC B sends to MSC A in a Continuethe Invoke for the MAP Procedure "Prepare Subsequent Handover" and informsMSC A about the identity of the target cell as well as about the number (=GlobalTitle) 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 eitherbut is administered by a third MSC (=MSC C), it performs a Handover procedure toMSC C which corresponds exactly to the first Handover (cf. Fig. 14). Thus, MSC Asends 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 assignedand a message of the air interface composed by the Base Station. Furthermore, MSCC selects a Handover Number (if necessary). Now, MSC C sends the HandoverNumber to MSC A in the Return Result (Last) for "Prepare Handover" (including theBSSMAP message "Handover Request Acknowledge" containing the air interfacemessage "Handover Command").

MSC A employs the Handover Number to set up a user connection to MSC C and toswitch 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 theMAP procedure "Prepare Subsequent Handover". Here, MSC A transmits to MSC Bthe BSSMAP message "Handover Request Acknowledge" as received from MSC C.

MSC B forwards the air interface message "Handover Command" to the (old) BaseStation where it is radiated. The Mobile Station is requested to switch to the new celland to the new channel (in the area of MSC C). As soon as the Mobile Station hasfound contact there, MSC C sends to MSC A the Invoke for "Process AccessSignaling" (with "Handover Detected"). When the new Base Station has sent"Handover Complete", MSC C relays this BSSMAP message to MSC A with anInvoke for the MAP operation "Send End Signal".

Now, MSC A clears down the three-party conference and releases the userconnection to MSC B. Afterwards, MSC A releases the transaction to MSC B with anEnd 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 requeststhe Base Station to release the former channel of the air interface.


TM3101EU01TM_000137

MSC

C

MSC

A

MSC

B

E

Continue

Invoke (Prepare Subsequent Handover)

(Target cell, Target MSC number,

BSSMAP-mess. „HO Request“)

BeginInvoke

(Prep. HO)

Continue

RRLast

(Prep. HO)

Continue

RRKast (Prepare Subsequent Handover)

(BSSMAP-message

„HO Request Acknowledge“)

Continue

Invoke

(Process

Access

Sign.)

Call Setup,

to MSC B,3-Conf.

HO Command

End

3-Conf.

Releaseto MS´C B

End

RRLast (Send End Signal)Release

to Base

Station

Continue

Invoke

(Send End

Sign.)

Fig. 15 Subsequent Handover MSC B � MSC C


TM3101EU01TM_000138

The case can happen, of course, that a subsequent Handover leads back into thearea of the original MSC. The sequence begins as in the former case. Again, theBase Station recognizes the necessity of a Handover to another radio cell, and MSCB (= the MSC in whose area the Mobile Station roams) finds out that the target celldoes not belong to the own area. Therefore, MSC B sends to MSC A in a Continuethe Invoke for the MAP procedure "Prepare Subsequent Handover" and informsMSC 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 ownarea. Thus, no communication with a third MSC is required, but MSC A directlytransmits "Handover Request" to the Base Station, which is responsible for the newcell. (Before so doing, MSC A selects a user channel to this Base Station andincludes the CIC into "Handover Request".) The Base Station selects an air interfacechannel and composes the air interface message "Handover Command" which itcommunicates to MSC A in the BSSMAP message "Handover RequestAcknowledge".

No Handover Number is required; therefore, the VLR is not involved. Instead, MSC Aswitches the user channel to the Base Station to a three-party conference with theformer user connection. Now, MSC A sends to MSC B in a Continue the ReturnResult (Last) for the MAP procedure "Prepare Subsequent Handover". In thecomponent, MSC A transmits to MSC B the BSSMAP message "Handover RequestAcknowledge" including the air interface message "Handover Command" ascomposed by the Base Station.

Next, MSC B has "Handover Command" radiated by its Base Station. The MobileStation is requested to switch to the new cell and to the new channel. When theMobile 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 thethree-party conference and releases the user connection to MSC B. Next, MSC Aalso 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 andrequests the Base Station to release the old air interface channel.

Again, the application content is "Handover Control Context - v2".


TM3101EU01TM_000139

MSC

A

MSC

C

E

Continue

Invoke (Prepare Subsequent Handover)

(Target cell, Target MSC number,

BSSMAP-mess. „HO Request“)HO Request

HO Request

Acknowledge

3-Conf.

Continue

RRLast (Prepare Subsequent Handover)

(BSSMAP-message „HO Request Ackowledge“)

End

RRLast (Send End Stgnal)

End

3-Conf.

Release

to MSC C

HO Detect

HO Complete

HO Command

Releaseto Base

Station

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


TM3101EU01TM_000140

The Mobile Station changes with a Handover its RR connection only; MM and CMconnections (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 MMand CM connections, however, it is the MSC. With a Handover, MSC B sets up anSCCP connection to the new BSC but does not evaluate any DTAP messagereceived over this SCCP connection; rather, DTAP messages are forwarded to MSCA 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 thereceived DTAP message. This MAP operation belongs to class 4; thus, there is noacknowledgment to MSC B.

Vice-versa, if MSC A wants to send an MM or CM message to a Mobile Station whichhas changed by Handover into the area of MSC B, it sends the DTAP data to MSC Bin an Invoke component for the operation "Forward Access Signaling"; thecomponent is contained in a Continue message. The MSC B forwards these DTAPdata over the existing SCCP connection to the BSC whence they are transmitted tothe Mobile Station. Again, the operation "Forward Access Signaling" belongs to class4; thus, there is no reply from MSC B.

With each subsequent Handover within MSC B, MSC B sets up an SCCP connectionto the new BSC (and releases the SCCP connection to the former BSC) so that thedescribed 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 setup 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 partnerside: at any rate, the Mobile Station and the MSC exchange messages like"Disconnect", "Release" and "Release Complete" in the DTAP. As discussed rightnow, 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 Areleases the user connection with MSC B and clears down the transaction to MSC Bwith an End containing the Return Result (Last) for the MAP operation "Send EndSignal". Now, MSC B releases the SCCP connection and the user connection to theBase Station. This being done, all user connections and all transactions are cleareddown, and all MAP procedures are acknowledged - as far as required. Thus, allphysical and logical resources are idle again.

The application context is "Handover Control Context - v2" for everything.


TM3101EU01TM_000141

Continue

Invoke (Process Access Signaling)

(DTAP-message)

MSC

A

MSC

B

E

Continue

Invoke (Forward Access Signaling)

(DTAP-message)

DTAP

DTAP

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

MSC

A

MSC

B

Release

to MSC B

End

RRLast (Send End Signal)

E

Release

to Base

Station

Fig. 18 Call clear down after Handover


TM3101EU01TM_000142

The last MAP operation we discuss concerns the check of the IMEI. This is the onlyMAP operation, which involves the F interface.

The IMEI Check can be activated project and installation specifically in the MSC. Ifthis is the case, the MSC interrogates during the call set up the IMEI of the called orcalling equipment (BSSMAP procedure identification). Thereupon, the MSC sets up atransaction at the F-interface to the responsible EIR with a Begin containing theInvoke for the MAP operation "Check IMEI"; the IMEI is included. The EIR checksthe IMEI and answers with the Return Result (Last) for this MAP operation in anEnd message. Here, the EIR informs the MSC whether the equipment was found onthe white, gray or black list.


TM3101EU01TM_000143

Continue

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

MSC EIR

F

Begin

Invoke (Check IMEI) (IMEI)

Fig. 19 IMEI Check


TM3101EU01TM_000144


TM3101EU01TM_000145

3 Formatting Rules of TCAP and MAP


TM3101EU01TM_000146

The formatting rules for TCAP and MAP correspond to the standard of the AbstractSyntax Notation 1 (ASN.1) as defined in the CCITT / ITU recommendations X.208and X.209. In this standard, the data to be transmitted consist of elements whoselayout is illustrated in Fig. 20. Such an element comprises

� a Tag in the length of one or several byte(s). The tag does not reflect the meaningof the element but its syntactical structure. Thus, the tag should not be comparedwith 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 higherprogramming languages. Only if two elements of the same data type must bedistinguished from each other (e.g. two optional parameters of the samesyntactical structure), the tag indicates which element is meant.

� a Length indicator comprising one or several byte(s).

� 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, lengthindicator and contents; in this case, we speak of a Constructor element. Themembers of a constructor element can be constructor elements again, etc.; the depthof interlocking is not restricted. If an element is not a constructor element, i.e. if itscontents do not consist of other elements, we speak of a Primitive element.


TM3101EU01TM_000147

Primitive Constructor

Length

Tag

Length

Tag

Contents

Contents

Contents

Length

Tag

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


TM3101EU01TM_000148

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 themessage type (that is, Begin, Continue, End or Abort). The length indicator for theentire TCAP message ensues. The contents of the element consist, in their turn, ofseveral elements (with tag, length indicator and contents), e.g. the transactionidentities. The penultimate element is the dialogue portion, and the last element is thecomponent portion; both are marked as such by their tags. Again, these elementshave a length indicator and contents.

The dialogue portion is a constructor element. For the sake of simplicity, we shall notdiscuss in this training documentation the structure of the dialogue portion, whichcontains many fields not relevant for a GSM-PLMN.

The component portion is a constructor element, too. Its contents consist of zero, oneor several component(s). Each component is an element in the contents of thecomponent portion.

Each component is a constructor element. Its tag indicates which type of componentit is (Invoke, Return Result (Last), Return Error or Reject). The contents of acomponent consist of elements, which can be primitive or constructor. We mention

� the invoke identifier, possibly the linked identifier, too

� the (requested or acknowledged) MAP operation

� 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 eachcomponent type which elements are mandatory or optional in the contents. Here, thepossible refusal causes of the Reject are declared, too. The GSM guideline 09.02,however, defines the possible MAP application contexts and MAP operations anddescribes which parameters are mandatory or optional for a given MAP operation inInvoke, Return Result (Last) and Return Error.


TM3101EU01TM_000149

Tag = Message Type

Length

Element of the transaction portion

( e.g. transaction identity)

Tag = Dialogue Portion

Length

Elements of the Dialogue Portion

Tag = Component Portion

Length

Tag = Component Type

Length

Element of the Component

(e.g. invoke identifier, parameter

Component

Transaction

Portion

Dialogue

Portion

Component

Portion

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


TM3101EU01TM_000150

The coding rules for the tag are given in Fig. 22. As you see, the first two bits indicatethe class of the tag. There are four tag classes defined:

� universal (code = 00): data types for all applications. These data types are definedin the CCITT recommendation X.209; in this training documentation, they arelisted in fig. 24.

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

� context specific (code = 10): these tags have a meaning only at a given positionwithin a given constructor element (e.g. within a given TCAP message type, acomponent type, a MAP operation).

� 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 distinctionbetween 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 tofollow; thus, the tag as a whole has a length of one byte. If, however, the value is 31or more, the five least significant bits of the first byte are set to 11111 as an escapecode. In this case, the tag value extends over the next bytes, but the most significantbit of each byte does not count. Rather, the most significant bit indicates whether thetag is completed with this byte (0) or extends to the following byte (1).

In this manner, arbitrarily large tag values can be coded.


TM3101EU01TM_000151

Value 30: Class PC Value =/ 11111

Value 31:

Class PC 1 1 1 1 1

1

1

0

= Value

Class

Class Meaning

00 universal (X.209)

01 application specific

10 context specific

11 private

Form

PC Meaning

0 Primitive

1 Constructor

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


TM3101EU01TM_000152

The coding of the length indicator is illustrated in Fig. 23. Mostly, the indicator doesnot exceed the value 127; in this case, one byte is sufficient whose most significantbit is set to 0 as a mark.

If the contents comprise 128 bytes or more, the length indicator must extend overseveral bytes. In this case, the most significant bit of the first byte is set to 1 as amark, and the remaining 7 bits indicate how many length indicator bytes are going tofollow ("length indicator of the length indicator"). In the following bytes, the lengthindicator value is coded. As this "length indicator of the length indicator" has a lengthof 7 bits, its maximal value is 127. Therefore, the length indicator itself comprises upto 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 morethan the estimated amount of atoms in the universe, and the transmission of such anelement with 64 kbit/s would take much, much longer than the expected remaininglifetime of the solar system. In other words: it will never happen that an element is toolong for its length indicator to be coded by this method.

Of course, the first byte of the length indicator cannot have the binary value 10000000, for this would mean that the length indicator value extends over the following 0bytes, which is absurd.

Finally, with constructor elements, an indefinite length indicator is possible, namely ifthe sender at the time of the length indicator generation cannot predict the totallength. The indefinite length indicator is always one byte long and has a binary valueof 1000 0000; this, as was explained right now, can never be the value of the firstbyte of a definite length indicator, so that errors are excluded. Now there follow theelements the constructor consists of (with their own tag, length indicator andcontents). At the end, a pseudo-element follows with the tag B’0000 0000 (universaltag 0: undefined acc. to Fig. 24) and the length indicator 0000 0000 (length 0 byte) asa 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 elementcontents, for this depends on the element type (i.e. on the tag).


TM3101EU01TM_000153

Value 127: 0 Value

= 0000000Value 127:

1 length of the length indicator

Value

1 0 0 0 0 0 0 0

Element

Element

0 0 0 0 0 0 0

0 0 0 0 0 0 0

Indefinite

value:

(Constructor

only)

Tag

Length

End of

Constructor

Fig. 23 Coding of the Length Indicator (CCITT / ITU X.209)


TM3101EU01TM_000154

Fig. 24 shows the universal tags. Not all of them are relevant for a GSM-PLMN. Thefollowing tags apply for TCAP and MAP:

� Boolean (1): CONTENTS "TRUE" (1) OR "FALSE" (0); LENGTH 1 BYTE

� INTEGER (2): an integer number; the first bit indicates the sign

� BITSTRING (3) occurs in the dialogue portion

� OCTETSTRING (4): a string of bytes which are evaluated individuallyExamples: IMSI, MSISDN

� NULL (5): a dummy; length 0 byte

� OBJECT IDENTIFIER (6) occurs in the dialogue portion

� EXTERNAL (8) occurs in the dialogue portion

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

� SEQUENCE (16): a sequence of elements in pre-defined order

Example: SEQUENCE (IMSI OCTETSTRING,

TMSI OCTETSTRING)

� 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) areconstructor; the others are primitive.

In a SEQUENCE (16), some of the members can be marked with the addendumOPTIONAL; these parts then may be omitted. Here, it can happen that contextspecific tags must be used to ensure uniqueness (see Fig. 27).

With a CHOICE type, two or more possibilities stand for selection which aredistinguished by their tags. Again, context specific tags must be used occasionally toobtain 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).


TM3101EU01TM_000155

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_000156

In the TCAP, both application and context specific tags are used. The message typesare 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 isobvious according to Fig. 21.

Further application specific tags concern the transaction identities; the elements areprimitive. The length may be 1 to 4; thus, it is not fixed - unlike the local references ofthe SCCP. In Abort messages, the abort cause is given and has an applicationspecific tag, and it is distinguished as to whether the abort was caused by the lowerlayers (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 specificconstructor tag for the dialogue portion as a whole, and another one for thecomponent portion (cf. Fig. 21).

Within the component portion, context specific tags are defined, e.g. the componenttypes (B'011... = context specific, constructor). The "linked identifier" in the Invokehas a context specific primitive tag whilst the invoke identifier has the universal tagB'0000 0010 = H'02 = Integer.

Further context specific primitive tags exist in Reject components only. They indicatewhether the reject was due to a general problem (e.g. a component of an unknowntype was received) or whether an Invoke, a Return Result or a Return Error waspinpointed as erroneous.


TM3101EU01TM_000157

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_000158

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 cannotidentify 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 assumesthe role of an identifier and not just of a type indication. In the definition, the new tagis given in square brackets.

There are two kinds of Tagged Types: explicit and implicit. With the implicitrepresentation (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 tagwas 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 specifictag 1 and the LAI the context specific tag 2. Both tags have the form primitivebecause 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 hehas 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 aframe. The new tag has the form constructor, and the only member of the constructorelement 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 aprimitive element with the universal tag 4 (= OCTETSTRING).


TM3101EU01TM_000159

1 0 0 0 0 0 0 1

1 0 1 0 0 0 0 1

1 0 1 0 0 0 0 1

1 0 1 0 0 0 0 1

[1] INTEGER

[1] IMPLICIT

INTEGER

[1] SEQUENCE

[1] IMPLICIT

SEQUENCE

0 0 0 0 0 0 1 1

Integer Value

Context, Constr., 1

Length 3

Universal, Prim., 2 (= INTEGER)

Length 1

Integer Value

Context, Prim., 1

Length 1

15 bytes contents

15 bytes contents

Length 15

Context, Constr., 1

Length 17

Universal, Constr., 16 ( = Sequence)

Length 15

Context, Constr., 1

0 0 0 0 0 0 1 0

0 0 0 0 0 0 0 1

0 0 0 0 0 0 0 1

0 0 0 1 0 0 0 1

0 0 1 1 0 0 0 0

0 0 0 0 1 1 1 1

0 0 0 0 1 1 1 1

Fig. 27 Tagged Types - Context specific


TM3101EU01TM_000160

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 operationit is; in the Return Result (Last), this information can be repeated although it couldbe derived from the invoke identifier, too, for the identifier was assigned to a fixedoperation by the preceding Invoke. Thus, the type of operation is mandatory in theconstructor 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 whichtypes of operation exist and how they are coded. Fig. 28 displays some MAPoperation types together with their numerical values; the list is confined to theoperations discussed in section 2.

In the GSM guideline 09.02, a complete list of all MAP operations with their values isfound. There are 46 different operations, and the values range up to 69. Thus, for theMAP operation code, a length of 1 byte is sufficient.


TM3101EU01TM_000161

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_000162

As an example, we study the MAP operation "Update Location" whose Invoke is sentfrom 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 forthis MAP operation.

UpdateLocation is defined as an OPERATION. The keyword ARGUMENT is relatedto the Invoke of this operation and indicates what must be transmitted besides theoperation code. This is always one ASN.1 element; if several data must be sent, theelement is a SEQUENCE consisting of mandatory and optional members. Eachmember 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 theLMSI). If the keyword ARGUMENT is amiss in the definition of an OPERATION, itmeans that, in the Invoke, nothing must be transmitted after the operation code.

RESULT is related to the Return Result (Last) and indicates what must betransmitted in this component beyond the invoke identifier and (possibly) theoperation code. Again, this is one ASN.1-Element, maybe a Sequence. If thekeyword RESULT is written alone, no further data must be transmitted in the ReturnResult (Last); in this case the operation code is omitted, too. If, however, further dataare required in the Return Result (Last), the operation code will be included in thiscomponent, too.

ERRORS is related to the Return Error and indicates the possible error codes of thiscomponent. The error codes are - similar to the operation codes - integer numberswith 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 RESULTand ERRORS. If both RESULT and ERRORS are present, there are both positiveand negative acknowledgments, and the operation belongs to class 1. If there is onlyERRORS but no RESULT, there are no positive acknowledgments and it is anoperation of class 2. If RESULT is present but ERRORS is not, the class is 3. If bothRESULT and ERRORS are amiss, we have an operation of class 4.


TM3101EU01TM_000163

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_000164

At another place of the guideline 09.02, the definition of the data types in use is foundwith 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) whosebytes consist of decimal digits coded in half bytes. The explanations say that thedistribution 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 byteare 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 lengthbetween 1 and 20. The explanations say that the first byte gives information aboutthe type of the transmitted number. The most significant bit is 1; the three followingbits 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 theNature of Address and for the Numbering Plan, 19 bytes remain for the digits so thatup to 38 digits can be transmitted.

A special case of the type "AddressString" is the "ISDN-AddressString"; here, thelength is restricted to 9 (= at most 16 digits). This type applies for the VLR address (inthe Invoke) and for the HLR address (in the Return Result (Last)). The LocationInfo is another such ISDN-AddressString but as a Tagged Type with the contextspecific tag 0 or 1, depending on whether it is a roaming number or an MSC number.


TM3101EU01TM_000165

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 1mscNumber [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_000166

Finally, the LMSI is an OCTETSTRING with the length 4. Because it appears as anoptional member in the Invoke for "Update Location" and confusions with otherOCTETSTRINGs must be avoided, the LMSI is a Tagged Type with the contextspecific tag 10.

At still another place of the guideline 09.02, the error codes for the possible negativecases are listed. Fig. 29 shows the values relevant for "Update Location" . The valuesare local, i.e. the tag is INTEGER.

Lets consider now a special "Update Location". The Invoke is sent from the VLR tothe HLR, and its argument is a SEQUENCE according to Fig. 29; thus, it has theuniversal 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 thelast element (= after the LMSI), a pseudo element with the tag B'0000 0000 and thelength 0 would have to be added (cf. Fig. 23).

According to Fig. 30, the IMSI ensues. Indeed, the next element has the universalprimitive tag 4; thus, it is an OCTETSTRING. The length is 8 and the digits (as aTBCD-String) are 262017708154711, which is combined from the MCC (262), theMNC (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 fromthe 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 aCHOICE 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 numberaccording to the ISDN Number Plan E.163 / 164. The digits are 35112345 (this is anumber in Portugal because of the country code 351).


TM3101EU01TM_000167

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

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

0 0 0 1 0 0 0 1

0 0 1 1 0 0 1 0

0 1 0 1 0 1 0 0Continuation see fig. 32

Location Info

IMSI

Fig. 31 Argument of the Invoke of "Update Location" - Example


TM3101EU01TM_000168

Next, the VLR number (an ISDN-Address-String) ensues according to Fig. 30. Thetag is universal, primitive, and its value is 4; thus, it is again an OCTETSTRING. Thelength is 5 bytes. Once again, it is an international ISDN number. This time, the digitsequence is 35112345 (Portugal again).

The last member of the Sequence is the optional member "LMSI". As a mark for itspresence, we find the context specific primitive tag 10. The length is 4. In thesubsequent 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 lengthindicators) of 30 bytes, as was indicated initially.


TM3101EU01TM_000169

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

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

VLR Number

Value

of the

LMSI

Fig. 32 Argument of the Invoke of "Update Location" - Continuation of the example


TM3101EU01TM_000170

The entire Invoke component for "Update Location" is displayed on Fig. 33; thelayout meets the demands of the ITU recommendation Q.773. The component has acontext specific constructor tag according Fig. 26, which marks it as an Invoke. Inour example (Fig. 31and Fig. 32), a component length of 38 bytes results. Again, it ispossible to use an indefinite length indicator.

The component is constructed like a Sequence and has the following members:

� Mandatory member Invoke Identifier with universal primitive tag 2 (= INTEGER);length 1 byte

� Optional member Linked Identifier with context specific primitive tag 0; length 1byte

� Mandatory member Operation Code with universal primitive tag 2 (= INTEGER);length 1 byte

� 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 beseen. No linked identifier is required; thus, the following element has not the contextspecific tag 0 but the universal primitive tag 2 (INTEGER, here: Operation Code). Thevalue 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.


TM3101EU01TM_000171

Context, Constr., 1 (= Invoke) 1 0 1 0 0 0 0 1

Lenght 38 0 0 1 0 0 1 1 0

Universal, Prim., 2 (= INTEGER) 0 0 0 0 0 0 1 0

Length 1 0 0 0 0 0 0 0 1

Universal, Prim., 2 (= INTEGER) 0 0 0 0 0 0 1 0

Length 1 0 0 0 0 0 0 0 1

Value 2 (= Update Location) 0 0 0 0 0 0 1 0

Argument: tag, lengthindicator and 30 bytes

contents(see fig. 32)

Value of the invoke identifier

Invoke Identifier

Operation Code

Argument

Fig. 33 Complete Invoke component for "Update Location" - Example


TM3101EU01TM_000172

Let us consider, at long last, the entire message Begin from the HLR to the VLRcontaining the Invoke for "Update Location". The tag, which characterizes themessage 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 mandatorymember Origination Transaction Identity (application specific primitive tag 8, cf. Fig.25) and the optional member Component Portion (application specific constructor tag12, cf. Fig. 25).

The transaction identities have a length between 1 and 4 bytes. We take anorigination transaction identity of two bytes.

Their now follows the component portion with a length indicator of 40 bytes (again, anindefinite length indicator would be possible). The element contains the Invokecomponent from Fig. 33 with its tag, its length indicator (38) and its contents.

Finally, the Begin is terminated with "End of Constructor" because an indefinitelength indicator was used.

This Begin message is built as "Data" parameter of 50 bytes total length into anSCCP message "Unitdata" (UDT).


TM3101EU01TM_000173

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

Application, Constr., 12 (=Comp. Portion) 0 1 1 0 1 1 0 0

0 0 1 0 1 0 0 0

Universal, Prim., 0 (End of Constructor) 0 0 0 0 0 0 0 0

Length 40

Length 0 0 0 0 0 0 0 0 0

Invoke compoenent

with tag, length, indicator,

invoke identifier,operation code

and argument

(see fig. 33)

End of Constructor

Orig. Trans. Id.

Component

Portion

Value of the Origination

Transaction Identity

Fig. 34 Begin message with Invoke component for "Update Location" (Example without Dialogue Portion)


TM3101EU01TM_000174


TM3101EU01TM_000175

4 Exercise


TM3101EU01TM_000176


TM3101EU01TM_000177

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

component

1 2 3 4

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 mobilestation?


TM3101EU01TM_000178

5. What is the difference between a constructor element and a primitiveelement?

6. A given type gets a new tag as a "Tagged Type" (explicit or implicit). Is thenew 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?


TM3101EU01TM_000179

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_000180


TM3101EU01TM_000181

5 Solution


TM3101EU01TM_000182


TM3101EU01TM_000183

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 thetransaction; 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 Endfollows at once, or the transaction is released locally.

3. Mark which components can exist for the four classes of operation!

class

component

1 2 3 4

Invoke X X X X

Return Result(Last)

X X

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 mobilestation?

MSC A sends MM and CM messages with Invoke "Forward AccessSignaling" to MSC B; MSC B forwards the messages to the mobilestation.

MSC B uses Invoke "Process Access Signaling" to forward to MSC A allMM and CM messages received from the mobile station.


TM3101EU01TM_000184

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 haveanother layout.

6. A given type gets a new tag as a "Tagged Type" (explicit or implicit). Is thenew type formed in this manner constructor or primitive?

Explicit: constructor always

Implicit: depends on whether the original type was constructor orprimitive

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

Date post:	12-Oct-2014
Category:	Documents
Upload:	abhinav-saini
View:	305 times
Download:	6 times

TCAP & MAP

Documents