Mobile Application Part (MAP)

DN99588472 Issue 6-0

Mobile Application Part (MAP)

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2009/11/4. All rights reserved

Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures. Non-observance of these conditions and the safety instructions can result in personal injury or in property damage. Therefore, only trained and qualified personnel may install and maintain the system. The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German: Wichtiger Hinweis zur Produktsicherheit In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen. Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren. Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

Mobile Application Part (MAP)

Table of Contents
This document has 40 pages. 1 2 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 2.5 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6 2.7.7 2.7.8 2.8 2.8.1 2.8.2 2.8.3 3 3.1 3.2 3.3 3.4 3.5 3.6 Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Mobile Application Part (MAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network elements with MAP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support protocol description of MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements and software architecture of MAP . . . . . . . . . . . . MAP procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP location management procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP location service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP operation and maintenance procedures. . . . . . . . . . . . . . . . . . . . . . . MAP call handling procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP supplementary service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . MAP short message service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . MAP security procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP subscriber information procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP signalling configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP general settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP overload control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP error counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SCCP return option for MAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number of authentication sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP operation timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direction-specific MAP functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple own network element addresses . . . . . . . . . . . . . . . . . . . . . . . . . . Prevention of MAP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP version handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direction-specific alarms related to MAP . . . . . . . . . . . . . . . . . . . . . . . . . . ANSI MAP - routing addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ANSI MAP - application context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMSC types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP traffic status information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP-related clear and event codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP cyclic buffer for erroneous protocol messages. . . . . . . . . . . . . . . . . . MAP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling MAP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting a fixed destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a fixed destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking how MAP traffic is currently proceeding . . . . . . . . . . . . . . . . . . . 10 10 11 12 13 13 14 15 15 16 16 17 17 17 19 19 20 20 20 21 21 21 23 23 23 24 24 24 24 24 24 28 28 30 30 30 31 31 32 32

Id:0900d80580570e90

Mobile Application Part (MAP)

4 5 6 7 8 9

Defining the MAP version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Activating MAP error counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Reading MAP cyclic buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Modifying the own network element address . . . . . . . . . . . . . . . . . . . . . . . . 36 Denying MAP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Configuring the default MAP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Id:0900d80580570e90

Mobile Application Part (MAP)

List of Figures
Figure 1 Figure 2 Figure 3 The interfaces covered by MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 MAP support protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 The MAP signalling configuration in the MSC and the HLR . . . . . . . . . 19

Id:0900d80580570e90

Mobile Application Part (MAP)

Id:0900d80580570e90

Mobile Application Part (MAP)

Summary of changes

1 Summary of changes
Changes made between issues 6-0 and 5-0 The company and product names have been changed according to the official Nokia Siemens Networks portfolio naming. Changes made between issues 5-0 and 4-2

Changes due to new features A new section about a new functionality SMSC types has been added to Chapter Direction-specific MAP functionalities due to the changes in the MultiCard SMS functionalities. Other changes As the description of the MAP statistics functionality has been changed and in order to clearly separate the following issues: general settings that affect the MAP protocol layer functionality direction-specific settings that affect the MAP protocol layer functionality other MAP related information which the operator can handle, but which does not affect the MAP protocol layer functionality MAP general settings Direction-specific MAP functionalities MAP traffic status information

The following subchapters have been re-structured

Changes made between issues 42 and 41

Changes due to new features As an enhancement, the Multiple Own Network Element Addresses feature can be used to divide the HLR to multiple virtual HLRs by showing different Global Title (GT) numbers outside the HLR. This division is done on IMSI basis. You can create analyses for IMSI ranges to specify which HLR number is used with certain IMSIs. Thus, you can configure one HLR address for a certain subscriber area in the Nokia HLR. The following sections have been updated with these enhancements: Direction-specific MAP functionalities Modifying the own network element address

Changes made between issues 41 and 40

Changes due to new features No changes. Other changes Minor editorial corrections have been made.

Id:0900d80580570e6e

Summary of changes

Mobile Application Part (MAP)

Changes made between issues 40 and 30

Changes due to new features The following sections have been modified due to changes in the Multiple Own Network Element Addresses feature: Direction-specific MAP functionalities A new subsection has been added about the own network element address modification. Modifying the own network element address A new operating instruction section has been added.

The CAMEL Phase 2 Functional Subset in SSP feature has brought two new subscriber information procedures: AnyTimeInfoHandling SubscriberDataModificationNotification

Other changes The Figure Interfaces covered by MAP has been enhanced. Further details have been added to the Subsection MAP overload control. A new subsection has been written on MAP timers: MAP operation timers New operating instruction sections have been added: Configuring the default MAP parameters Denying MAP traffic

Changes made between issues 30 and 20

Interfaces using MAP protocol Figure The interfaces covered by the MAP modified: Ls and Lv interfaces removed, M interface added. Support protocol description of MAP SIGTRAN mentioned as a replacement of MTP. Software architecture of MAP Pairs: GMSC SGNS, MSC-A MSC-B, MSC-A MSC-B', and VLR gsmSCF have beed added to the list of MAP dialogues. Clear Codes related to MAP Clear Code '0410 GT ANALYSIS FAILED' added to the list of Clear Codes related to MAP. The MAP related clear and event codes have been moved to Chapter 2. Alarms related to MAP The list of alarms related to MAP has been removed from this document. It can be found in Failure Printouts. Changes made between issues 20 and 10

Id:0900d80580570e6e

Mobile Application Part (MAP)

Summary of changes

Introduction to Mobile Application Part References to MAP interfaces, which are not implemented in Nokia M11 were removed. New interface added (M interface for MM notification). New MAP procedures and a section on MAP Subscriber information procedures added. MAP general settings New heading. New section on Direction specific MAP functionalities added. Information on ANSI MAP routing addresses, SCCP return option for MAP and Authentication sets of MAP added.

Id:0900d80580570e6e

Mobile Application Part (MAP)

Mobile Application Part (MAP)

2 Mobile Application Part (MAP)

MAP interfaces are open interfaces specified by ETSI/3GPP. MAP protocol functions mainly concern the information exchange between switches and registers in GSM/UMTS networks related to the possibility for a mobile station to roam. For transferring the information between functional units in PLMNs, MAP uses the services provided by Signalling System No. 7. MAP protocol layer receives internally-coded data from a MAP user, for example, from a Home Location Register (HLR) application, a Visitor Location Register (VLR) application, or a Short Message Service (SMS) application, and sends the data in a standardised format, that is, in the ASN.1 format, to a peer network element. Non-call-related signalling and the mobility of subscribers make additional demands. An example of a MAP procedure is the location update in which MAP is used for signalling between the VLR and the HLR.

2.1

Network elements with MAP interface

The following network elements have the MAP interface: Home Location Register (HLR) Visitor Location Register (VLR) Mobile Services Switching Centre (MSC) Equipment Identity Register (EIR) Serving GPRS Support Node (SGSN) GSM Service Control Function (gsmSCF) Gateway Mobile Location Center (GMLC)

MAP is implemented as specified by ETSI and its successor 3GPP. Compatibility between different network elements provided by different vendors has been proven in a number of networks in inter-PLMN roaming cases and also in intra-PLMN cases, where Nokia Siemens Networks is one of the two or more equipment suppliers. Interfaces using MAP protocol The following interfaces are covered by MAP:

Figure 1

The interfaces covered by MAP

10

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

C interface D interface E interface F interface G interface Gc interface Gd interface

between the MSC and the HLR, for example, routing information inquiries for Mobile-Terminated (MT) calls between the VLR and the HLR, for example, location update, subscriber data management between two MSCs, for example, handovers, Mobile-Originated (MO) and Mobile-Terminated (MT) short messages between the MSC and the Equipment Identity Register (EIR), International Mobile Equipment Identity (IMEI) status checking between the two VLRs, International Mobile Subscriber Identity (IMSI), and authentication triplet retrievals from the previous VLR between the HLR and the GGSN, mobile terminated PDP context activation. This interface has not been implemented between the SMS-GMSC and the Serving GPRS Support Node (SGSN), for example General Packet Radio Service (GPRS) short messages between the EIR and the SGSN, GPRS IMEI checking between the HLR and the SGSN, for example, GPRS location update between the HLR and the gsmSCF, for example, Unstructured Supplementary Service Data (USSD) or any time handling of subscriber data between the MSC and the GSM Service Control Function (gsmSCF), supplementary service notification between the HLR and the Gateway Mobile Location Centre (GMLC), location services between the MSC and the GMLC, location services between the VLR and the gsmSCF, Mobility Management (MM) notification

Gf interface Gr interface J interface L interface Lh interface Lg interface M interface

2.2

Support protocol description of MAP

MAP uses the services of the other signalling protocol layers of the system. These protocol layers are: MTP SCCP TCAP

Message Transfer Part (MTP) is the foundation on which SS7 is built. Signalling Connection Control Part (SCCP) enables the placement of signalling messages in the correct order at the distant end (connection-oriented network service) and signalling across multiple networks in the absence of a call (connectionless network service). MAP uses only the connectionless services of the following SCCP: Class 0 Class 1 Basic connectionless class Sequenced connectionless class

Transaction Capabilities Application Part (TCAP) handles the MAP transaction messages between different network elements. MAP uses the SCCP's services through TCAP.

Id:0900d80580570e78

11

Mobile Application Part (MAP)

Mobile Application Part (MAP)

The IETF Signalling Transmission (SIGTRAN) protocol stack (M3UA, SCTP, IP) can replace the MTP to transfer SS7 signalling over IP networks.

Figure 2

MAP support protocols

When one network element that has MAP operates with another network element, both elements have to have the above-mentioned protocol stack, that is, MAP, TCAP, SCCP, and MTP. A network element can also serve as an Signalling Transfer Point (STP) between other network elements when it only transmits signalling from one element to another. In this case, the STP can only have an MTP, or an MTP and an SCCP even if the other network elements also have MAP.

2.3

Hardware requirements and software architecture of MAP

Hardware requirements MAP does not require any special hardware. The MAP implementation is located in a Common Channel Signalling Unit (CCSU), in a General Signalling Unit (GSU), or in a Sigtran Signalling Unit (SIGU). The same generic MAP implementation can be used in all network elements. Software architecture MAP is implemented by the Mobile Application Part Service Block (MATSEB) that belongs to the Signalling Services System Block (SGLSYB). MATSEB is made up of several program blocks. The program blocks necessary for implementing MAP are the following: Mobile Application Part TCAP Adapter Program Block (MTAPRB) Mobile Application Part HLR Program Block (MHRPRB) MAP Statistical Program Block (MPSTAT) MAP Control Parameter Management Program Block (MCPPRB) MAP Parameter Handling MML (MAHAND) MAP Statistics MML Program Block (MPHMML)

The MAP implementation contains network element dependent functions of the MAP interface. These functions are called MAP Application Service Elements (ASEs). Each MAP ASE is able to handle the user interface and the required dialogues. The MAP program of the MSC controls MAP dialogues between:

12

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

the pair of Visited MSC (VMSC) and Short Message Service Interworking MSC (SMS-IWMSC) the pair of VMSC and SMS Gateway MSC (SMS-GMSC) the pair of VMSC and gsmSCF the pair of VMSC and GMLC the pair of SMS-GMSC and HLR the pair of GMSC and HLR the pair of VMSC and EIR the pair of SMS-GMSC and SGSN the pair of SMS-IWMSC and SGSN the pair of anchor MSC (MSC-A) and MSC-B the pair of MSC-A and MSC-B' the pair of VLRs the pair of VLR and HLR the pair of VLR and Authentication Centre (AUC) the pair of VLR and gsmSCF the pair of HLR and VLR the pair of HLR and GMSC the pair of HLR and SMS-GMSC the pair of HLR and SGSN the pair of HLR and gsmSCF the pair of HLR and GMLC the pair of AUC and VLR the pair of EIR and VMSC the pair of EIR and SGSN

The MAP program of the VLR controls MAP dialogues between:

The MAP program of the HLR controls MAP dialogues between:

The MAP program of the EIR controls MAP dialogues between:

2.4

MAP procedures
A MAP procedure is a service offered by MAP. The procedure defines the operations that can be used in a given transaction. The procedures are described here only briefly, and the operations are not presented. For more information, see the MSC/VLR-HLR/EIR/MSC/VLR/GMLC/gsmSCF Mobile Application Part, Interface Specification and the HLR/EIR-MSC/VLR/SGSN/gsmSCF/GMLC Mobile Application Part, Interface Specification.

2.4.1

MAP location management procedures

The following location management procedures are used to handle the mobility of a subscriber:

Id:0900d80580570e78

13

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Location update The location update procedure is used to update location information held in the network. Location information is used to route incoming calls, packet data, short messages, and USSD to a roaming subscriber. The MAP_UPDATE_GPRS_LOCATION service is used by the SGSN to update the location information stored in the HLR. Location cancellation The purpose of the procedure is to delete the subscriber's record from the previous VLR after the subscriber has registered in a new VLR. The procedure can also be used if the subscriber's record has to be deleted for other operator-determined purposes, for example, withdrawal of subscription. This service is also used between the HLR and the SGSN to delete a subscriber record from the SGSN. The service can be invoked automatically when a Mobile Station (MS) moves from one SGSN area to another, to remove the subscriber record from the old SGSN, or by the HLR operator to enforce a location update from the SGSN to the HLR. Mobility management event reporting This procedure is used to notify the gsmSCF about a subscriber's change of location. The procedure is triggered by, for example, location update. MS purging An MS record is to be purged either because of an administrative action, or because the MS has been inactive for an extended period. After the purging, any request for routing information for a mobile-terminated call or a Mobile-Terminated Short Message (MTSM) is treated as if the MS is not reachable. This service is also used between the SGSN and the HLR to cause the HLR to mark its data for an MS, so that any request for routing information for a mobile-terminated short message or a network-requested PDP context activation is treated as if the MS is not reachable. Handover When an MS moves from one MSC area to another during a transaction, the handover procedure has to be performed in order to continue communication. For that purpose, the MSCs involved have to exchange data to initiate and then to realise the operation. Fault recovery After a fault in a location register, the fault recovery procedures ensure that subscriber data in the VLR or in the SGSN become consistent with the subscriber data stored in the HLR for the given MS. It also ensures that location information in the HLR, VLR, and SGSN shows accurately the current location of the MS. There are two fault recovery procedures: VLR restoration HLR restoration

2.4.2

MAP location service procedures

The location service procedures are used:

14

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

between the GMLC and the HLR to retrieve routing information needed for routing a location service request to the servicing VMSC by the GMLC to request the location of a target MS from the VMSC by the VMSC to provide the location of a target MS to the GMLC when the request for location is either implicitly administered or made at some earlier time

2.4.3

MAP operation and maintenance procedures

The following three operation and maintenance procedures are needed for operating and maintaining the GSM PLMN network: Tracing procedures Subscriber tracing activation The subscriber tracing activation procedure is used at location update or data restoration when the trace mode of a subscriber is set active in the HLR, or as a standalone procedure when the subscriber is already registered and the trace mode becomes active in the HLR. Subscriber tracing deactivation The subscriber tracing deactivation procedure is used when the trace request of a subscriber has to be cancelled.

Subscriber data management procedures Subscriber deletion In the subscriber deletion procedure, the subscriber data has to be removed from the VLR and the HLR. Subscriber data modification In the subscriber data modification procedure, subscriber data is modified in the HLR, and when necessary, also in the VLR or in the SGSN.

Subscriber identity procedure In the subscriber identity procedure, the IMSI of a subscriber is retrieved from the HLR.

2.4.4

MAP call handling procedures

The MAP call handling procedures are used to retrieve routing information to handle a mobile-terminated call, to transfer the control of a call back to the GMSC if the call is to be forwarded, to retrieve and to transfer information between the anchor MSC and the relay MSC for inter-MSC group calls/broadcast calls, to handle the reporting of MS status for call completion services, and to handle the notification of a remote user free for Completion of Calls to Busy Subscribers (CCBS). The following call handling procedures are used: retrieval of routing information transfer of call handling inter-MSC group call setting of reporting state status reporting remote user free

Id:0900d80580570e78

15

Mobile Application Part (MAP)

Mobile Application Part (MAP)

2.4.5

MAP supplementary service procedures

The following MAP supplementary service procedures are used: Registration It is used to register data related to a supplementary service in the HLR. Erasure It is used to erase data related to a supplementary service in the HLR. Activation It is used to activate a supplementary service in the HLR. Deactivation It is used to deactivate a supplementary service in the HLR. Interrogation It is used to retrieve information related to a supplementary service from the VLR or HLR. Password registration It is used to register a password in the HLR. Mobile-initiated USSD It supports supplementary service signalling procedures that can allow PLMNspecific services to be introduced. Network-initiated USSD It supports supplementary service signalling procedures that can allow PLMNspecific services to be introduced. Supplementary service invocation notification It is used to notify the gsmSCF about the invocation of a GSM supplementary service. Activation of CCBS request Deactivation of CCBS request

2.4.6

MAP short message service procedures

The following four SMS procedures are used to control both the mobile-originated and mobile-terminated SMS transfer: Mobile-originated short message transfer The MO-SMS transfer procedure is used to forward an SM from a mobile subscriber to a Service Centre. Mobile-terminated short message transfer The MT-SM transfer procedure is used to forward an SM or several SMs from a Service Centre to a mobile subscriber. Short message alert The SMS alert procedure is used to alert a Service Centre when a mobile subscriber is active after an SMS transfer has failed as the mobile subscriber has not been reachable. This procedure is also used when the mobile station has indicated that it has the memory capacity to accept an SM. Short message delivery status report The SMS delivery status report procedure is used to set the Service Centre address into a message waiting list in the HLR as the subscriber is absent or unidentified, or the memory capacity is exceeded.

16

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

2.4.7

MAP security procedures

The following MAP security procedures are used: IMEI checking procedure The IMEI checking procedure is used between the MSC and the EIR, and between the SGSN and the EIR to request the check of an IMEI. Authentication procedure The authentication procedure is performed in order to validate the correctness of the mobile user's SIM card and to prevent a fake card from accessing the network. Authentication failure reporting The authentication failure reporting procedure is used to notify the HLR about the occurrence of an authentication failure in the SGSN or VLR. Send identification procedure The send identification procedure is used between a VLR and a Previous VLR (PVLR) for retrieving IMSI and authentication sets for a subscriber registering afresh in that VLR. The procedure is invoked by a VLR when it receives a Location Area Identification (LAI) indicating that the subscriber was registered in a different VLR.

2.4.8

MAP subscriber information procedures

The following MAP subscriber information procedures are used: AnyTimeInfoEnquiry With this procedure, the gsmSCF can request information on, for example, subscriber state and location at any time. Information concerning subscriber state or location may be requested from the HLR. GMLC can only provide information about the subscriber location. SubscriberInfoEnquiry The SubscriberInfoEnquiry is used to request information on, for example, subscriber state and location from the VLR or SGSN at any time. AnyTimeInfoHandling With this procedure, the gsmSCF can interrogate the HLR about the subscriber's subscription information, and can request modifications in the subscriber's subscription information. SubscriberDataModificationNotification With this procedure, the HLR informs the gsmSCF of changes in the subscriber data.

2.5

MAP signalling configuration

The HLR controls the HLR, AUC, and EIR functions and the MSC controls the MSC and VLR functions. The functions are grouped in the subsystems that communicate with other network elements through MAP. The subsystems are defined at the SCCP level and are thus called SCCP subsystems for MAP. HLR and AUC functions are reached through the MAPH subsystem, EIR function through the MAPE subsystem, MSC function through the MAPM subsystem, and VLR function through the MAPV subsystem. When a new network element is connected to the network, the main objective is to make the SCCP subsystems for MAP reachable to all the other network elements. As a con-

Id:0900d80580570e78

17

Mobile Application Part (MAP)

Mobile Application Part (MAP)

sequence, MAP and all the underlying protocols have to be appropriately defined in the whole network area. SCCP routing plays a significant role in the GSM network configuration. In Figure The MAP signalling configuration in the MSC and the HLR, you can see that if you use routing on Subsystem Number (SSN), a more static definition has to be made in both the new network element and all the other elements where routing on SSN is defined towards the new element (all the SPC definitions and corresponding SSN definitions). If routing on Global Title (GT) is used in all cases (which is preferable), emphasis is on GT translation definitions. Although more analyses are needed when routing on GT is used, the resulting flexibility gives the network a much better upgrade ability. If routing is based on the GT, the actual routing happens at SCCP and MTP level. If the routing is based on SSN, it is performed only by the MTP. For more information on SCCP addressing, see SCCPaddressing (GT or SPC/SSN) in Common Channel Signalling (MTP, SCCP and TC).

18

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Figure 3

The MAP signalling configuration in the MSC and the HLR

For more information on configuration, see Introductionto MSC and HLR integration in MSC and HLR Integration.

2.6
2.6.1

MAP general settings

MAP overload control
MAP protects MAP users from the overload caused by incoming dialogue initiations. MAP also protects its own unit, the CCSU from overload caused by outgoing dialogue initiations.

Id:0900d80580570e78

19

Mobile Application Part (MAP)

Mobile Application Part (MAP)

For incoming dialogues, the default behaviour is that MAP uses the ticket service. The usage of the ticket service can be deactivated. If the ticket service is used, the overloading events are discarded as the default functionality. As a configurable option, MAP can also inform the requesting network element about the overload situation by sending a TC-ABORT back to the network. The decision as to which events may be discarded is based on the priorities of the application contexts. For incoming and outgoing dialogues, MAP protects its own unit from overload, when the number of unhandled dialogue initiations exceeds a predetermined threshold. For detailed information, see Section MAP interface in a CCSU of the MSC &VLR and MSC Server in Overload and Congestion Control ( MSC Server), Functional Description. For operating instructions, see Configuring the default MAP parameters.

2.6.2

MAP error counters

The counters in which data about failed MAP operations can be compiled are needed because alarms are generated from these counters if the error ratio exceeds the defined thresholds. There are three different threshold levels: low, medium, and high. Every MAP operation can have its own thresholds. The thresholds can be set up for minor, major, and critical alarms. If the threshold level low is exceeded, minor alarm 2701 MAP PROCEDURE FAILURE - LOW is generated. Similarly, if threshold level medium is exceeded, major alarm 2702 MAP PROCEDURE FAILURE - MEDIUM is generated, and if threshold level high is exceeded, critical alarm 2703 MAP PROCEDURE FAILURE - HIGH is generated. The counters which are used for setting the alarm are independent in each signalling unit. Before threshold limits are checked, the minimum number of operations has to be started in the unit. Also, this same minimum number has to be reached before the unit's error counters can be automatically reset. For operating instructions, see Activating MAP error counters.

2.6.3

SCCP return option for MAP

At SCCP level (in Unitdata (UDT) and Extended Unitdata (XUDT) messages), it is possible to set that the message should be returned to the sender in case of routing problems. It can be controlled by using the MAP parameter management MMI whether this functionality is active or not. It is active by default. This functionality is controlled only at the sending side. At the receiving side, returning is performed if needed and if it is allowed. This is determined by the indicator in the received SCCP message. The alarm related to the routing problems of this functionality is 2646 PROTOCOL ROUTING FAILURE.

2.6.4

Number of authentication sets

Authentication requests with MAP versions 1 and 2 cannot contain information about how many authentication sets are requested by the VLR/SGSN. To handle these situations the value of the returned authentication sets is configured locally in the HLR and in the VLR. There are separate parameters for MAP version 1 and MAP version 2. The parameters do not have any effect when MAP version 3 is used.

20

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

By default, the returned amount of authentication sets is four. The maximum value with MAP version 1 is five. The maximum value with MAP version 2 is four. This is due to the limitations at the MTP level. If the response message is too long to fit in an MTP message, no information is delivered to the VLR/SGSN. The setting of these parameters has a meaning in the HLR affecting the SendAuthenticationInfo operation, and in the VLR affecting the SendIdentification operation. As to the SendIdentification operation between VLRs, maximum of three sets is sent in the response even if the configured value of the parameter is higher than three.

2.6.5

MAP operation timers

MAP operations are controlled with a timer, which is started in the initiating node when an operation invocation is sent. Almost all MAP operations must be acknowledged with either a positive or a negative result. If the result is not received within the specified time, the operation is considered unsuccessful. The operation timer value is defined separately for each MAP operation, and it is typically between 10 to 30 seconds. For certain operations, shorter or longer timers are also used. You can interrogate the MAP operation timer values but you cannot configure them. You can use the OPP command to interrogate the timer values.

2.7

Direction-specific MAP functionalities

To optimise the use of the signalling network, you can create network entity address analyses for MAP dialogue initiations. When a dialogue towards a remote network element is to be initiated, or a dialogue initiation is received from a remote network element, the address is analysed in the analysis tree you have created. The analysis is based on the SCCP level address (GT or SPC) of the peer network element. In case an analysis has not been determined for the destination address, a default can be defined for all of the direction-specific MAP functionalities. In connection with address analysis, the following direction-specific MAP functionalities are used: use of multiple own network element addresses MAP version handling and prevention of MAP traffic use of proprietary parameters (extensions) direction-specific alarm handling selection of routing address type (ITU-T or ANSI) selection of Application Context type selection of SMSC types

2.7.1

Multiple own network element addresses

When roaming agreements are set up, all data concerning the shared common core network (for example, GT addresses) have to be sent to the international roaming operators. This can cause confusion in the remote end and can lead to future problems for roaming signalling. The Multiple Own Network Element Addresses feature enables the operators sharing a common core network to be able to specify their own SS7 Calling Party Address (CgPA)

Id:0900d80580570e78

21

Mobile Application Part (MAP)

Mobile Application Part (MAP)

to the MSC/VLR. This means that the MSC/VLR has multiple own addresses and each partnering operator can associate its own MSC/VLR CgPA to its roaming subscribers. With this mechanism, SS7 signalling is routed from the roaming subscriber's core network back to the shared MSC/VLR through the correct core network. Thus, the SS7 signalling is routed correctly in core network sharing cases, and the SS7 signalling load is distributed evenly to the network sharing partners. Monitoring of signalling in core network sharing cases is easier as well, and the operator can make more flexible roaming agreements. The MAP protocol checks whether there is an address analysis for the Called Party Address (CdPA) and whether the result of that analysis is the new own network element address. The own address parameter is used on SCCP level and in some operations the new own network element addresses are also used as MAP message parameters. These operations are: UpdateLocation PurgeMS SubscriberLocationReport ProvideSubscriberInfo response AuthenticationFailureReport SendRoutingInfo NoteMM-Event

You can modify the value of the own network element address. The possible modification is based on the analysis of the SCCP level Called Party Address. As an enhancement, this feature can be used to divide the HLR to multiple virtual HLRs by showing different GT numbers outside the HLR. This division is done on IMSI basis. You can create an analysis for the IMSI (E.212) ranges to specify which HLR number is used with certain IMSIs. Based on the analysis, the analysis result can give a new HLR address. Thus, you can configure one HLR address for a certain subscriber area in the Nokia Siemens Networks DX HLR. If no analysis exists, the default number is used. The HLR address (in SCCP and in MAP level if the parameter exists) is changed in the following operations where a dialogue is initiated from the HLR: InsertSubscriberData DeleteSubscriberData CancelLocation ActivateTraceMode DeactivateTraceMode ProvideRoamingNumber ProvideSubscriberInfo UnstructuredSS-Request UnstructuredSS-Notify SS-InvocationNotification SetReportingState RemoteUserFree GetPassword AlertSC Reset In the HLR, you cannot configure the SCCP Calling Party Address for a message that contains Reset operation.

22

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

The MAP level HLR address is changed in the following result components of MAP operations: RestoreData result UpdateLocation result UpdateGPRSLocation result

The SCCP level address is changed in the first response message of the following network-initiated MAP dialogues: networkLocUpContext-v3, networkLocUp (v2,v1) infoRetrievalContext-v3,v2 gprsLocationUpdateContext-v3

2.7.2

Prevention of MAP traffic

If you have the prevention of MAP traffic in use, you can block all the dialogue initiations. The prevention is based on the SCCP level address (GT or SPC) of the peer network element. If the address analysis of the remote network element leads to value 'denied', the dialogues to/from this element are not accepted, that is, the dialogue is not sent to the network and the dialogue initiation from the network is aborted. The prevention of MAP traffic is handled by version handling.

2.7.3

MAP version handling

MAP is continually evolving as new services are introduced to the GSM system. When a set of new services is introduced and new MAP operations or new parameters to existing operations are added, the version for related ACs is updated. This versioning ensures backward compatibility to earlier implementations. When a MAP entity supports a particular new version, it also has the ability to revert to using a lower version if the new version is not supported by a peer entity. This mechanism is called protocol version fallback. The fallbacks can cause extra load on signalling networks. For operating instructions, see Section Defining the MAP version.

2.7.4

MAP extensions
On the basis of the address analysis result, it is also determined whether the extensions for operations and their parameters are in use or not. The extensions are Nokia Siemens Networks-specific additions to MAP messages, and their use can be denied. The Nokia Siemens Networks-specific extension can only be used with Nokia Siemens Networks DX MSC/VLRs and HLRs. Usually, extensions sent by another vendor's network elements are not understood. They are ignored because their coding cannot be opened. However, if, for example, a foreign network sends extensions that are interpreted as extensions specific to the own PLMN and, therefore, may have unwanted effects, it can be helpful that all extensions sent from certain directions can be explicitly ignored. This applies also to the outgoing direction: the extensions are not sent.

g Do not deny the use of the extensions, because the denial can prevent the use of
Nokia Siemens Networks-specific applications and some operations.

Id:0900d80580570e78

23

Mobile Application Part (MAP)

Mobile Application Part (MAP)

2.7.5

Direction-specific alarms related to MAP

The alarms 2646 PROTOCOL ROUTING FAILURE and 1647 OPERATION TIMER EXPIRY are direction-specific in the sense that they can be blocked to a certain direction. This means that in a certain direction it can be defined AC-specifically whether the alarm is set or not.

2.7.6

ANSI MAP - routing addresses

It is possible to define the type of used routing addresses. There are two possibilities, ITU and ANSI. With Global Title (GT) addresses, GTI 4 is used with ITU and GTI 2 with ANSI. The length of the signalling point codes in ITU and ANSI signalling is different. Standard ITU length is 14 bits. ANSI uses 24 bits long signalling point codes. Global titles with GTI 2 contain the translation type and digits. GTs with GTI 4 contain the translation type, numbering plan, encoding scheme, nature of address indicator, and digits. The differences between ITU and ANSI addresses at the SCCP and MTP level are not discussed here. When a dialogue is to be initiated towards the network, MAP selects the type of address (ITU/ANSI) to be used based on what is configured with MAP parameter management. When a dialogue is initiated by the network, MAP accepts both types of addresses if ANSI MAP support feature is activated in the network element.

2.7.7

ANSI MAP - application context

The value of the AC name and abstract syntax identifier (AS-ID) is different in ITU and ANSI systems. The type of AC and AS-ID can be selected on the basis of the remote end (direction). When a dialogue is initiated, the type is selected on the basis of MAP configuration information. When a dialogue initiation request is received from the network, ITU is always accepted. ANSI is accepted in case ANSI MAP support feature is activated in the network element.

2.7.8

SMSC types
The result of the address analysis can indicate an Short Message Service Centre (SMSC) type. This information is meaningful only when a SendRoutingInfoForSM or a ReportSM-DeliveryStatus operation (application context 20, shortMsgGatewayContext) is received from the network. The information about the SMSC type is forwarded by MAP to the HLR application, which uses the information in the business logic of the MultiSIM functionality.

2.8
2.8.1

MAP traffic status information

MAP-related clear and event codes
This section lists clear codes and event codes that can be encountered when MAP is used. For more information, see the Clear Code List.

24

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Clear codes related to MAP Clear code 0005 B SUBSCRIBER BUSY Explanation 1. A subscriber is not able to receive an MobileTerminated Short Message (MT-SM) because the MS is busy receiving another MT-SM. 2. MAP sets the clear code if the BusySubscriber error is received from another network element and the error component does not contain any additional information. 0010 ABSENT SUBSCRIBER 0021 B-SUBSCRIBER BUSY, CCBS POSSIBLE The response received by the MSC/VLR is that an MS is not reachable. MAP sets the clear code if the BusySubscriber error is received from another network element with a CCBS-Possible indicator.

0022 B-SUBSCRIBER BUSY, CCBS NOT MAP sets the clear code if the BusySubscriber POSSIBLE error is received from another network element without a CCBS-Possible indicator. 0304 B-LINE OUT OF SERVICE MAP sets the clear code in the MSC/VLR when the incoming calls to a called subscriber have been barred by an operator. MAP sets the clear code in the MSC/VLR when a mobile subscriber has activated the supplementary service of incoming call barring. MAP sets the clear code in the MSC/VLR when data of a called MS cannot be found in the HLR. MAP sets the clear code in the MSC/VLR when the number of a called MS in the HLR has changed. 1. MAP sets the clear code in the MSC/VLR when the HLR has responded with a negative acknowledgement to the SendRoutingInfo operation with cause code CugReject without any additional information. 2. The SendRoutingInfo operation is rejected by MAP in the VLR because CUG information cannot be supported with the current MAP version. 0311 BEARER SERVICE NOT PROVISIONED The HLR has responded to the SendRoutingInfo operation that the bearer service is not provided. As a result, MAP sets the clear code in the MSC/VLR. The response received to an operation is that the teleservice is not provided.

0306 B-CALLS RESTRICTED

0307 B-NUMBER UNUSED 0308 B-NUMBER CHANGED

0310 UNSPECIFIED CUG CALL FAILURE

0312 TELESERVICE NOT PROVISIONED

Id:0900d80580570e78

25

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Clear code 0313 ILLEGAL SUBSCRIBER 0314 UNIDENTIFIED SUBSCRIBER

Explanation MAP sets the clear code if the IllegalSubscriber error is received from another network element. The error is received from another network element.

0315 B SUBSCRIBER HAS CALL DIVER- The HLR has given a negative response to the SION BARRING SendRoutingInfo operation with cause code ForwardingViolation. 0319 ILLEGAL SUBSCRIBER STATION 031A INCOMING CALLS BARRED WITHIN THE CUG The error is received from another network element. The HLR has responded to the SendRoutingInfo operation that incoming calls have been barred within the CUG. As a result, MAP sets the clear code in the MSC/VLR.

031C SUBSCRIBER NOT A MEMBER OF The HLR has responded to the SendRoutingInfo THE CUG operation that a subscriber is not the member of CUG. As a result, MAP sets the clear code in the MSC/VLR. 031F REQUESTED BASIC SERVICE VIOLATES CUG CONSTRAINTS The HLR has responded to the SendRoutingInfo operation that the requested basic service violates CUG constrains. As a result, MAP sets the clear code in the MSC/VLR. The HLR has responded to the SendRoutingInfo operation that called party SS interaction violates within CUG. As a result, MAP sets the clear code in the MSC/VLR. Call control has sent the erroneous SendRoutingInfo request. As a result, MAP sets the clear code in the MSC/VLR. MAP sets the clear code when the attempt to start a MAP service has failed at a receiving end because of limited resources or congestion. MAP sets the clear code if the RoamingNotAllowed error is received from another network element. MAP sets the clear code if a notice that a message could not be delivered to a remote node is received from SCCP, and the notice contains a cause code indicating that address translation is missing. MAP sets the clear code if a CCSU is overloaded. The negative acknowledgement received to an operation from the other network element is FacilityNotSupported.

0320 CALLED PARTY SUPPLEMENTARY SERVICE INTERACTION VIOLATED WITHIN CUG 0405 ERRONEOUS REQUEST FROM CO-PROCESS 040C MAP CONGESTION

040E ROAMING NOT ALLOWED

0410 GT ANALYSIS FAILED

060B OVERLOAD CONGESTION 0810 FACILITY IS NOT SUPPORTED IN THE PLMN

26

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Clear code 0811 NETWORK FAILURE

Explanation The negative acknowledgement received to an operation from another network element is SystemFailure. 1. MAP sets the clear code with an undefined reason. This cause is used as a default if none of the clear codes usually set by MAP is suitable. 2. The negative acknowledgement received to an operation from the other network element is DataMissing. 3. The negative acknowledgement received to an operation from another network element is UnexpectedDataValue. 4. An abort message has been received from the network. 5. A reject component has been received from the network. 6. There is a routing failure. A MAP message could not be routed to a destination network element. 7. TCAP resource limitation. 8. MAP has received an unexpected message from TCAP. 9. A MAP internal error. 10. No response has been received from the MSC. 11. No response has been received from the EIR. 12. No response has been received from the SCP.

0812 MAP FAILURE

081B HLR FAILURE

MAP sets the clear code in the MSC/VLR when no response has been received from the HLR in the SendRoutingInfo operation. No response has been received from the VLR. An overload message has been received from the network.

081C VLR FAILURE 081F NETWORK, OVERLOAD CONGESTION

Id:0900d80580570e78

27

Mobile Application Part (MAP)

Mobile Application Part (MAP)

Event codes related to MAP Event code 103E UNAUTHORIZED LCS CLIENT OR REQUEST Explanation 1. MAP sets the event code when it receives a negative acknowledgement from the GMLC with MAP error UnauthorizedRequestingNetwork. 2. MAP sets the event code when it receives a negative acknowledgement from the GMLC with MAP error UnknownOrUnreachableLCSClient.

2.8.2

MAP cyclic buffer for erroneous protocol messages

If other network elements send invalid data, it is useful to know what kind of data they send. This information is relevant for troubleshooting. If MAP finds the received data invalid, an alarm is set and the data is stored in the cyclic buffer from which it can be displayed with the MMI. The buffer can store 200 erroneous messages. There is a cyclic buffer in every signalling unit. The following data is included in a cyclic buffer entry: identification of the process that stores the data in the cyclic buffer application context of a dialogue type of the TCAP message time when the entry is written routing address of the remote end (GT or SPC, and the signalling network) subsystem number of the remote end the reason why the received data was interpreted as invalid invalid data g In some cases, there may be an internal header before invalid data. The header cannot be interpreted by using the GSM specifications. The internal header is not transferred in the network.

For operating instructions, see Reading MAP cyclic buffer.

2.8.3

MAP statistics
MAP statistics (MAP protocol measurement) is used to monitor the amount of incoming and outgoing MAP signalling messages. Gathered statistical information can be used, for example, in troubleshooting. Statistical data is gathered separately for different MAP interfaces. The interfaces are identified with the Subsystem Numbers (SSN) of the communicating MAP entities, for example, the HLR-VLR is identified as one interface. For every interface, there are 11 sets of counters. Each counter set is used for a different destination that is defined for using SPC or GT addresses. The destination addresses for up to 10 of the counter sets are manually configured by the operator. These 10 counter sets are used as fixed destinations, that is, a destination address can be given and then the counter set is reserved only for this specified destination. The 11th counter set is reserved for transactions which are to/from all other destinations, that means the destination address in the MAP signalling message is not one of the predefined ones.

28

Id:0900d80580570e78

Mobile Application Part (MAP)

Mobile Application Part (MAP)

The counter sets are divided into counters for dialogues (identified by the Application Context identifier), and for operations that are invoked during the dialogue (identified by the operation code). There are separate counters for incoming and outgoing MAP dialogues. This is necessary for making distinction between incoming and outgoing events in case of dialogues which are shown in the statistics between identical subsystems on both ends (for example, MSC-MSC or VLR-VLR). The following data is gathered for every dialogue (application context) and for the used dialogue version: total number of initiated dialogues total number of dialogues aborted by a local application total number of dialogues aborted by MAP layer at the own node total number of dialogues aborted by TC-P-Abort received from the network total number of dialogues aborted by TC-U-Abort received from the network total number of dialogues interrupted because of an operation timer expiration total number of dialogues interrupted because of an internal timer expiration total number of version fallbacks

One MAP dialogue contains one or more MAP operations. There are separate counters for incoming and outgoing MAP operations. This is needed because some operations are invoked between identical subsystems on both ends. The following data is gathered for every operation code and for the used dialogue version for the operation: total number of invoked operations total number of operations that resulted an error total number of operations that resulted an abort or reject total number of operations for which there was no response before an operation timer expiration

For operating instructions, see Section 2.8.3 MAP statistics.

Id:0900d80580570e78

29

Handling MAP statistics

Mobile Application Part (MAP)

3 Handling MAP statistics

MAP statistics is used to monitor the amount of MAP traffic towards and from network entities. For full description of the commands, see the MAP and SSAP Measurements Handling, OX Command Group. For detailed information, see MAP statistics MAPstatistics.

3.1

Setting a fixed destination

Steps 1 Display the destination list (OXY) Example Display the destination list which contains all the fixed destinations from your MSC to the HLR. ZOXY:PROTOCOL=MAP:SNET=MSC:DNET=HLR; 2 Set the fixed destination (OXF) Example Set as the fixed destination the signalling point code 76 that is located in common channel signalling network NA0 and belongs to the HLR. ZOXF:PROTOCOL=MAP:SNET=MSC:DNET=HLR:CCNET=NA0,SPC=76; 3 Check the outcome (OXY) Display the destination list to check that the setting of the destination has been carried out successfully. Example Display the destination list containing all the fixed destinations from your MSC to the HLR. ZOXY:PROTOCOL=MAP:SNET=MSC:DNET=HLR;

3.2

Deleting a fixed destination

Steps 1 Display the destination list (OXY) Example Display the destination list containing all the fixed destinations from your MSC to the HLR. ZOXY:PROTOCOL=MAP:SNET=MSC:DNET=HLR; 2 Delete the fixed destination (OXD) Example Delete fixed destination SPC 76 that is located in common channel signalling network NA0. ZOXD:PROTOCOL=MAP:SNET=MSC:DNET=HLR:CCNET=NA0,SPC=76;

30

Id:0900d80580570e7b

Mobile Application Part (MAP)

Handling MAP statistics

Check the outcome (OXY) Display the destination list to check that the deleting process has been carried out successfully. Example Display the destination list containing all the fixed destinations from your MSC to the HLR. ZOXY:PROTOCOL=MAP:SNET=MSC:DNET=HLR;

3.3

Starting counters
Before you start The counters are started for only certain interfaces or for all interfaces (an interface is a combination of the own subsystem and the remote subsystem). If the counters are started for only certain interfaces, the measurement period is one hour and the counter report is stored to a file once an hour. If the counters are started for all interfaces, the measurement period is one day and the counter report is stored to a file every night, and also the cumulative counters for the day can be viewed with the OXL command. Steps 1 Display the measurement state (OXP) Example Display the MAP measurement state. ZOXP:PROTOCOL=MAP; 2 Start MAP meters if the measurement state is other than 'running' (OXS) Example Set the MAP meters for all interfaces to start on 15 August 2005 at noon. ZOXS:PROTOCOL=MAP:SDAY=20050815,STIME=1200;

3.4

Displaying counters
Before you start The counters are collected automatically from the signalling units to the centralized part once an hour on the full hour. After that the contents of the counters can be viewed either in the report file or with the OXL command. Steps 1 Display the MAP meters (OXL) Example Display general information on the MAP meters of signalling point code 76 that is located in NA0 common channel network and belongs to the HLR. ZOXL:PROTOCOL=MAP:SNET=MSC:DNET=HLR::CCNET=NA0,SPC=76::GEN;

Id:0900d80580570e7b

31

Handling MAP statistics

Mobile Application Part (MAP)

3.5

Stopping counters
Steps 1 Stop the MAP meters (OXE) Example Stop the MAP meters. ZOXE:PROTOCOL=MAP; The collecting of counter information from the distributed parts in each signalling unit is stopped and the counters are cleared in the distributed parts and in the centralized part.

3.6

Checking how MAP traffic is currently proceeding

If you want to check how MAP traffic is currently proceeding, you can do it in the following way. In the example, the MAP meters of signalling point code 76 are displayed as application contexts for the MAP, and the SPC 76 that belongs to the HLR is located in NA0 common channel network. Steps 1 2 3 Stop the MAP meters (OXE) ZOXE:PROTOCOL=MAP; Set the MAP meters to start today at noon (OXS) ZOXS:PROTOCOL=MAP:STIME=1200; After 1 p.m. display general information on the MAP meters for the past hour (OXL) ZOXL:PROTOCOL=MAP:SNET=MSC:DNET=HLR::CCNET=NA0,SPC=76:AC:GEN;

32

Id:0900d80580570e7b

Mobile Application Part (MAP)

Defining the MAP version

4 Defining the MAP version

When a set of new services is introduced and new MAP operations or new parameters to existing operations are added, the version of the related ACs is updated. This versioning ensures backward compatibility to earlier implementations. When a MAP entity supports a particular new version, it is also able to revert to a lower version if the new version is not supported by a peer entity. This mechanism is called protocol version fallback. The fallbacks can cause extra load on signalling networks. To optimise the use of the correct version and thus minimise connection fallbacks, you can create network entity address analyses. With the address analyses, you can define which versions are used for different directions and for different network elements. The version used is determined by the analysis result. You can also define which version is used as a default value when no address analysis is created for a certain direction, and no version suggestion is received from the MAP user. If the address analysis exists for the destination address, the result of the analysis is used to select the version. In this case, both the version requested by the MAP user and the version defined as the default version are ignored. Each version is used for communicating with a particular network in the chosen AC. The used version for each AC is created to a version result record that is used in the result of the address analysis to select the correct version. Different version result records are used for selecting the versions for different directions or network elements. The maximum number of the different version result records that can be created is 254. For full description of the commands, see the MAP Parameter Handling, OP Command Group. Steps 1 Modify the application context-specific default MAP version (OPH) Example Modify the default MAP version for application context number 1. ZOPH:MODIFY:AC=1:VER=2; 2 Create the network entity address analysis result record (OPV) Example Create the network entity address analysis result record for application context number 1. The number of the result record is 10, and the name is HELSINKI. The used MAP version is the default version for this application context. ZOPV:CREATE:RES=10,NAME=HELSINKI:AC=1:VER=DEF; 3 4 Repeat step two until all the ACs have the desired version Create the network entity address analysis (OPC) Use the name or the number of the result record. Example Create the network entity address analysis for the network entity with international global title address 12345. The numbering plan for the GT is E.164. The number of the result record is 10. ZOPC:TOA=GT:DIG=12345,TON=INT,NP=E164:RES=10;

Id:0900d80580570e7e

33

Activating MAP error counters

Mobile Application Part (MAP)

5 Activating MAP error counters

The counters in which data about failed MAP operations can be compiled are needed because alarms are generated from these counters if the error ratio exceeds the defined thresholds. For full description of the commands, see the MAP Parameter Handling, OP Command Group. Steps 1 Modify the automatic reset parameters: reset time interval and minimum limit (OPX) Example Modify the reset time interval to 3 hours and the minimum number of MAP operations to 200. ZOPX:MODIFY:3,200; 2 Set the error alarm thresholds for the operation code (OPS) Example Set the error alarm threshold levels to 10%, 20%, and 30% for MAP version 2 and operation code 7. ZOPS:7:2:LOW=100,MEDIUM=200,HIGH=300; 3 4 Repeat Step Set the error alarm thresholds for the operation code (OPS) until all the thresholds are correct Activate the error counters for the operation code (OPA) Example Activate the error counters for MAP version 2 and operation code 7. ZOPA:7:2:ACT; 5 Repeat Step Activate the error counters for the operation code (OPA) until all the needed error counters are activated

34

Id:0900d80580570e81

Mobile Application Part (MAP)

Reading MAP cyclic buffer

6 Reading MAP cyclic buffer

If other network elements send invalid data, it is useful to know what kind of data they send. This information is relevant for troubleshooting. For full description of the command, see the MAP Parameter Handling, OP Command Group. Steps 1 Read the cyclic buffer Example Output the newest erroneous message from active CCSU 1. ZOPO:1:NEW:1;

Id:0900d80580570e84

35

Modifying the own network element address

Mobile Application Part (MAP)

7 Modifying the own network element address

The operator configures the new MAP address analysis results with the commands of the MAP Parameter Handling, OP command group. The new results are the MSC address, the VLR address, and the HLR address. The MAP protocol checks whether there is an address analysis for the Called Party Address (CdPA) and whether the result of that analysis is the new own network element address. If there is an address analysis resulting in new own network element addresses (MSC, VLR, HLR), one of them, depending on the operation, is set as the new Calling Party Address (CgPA) of the SCCP. The MSC, VLR, and HLR addresses are all in E.164 format with a maximum of 18 digits. In the HLR, you can give the HLR address, and in the MSC/VLR, you can give the MSC and VLR address. In some operations the new own network element addresses are also used as MAP message parameters. When a roaming subscriber in the shared network starts MAP/CAP signalling towards the home network, the VMSC chooses the correct MSC and VLR address based on the CdPA. For full description of the commands, see the MAP Parameter Handling, OP Command Group. Steps 1 Create result addresses for the network entity address analysis (OPK) Use the OPK MML command to create, modify, and delete the virtual MSC/VLR address pairs and the virtual HLR address. In the MSC, the result address is an MSC-VLR address pair. In the HLR, the defined result address is an HLR address. Example (MSC/VLR) Create the result address pair number 1, with virtual MSC and VLR addresses. The record name is WEST. ZOPK:RESA=1,ANAME=WEST:MSC=12345,VLR=54321; Modify the result address pair number 1. The new name of the record is EAST. ZOPK:RESA=1:NEWN=EAST,MSC=12345,VLR=54321; Example (HLR) Create the result address pair number 1 with virtual HLR address with NoA=INT. The record name is 'WEST'. ZOPK:RESA=1,ANAME=WEST:HLR=12345,HTON=INT; 2 Create network entity address analysis Before you start The result record and result address pair possibly referred to in the command must be created in advance using the OPV and OPK MML commands, respectively.

36

Id:0900d80580570e87

Mobile Application Part (MAP)

Modifying the own network element address

Use the OPC MML command to create a network entity address analysis for determining the best MAP version, virtual MSC/VLR addresses, or virtual HLR addresses. The network entity address analysis for the virtual HLR address is only available in the HLR. Example (MSC/VLR) Create a network entity address analysis for the network entity with global title address 123456789, type of number NAT, and numbering plan E.164. ZOPC:TOA=GT:DIG=123456789,TON=NAT,NP=E164:RES=1,RESA=1; Example (HLR) Create a network entity address analysis for the network entity with global title address: 123456789, type of number: INT, and numbering plan: E.212. ZOPC:TOA=GT:DIG=123456789,TON=INT,NP=E212:RES=1,RESA=1;

Id:0900d80580570e87

37

Denying MAP traffic

Mobile Application Part (MAP)

8 Denying MAP traffic

With MAP level configuration, you can configure which MAP procedures are allowed from an initiating address. The SCCP level Calling Party Address parameter is analysed. The result of the analysis indicates whether certain MAP procedures are allowed or not from that initiating address. In practice, it means that you can, for example, specify from which SMSCs your subscribers can receive short messages. In this example, the configuration is done only in the HLR. That way, only the Home Public Land Mobile Network (PLMN) subscribers are affected. If the HLR denies the MT-SM, the MT-SM transfer is terminated already during the HLR enquiry. In the following operating instructions, it is assumed that by default the MT-SMs are allowed from any SMSC. Only for explicitly defined SMSCs is the MT-SM denied. The routing info enquiry for an MT-SM is done with the SendRoutingInfoForSM MAP operation that belongs to the 'shortMsgGatewayContext' MAP Application Context (AC number 20). This AC must be controlled by the result of the peer network element address analysis. For full description of the commands, see the MAP Parameter Handling, OP Command Group. Steps 1 2 Check the current application context setting (OPH) ZOPH; Set the highest supported MAP version (OPH) If the highest supported version is already set to an appropriate value, that is, other than 'DENIED', no changes for the default setting are needed. If the setting has to be modified, use the OPH MML command. If there are no special reasons for any particular MAP version, the highest available version can be selected to give full support for the AC. ZOPH:MODIFY:AC=20:VER=3; 3 Create a new result record (OPV) Before you can create the address analysis for the network element addresses you want to handle differently, you have to create a new result record that instructs that AC=20 is denied. ZOPV:CREATE:NAME=DENYMTSM:AC=20:VER=DENIED; 4 Create the address analysis for the SMSC address The analysis result has to point to the new result which has been created earlier. ZOPC:TOA=GT:DIG=address,NP=E164,TON=INT:NAME=DENYMTSM; The 'address' contains the SMSC address or the starting digits of the SMSC address if it is appropriate to deny the MT-SM totally from a certain PLMN. In this example, it is assumed that Global Title addressing is used between the SMSC and the HLR. Within the HPLMN, it is also possible that Point Code addressing is used. In that case, the peer network element address has to be given as the Point Code in the OPC command. 5 Repeat the procedure for all the addresses you want to deny

38

Id:0900d80580570e8a

Mobile Application Part (MAP)

Denying MAP traffic

If the denial has to be created for several SMSCs, the OPC command is repeated for all the addresses. They should all point to the same result record.

Id:0900d80580570e8a

39

Configuring the default MAP parameters

Mobile Application Part (MAP)

9 Configuring the default MAP parameters

The default MAP parameters can be configured with the OPM MML command. When using this command, you can activate the SCCP return option and the overload control option. You can also check the standard used in TCAP, the standard of the SCCP address, and the standard of the object identifier. You can also define the number of authentication sets in the case of different MAP versions. When SCCP return is activated, messages sent to the network are returned in case of a routing failure. That is, if the SCCP message cannot be routed further, it is returned to the sender. If an overload condition is detected while handling the TC-begin message received from the network, that is, a MAP dialogue is to be initiated, the dialogue is not accepted and nothing is sent back to the network. This means that by default, the remote network element is not informed about the rejection of the dialogue. MAP can also inform the requesting network element about the overload situation by sending a TC-ABORT back to the network. For full description of the commands, see the MAP Parameter Handling, OP Command Group. Steps 1 Activate the SCCP return option When this option is activated, messages are returned to the sender if a routing failure happens. Use the OPM MML command to activate this option. Example Activate the SCCP return option. ZOPM:SCCP=YES; 2 Activate the sending of the overload notification Use the OPM MML command to activate the sending of the TC-ABORT message in case an overload is detected. Example Activate the TC-ABORT message sending. ZOPM:OLC=YES; 3 Modify the default TCAP standard and SCCP address standard Use the OPM MML command to modify the standard TCAP and SCCP address values. Example Modify the default standard of TCAP, standard of SCCP address, and standard of object identifier to ANSI. ZOPM:TCAP=ANSI,OBID=ANSI,ADDR=ANSI;

40

Id:0900d80580570e8d