map description
TRANSCRIPT
-
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).
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
12/57
12 MAP Presentation
MAP
TCAP
SCCP
MTP
Figure 4.2 MAP in the OSI model
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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-
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
case result of request
send TCAP message
to send BEGIN message
BEGIN (INVOKE)
Figure 7.4 C7-Signalling/dialogue begin
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
case result of request
write MAP messageinto buffer
C7RESULTREQC7ERRORREQ
C7REJECTREQ
C7RESULTREQACCC7ERRORREQACCC7REJECTREQACC
C7RESULTREQNACCC7ERRORREQNACCC7REJECTREQNACC
(* request mess. type*)
Figure 7.9 C7-Signalling/continuation/component
-
7/29/2019 MAP Description
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
case result of request
send TCAP message
to send message
C7ENDREQC7ABOTRREQ
C7CONTREQEXECC7ENDREQEXECC7ABORTREQEXEC
C7ENDREQNEXECC7ABORTREQNEXEC
Figure 7.10 C7-Signalling/continuation/message
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
42/57
42 MAP Presentation
indicates success. The error types are imported from a separateERROR module.
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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)
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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).
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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).
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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
-
7/29/2019 MAP Description
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.