map description

7/29/2019 MAP Description

1/57

MAP Presentation 1

1 General

This presentation shall give a brief introduction of the MAP pro-

tocol for mobile networks. In the first two sections the mobilenetwork structure and an overview of the most common networkoperations are presented for those, who have never been workingwith CME 20 or similar products.

The following chapters describe the standardized model, inwhich MAP is embedded. The system elements, where MAP is

based on are explained, focussing on their interworking towardsMAP.

In the final sections some features are discussed, which are use-ful for certain applications (e.g. unit design for MAP blocks orfunction test with MAP) and some information is given aboutdifferent MAP versions and variants (MAP V2 and EricssonMAP).


2/57

2 MAP Presentation

2 Network Structure

The GSM (Global System for Mobile Communications) networkcan be separated into two main parts. The Switching System andthe Base Station System. The Switching System is connected viathe Gateway MSC (Mobile Services Switching Center) to othernetworks, e.g. PSTN (Public Switched Telephone Network),ISDN (Integrated Services Digital Network) or other PLMNs(Public Land Mobile Network). The Base Station System pro-

vides the means for interconnection of the mobile stations byradio link.

All the different links between the networks and the networknodes are using CCITT Signalling System No.7 protocols, e.g.MAP (Mobile Application Part), TUP (Telephony User Part),ISUP (ISDN User Part) or BSSAP (Base Station System UserPart). The MAP protocol is specially designed for the mobile

network. It is mainly used to exchange data for the call setup (ortermination) and subscriber data in the network.

Two different types of signalling are distinguished in CCITTNo.7 networks: In the CAS (Channel Associated Signalling) net-works the signalling is always sent on the speech connection. Inthe more advanced CCS (Common Channel Signalling) the sig-

nalling is separated from the speech or data link.

The CCITT #7 signalling networks, which use CCS, can bedivided further regarding their connection type. It exists connec-tionless and connection-orientedsignalling. In the connection-oriented signalling a logical link is established between thesender and the receiver of the message. The message is alwaysfollowing the same path.


3/57

MAP Presentation 3

In the connectionless signalling, which is used for the MAP pro-

tocol, every message is containing the addresses of sender andreceiver. The messages are sent through the network like a pack-age, trying to find a way to the receiver. During an ongoing dia-logue every message might find a different path, compared to aprevious message.


4/57

4 MAP Presentation

Other Networks Base Station System

(BSC/BTS)ISDN

PSTN

PLMN

GSM Network Structure

Radio Connection toMobile Station

Figure 2.1 Network Structure

AUC

HLR VLR

Switching System

MSC

GMSC

AUC - Authentication CenterMSC - Mobile Services Switching CenterGMSC - Gateway MSCHLR - Home Location RegisterVLR - Visitor Location Register


5/57

MAP Presentation 5

3 Network Operations

The network operations or services for the mobile networks canbe distributed into groups of functionality. According to GSM09.02 (Phase 2) the following groups exist:

* Mobility Services* Operation and Maintenance Services* Call Handling Services

* Supplementary Services Related Services* Short Message Service Management Services

The elemental network services belong to the mobility and to thecall handling group, where the basic operations for call set-upand subscriber mobility are located. Some of the operations arementioned here as an example.

3.1 Mobility Services

The mobility services in MAP provide the necessary dataexchange to enable the roaming of the subscriber and to performhandover during calls with mobile subscribers.

Within this group another division can be done, reflecting thedifferent features of mobility. The following shows some of thesubgroups and mentions typical operations.

- The Location Management Services comprise the operationsfor Update_Location, Cancel_Location and related func-tionality.


6/57

6 MAP Presentation

- The Handover Services include all handover operations, suchas Perform_Handover or Perform_Subsequent_Handover, and

related operations like Send_End_Signal.

- The Subscriber Management Services are used to provide theVLR with subscriber data from the HLR using the operationsInsert_Subscriber_Data and Delete_Subscriber_Data.

Other subgroups support services related to data and networksecurity, fault recovery, paging of mobile subscribers and so on.

The picture on the next page shows the mentioned operations inthe PLMN.


7/57

MAP Presentation 7

Update_Lo

cation

Cancel_

Lo

cation

Insert_

Sub

scriber_Data

Delete_

Subscriber_Data

Perform_

Hando

ver

Perform_

Subsequent_Handover

Send_

End_

Sign

al

MSC/V

LR1

M

SC/VLR2

HLR

Figure 3.1 MAP operations/1


8/57

8 MAP Presentation

3.2 Call Handling Services

The call handling services cover all operations needed to set upcalls from and to mobile subscribers. In contrast to the mobilityservices the call handling services are not further divided. Theoperations from this group, which are supported in CME areSend_Routing_Information and Provide_Roaming_Number. Allother call handling operations are used between MSC and VLR.In CME this network nodes are not separated and therefore not

connected via a CCITT #7 interface, but by an internal signallinginterface (software signals). The two mentioned operations areused as shown below.

Send_Routing_Information

Provide_Roaming_Number

GMSC

HLR

MSC/VLR

Figure 3.2 MAP operations/2


9/57

MAP Presentation 9

4 OSI Model

The OSI (Open System Interconnection) Model is used todescribe the structure of communication systems. The principleis the division of the entire system into seven hierarchical layers.Every layer has a certain task to fulfil. The model applies as wellto our mailing system, and its elements can be used for a betterunderstanding of the different layers.

The same layers work in a similar way on the receivers side. Theexample shows, that every layer takes the message from the pre-

vious layer and modifies it, adds something or changes theappearance of the message.

layer signification

APPICATION author of a letter to a foreign friend

PRESENTATION translator from the authors language to the friends language

SESSION secretary, who types the letter

TRANSPORT postman fetches the letter from the secretary

NETWORK sorter finds out, where the letter has to be sent

DATA-LINK packer puts the letter together with other letter

PHYSICAL mail bus transports the letter to the appropriate receiver

Table 1: Example for an application of the OSI model


10/57

10 MAP Presentation

PRESENTATION

SESSION

TRANSPORT

NETWORK

DATA-LINK

PHYSICAL

APPLICATION AUTHOR

TRANSLATOR

SECRETARY

POSTMAN

SORTER

PACKER

MAIL BUS

Figure 4.1 OSI layers


11/57

MAP Presentation 11

4.1 CCITT #7 in the OSI Model

The mobile signalling network can be interpreted as well bymeans of the OSI model, but only four of the seven layers apply.Compared to the example these are the author and the wholemailing infrastructure, except the postman. The analogon to theauthor is MAP together with TCAP (Transaction CapabilityApplication Part). The tasks of the mail are carried out by SCCP(Signalling Connection and Control Part) and MTP (MessageTransfer Part

).

SCCP and MTP

MTP is representing layers 1, 2 and a part of layer 3. It providesthe means for transport and delivery of the information, that iscreated by MAP. It also takes care that this transport is per-

formed in a reliable way, concerning data safety.

SCCP is located in layer 3 and handles the coordination and therouting of the messages, that are received from higher layers. Itinterfaces directly to TCAP, that resides in the application layer.The layers 4 to 6 of the OSI model are not used by the CCITT #7signalling network.


12/57

12 MAP Presentation

MAP

TCAP

SCCP

MTP

Figure 4.2 MAP in the OSI model


13/57

MAP Presentation 13

5 TCAP Survey

TCAP is defined and described by CCITT in the recommenda-tions Q771 to Q775. For the time being two issues of this recom-mendations apply to the TCAP used for CME20. The relevantbook series are the blue and the white books. In accordance tothis we distinguish blue and white TCAP. The followinginformation applies to both versions.

5.1 TCAP Characteristics

Dialogue Type

- structured (thats what we use in CME20)- unstructured (only unidirectional messages)

Dialogue Class

The four different classes show which kind of answer can beexpected, if a dialogue for a certain class is initiated.

Class Feature

1 success and failure reported

2 only failure reported

3 only success reported4 neither success nor failure reported

Table 2: TCAP dialogue classes


14/57

14 MAP Presentation

5.2 TCAP Message Structure

The TCAP messages always consist of the same elements, the socalled portions, that always keep the same order. They areframed by the message type tag and the length indicator for thetotal message length. For the whole structure see figure 5.1.

Transaction Portion

Contains an identity, that allows to distinguish different dia-logues, that are handled at the same time.

Dialogue Portion

Consists of two elements, the application context(AC) and theuser information (UI). The application context specifies the pro-tocol type and version that is using TCAP. The user information

can contain any information, that is exchanged between twoTCAP-users, but is not part of a component. Its meaning dependson the protocol specified by the application context.

The dialogue portion is defined for white TCAP only. Thatmeans, that only one protocol is specified as a TCAP-user forblue TCAP. This protocol is specified in GSM 09.02 (MAP). In a

blue TCAP message the dialogue portion is not present.

More details about the dialogue portion can be found in the chap-ter about MAP V2 features.

Component Portion

Comprises the invoke identity, the operation code and the param-


15/57

MAP Presentation 15

eters (data) and is framed by the component type tag and therelated length value. The invoke identity allows to distinguish

between different operations within one dialogue. The operationcode identifies the operation according to the appropriate proto-col specification.

In the parameter field resides the actual MAP data, which isincluded here by the TCAP user. The structure of the entire mes-sage is shown in the next picture.


16/57

16 MAP Presentation

Operation Code Length

Operation Code Tag

Message Type Tag

Message Length

Transaction Portion

Dialogue Portion

Component Portion Tag

Component Portion Length

Component Type Tag

Component Type Length

Invoke ID

MAP message

(Operation Code + Data)

Figure 5.1 Structure of a TCAP message


17/57

MAP Presentation 17

5.3 TCAP Dialogue Structure

To describe a dialogue on TCAP level, it is useful to show onlya few of the elements mentioned in the previous chapter. Themost characteristic parts from TCAP point of view are the mes-sage (type) and the component. The message (type) can be inter-preted as the envelope of the dialogue, that indicates the kind ofmessage that is sent. The component can be compared to letter,containing the message information itself.

As a concept for the TCAP dialogues, the term dialogue in thefollowing shall be used to refer to the message level, while oper-ations are describing activities on the parameter level.

Normally a component (letter) is put into an message (envelope)and is sent to the receiver. Different types of messages are usedto start and finish a dialogue or to continue it. All message types

needed for structured dialogues are listed in the following table.Since MAP only uses structured dialogues, the unstructured dia-logues are not further examined in this context.

Note: 1) Two different ABORT messages exist user (TC-user) and provider

(TCAP) ABORT

Message type Usage

BEGIN Starts the dialogue

END Terminates the dialogue

CONTINUE Keeps the dialogue ongoing in both direct.

ABORT1) Aborts dialogue (protocol violation)

Table 3: TCAP message types


18/57

18 MAP Presentation

Within a dialogue operations can be started, continued and termi-nated successfully or unsuccessfully.

Note: 1) Two different REJECT components exist, one for local and one for a

remote REJECT, but this affects only the handling within the entities and not the

dialogue between them.

Depending on the purpose of the feature, one or more operationsare carried out during a dialogue. The sequence on the followingpage shows an example how a typical TCAP dialogue can looklike.

During the dialogue two operations are performed (oper1 andoper2). The first operation is started by sending an INVOKE

component in a BEGIN message. By reception of this messagethe receiving side invokes the second operation in a CONTINUEmessage. The second operation is framed by the first operation sothat the result for the second operation is sent next.Here thereceiver detects a problem and reports an error in the END mes-sage to the entity where the operation was invoked.

Component Usage

INVOKE Starts the operation

RESULT Carries result for successfully executed operat.

ERROR Reports reason for failure of operation

REJECT 1) Indicates protocol viol. on component sublayerCANCEL Terminates operation (e.g. due to time-out)

Table 4: TCAP component types


19/57

MAP Presentation 19

SENDER RECEIVER

TCAP Dialogue

BEGIN

INVOKE oper1

CONTINUE

INVOKE oper2

CONTINUE

RESULT oper2

END

ERROR oper1

(local TCAP) (remote TCAP)

Figure 5.2 Example for TCAP dialogue


20/57

20 MAP Presentation

To carry out a structured dialogue the following combinations ofmessages and components are allowed:

Notes:1) This combinations are only allowed in a certain state of a dia-

logue or under certain conditions.

2) An ABORT message is always sent empty.

3) A Cancel component is always sent without message.

BEGIN CONTINUE END ABORT

INVOKE allowed allowed allowed 1) 2)

RESULT not allowed allowed allowed 2)

ERROR not allowed allowed 1) allowed 2)

REJECT not allowed allowed 1) allowed 2)

CANCEL 3) 3) 3) 2) 3)

Table 5: Allowed combinations of messages and components


21/57

MAP Presentation 21

6 Specification of Operations

As already mentioned, GSM has defined the MAP protocol intheir recommendation 09.02. The Ericsson implementation ofthis protocol is not always fully compliant to this specification.Therefor exist separate specifications on functional level, thatdescribe in detail how the CME 20 solution looks like.

This specifications are based on network entities, so that separate

documents can be found for MSC/VLR, GMSC, HLR and so on.

Besides a complete set of these documents is issues for everyversion and every variant of MAP. Up to now, two versions ofthe protocol are defined, based on the GSM (development-)phases 1 and 2. For several reasons (later explained in the chapterMAP variants and versions) an Ericsson specific set of opera-tions had to be defined as well.

Therefore a notable number of documents has to be maintained,the list below shows only the documents, specifying MAP forMSC/VLR (corresponding documents exist for all other networknodes):

* CCITT Signalling System No.7, MAP V1 in MSC/VLR

* CCITT Signalling System No.7, MAP V2 in MSC/VLR

* Ericsson Variant CCITT Signalling System No.7, MAP V1 in MSC/VLR* Ericsson Variant CCITT Signalling System No.7, MAP V2 in MSC/VLR

Besides general MAP information, these documents contain ashort description of every applicable operation, the formaldescription of the operation parameters (compare section aboutASN.1) and the signalling sequences similar to the TCAPsequence of the previous chapter.


22/57

22 MAP Presentation

7 TCAP MAP Interface Specification

In the proceeding sections the TCAP dialogue and the elementsof a TCAP message have been explained. This chapter shows theimplementation and more intensive the usage of TCAP. It will befocused on the interface towards TCAP. TCAP is realized as anumber of software blocks. The interwork towards the softwareblocks, that handle MAP messages is done via an internal signalinterface.

The task of these MAP blocks (TC-user) is now to include theparameters of the prepared MAP message (operation code anddata, figure 4) into the appropriate component and message type(chapter 3.3) according to the definition of the dialogue.

On this level a distinction of incoming and outgoing dialogues isuseful. However, in both cases the same software signals apply

and the handling of the parameters is comparable. For all incom-ing dialogues the same function block is attached to the TCAPblocks. This message handler checks all incoming messages onthe availability of a specific handler for the invoked operation. Inthe successful case the dialogue is handed over to the appropriateMAP block and the new block is indicated to TCAP. For outgo-ing dialogues (usually) only the handler of the MAP message is

linked to TCAP for the whole time.

The Handling of every dialogue can be divided into severalphases, each of them is performed by certain signallingsequences. Some of this phases are optional and are not men-tioned here, a design rule with the title CCITT, InterworkDescription Connectionless White TCAP TC-User isdescribing them all in detail.


23/57

MAP Presentation 23

7.1 Outgoing Dialogues

Dialogue Seizure

In the first step, the availability of TCAP is verified. The signalC7DIALSEIZREQ requests TCAP to handle a new dialogue. IfTCAP is able to do this, it acknowledges with signalC7DIALGRANTED, else signal C7DIALDENIED is returned.

TC-User TCAP

C7DIALSEIZREQ

C7DIALGRANTED

C7DIALDENIED

case result of seizure

Figure 7.1 C7-Signalling/seizure


24/57

24 MAP Presentation

Dialogue Portion Control (Transmission)

If the dialogue shall be carried out in a protocol version differentfrom MAP V1 the next step after the seizure of TCAP is toinclude the dialogue portion (DP) in the message. The inclusionis requested by sending the signal C7DIPORTREQ to TCAP.

The return signal C7DIPORTREQACC allows the insertion ofthe DP and carries the index and the reference of the TCAP

buffer. The DP is now written directly into the buffer. Moreinformation about the contents of the DP and the insertion of datainto dynamic buffers is presented in the section MAP V2 fea-tures. The unsuccessful outcome of the request is indicated withsignal C7DIPORTREQNACC.

TC-User TCAP

C7DIPORTREQ

C7DIPORTREQACC

C7DIPORTREQNACC

case result of DP request

write DP into buffer

Figure 7.2 C7-Signalling/DP-control


25/57

MAP Presentation 25

Invoke Component Control

Since every dialogue has to start with the invocation of an opera-tion, the inclusion of this component has to be requested now.The related signal C7INVOKEREQ can be answered withC7INVOKEREQACC or C7INVOKEREQNACC for sucessfulor unsucessful case respectively. In case of acceptance of therequest, the buffer index and the buffer reference are received inthe acknowledge signal and the MAP message is written into the

TCAP buffer.

Since it is possible to start more than one opeartion at the sametime, this procedure can be repeated for every invocation. Theinclusion of several components into one message is generallycalled grouping, but applies to a few dialogues only.

TC-User TCAP

C7INVOKEREQ

C7INVOKEREQACC

C7INVOKEREQNACC

case result of request

write MAP message

for invocation

into buffer

Figure 7.3 C7-Signalling/invocation


26/57

26 MAP Presentation

Begin Message Control

The message, that starts the dialogue contains now everything,that is needed to send it, except the message type. With the indi-cation of Begin as the required message type in signalC7BEGINREQ the TCAP message can be sent to the remoteside. Similar to the proceeding sequences the request is acknowl-edged with the signals C7BEGINREQEXEC for executed andC7BEGINREQNEXEC for not executed message sending.

TC-User TCAP

C7BEGINREQ

C7BEGINREQEXEC

C7BEGINREQNEXEC


send TCAP message

to send BEGIN message

BEGIN (INVOKE)

Figure 7.4 C7-Signalling/dialogue begin


27/57

MAP Presentation 27

Backward Message Control

After sending the Begin message the remote TCAP can answerwith a various number of messages, depending of the structure ofthe dialogue, operation class, the sent data, etc. The returnedmessage must correspond to one of the three remaining messagetypes (CONTINUE, END or ABORT). For sure a BEGIN mes-sage might be received as well mistakenly, but this kind of sys-tem failures shall not be covered here. Therefore the following

signals have to be handled by the TC-user.

C7CONTINDC7ENDINDC7PABORTC7UABORTINDC7TCNOTICEC7CANCELIND

The TC-Notice indication can be received in case a message wasreturned to TCAP. The indication that a dialogue was canceled,is received if TCAP timed a dialogue out, because the maximumwaiting time for a reply was exceeded.


28/57

28 MAP Presentation

TC-User TCAP

C7DIALINDR

C7PABORTIND

C7CONTIND

C7DIALINDRacknowledgemessageindicationdialogue terminated

if Continue or End re-ceived, the component isexpected next(*see next chapter*)

Reception*)

Figure 7.5 C7-Signalling/backward message


29/57

MAP Presentation 29

Backward Component Control

After the handling of the message type the component, that wasincluded in the message is now indicated to the TC-user. Possiblecomponents are INVOKE, RESULT, ERROR, CANCEL andREJECT. Again these indications are transported in a number ofsignals.

TC-User TCAP

C7LTERMREQ

(... case next event fromTCAP)

C7CANCELIND

the TCAP to TCAPdialogue is alreadyfinished, the TC-userTCAP dialogue is nowlocally aborted

C7LTERMREQRlocal termination executed

Figure 7.6 C7-Signalling/backward message cancel


30/57

30 MAP Presentation

TC-User TCAP

C7OPINDR

C7CANCELIND

C7INVOKEIND

C7OPINDRacknowledgeoperationindicationdialogue terminated

not expected, thedialogue is abortedlocally

C7LTERMREQ

C7LTERMREQR

Else read data frombuffer if present

to continue or finishdialogue(* see chapter DialogueContinuation *)

Figure 7.7 C7-Signalling/backward component


31/57

MAP Presentation 31

Dialogue Portion Control (Reception)

The signals C7DPINFOREQACK are used to fetch the informa-tion about the contents of the DP. The return signal containsbuffer index and reference for the elements of the DP, the appli-cation context and the user information.

TC-User TCAP

C7DPINFOREQ

C7DPINFOREQACKFetch DP information

read DP from buffer

The contents can beanalyzed now

Figure 7.8 C7-Signalling/DP reception


32/57

32 MAP Presentation

Dialogue Continuation

The Dialogue reached now the full duplex state. Either theremote or the local side can send the next message. In the firstcase the chapter for the backward message control applies,except for the check of the DP when a CONTINUE or an ENDmessage is received. Similar to the begin of the dialogue the mes-sage is built when the local TC-user wants to sent data. Possiblemessage types are CONTINUE, END, ABORT containing

INVOKE, RESULT, ERROR or REJECT components, whichare requested first.

TC-User TCAP

C7INVOKEREQ

C7INVOKEREQACC

C7INVOKEREQNACC


write MAP messageinto buffer

C7RESULTREQC7ERRORREQ

C7REJECTREQ

C7RESULTREQACCC7ERRORREQACCC7REJECTREQACC

C7RESULTREQNACCC7ERRORREQNACCC7REJECTREQNACC

(* request mess. type*)

Figure 7.9 C7-Signalling/continuation/component


33/57

MAP Presentation 33

The dialogue proceeds now in this way until a regular (END) orprearranged end (ABORT, ERROR, REJECT, CANCEL)occurs. It shall be noted, that in case of a requested abortion theDP has to be included in some cases, using the known procedure(see DP control).

TC-User TCAP

C7CONTREQ

C7CONTREQNEXEC


send TCAP message

to send message

C7ENDREQC7ABOTRREQ

C7CONTREQEXECC7ENDREQEXECC7ABORTREQEXEC

C7ENDREQNEXECC7ABORTREQNEXEC

Figure 7.10 C7-Signalling/continuation/message


34/57

34 MAP Presentation

7.2 Incoming Dialogues

The incoming dialogues are handled in a very similar wayregarding the interface TC-user-TCAP. The differences aremainly related to the DP handling. The DP has to be checkedwith the reception of the BEGIN message and has to be insertedin the first return message. Furthermore no seizure of TCAP isperformed.

7.3 Example SendRoutingInformation

The following example lists the complete sequence of the TC-user-TCAP interworking for the successful execution of theOperation SendRoutingInformation. The operation is fairly sim-ple regarding the dialogue. The Begin message containing theInvoke component is answered with an END carrying a

RESULT. Additionally it shall be noted that two types of resultsexist, that are the last-result-type and the not-last-result-type. Inthis example obviously the last-result-type is used. The operationis carried out with MAP V2, every request is answered positiveand the result is received as expected.

The purpose of the operation is to retrieve in GMSC via HLR

information about the location of the called subscriber providede.g. as a roaming number.


35/57

MAP Presentation 35

GMSC

TC-user (GAP) TCAP

C7DIALSEIZREQ

C7DIALGRANTED

C7DIPORTREQC7DIPORTREQACC

C7INVOKEREQ

C7INVOKEREQACC

HLR

TCAP

C7BEGINREQ

C7BEGINREQEXEC

BEGIN

INVOKE (SendRoutingInfo)

(contd)

Write MAP data to TCAP buffer

Write DP to TCAP buffer

Figure 7.11a C7-Signalling/SRI


36/57

36 MAP Presentation

GMSC

TC-user (GAP) TCAP

HLR

TCAP

END

RESULT-L (SendRoutingInfo)C7ENDIND

C7DPINFOREQ

C7DIALINDR

Read DP from TCAP buffer

C7DPINFOREQACK

C7OPINDR

Read result data from TCAP buffer

C7RESULTIND

(end)

Figure 7.11b C7-Signalling/SRI


37/57

MAP Presentation 37

8 ASN.1

ASN.1 stands for Abstract Syntax Notation One and is an inter-national standardized way of describing application layer proto-col information. The application of its rules provides a uniquedefinition of the contents of the data fields (components) for allMAP operations. ASN.1 can be compared to a (programming)language that allows every user to read and write information ina way, that any other user can easily recover the proper informa-

tion.

Since the subject of ASN.1 is rather complex only a rough over-view shall be presented here.

The ASN.1 standard is defined in CCITT recommendationsX.208 (notation) and in X.209 (encoding rules). The notationdescribes e.g. types, tags and structures. The encoding rules

deliver the tool to translate a set of values into a sequence of data,based on the ASN.1 formal description.

8.1 Notation

The principle of structuring data is the tagging of it. The ASN.1

tag identifies a data in a similar way as it is done for structuringthe TCAP message. The structure always consists of tag, lengthand contents, the contents might have substructures following thesame principles.


38/57

38 MAP Presentation

The Tag itself (in some cases it is called as well identifier) is a 8-bit word and consists of three elements: The two most significantbit are called class and describe the validity of the tag. The classcan be either universal, application wide, context specific or pri-vate. The next bit indicates, whether the contents following this

tag is sub-structured (constructor) or not (primitive). The remain-ing five (least significant) bit represent the type (or number), thatcorresponds to the contents.

TAG

LENGTH

CONTENTS

TAG

LENGTH

CONTENTS

Figure 8.1Data structure

01234567

Class Form Tag Type

Bit

Figure 8.2 Coding of the Tag/Identifier


39/57

MAP Presentation 39

bit 7 bit 6 signification0 0 universal

0 1 application wide

1 0 context specific

1 1 private use

Table 6: Class

bit 5 signification

0 primitive

1 constructor

Table 7: Form

bit 0-4decimal

significationbit 0-4decimal

signification

1 BOOLEAN 17 SET (OF)

2 INTEGER 18 NumericString

3 BIT STRING 19 PrintableString

4 OCTET STRING 20 TelexString

5 NULL 21 VideotexString

Table 8: Tag Type


40/57

40 MAP Presentation

The table with the tag types only applies to the tags of class uni-versal. This means they are generally defined standard types thatcan be used everywhere. Every type is assigned to one of the fourgroups SIMPLE, STRUCTURED, CHARACTER STRING orUSEFUL. The types used in MAP belong mainly to the first twogroups.

6 OBJECT IDEN-TIF.

22 IA5String

7 ObjectDescriptor 23 UTCTime

8 EXTERNAL 24 GeneralizedTime

9 REAL 25 GraphicString

10 ENUMERATED 26 VisibleString16 SEQUENCE (OF) 27 GeneralString

SIMPLE STRUCTURED

BOOLEANINTEGERENUMERATEDREALBIT STRINGOCTET STRINGNULLOBJECT IDENTIFIER

SET (OF)SEQUENCE (OF)CHOICE 1)ANY 1)

Table 9: Common tag types used in MAP

bit 0-4decimal

significationbit 0-4decimal

signification

Table 8: Tag Type


41/57

MAP Presentation 41

Note: 1) This types belong to group STRUCTURED, but since they only appear in

the ASN.1 formal description, they dont have assigned any tag and are not

included in table 8.

If the class of the tag is different from universal, the contents ofthe tag type has to be defined by the user. In the case of MAP theapplication wide definitions are valid for the whole MAP. Thecontext specific tags are defined on one structure level only (in aSEQUENCE of one operation) and the private tags are used inthe Ericsson variant of MAP.

8.2 Encoding Rules

Instead of translating certain data into the appropriate ASN.1code, an existing ASN.1 description shall be analyzed in thischapter using the basic encoding rules (BER). At the end theactual sequence of all octets that form the MAP message shall beretrieved. This is exactly the proceeding when coding an opera-

tion-handling software block.

This structure in figure 8.3 shows the ASN.1 description for theoperation SendRoutingInformation, as it is defined in the Func-tion Specification for MAP V1. In the first line the operationname and the sending and receiving entities are mentioned. Theoperation code for SendRoutingInformation (SRI) is 22. This is

already the first octet in our MAP message. Further it is stated,that SRI is a class-one operation. According to chapter 5.1, thismeans success and failure of the operation are reported.

The ASN.1 description of the operation is divided into three sec-tions. The section PARAMETERS contains the definition of thedata that is included in the invoke component. The sectionRESULT shows the data in the corresponding components that


42/57

42 MAP Presentation

indicates success. The error types are imported from a separateERROR module.


43/57

MAP Presentation 43

SEND ROUTING INFORMATION (GMSC-->HLR)

Operation Code=22

Class=1

ASN.1 Formal Description

SendRoutingInformation ::= OPERATION

PARAMETERS SEQUENCE {

msIsdn (0) IMPLICIT IsdnAddressString,

numberOfForwarding (2) IMPLICIT NumberOfForwarding

OPTIONAL,networkSignalInfo (10)IMPLICIT ExternalSignalInfo

OPTIONAL}

RESULT SEQUENCE {

imsi IMSI

routingInfo CHOICE{

roamingNumber IsdnAddressString,

forwardingData ForwardingData}}

ERRORS {

SystemFailure,

DataMissing,

UnexpectedDataValue,

FacilityNotSupported,

UnknownSubscriber,

BearerServiceNotProvisioned,

TeleServiceNotProvisioned,

AbsentSubscriber

CallBarred

CUG-Reject,

ForwardingViolation}

Figure 8.3 ASN.1 example


44/57

44 MAP Presentation

The situation before the operation shall be as follows: A callattempt towards a mobile subscriber reached the GMSC. The call

is a normal call originating in PSTN and the roaming numbershall be fetched via HLR. The call was forwarded once before itarrived at the GMSC. This situation requires the MSISDN (this isthe number, that was dialled by the calling subscriber) and thenumber of forwardings (here: 1) to be sent to the HLR.

The order of the data is taken directly from the ASN.1 code. Theadditional data of networkSignalInfo is optional and therefore

omitted. The data are formally put into a sequence, i.e. a specialtag is used to show that a number of data is sent sequentially.

Sequence Tag = H30

Total Length

Data1 Tag (MSISDN)

Data1 Length

Data1

Data2 Tag (NumOfForw.)

Data2 Length

Data2

Figure 8.4 Data in a sequence


45/57

MAP Presentation 45

Figure 8.4 shows the sequence as it will look like in the examplefor SRI. The missing information are the tags of the parameters,

the lengths and the contents of the data fields, which for surecould be sub-structured.

The left column lists the parameters, while the right columndefines them. Each definition leads to a type that is separatelydefined or to a universal type. According to this the IsdnAd-dressString and NumberOfForwarding type definitions areneeded, because they are not universal.

If the ASN.1 description is checked further regarding the investi-gated parameters two things are remarkable: The value in theparenthesis (0 and 2) and the IMPLICIT indicator. In ASN.1 it isdistinguished between implicit and explicit tagging. If a typedeclaration of a non-universal parameter is based on a universaltype the explicit tagging encapsulates the original parameter,

while the implicit form replaces it.

2 2 12345INTEGER (=#12345)

Original Type and Value:

2 2 12345[6] INTEGER

Explicit tagging:

4A6

86 2 12345[6] IMPLICIT INTEGER (=#12345)

Implicit tagging:

Figure 8.5 Implicit and explicit tagging

(=#12345)


46/57

46 MAP Presentation

In the example in figure 8.5 the tag value for the explicit tag is 6and the whole identifier has the value A6 (class: context spe-

cific=10; form: constructor=1). The identifier in the implicit tag-ging is equal to 86 (class: context specific=10; form:primitive=0).

Consequently it is easy to recognize, that the parameters of theSRI message use the implicit tagging. The next step is to exam-ine the declaration for the types in the right column. In the func-tion specification the following is stated about the

IsdnAddressString:

IsdnAddressString ::= AddressString (SIZE (1..maxIsdnAddressLength))

maxIsdnAddressLength = 9 octets

This leads to the definition of the AddressString and limits itslength to 9 octets, even though the Address string is allowed to

consist of 20 octets.

AddressString ::= OCTET STRING (SIZE (1..maxAddressLength))

maxAddressLenght = 20 octets

a) The first octet includes a one bit extension indicator, a 3-bit nature of

address indicator and a 4-bit numbering plan indicator.

b) Subsequent octets representing address digits encoded as a TBCD-

STRING parameter.

Bit 8: Extension indicator

1 no extension

Bit 7-5: Nature of address indicator

000 unknown

001 international number

010 national significant number

011 network specific number


47/57

MAP Presentation 47

100 subscriber number

101 reserved

110 abbreviated number

111 reserved for extensionBit 4-1: Numbering Plan indicator

0000 unknown

0001 ISDN/telephony numbering plan (Rec. CCITT E.164)

0010 spare

0011 data numbering plan (Rec. CCITT X.121)

0100 telex numbering plan (Rec. CCITT F.69)

0101 spare

0110 land mobile numbering plan (Rec. CCITT E.212)

0111 spare1000 national numbering plan

1001 private numbering plan

1010-1110 reserved

1111 reserved for extension

TBDC-STRING ::= OCTET STRING

bits 4321 of octet n are encoding digit 2n-1

bits 8765 of octet n are encoding digit 2n

4th digit

6th digit

1st digit

3rd digit

5th digit

2nd digit

4 3 2 16 58

octet 3 of contents

octet 2 of contents

octet 1 of contents

octet n of contents(2n-1)th digit2nth digit

7


48/57

48 MAP Presentation

The first octet contains the numbering plan indicator and thenature of address indicator. The corresponding numbering plan is

telephony (E.164) and the nature of address is international. Theextension bit is set to 1, therefore the entire octet has the valueH91. The called number was 4917212345, so the total length ofthe address string is 6 octets. The identifier for the wholeMSISDN is a context specific (10) primitive (0) with the implicittag 0.The coding looks as follows

With the definition of the number of forwardings the coding ofthis parameter is done in the same way:

NumberOfForwarding ::= INTEGER (1..5)

The complete MAP message including the operation code cannow be coded by combining the existent elements.

80 06 91 94 71 12 32 54

lengthcontents

Figure 8.7 Coding of the MSISDN

identifier(tag)

82 01 01Figure 8.8 Coding of the number of forwardings


49/57

MAP Presentation 49

Sequence Tag

Total Length

MSISDN Tag

Length

MSISDN

Number ofForw. Tag

Length

Number of Forwardings

Operation Code 22

30

0B

80

06

919471

123254

82

01

01

hex value

Figure 8.9 Coding of the SendRoutingInfo message


50/57

50 MAP Presentation

Length Coding

Sequence Tag = H30

Total Length

MSISDN Tag

Length

MSISDN

Number ofForw. Tag

Length

Number of Forwardings

Operation Code


51/57

MAP Presentation 51

The format of the length octets in MAP message is derived byapplying the related encoding rules. It is important to know about

all possible length formats, because each of them can be receivedin a message. Basically three different formats are used, the shortform, the long form and the indefinite form.

The short form is used, if the length of the covered data is lessthan 128 octets. The value is explicitly coded in the length octet.

The long format can be used, if the length is more than 127

octets. The coding needs then more than one octet. The firstlength octet has a value bigger than h80. The least significant 7bits indicate the number of subsequent octets that are indicatingthe actual length. Since TCAP doesnt support messages longerthan 256 octets (in one go), there will be usually the value h81 inthis octet.

The indefinite form can be used for any length. It must not beused for primitives, but only for structures, so that on the deepestlevel of the structure a definite form is employed (either long orshort format). The length octet contains in case of indefinite formalways the value h80 and the data structure is terminated withtwo octets of zeros (End-of-Contents indicator).


52/57

52 MAP Presentation

Figure 8.10 Coding of the length octets

octets with length relevant information

data field, containing 16 (=h10) octets

Tag Tag Tag

#81#10

#10 *)

*) Note: For this length value the short formshould have been used, but the exampleis only used to show the differences of the

00

00

#80

short form

long form

indefinite form

forms


53/57

MAP Presentation 53

9 MAP Versions and Variants

As already mentioned in the proceeding sections MAP is existingin a number of different issues. Actually in Ericsson four differ-ent MAPs can be found. It is distinguished between MAP ver-sions and MAP variants. The term version is used if the base isthe standard MAP as it is defined by GSM. Especially no addi-tional data within the messages are allowed compared to thestandard, but some minor deviations can always be expected.

The main requirement is the fault-free (and all standard servicessupporting) interworking of different network entities from dif-ferent vendors or independently working design offices. MAP isdivided according to the GSM recommendation developmentinto two issues named MAP V1 (GSM phase1) and MAP V2(GSM phase2).

The MAP variants comprise operations similar to the GSM stan-

dard, but private data is allowed here and in some cases even pri-vate operations are created. The reason for that is the customerrequirement for certain services that are not standardized yet orcan not be handled within the standard operations. Anyway thevariant operations are based on the existing GSM operations andtherefore the issues of the MAP variants are aligned with them.

9.1 MAP Versions MAP V1 and MAP V2

The main difference of the change from MAP V1 to MAP V2was the introduction of the dialogue portion (DP). The two ele-ments of the DP are the application context (AC) and the userinformation (UI).


54/57

54 MAP Presentation

Application Context

The AC refers to the required protocol (including the version)

and the list of operation packages (i.e. set of operations) fromwhich operations can be invoked during the dialogue. Thereforthe AC is divided into three parts. The first part gives an exactreference to the protocol and consists of five octets. The secondand third part are represented by one octet each and correspondto the name of the application context (or application-context-name) and to the protocol version.

The values of the reference part are fixed, while the application-context-name values are defined in GSM 09.02. The protocolversion has usually the value 2, because if version 1 is used noAC is present at all.

If the application-context-name and the protocol version, whichwere proposed in an invocation, can be supported by the

protocol reference

application-context-name

protocol version

ccitt identified organization = 04

etsi = 00

mobileDomain = 00

gsm-network = 01

acid = 00

is always identicalfor existing MAPs

Figure 9.1 Coding of the AC


55/57

MAP Presentation 55

responding entity the dialogue continues on this basis, otherwiseit is refused and the initiating user needs to start a new dialogue

using an AC with a lower protocol version. This is called fall-back.

The AC-names are defined in two steps. All operations areassigned operation packages, that include operations with certainrelations (e.g all operateSS services like registerSS, eraseSS,activateSS, etc.). The AC-names are based on these packages andit is possible that some packages are included in more than one

AC-name (see e.g. SubscriberDataMngtPackage).

In the present implementation of MAP V2 in CME20 the follow-ing AC are supported:

The packages in turn are containg the operations according totable 11.

Application Context Operation Package Interface

locationInfoRetrievalContext Interrogation Package GMSC-HLR

networkLocUpContext LocationUpdatingPackage

DataRestorationPackageSubscriberDataMngtPackage

TracingPackage

HLR-VLR

roamingNumberEnquiryContext RoamingNumberEnquieryPackage HLR-VLR

subscriberDatMngtContext SubscriberDataMngtPackage HLR-VLR

Table 10: Relation between AC and packages


56/57

MAP Presentation 56

The resulting relation between the ACs and the operations caneasily be retrieved with these tables, these tables can be found inthe function specifications for MAP V2 of CME20.

User Information

The User Information UI in the dialogue portion is used to carryinformation, that is defined by the protocol, referenced to in theAC. In MAP it is used to carry the reason code for U-ABORTmessages, which can result in an reattempt or fall-back.

9.2 Ericsson MAP Variants

Aligned to the standard MAP, the Ericsson variants do have aswell versions 1 and 2. The special Ericsson specific services thatare supported with this MAP issues are the following:

Operation Package Operation

InterrogationPackage sendRoutingInfo

LocationUpdatingPackage updateLoacation

DataRestorationPackage restoreData

SubscriberDataMngtPackage insertSubscriberDatadeleteSubscriberData

TracingPackage activateTraceModedeactivateTraceMode

RoamingNumberEnquieryPackage provideRoamingNumber

Table 11: Relation between packages and operations


57/57

MAP Presentation 57

(Status: End 1993, after CME20 SS Phase 3)

* TIN Terminating Intelligent Network Service* OIN Originating Intelligent Network Service* SPN Single Personal Number Service* ICI Immediate Call Itemization* DN Dual Numbering

A view to the future indicates already now the introduction ofoperations that have nothing in common with the existing stan-

dard operations and are especially designed to support and per-form Ericsson specific services.

map description

Documents