MAP Presentation

1 General This presentation shall give a brief introduction of the MAP protocol for mobile networks. In the first two sections the mobile network structure and an overview of the most common network operations are presented for those, who have never been working with CME 20 or similar products. The following chapters describe the standardized model, in which MAP is embedded. The system elements, where MAP is based on are explained, focussing on their interworking towards MAP. In the final sections some features are discussed, which are useful for certain applications (e.g. unit design for MAP blocks or function test with MAP) and some information is given about different MAP versions and variants (MAP V2 and Ericsson MAP).

MAP Presentation

2 Network Structure The GSM (Global System for Mobile Communications) network can be separated into two main parts. The Switching System and the Base Station System. The Switching System is connected via the Gateway MSC (Mobile Services Switching Center) to other networks, e.g. PSTN (Public Switched Telephone Network), ISDN (Integrated Services Digital Network) or other PLMNs (Public Land Mobile Network). The Base Station System provides the means for interconnection of the mobile stations by radio link. All the different links between the networks and the network nodes 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 User Part). The MAP protocol is specially designed for the mobile network. It is mainly used to exchange data for the call setup (or termination) and subscriber data in the network. Two different types of signalling are distinguished in CCITT No.7 networks: In the CAS (Channel Associated Signalling) networks the signalling is always sent on the speech connection. In the more advanced CCS (Common Channel Signalling) the signalling is separated from the speech or data link. The CCITT #7 signalling networks, which use CCS, can be divided further regarding their connection type. It exists connectionless and connection-oriented signalling. In the connectionoriented signalling a logical link is established between the sender and the receiver of the message. The message is always following the same path.

MAP Presentation

In the connectionless signalling, which is used for the MAP protocol, every message is containing the addresses of sender and receiver. The messages are sent through the network like a package, trying to find a way to the receiver. During an ongoing dialogue every message might find a different path, compared to a previous message.

MAP Presentation

GSM Network Structure

AUC

MSC GMSC

HLR

VLR

Switching System

Other Networks ISDN PSTN PLMN

Base Station System (BSC/BTS) Radio Connection to Mobile Station

AUC - Authentication Center MSC - Mobile Services Switching Center GMSC - Gateway MSC HLR - Home Location Register VLR - Visitor Location Register

Figure 2.1 Network Structure

MAP Presentation

3 Network Operations The network operations or services for the mobile networks can be distributed into groups of functionality. According to GSM 09.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 the call handling group, where the basic operations for call set-up and subscriber mobility are located. Some of the operations are mentioned here as an example. 3.1 Mobility Services The mobility services in MAP provide the necessary data exchange to enable the roaming of the subscriber and to perform handover during calls with mobile subscribers. Within this group another division can be done, reflecting the different features of mobility. The following shows some of the subgroups and mentions typical operations. - The Location Management Services comprise the operations for Update_Location, Cancel_Location and related functionality.

MAP Presentation

- The Handover Services include all handover operations, such as Perform_Handover or Perform_Subsequent_Handover, and related operations like Send_End_Signal. - The Subscriber Management Services are used to provide the VLR with subscriber data from the HLR using the operations Insert_Subscriber_Data and Delete_Subscriber_Data. Other subgroups support services related to data and network security, fault recovery, paging of mobile subscribers and so on. The picture on the next page shows the mentioned operations in the PLMN.

MAP Presentation

Update_Location Cancel_Location Insert_Subscriber_Data Delete_Subscriber_Data HLR

MSC/VLR1

Perform_Handover Perform_Subsequent_Handover MSC/VLR2 Send_End_Signal

Figure 3.1 MAP operations/1

MAP Presentation

3.2 Call Handling Services The call handling services cover all operations needed to set up calls from and to mobile subscribers. In contrast to the mobility services the call handling services are not further divided. The operations from this group, which are supported in CME are Send_Routing_Information and Provide_Roaming_Number. All other 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 signalling interface (software signals). The two mentioned operations are used as shown below.

GMSC Send_Routing_Information

HLR Provide_Roaming_Number

MSC/VLR

Figure 3.2 MAP operations/2

MAP Presentation

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

layer APPICATION PRESENTATION SESSION TRANSPORT NETWORK DATA-LINK PHYSICAL

signification author of a letter to a foreign friend translator from the authors language to the friends language secretary, who types the letter postman fetches the letter from the secretary sorter finds out, where the letter has to be sent packer puts the letter together with other letter mail bus transports the letter to the appropriate receiver

Table 1: Example for an application of the OSI model

The same layers work in a similar way on the receivers side. The example shows, that every layer takes the message from the previous layer and modifies it, adds something or changes the appearance of the message.

10

MAP Presentation

APPLICATION

AUTHOR

PRESENTATION

TRANSLATOR

SESSION

SECRETARY

TRANSPORT

POSTMAN

NETWORK

SORTER

DATA-LINK

PACKER

PHYSICAL

MAIL BUS

Figure 4.1 OSI layers

MAP Presentation

11

4.1 CCITT #7 in the OSI Model The mobile signalling network can be interpreted as well by means of the OSI model, but only four of the seven layers apply. Compared to the example these are the author and the whole mailing infrastructure, except the postman. The analogon to the author is MAP together with TCAP (Transaction Capability Application Part). The tasks of the mail are carried out by SCCP (Signalling Connection and Control Part) and MTP (Message Transfer Part). SCCP and MTP MTP is representing layers 1, 2 and a part of layer 3. It provides the means for transport and delivery of the information, that is created by MAP. It also takes care that this transport is performed in a reliable way, concerning data safety. SCCP is located in layer 3 and handles the coordination and the routing of the messages, that are received from higher layers. It interfaces directly to TCAP, that resides in the application layer. The layers 4 to 6 of the OSI model are not used by the CCITT #7 signalling network.

12

MAP Presentation

MAP

TCAP

SCCP

MTP

Figure 4.2 MAP in the OSI model

MAP Presentation

13

5 TCAP Survey TCAP is defined and described by CCITT in the recommendations Q771 to Q775. For the time being two issues of this recommendations apply to the TCAP used for CME20. The relevant book series are the blue and the white books. In accordance to this we distinguish blue and white TCAP. The following information applies to both versions. 5.1 TCAP Characteristics Dialogue Type - structured (thats what we use in CME20) - unstructured (only unidirectional messages) Dialogue Class

Class 1 2 3 4 only failure reported only success reported

Feature success and failure reported

neither success nor failure reported

Table 2: TCAP dialogue classes

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

14

MAP Presentation

5.2 TCAP Message Structure The TCAP messages always consist of the same elements, the so called portions, that always keep the same order. They are framed by the message type tag and the length indicator for the total message length. For the whole structure see figure 5.1. Transaction Portion Contains an identity, that allows to distinguish different dialogues, that are handled at the same time. Dialogue Portion Consists of two elements, the application context (AC) and the user information (UI). The application context specifies the protocol type and version that is using TCAP. The user information can contain any information, that is exchanged between two TCAP-users, but is not part of a component. Its meaning depends on the protocol specified by the application context. The dialogue portion is defined for white TCAP only. That means, that only one protocol is specified as a TCAP-user for blue 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 chapter about MAP V2 features. Component Portion Comprises the invoke identity, the operation code and the param-

MAP Presentation

15

eters (data) and is framed by the component type tag and the related length value. The invoke identity allows to distinguish between different operations within one dialogue. The operation code identifies the operation according to the appropriate protocol specification. In the parameter field resides the actual MAP data, which is included here by the TCAP user. The structure of the entire message is shown in the next picture.

16

MAP Presentation

Message Type Tag Message Length Transaction Portion Dialogue Portion Component Portion Tag Component Portion Length Component Type Tag Component Type Length Invoke ID Operation Code Tag Operation Code Length MAP message (Operation Code + Data)

Figure 5.1 Structure of a TCAP message

MAP Presentation

17

5.3 TCAP Dialogue Structure To describe a dialogue on TCAP level, it is useful to show only a few of the elements mentioned in the previous chapter. The most characteristic parts from TCAP point of view are the message (type) and the component. The message (type) can be interpreted as the envelope of the dialogue, that indicates the kind of message 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 the following shall be used to refer to the message level, while operations 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 used to 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 dialogues are not further examined in this context. Message type BEGIN END CONTINUE ABORT1) Starts the dialogue Terminates the dialogue Keeps the dialogue ongoing in both direct. Aborts dialogue (protocol violation)
Table 3: TCAP message types Note: 1) Two different ABORT messages exist user (TC-user) and provider (TCAP) ABORT

Usage

18

MAP Presentation

Within a dialogue operations can be started, continued and terminated successfully or unsuccessfully. Component INVOKE RESULT ERROR REJECT 1) CANCEL Starts the operation Carries result for successfully executed operat. Reports reason for failure of operation Indicates protocol viol. on component sublayer Terminates operation (e.g. due to time-out)
Table 4: TCAP component types 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.

Usage

Depending on the purpose of the feature, one or more operations are carried out during a dialogue. The sequence on the following page shows an example how a typical TCAP dialogue can look like. During the dialogue two operations are performed (oper1 and oper2). The first operation is started by sending an INVOKE component in a BEGIN message. By reception of this message the receiving side invokes the second operation in a CONTINUE message. The second operation is framed by the first operation so that the result for the second operation is sent next.Here the receiver detects a problem and reports an error in the END message to the entity where the operation was invoked.

MAP Presentation

19

TCAP Dialogue

SENDER (local TCAP) BEGIN INVOKE oper1

RECEIVER (remote TCAP)

CONTINUE INVOKE oper2 CONTINUE RESULT oper2 END ERROR oper1

Figure 5.2 Example for TCAP dialogue

20

MAP Presentation

To carry out a structured dialogue the following combinations of messages and components are allowed: BEGIN INVOKE RESULT ERROR REJECT CANCEL
allowed not allowed not allowed not allowed 3)

CONTINUE
allowed allowed allowed 1) allowed 1) 3)

END
allowed 1) allowed allowed allowed 3)

ABORT
2) 2) 2) 2) 2) 3)

Table 5: Allowed combinations of messages and components

Notes: 1) This combinations are only allowed in a certain state of a dialogue or under certain conditions. 2) An ABORT message is always sent empty. 3) A Cancel component is always sent without message.

MAP Presentation

21

6 Specification of Operations As already mentioned, GSM has defined the MAP protocol in their recommendation 09.02. The Ericsson implementation of this protocol is not always fully compliant to this specification. Therefor exist separate specifications on functional level, that describe 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 every version and every variant of MAP. Up to now, two versions of the protocol are defined, based on the GSM (development-) phases 1 and 2. For several reasons (later explained in the chapter MAP variants and versions) an Ericsson specific set of operations 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 for MSC/VLR (corresponding documents exist for all other network nodes):
* * * * 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 a short description of every applicable operation, the formal description of the operation parameters (compare section about ASN.1) and the signalling sequences similar to the TCAP sequence of the previous chapter.

22

MAP Presentation

7 TCAP <-> MAP Interface Specification In the proceeding sections the TCAP dialogue and the elements of a TCAP message have been explained. This chapter shows the implementation and more intensive the usage of TCAP. It will be focused on the interface towards TCAP. TCAP is realized as a number of software blocks. The interwork towards the software blocks, that handle MAP messages is done via an internal signal interface. The task of these MAP blocks (TC-user) is now to include the parameters of the prepared MAP message (operation code and data, 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 is useful. However, in both cases the same software signals apply and the handling of the parameters is comparable. For all incoming dialogues the same function block is attached to the TCAP blocks. This message handler checks all incoming messages on the availability of a specific handler for the invoked operation. In the successful case the dialogue is handed over to the appropriate MAP block and the new block is indicated to TCAP. For outgoing 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 several phases, each of them is performed by certain signalling sequences. Some of this phases are optional and are not mentioned here, a design rule with the title CCITT, Interwork Description Connectionless White TCAP <--> TC-User is describing them all in detail.

MAP Presentation

23

7.1 Outgoing Dialogues Dialogue Seizure In the first step, the availability of TCAP is verified. The signal C7DIALSEIZREQ requests TCAP to handle a new dialogue. If TCAP is able to do this, it acknowledges with signal C7DIALGRANTED, else signal C7DIALDENIED is returned.

TC-User C7DIALSEIZREQ

TCAP

C7DIALGRANTED

case result of seizure <successful>

C7DIALDENIED

<unsuccessful>

Figure 7.1 C7-Signalling/seizure

24

MAP Presentation

Dialogue Portion Control (Transmission) If the dialogue shall be carried out in a protocol version different from MAP V1 the next step after the seizure of TCAP is to include the dialogue portion (DP) in the message. The inclusion is requested by sending the signal C7DIPORTREQ to TCAP. The return signal C7DIPORTREQACC allows the insertion of the DP and carries the index and the reference of the TCAP buffer. The DP is now written directly into the buffer. More information about the contents of the DP and the insertion of data into dynamic buffers is presented in the section MAP V2 features. The unsuccessful outcome of the request is indicated with signal C7DIPORTREQNACC.

TC-User C7DIPORTREQ

TCAP

C7DIPORTREQACC

case result of DP request <successful> write DP into buffer

C7DIPORTREQNACC

<unsuccessful>

Figure 7.2 C7-Signalling/DP-control

MAP Presentation

25

Invoke Component Control Since every dialogue has to start with the invocation of an operation, the inclusion of this component has to be requested now. The related signal C7INVOKEREQ can be answered with C7INVOKEREQACC or C7INVOKEREQNACC for sucessful or unsucessful case respectively. In case of acceptance of the request, the buffer index and the buffer reference are received in the acknowledge signal and the MAP message is written into the TCAP buffer. Since it is possible to start more than one opeartion at the same time, this procedure can be repeated for every invocation. The inclusion of several components into one message is generally called grouping, but applies to a few dialogues only.

TC-User C7INVOKEREQ

TCAP

C7INVOKEREQACC

case result of request for invocation <successful> write MAP message into buffer

C7INVOKEREQNACC

<unsuccessful>

Figure 7.3 C7-Signalling/invocation

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 indication of Begin as the required message type in signal C7BEGINREQ the TCAP message can be sent to the remote side. Similar to the proceeding sequences the request is acknowledged with the signals C7BEGINREQEXEC for executed and C7BEGINREQNEXEC for not executed message sending.

TC-User C7BEGINREQ

TCAP

case result of request to send BEGIN message <successful>

C7BEGINREQEXEC C7BEGINREQNEXEC

send TCAP message BEGIN (INVOKE) <unsuccessful>

Figure 7.4 C7-Signalling/dialogue begin

MAP Presentation

27

Backward Message Control After sending the Begin message the remote TCAP can answer with a various number of messages, depending of the structure of the dialogue, operation class, the sent data, etc. The returned message must correspond to one of the three remaining message types (CONTINUE, END or ABORT). For sure a BEGIN message might be received as well mistakenly, but this kind of system failures shall not be covered here. Therefore the following signals have to be handled by the TC-user. C7CONTIND C7ENDIND C7PABORT C7UABORTIND C7TCNOTICE C7CANCELIND The TC-Notice indication can be received in case a message was returned to TCAP. The indication that a dialogue was canceled, is received if TCAP timed a dialogue out, because the maximum waiting time for a reply was exceeded.

28

MAP Presentation

TC-User

TCAP

C7CONTIND C7ENDIND C7UABORTIND

case next event from TCAP

<Continue, End or U-Abort> Check DP, if MAP V2 (*see chapter DP control, Reception*)

C7DIALINDR

acknowledge message indication if Continue or End received, the component is expected next (*see next chapter*) <P-Abort or message returned>

C7PABORTIND C7TCNOTICE

C7DIALINDR

acknowledge message indication dialogue terminated

Figure 7.5 C7-Signalling/backward message

MAP Presentation

29

TC-User

TCAP

(... case next event from TCAP)

C7CANCELIND C7LTERMREQ

<Cancel>

the TCAP to TCAP dialogue is already finished, the TC-user TCAP dialogue is now locally aborted

C7LTERMREQR
local termination executed

Figure 7.6 C7-Signalling/backward message cancel

Backward Component Control After the handling of the message type the component, that was included in the message is now indicated to the TC-user. Possible components are INVOKE, RESULT, ERROR, CANCEL and REJECT. Again these indications are transported in a number of signals.

30

MAP Presentation

TC-User

TCAP

C7INVOKEIND C7RESULTIND C7ERRORIND C7LTERMREQ C7LTERMREQR

case next event from TCAP

<Invoke, Result or Error> If the component was not expected, the dialogue is aborted locally

Else read data from buffer if present

C7OPINDR

C7CANCELIND C7(L)REJECT

acknowledge component to continue or finish dialogue (* see chapter Dialogue Continuation *) <Cancel, local or remote Reject>

C7OPINDR

acknowledge operation indication dialogue terminated

Figure 7.7 C7-Signalling/backward component

MAP Presentation

31

Dialogue Portion Control (Reception) The signals C7DPINFOREQACK are used to fetch the information about the contents of the DP. The return signal contains buffer index and reference for the elements of the DP, the application context and the user information.

TC-User C7DPINFOREQ

TCAP

C7DPINFOREQACK

Fetch DP information

read DP from buffer The contents can be analyzed now

Figure 7.8 C7-Signalling/DP reception

32

MAP Presentation

Dialogue Continuation The Dialogue reached now the full duplex state. Either the remote or the local side can send the next message. In the first case the chapter for the backward message control applies, except for the check of the DP when a CONTINUE or an END message is received. Similar to the begin of the dialogue the message is built when the local TC-user wants to sent data. Possible message types are CONTINUE, END, ABORT containing INVOKE, RESULT, ERROR or REJECT components, which are requested first. TC-User C7INVOKEREQ C7RESULTREQ C7ERRORREQ C7REJECTREQ C7INVOKEREQACC C7RESULTREQACC C7ERRORREQACC C7REJECTREQACC TCAP

case result of request <successful> write MAP message into buffer (* request mess. type*)

C7INVOKEREQNACC C7RESULTREQNACC C7ERRORREQNACC C7REJECTREQNACC

<unsuccessful>

Figure 7.9 C7-Signalling/continuation/component

MAP Presentation

33

TC-User C7CONTREQ C7ENDREQ C7ABOTRREQ

TCAP

case result of request to send message <successful>

C7CONTREQEXEC C7ENDREQEXEC C7ABORTREQEXEC C7CONTREQNEXEC C7ENDREQNEXEC C7ABORTREQNEXEC

send TCAP message

<unsuccessful>

Figure 7.10 C7-Signalling/continuation/message

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

34

MAP Presentation

7.2 Incoming Dialogues The incoming dialogues are handled in a very similar way regarding the interface TC-user-TCAP. The differences are mainly related to the DP handling. The DP has to be checked with the reception of the BEGIN message and has to be inserted in the first return message. Furthermore no seizure of TCAP is performed. 7.3 Example SendRoutingInformation The following example lists the complete sequence of the TCuser-TCAP interworking for the successful execution of the Operation SendRoutingInformation. The operation is fairly simple regarding the dialogue. The Begin message containing the Invoke component is answered with an END carrying a RESULT. Additionally it shall be noted that two types of results exist, that are the last-result-type and the not-last-result-type. In this example obviously the last-result-type is used. The operation is carried out with MAP V2, every request is answered positive and 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 provided e.g. as a roaming number.

MAP Presentation

35

GMSC
TC-user (GAP)
C7DIALSEIZREQ C7DIALGRANTED C7DIPORTREQ C7DIPORTREQACC

HLR
TCAP TCAP

Write DP to TCAP buffer

C7INVOKEREQ C7INVOKEREQACC Write MAP data to TCAP buffer

C7BEGINREQ C7BEGINREQEXEC BEGIN INVOKE (SendRoutingInfo)

(contd)

Figure 7.11a C7-Signalling/SRI

36

MAP Presentation

GMSC
TC-user (GAP) TCAP

HLR
TCAP

END

C7ENDIND

RESULT-L (SendRoutingInfo)

C7DPINFOREQ C7DPINFOREQACK

Read DP from TCAP buffer

C7DIALINDR C7RESULTIND Read result data from TCAP buffer

C7OPINDR (end) Figure 7.11b C7-Signalling/SRI

MAP Presentation

37

8 ASN.1 ASN.1 stands for Abstract Syntax Notation One and is an international standardized way of describing application layer protocol information. The application of its rules provides a unique definition of the contents of the data fields (components) for all MAP operations. ASN.1 can be compared to a (programming) language that allows every user to read and write information in a way, that any other user can easily recover the proper information. Since the subject of ASN.1 is rather complex only a rough overview shall be presented here. The ASN.1 standard is defined in CCITT recommendations X.208 (notation) and in X.209 (encoding rules). The notation describes 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 structuring the TCAP message. The structure always consists of tag, length and contents, the contents might have substructures following the same principles.

38

MAP Presentation

TAG LENGTH CONTENTS

TAG LENGTH CONTENTS

Figure 8.1Data structure

The Tag itself (in some cases it is called as well identifier) is a 8bit word and consists of three elements: The two most significant bit are called class and describe the validity of the tag. The class can be either universal, application wide, context specific or private. The next bit indicates, whether the contents following this tag is sub-structured (constructor) or not (primitive). The remaining five (least significant) bit represent the type (or number), that corresponds to the contents.

Bit

Class

Form

Tag Type
Figure 8.2 Coding of the Tag/Identifier

MAP Presentation

39

bit 7 bit 6 0 0 1 1 0 1 0 1

signification universal application wide context specific private use

Table 6: Class

bit 5 0 1

signification primitive constructor

Table 7: Form

bit 0-4 decimal 1 2 3 4 5

signification BOOLEAN INTEGER BIT STRING OCTET STRING NULL

bit 0-4 decimal 17 18 19 20 21

signification SET (OF) NumericString PrintableString TelexString VideotexString

Table 8: Tag Type

40

MAP Presentation

bit 0-4 decimal 6 7 8 9 10 16

signification OBJECT IDENTIF. ObjectDescriptor EXTERNAL REAL ENUMERATED SEQUENCE (OF)

bit 0-4 decimal 22 23 24 25 26 27

signification IA5String UTCTime GeneralizedTime GraphicString VisibleString GeneralString

Table 8: Tag Type

The table with the tag types only applies to the tags of class universal. This means they are generally defined standard types that can be used everywhere. Every type is assigned to one of the four groups SIMPLE, STRUCTURED, CHARACTER STRING or USEFUL. The types used in MAP belong mainly to the first two groups. SIMPLE BOOLEAN INTEGER ENUMERATED REAL BIT STRING OCTET STRING NULL OBJECT IDENTIFIER STRUCTURED SET (OF) SEQUENCE (OF) CHOICE 1) ANY 1)

Table 9: Common tag types used in MAP

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 of the tag type has to be defined by the user. In the case of MAP the application wide definitions are valid for the whole MAP. The context specific tags are defined on one structure level only (in a SEQUENCE of one operation) and the private tags are used in the Ericsson variant of MAP. 8.2 Encoding Rules Instead of translating certain data into the appropriate ASN.1 code, an existing ASN.1 description shall be analyzed in this chapter using the basic encoding rules (BER). At the end the actual sequence of all octets that form the MAP message shall be retrieved. This is exactly the proceeding when coding an operation-handling software block. This structure in figure 8.3 shows the ASN.1 description for the operation SendRoutingInformation, as it is defined in the Function Specification for MAP V1. In the first line the operation name and the sending and receiving entities are mentioned. The operation 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, this means success and failure of the operation are reported. The ASN.1 description of the operation is divided into three sections. The section PARAMETERS contains the definition of the data that is included in the invoke component. The section RESULT shows the data in the corresponding components that

42

MAP Presentation

indicates success. The error types are imported from a separate ERROR module.

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 imsi routingInfo roamingNumber forwardingData SEQUENCE { IMSI CHOICE{ IsdnAddressString, ForwardingData}}

ERRORS { SystemFailure, DataMissing, UnexpectedDataValue, FacilityNotSupported, UnknownSubscriber, BearerServiceNotProvisioned, TeleServiceNotProvisioned, AbsentSubscriber CallBarred CUG-Reject, ForwardingViolation}

Figure 8.3 ASN.1 example

44

MAP Presentation

The situation before the operation shall be as follows: A call attempt towards a mobile subscriber reached the GMSC. The call is a normal call originating in PSTN and the roaming number shall be fetched via HLR. The call was forwarded once before it arrived at the GMSC. This situation requires the MSISDN (this is the number, that was dialled by the calling subscriber) and the number of forwardings (here: 1) to be sent to the HLR. The order of the data is taken directly from the ASN.1 code. The additional data of networkSignalInfo is optional and therefore omitted. The data are formally put into a sequence, i.e. a special tag 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

MAP Presentation

45

Figure 8.4 shows the sequence as it will look like in the example for SRI. The missing information are the tags of the parameters, the lengths and the contents of the data fields, which for sure could be sub-structured. The left column lists the parameters, while the right column defines them. Each definition leads to a type that is separately defined or to a universal type. According to this the IsdnAddressString and NumberOfForwarding type definitions are needed, because they are not universal. If the ASN.1 description is checked further regarding the investigated parameters two things are remarkable: The value in the parenthesis (0 and 2) and the IMPLICIT indicator. In ASN.1 it is distinguished between implicit and explicit tagging. If a type declaration of a non-universal parameter is based on a universal type the explicit tagging encapsulates the original parameter, while the implicit form replaces it.

Original Type and Value: INTEGER (=#12345) Explicit tagging: [6] INTEGER (=#12345) Implicit tagging: [6] IMPLICIT INTEGER (=#12345) 86 2 12345 A6 4 2 2 12345 2 2 12345

Figure 8.5 Implicit and explicit tagging

46

MAP Presentation

In the example in figure 8.5 the tag value for the explicit tag is 6 and the whole identifier has the value A6 (class: context specific=10; form: constructor=1). The identifier in the implicit tagging is equal to 86 (class: context specific=10; form: primitive=0). Consequently it is easy to recognize, that the parameters of the SRI message use the implicit tagging. The next step is to examine the declaration for the types in the right column. In the function 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 its length 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 TBCDSTRING 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

MAP Presentation 100 subscriber number 101 reserved 110 abbreviated number 111 reserved for extension Bit 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 spare 1000 national numbering plan 1001 private numbering plan 1010-1110 reserved 1111 reserved for extension

47

TBDC-STRING ::= OCTET STRING bits 4321 of octet n are encoding digit 2n-1 bits 8765 of octet n are encoding digit 2n

1 octet 1 of contents octet 2 of contents octet 3 of contents

2nd digit 4th digit 6th digit

1st digit 3rd digit 5th digit

2nth digit

(2n-1)th digit

octet n of contents

48

MAP Presentation

The first octet contains the numbering plan indicator and the nature of address indicator. The corresponding numbering plan is telephony (E.164) and the nature of address is international. The extension bit is set to 1, therefore the entire octet has the value H91. The called number was 4917212345, so the total length of the address string is 6 octets. The identifier for the whole MSISDN is a context specific (10) primitive (0) with the implicit tag 0.The coding looks as follows

80

06

91

94

71

12

32

54

identifier (tag) length

contents

Figure 8.7 Coding of the MSISDN

With the definition of the number of forwardings the coding of this parameter is done in the same way:
NumberOfForwarding ::= INTEGER (1..5)

82

01

01 Figure 8.8 Coding of the number of forwardings

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

MAP Presentation

49

hex value Operation Code Sequence Tag Total Length MSISDN Tag Length MSISDN 22 30 0B 80 06 91 94 71 12 32 54

Number ofForw. Tag Length Number of Forwardings

82 01 01

Figure 8.9 Coding of the SendRoutingInfo message

50

MAP Presentation

Operation Code Sequence Tag = H30 Total Length MSISDN Tag Length MSISDN Number ofForw. Tag Length Number of Forwardings

Length Coding

MAP Presentation

51

The format of the length octets in MAP message is derived by applying the related encoding rules. It is important to know about all possible length formats, because each of them can be received in a message. Basically three different formats are used, the short form, the long form and the indefinite form. The short form is used, if the length of the covered data is less than 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 first length octet has a value bigger than h80. The least significant 7 bits indicate the number of subsequent octets that are indicating the actual length. Since TCAP doesnt support messages longer than 256 octets (in one go), there will be usually the value h81 in this octet. The indefinite form can be used for any length. It must not be used for primitives, but only for structures, so that on the deepest level of the structure a definite form is employed (either long or short format). The length octet contains in case of indefinite form always the value h80 and the data structure is terminated with two octets of zeros (End-of-Contents indicator).

52

MAP Presentation

octets with length relevant information data field, containing 16 (=h10) octets Tag #10 Tag #81 #10 *) Tag #80

short form long form

00 00 indefinite form

*) Note: For this length value the short form should have been used, but the example is only used to show the differences of the forms Figure 8.10 Coding of the length octets

MAP Presentation

53

9 MAP Versions and Variants As already mentioned in the proceeding sections MAP is existing in a number of different issues. Actually in Ericsson four different MAPs can be found. It is distinguished between MAP versions and MAP variants. The term version is used if the base is the standard MAP as it is defined by GSM. Especially no additional data within the messages are allowed compared to the standard, but some minor deviations can always be expected. The main requirement is the fault-free (and all standard services supporting) interworking of different network entities from different vendors or independently working design offices. MAP is divided according to the GSM recommendation development into two issues named MAP V1 (GSM phase1) and MAP V2 (GSM phase2). The MAP variants comprise operations similar to the GSM standard, but private data is allowed here and in some cases even private operations are created. The reason for that is the customer requirement for certain services that are not standardized yet or can not be handled within the standard operations. Anyway the variant operations are based on the existing GSM operations and therefore 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 V2 was the introduction of the dialogue portion (DP). The two elements of the DP are the application context (AC) and the user information (UI).

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) from which operations can be invoked during the dialogue. Therefor the AC is divided into three parts. The first part gives an exact reference to the protocol and consists of five octets. The second and third part are represented by one octet each and correspond to the name of the application context (or application-contextname) and to the protocol version. The values of the reference part are fixed, while the applicationcontext-name values are defined in GSM 09.02. The protocol version has usually the value 2, because if version 1 is used no AC is present at all.
ccitt identified organization = 04 etsi mobileDomain gsm-network acid application-context-name protocol version = 00 = 00 = 01 = 00 protocol reference is always identical for existing MAPs

Figure 9.1 Coding of the AC

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

MAP Presentation

55

responding entity the dialogue continues on this basis, otherwise it is refused and the initiating user needs to start a new dialogue using an AC with a lower protocol version. This is called fallback. The AC-names are defined in two steps. All operations are assigned operation packages, that include operations with certain relations (e.g all operateSS services like registerSS, eraseSS, activateSS, etc.). The AC-names are based on these packages and it 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 following AC are supported:

Application Context locationInfoRetrievalContext networkLocUpContext

Operation Package Interrogation Package LocationUpdatingPackage DataRestorationPackage SubscriberDataMngtPackage TracingPackage RoamingNumberEnquieryPackage SubscriberDataMngtPackage

Interface GMSC-HLR HLR-VLR

roamingNumberEnquiryContext subscriberDatMngtContext

HLR-VLR HLR-VLR

Table 10: Relation between AC and packages

The packages in turn are containg the operations according to table 11.

MAP Presentation

56

Operation Package InterrogationPackage LocationUpdatingPackage DataRestorationPackage SubscriberDataMngtPackage TracingPackage RoamingNumberEnquieryPackage sendRoutingInfo updateLoacation restoreData

Operation

insertSubscriberData deleteSubscriberData activateTraceMode deactivateTraceMode provideRoamingNumber

Table 11: Relation between packages and operations

The resulting relation between the ACs and the operations can easily be retrieved with these tables, these tables can be found in the function specifications for MAP V2 of CME20. User Information The User Information UI in the dialogue portion is used to carry information, that is defined by the protocol, referenced to in the AC. In MAP it is used to carry the reason code for U-ABORT messages, which can result in an reattempt or fall-back.

9.2 Ericsson MAP Variants Aligned to the standard MAP, the Ericsson variants do have as well versions 1 and 2. The special Ericsson specific services that are supported with this MAP issues are the following:

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 of operations that have nothing in common with the existing standard operations and are especially designed to support and perform Ericsson specific services.