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





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.

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. and related operations like Send_End_Signal.The Handover Services include all handover operations. such as Perform_Handover or Perform_Subsequent_Handover.6 MAP Presentation . . The picture on the next page shows the mentioned operations in the PLMN. . fault recovery. paging of mobile subscribers and so on. Other subgroups support services related to data and network security.

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

which are supported in CME are Send_Routing_Information and Provide_Roaming_Number.2 MAP operations/2 . but by an internal signalling interface (software signals). In contrast to the mobility services the call handling services are not further divided. GMSC Send_Routing_Information HLR Provide_Roaming_Number MSC/VLR Figure 3. In CME this network nodes are not separated and therefore not connected via a CCITT #7 interface.2 Call Handling Services The call handling services cover all operations needed to set up calls from and to mobile subscribers. The two mentioned operations are used as shown below. All other call handling operations are used between MSC and VLR.8 MAP Presentation 3. The operations from this group.

adds something or changes the appearance of the message. The principle is the division of the entire system into seven hierarchical layers. layer APPICATION PRESENTATION SESSION TRANSPORT NETWORK DATA-LINK PHYSICAL signification author of a letter to a foreign friend translator from the author’s language to the friend’s language secretary. . The example shows. 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 model applies as well to our mailing system. and its elements can be used for a better understanding of the different layers.MAP Presentation 9 4 OSI Model The OSI (Open System Interconnection) Model is used to describe the structure of communication systems. that every layer takes the message from the previous layer and modifies it. Every layer has a certain task to fulfil.


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

12 MAP Presentation MAP TCAP SCCP MTP Figure 4.2 MAP in the OSI model .

5.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. . In accordance to this we distinguish ‘blue’ and ‘white’ TCAP. if a dialogue for a certain class is initiated.structured (that’s what we use in CME20) .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.1 TCAP Characteristics Dialogue Type . The following information applies to both versions. The relevant book series are the blue and the white books.

More details about the dialogue portion can be found in the chapter about MAP V2 features. In a blue TCAP message the dialogue portion is not present. Component Portion Comprises the invoke identity. that are handled at the same time. Dialogue Portion Consists of two elements.2 TCAP Message Structure The TCAP messages always consist of the same elements. They are framed by the message type tag and the length indicator for the total message length.14 MAP Presentation 5. that allows to distinguish different dialogues. That means. Its meaning depends on the protocol specified by the application context. the application context (AC) and the user information (UI). the operation code and the param- . The user information can contain any information. the so called portions. For the whole structure see figure 5. The application context specifies the protocol type and version that is using TCAP. The dialogue portion is defined for white TCAP only.1. This protocol is specified in GSM 09. that only one protocol is specified as a TCAP-user for blue TCAP. that is exchanged between two TCAP-users. but is not part of a component. that always keep the same order. Transaction Portion Contains an identity.02 (MAP).

The operation code identifies the operation according to the appropriate protocol specification. which is included here by the TCAP user. In the parameter field resides the actual MAP data.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 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 .

The message (type) can be interpreted as the envelope of the dialogue. Normally a component (letter) is put into an message (envelope) and is sent to the receiver. Message type BEGIN END CONTINUE ABORT1) Starts the dialogue Terminates the dialogue Keeps the dialogue ongoing in both direct. the term dialogue in the following shall be used to refer to the message level. the unstructured dialogues are not further examined in this context. while operations are describing activities on the parameter level.MAP Presentation 17 5. All message types needed for structured dialogues are listed in the following table. that indicates the kind of message that is sent. it is useful to show only a few of the elements mentioned in the previous chapter. As a concept for the TCAP dialogues. Different types of messages are used to start and finish a dialogue or to continue it. Aborts dialogue (protocol violation) Table 3: TCAP message types Note: 1) Two different ABORT messages exist user (TC-user) and provider (TCAP) ABORT Usage .3 TCAP Dialogue Structure To describe a dialogue on TCAP level. The component can be compared to letter. Since MAP only uses structured dialogues. containing the message information itself. The most characteristic parts from TCAP point of view are the message (type) and the component.

Usage Depending on the purpose of the feature. continued and terminated successfully or unsuccessfully. due to time-out) Table 4: TCAP component types Note: 1) Two different REJECT components exist. The sequence on the following page shows an example how a typical TCAP dialogue can look like.g.18 MAP Presentation Within a dialogue operations can be started. The second operation is framed by the first operation so that the result for the second operation is sent next. one for local and one for a remote REJECT. but this affects only the handling within the entities and not the dialogue between them. . Reports reason for failure of operation Indicates protocol viol. By reception of this message the receiving side invokes the second operation in a CONTINUE message. The first operation is started by sending an INVOKE component in a BEGIN message. one or more operations are carried out during a dialogue. During the dialogue two operations are performed (oper1 and oper2). Component INVOKE RESULT ERROR REJECT 1) CANCEL Starts the operation Carries result for successfully executed operat. on component sublayer Terminates operation (e.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. . 3) A Cancel component is always sent without message. 2) An ABORT message is always sent empty.

that describe in detail how the CME 20 solution looks like. For several reasons (later explained in the chapter MAP variants and versions) an Ericsson specific set of operations had to be defined as well. Therefor exist separate specifications on functional level. so that separate documents can be found for MSC/VLR. This specifications are based on network entities. The Ericsson implementation of this protocol is not always fully compliant to this specification. the formal description of the operation parameters (compare section about ASN. MAP V1 in MSC/VLR CCITT Signalling System No.7.MAP Presentation 21 6 Specification of Operations As already mentioned. based on the GSM (development-) phases 1 and 2. specifying MAP for MSC/VLR (corresponding documents exist for all other network nodes): * * * * CCITT Signalling System No.7. the list below shows only the documents. . GMSC. Up to now. and the signalling sequences similar to the TCAP sequence of the previous chapter. these documents contain a short description of every applicable operation. HLR and so on. MAP V2 in MSC/VLR Ericsson Variant CCITT Signalling System No. GSM has defined the MAP protocol in their recommendation 09. MAP V1 in MSC/VLR Ericsson Variant CCITT Signalling System No. Therefore a notable number of documents has to be maintained. two versions of the protocol are defined. MAP V2 in MSC/VLR Besides general MAP information. Besides a complete set of these documents is issues for every version and every variant of MAP.

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

else signal C7DIALDENIED is returned. TC-User C7DIALSEIZREQ TCAP C7DIALGRANTED case result of seizure <successful> C7DIALDENIED <unsuccessful> Figure 7. The signal C7DIALSEIZREQ requests TCAP to handle a new dialogue.1 C7-Signalling/seizure . the availability of TCAP is verified. If TCAP is able to do this. it acknowledges with signal C7DIALGRANTED.MAP Presentation 23 7.1 Outgoing Dialogues Dialogue Seizure In the first step.

TC-User C7DIPORTREQ TCAP C7DIPORTREQACC case result of DP request <successful> write DP into buffer C7DIPORTREQNACC <unsuccessful> Figure 7. The return signal C7DIPORTREQACC allows the insertion of the DP and carries the index and the reference of the TCAP buffer. The unsuccessful outcome of the request is indicated with signal C7DIPORTREQNACC.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.2 C7-Signalling/DP-control . 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 inclusion is requested by sending the signal C7DIPORTREQ to TCAP.

TC-User C7INVOKEREQ TCAP C7INVOKEREQACC case result of request for invocation <successful> write MAP message into buffer C7INVOKEREQNACC <unsuccessful> Figure 7. The inclusion of several components into one message is generally called ‘grouping’. The related signal C7INVOKEREQ can be answered with C7INVOKEREQACC or C7INVOKEREQNACC for sucessful or unsucessful case respectively. this procedure can be repeated for every invocation.3 C7-Signalling/invocation . the buffer index and the buffer reference are received in the acknowledge signal and the MAP message is written into the TCAP buffer.MAP Presentation 25 Invoke Component Control Since every dialogue has to start with the invocation of an operation. In case of acceptance of the request. but applies to a few dialogues only. the inclusion of this component has to be requested now. Since it is possible to start more than one opeartion at the same time.

that starts the dialogue contains now everything. With the indication of ‘Begin’ as the required message type in signal C7BEGINREQ the TCAP message can be sent to the remote side. that is needed to send it. except the message type.4 C7-Signalling/dialogue begin . TC-User C7BEGINREQ TCAP case result of request to send BEGIN message <successful> C7BEGINREQEXEC C7BEGINREQNEXEC send TCAP message BEGIN (INVOKE) <unsuccessful> Figure 7. Similar to the proceeding sequences the request is acknowledged with the signals C7BEGINREQEXEC for executed and C7BEGINREQNEXEC for not executed message sending.26 MAP Presentation Begin Message Control The message.

because the maximum waiting time for a reply was exceeded. etc. operation class. END or ABORT). 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. For sure a BEGIN message might be received as well mistakenly.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. The indication that a dialogue was canceled. is received if TCAP timed a dialogue out. The returned message must correspond to one of the three remaining message types (CONTINUE. but this kind of system failures shall not be covered here. . the sent data.

the component is expected next (*see next chapter*) <P-Abort or message returned> C7PABORTIND C7TCNOTICE C7DIALINDR acknowledge message indication dialogue terminated Figure 7. Reception’*) C7DIALINDR acknowledge message indication if Continue or End received.28 MAP Presentation TC-User TCAP C7CONTIND C7ENDIND C7UABORTIND case next event from TCAP <Continue. End or U-Abort> Check DP.5 C7-Signalling/backward message . if MAP V2 (*see chapter ‘DP control.

CANCEL and REJECT. ERROR..MAP Presentation 29 TC-User TCAP (. 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. Again these indications are transported in a number of signals.. RESULT. Possible components are INVOKE. . case next event from TCAP) C7CANCELIND C7LTERMREQ <Cancel> the TCAP to TCAP dialogue is already finished. that was included in the message is now indicated to the TC-user.

30 MAP Presentation TC-User TCAP C7INVOKEIND C7RESULTIND C7ERRORIND C7LTERMREQ C7LTERMREQR case next event from TCAP <Invoke.7 C7-Signalling/backward component . 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. Result or Error> If the component was not expected. local or remote Reject> C7OPINDR acknowledge operation indication dialogue terminated Figure 7.

8 C7-Signalling/DP reception .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.

Possible message types are CONTINUE. In the first case the chapter for the backward message control applies. TC-User C7INVOKEREQ C7RESULTREQ C7ERRORREQ C7REJECTREQ C7INVOKEREQACC C7RESULTREQACC C7ERRORREQACC C7REJECTREQACC TCAP case result of request <successful> write MAP message into buffer (* request mess. ABORT containing INVOKE.9 C7-Signalling/continuation/component . except for the check of the DP when a CONTINUE or an END message is received. END. RESULT. which are requested first. Either the remote or the local side can send the next message. Similar to the begin of the dialogue the message is built when the local TC-user wants to sent data.32 MAP Presentation Dialogue Continuation The Dialogue reached now the full duplex state. type*) C7INVOKEREQNACC C7RESULTREQNACC C7ERRORREQNACC C7REJECTREQNACC <unsuccessful> Figure 7. ERROR or REJECT components.

It shall be noted. CANCEL) occurs. . ERROR. that in case of a requested abortion the DP has to be included in some cases.10 C7-Signalling/continuation/message The dialogue proceeds now in this way until a regular (END) or prearranged end (ABORT. using the known procedure (see DP control).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. REJECT.

every request is answered positive and the result is received as expected. The differences are mainly related to the DP handling.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 operation is carried out with MAP V2. The Begin message containing the Invoke component is answered with an END carrying a RESULT.g. 7. In this example obviously the last-result-type is used. Additionally it shall be noted that two types of results exist.2 Incoming Dialogues The incoming dialogues are handled in a very similar way regarding the interface TC-user-TCAP. that are the last-result-type and the not-last-result-type.34 MAP Presentation 7. Furthermore no seizure of TCAP is performed. The purpose of the operation is to retrieve in GMSC via HLR information about the location of the called subscriber provided e. as a roaming number. The DP has to be checked with the reception of the BEGIN message and has to be inserted in the first return message.


11b 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.

The application of its rules provides a unique definition of the contents of the data fields (components) for all MAP operations. 8.1 tag identifies a data in a similar way as it is done for structuring the TCAP message.208 (notation) and in X.1 Notation The principle of structuring data is the tagging of it.209 (encoding rules).1 is rather complex only a rough overview shall be presented here. The structure always consists of tag.1 stands for Abstract Syntax Notation One and is an international standardized way of describing application layer protocol information. ASN. Since the subject of ASN. that any other user can easily recover the proper information.1 can be compared to a (programming) language that allows every user to read and write information in a way. the contents might have substructures following the same principles. based on the ASN.1 formal description.MAP Presentation 37 8 ASN. . The ASN. The encoding rules deliver the tool to translate a set of values into a sequence of data. length and contents. The ASN.g. The notation describes e.1 ASN.1 standard is defined in CCITT recommendations X. tags and structures. types.

The class can be either universal. whether the contents following this tag is sub-structured (constructor) or not (primitive). application wide. The next bit indicates. that corresponds to the contents. context specific or private.2 Coding of the Tag/Identifier . Bit 7 6 5 4 3 2 1 0 Class Form Tag Type Figure 8. The remaining five (least significant) bit represent the type (or number).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.

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 .

The types used in MAP belong mainly to the first two groups.40 MAP Presentation bit 0-4 decimal 6 7 8 9 10 16 signification OBJECT IDENTIF. 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 . 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. CHARACTER STRING or USEFUL. STRUCTURED. Every type is assigned to one of the four groups SIMPLE.

If the class of the tag is different from universal.2 Encoding Rules Instead of translating certain data into the appropriate ASN. 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.1 code.1 description for the operation SendRoutingInformation. This is exactly the proceeding when coding an operation-handling software block. this means success and failure of the operation are reported. In the first line the operation name and the sending and receiving entities are mentioned. but since they only appear in the ASN. According to chapter 5. Further it is stated. that SRI is a class-one operation.1 formal description. the contents of the tag type has to be defined by the user. This structure in figure 8. The section RESULT shows the data in the corresponding components that .1 description of the operation is divided into three sections. The operation code for SendRoutingInformation (SRI) is 22. as it is defined in the Function Specification for MAP V1. The section PARAMETERS contains the definition of the data that is included in the invoke component. an existing ASN. In the case of MAP the application wide definitions are valid for the whole MAP.MAP Presentation 41 Note: 1) This types belong to group STRUCTURED. This is already the first octet in our MAP message. 8. At the end the actual sequence of all octets that form the MAP message shall be retrieved.3 shows the ASN. they don’t have assigned any tag and are not included in table 8.1. The ASN.1 description shall be analyzed in this chapter using the basic encoding rules (BER).

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

ForwardingData}} ERRORS { SystemFailure. AbsentSubscriber CallBarred CUG-Reject.1 Formal Description SendRoutingInformation ::= OPERATION PARAMETERS SEQUENCE { msIsdn (0) IMPLICIT IsdnAddressString. DataMissing.1 example . networkSignalInfo (10)IMPLICIT ExternalSignalInfo OPTIONAL} RESULT imsi routingInfo roamingNumber forwardingData SEQUENCE { IMSI CHOICE{ IsdnAddressString.MAP Presentation 43 SEND ROUTING INFORMATION (GMSC-->HLR) Operation Code=22 Class=1 ASN. UnexpectedDataValue. TeleServiceNotProvisioned.3 ASN. ForwardingViolation} Figure 8. UnknownSubscriber. BearerServiceNotProvisioned. numberOfForwarding (2) IMPLICIT NumberOfForwarding OPTIONAL. FacilityNotSupported.

e. This situation requires the MSISDN (this is the number. The order of the data is taken directly from the ASN. Sequence Tag = H’30 Total Length Data1 Tag (MSISDN) Data1 Length Data1 Data2 Tag (NumOfForw.44 MAP Presentation The situation before the operation shall be as follows: A call attempt towards a mobile subscriber reached the GMSC.4 Data in a sequence . The data are formally put into a sequence. i. The call was forwarded once before it arrived at the GMSC.) Data2 Length Data2 Figure 8. The additional data of networkSignalInfo is optional and therefore omitted.1 code. The call is a normal call originating in PSTN and the roaming number shall be fetched via HLR. a special tag is used to show that a number of data is sent sequentially. that was dialled by the calling subscriber) and the number of forwardings (here: 1) to be sent to the HLR.

The left column lists the parameters.1 it is distinguished between implicit and explicit tagging.5 Implicit and explicit tagging . If the ASN. which for sure could be sub-structured. because they are not universal. The missing information are the tags of the parameters.4 shows the sequence as it will look like in the example for SRI.MAP Presentation 45 Figure 8. while the right column defines them. In ASN. If a type declaration of a non-universal parameter is based on a universal type the explicit tagging encapsulates the original parameter.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. 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. According to this the IsdnAddressString and NumberOfForwarding type definitions are needed. the lengths and the contents of the data fields. Each definition leads to a type that is separately defined or to a universal type.

Consequently it is easy to recognize. a 3-bit nature of address indicator and a 4-bit numbering plan indicator. form: primitive=0). AddressString ::= OCTET STRING (SIZE (1. even though the Address string is allowed to consist of 20 octets. 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 .46 MAP Presentation In the example in figure 8.maxAddressLength)) maxAddressLenght = 20 octets a) The first octet includes a one bit extension indicator.. 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. b) Subsequent octets representing address digits encoded as a TBCDSTRING parameter. The identifier in the implicit tagging is equal to 86 (class: context specific=10. form: constructor=1). that the parameters of the SRI message use the implicit tagging.5 the tag value for the explicit tag is 6 and the whole identifier has the value A6 (class: context specific=10.

CCITT E. CCITT E.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 F.69) 0101 spare 0110 land mobile numbering plan (Rec.121) 0100 telex numbering plan (Rec.164) 0010 spare 0011 data numbering plan (Rec.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 8 7 6 5 4 3 2 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 . CCITT X.

so the total length of the address string is 6 octets.5) 82 01 01 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. The corresponding numbering plan is telephony (E. The identifier for the whole MSISDN is a context specific (10) primitive (0) with the implicit tag 0.48 MAP Presentation The first octet contains the numbering plan indicator and the nature of address indicator. . The extension bit is set to 1. therefore the entire octet has the value H’91.The coding looks as follows 80 06 91 94 71 12 32 54 identifier (tag) length contents 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.164) and the nature of address is international. The called number was 4917212345..

9 Coding of the SendRoutingInfo message .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.

Tag Length Number of Forwardings Length Coding .50 MAP Presentation Operation Code Sequence Tag = H’30 Total Length MSISDN Tag Length MSISDN Number ofForw.

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

52 MAP Presentation octets with length relevant information data field. containing 16 (=h’10) 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 .

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. but private data is allowed here and in some cases even private operations are created. Actually in Ericsson four different ‘MAPs’ can be found. The two elements of the DP are the application context (AC) and the user information (UI). 9. 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. The term version is used if the base is the standard MAP as it is defined by GSM. but some minor deviations can always be expected.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).MAP Presentation 53 9 MAP Versions and Variants As already mentioned in the proceeding sections MAP is existing in a number of different issues. It is distinguished between MAP versions and MAP variants. Especially no additional data within the messages are allowed compared to the standard. 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. .

02. Therefor the AC is divided into three parts. The protocol version has usually the value 2.e. can be supported by the . which were proposed in an invocation. The values of the reference part are fixed.54 MAP Presentation Application Context The AC refers to the required protocol (including the version) and the list of operation packages (i. because if version 1 is used no AC is present at all. while the applicationcontext-name values are defined in GSM 09. 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. set of operations) from which operations can be invoked during the dialogue.1 Coding of the AC If the application-context-name and the protocol version. 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 AC-names are defined in two steps.g all operateSS services like registerSS.g. SubscriberDataMngtPackage). This is called fallback.). .MAP Presentation 55 responding entity the dialogue continues on this basis. 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. otherwise it is refused and the initiating user needs to start a new dialogue using an AC with a lower protocol version. eraseSS. etc. activateSS. 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. All operations are assigned operation packages. that include operations with certain relations (e.

2 Ericsson MAP Variants Aligned to the standard MAP.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. which can result in an reattempt or fall-back. In MAP it is used to carry the reason code for U-ABORT messages. User Information The User Information UI in the dialogue portion is used to carry information. The special Ericsson specific services that are supported with this MAP issues are the following: . that is defined by the protocol. the Ericsson variants do have as well versions 1 and 2. these tables can be found in the function specifications for MAP V2 of CME20. referenced to in the AC. 9.

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