Map

Mobile Application Part (MAP)

DN99588472

Issue 6-0

2


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 DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, 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

f 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 zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

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 Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

3


Id:0900d80580570e90

Table of ContentsThis document has 40 pages.

1 Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Mobile Application Part (MAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1 Network elements with MAP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Support protocol description of MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Hardware requirements and software architecture of MAP . . . . . . . . . . . . 122.4 MAP procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 MAP location management procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 MAP location service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.3 MAP operation and maintenance procedures. . . . . . . . . . . . . . . . . . . . . . . 152.4.4 MAP call handling procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.5 MAP supplementary service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.6 MAP short message service procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.7 MAP security procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.8 MAP subscriber information procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 MAP signalling configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 MAP general settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.1 MAP overload control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.2 MAP error counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.3 SCCP return option for MAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.4 Number of authentication sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.5 MAP operation timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Direction-specific MAP functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7.1 Multiple own network element addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7.2 Prevention of MAP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.3 MAP version handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.4 MAP extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.5 Direction-specific alarms related to MAP . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.6 ANSI MAP - routing addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.7 ANSI MAP - application context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.8 SMSC types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 MAP traffic status information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.1 MAP-related clear and event codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.2 MAP cyclic buffer for erroneous protocol messages. . . . . . . . . . . . . . . . . . 282.8.3 MAP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Handling MAP statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1 Setting a fixed destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Deleting a fixed destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Starting counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Displaying counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5 Stopping counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 Checking how MAP traffic is currently proceeding . . . . . . . . . . . . . . . . . . . 32

4


Id:0900d80580570e90

4 Defining the MAP version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Activating MAP error counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Reading MAP cyclic buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Modifying the own network element address . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Denying MAP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9 Configuring the default MAP parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5


Id:0900d80580570e90

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

6


Id:0900d80580570e90

7

Mobile Application Part (MAP) Summary of changes

Id:0900d80580570e6e

1 Summary of changesChanges made between issues 6-0 and 5-0The 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 featuresA new section about a new functionality SMSC types has been added to Chapter Direc-tion-specific MAP functionalities due to the changes in the MultiCard SMS functional-ities.

Other changesAs 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

The following subchapters have been re-structured

• MAP general settings • Direction-specific MAP functionalities • MAP traffic status information

Changes made between issues 4–2 and 4–1

Changes due to new featuresAs 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 due to new featuresNo changes.

Other changesMinor editorial corrections have been made.

8


Id:0900d80580570e6e

Summary of changes


Changes due to new featuresThe following sections have been modified due to changes in the Multiple Own Network Element Addresses feature:

• Direction-specific MAP functionalitiesA new subsection has been added about the own network element address modifi-cation.

• Modifying the own network element addressA 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 changesThe 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


Interfaces using MAP protocolFigure “The interfaces covered by the MAP” modified: Ls and Lv interfaces removed, M interface added.

Support protocol description of MAPSIGTRAN mentioned as a replacement of MTP.

Software architecture of MAPPairs: 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 MAPClear 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 MAPThe list of alarms related to MAP has been removed from this document. It can be found in Failure Printouts.


9

Mobile Application Part (MAP) Summary of changes

Id:0900d80580570e6e

Introduction to Mobile Application PartReferences 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 settingsNew 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.

10


Id:0900d80580570e78


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 transfer-ring 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) applica-tion, or a Short Message Service (SMS) application, and sends the data in a stan-dardised 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 interfaceThe 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 protocolThe following interfaces are covered by MAP:

Figure 1 The interfaces covered by MAP

11

Mobile Application Part (MAP) Mobile Application Part (MAP)

Id:0900d80580570e78

C interface between the MSC and the HLR, for example, routing information inqui-ries for Mobile-Terminated (MT) calls

D interface between the VLR and the HLR, for example, location update, subscriber data management

E interface between two MSCs, for example, handovers, Mobile-Originated (MO) and Mobile-Terminated (MT) short messages

F interface between the MSC and the Equipment Identity Register (EIR), Interna-tional Mobile Equipment Identity (IMEI) status checking

G interface between the two VLRs, International Mobile Subscriber Identity (IMSI), and authentication triplet retrievals from the previous VLR

Gc interface between the HLR and the GGSN, mobile terminated PDP context acti-vation. This interface has not been implemented

Gd interface between the SMS-GMSC and the Serving GPRS Support Node (SGSN), for example General Packet Radio Service (GPRS) short messages

Gf interface between the EIR and the SGSN, GPRS IMEI checking

Gr interface between the HLR and the SGSN, for example, GPRS location update

J interface between the HLR and the gsmSCF, for example, Unstructured Supple-mentary Service Data (USSD) or any time handling of subscriber data

L interface between the MSC and the GSM Service Control Function (gsmSCF), supplementary service notification

Lh interface between the HLR and the Gateway Mobile Location Centre (GMLC), location services

Lg interface between the MSC and the GMLC, location services

M interface between the VLR and the gsmSCF, Mobility Management (MM) notifi-cation

2.2 Support protocol description of MAPMAP 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 Basic connectionless class

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

12


Id:0900d80580570e78


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 MAPHardware requirementsMAP 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 architectureMAP 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:

13


Id:0900d80580570e78

• 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 MAP program of the VLR controls MAP dialogues between:

• 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 MAP program of the HLR controls MAP dialogues between:

• 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 MAP program of the EIR controls MAP dialogues between:

• the pair of EIR and VMSC • the pair of EIR and SGSN

2.4 MAP proceduresA 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/gsm-SCF/GMLC Mobile Application Part, Interface Specification.

2.4.1 MAP location management proceduresThe following location management procedures are used to handle the mobility of a sub-scriber:

14


Id:0900d80580570e78


Location updateThe location update procedure is used to update location information held in the network. Location information is used to route incoming calls, packet data, short mes-sages, 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 cancellationThe 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 reportingThis procedure is used to notify the gsmSCF about a subscriber's change of location. The procedure is triggered by, for example, location update.

MS purgingAn 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 (MT-SM) 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.

HandoverWhen 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 recoveryAfter 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 pro-cedures:

• VLR restoration • HLR restoration

2.4.2 MAP location service proceduresThe location service procedures are used:

15


Id:0900d80580570e78

• 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 proceduresThe following three operation and maintenance procedures are needed for operating and maintaining the GSM PLMN network:

Tracing procedures

• Subscriber tracing activationThe subscriber tracing activation procedure is used at location update or data res-toration when the trace mode of a subscriber is set active in the HLR, or as a stand-alone procedure when the subscriber is already registered and the trace mode becomes active in the HLR.

• Subscriber tracing deactivationThe subscriber tracing deactivation procedure is used when the trace request of a subscriber has to be cancelled.

Subscriber data management procedures

• Subscriber deletionIn the subscriber deletion procedure, the subscriber data has to be removed from the VLR and the HLR.

• Subscriber data modificationIn 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 procedureIn the subscriber identity procedure, the IMSI of a subscriber is retrieved from the HLR.

2.4.4 MAP call handling proceduresThe 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

16


Id:0900d80580570e78


2.4.5 MAP supplementary service proceduresThe following MAP supplementary service procedures are used:

• RegistrationIt is used to register data related to a supplementary service in the HLR.

• ErasureIt is used to erase data related to a supplementary service in the HLR.

• ActivationIt is used to activate a supplementary service in the HLR.

• DeactivationIt is used to deactivate a supplementary service in the HLR.

• InterrogationIt is used to retrieve information related to a supplementary service from the VLR or HLR.

• Password registrationIt is used to register a password in the HLR.

• Mobile-initiated USSDIt supports supplementary service signalling procedures that can allow PLMN-specific services to be introduced.

• Network-initiated USSDIt supports supplementary service signalling procedures that can allow PLMN-specific services to be introduced.

• Supplementary service invocation notificationIt 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 proceduresThe following four SMS procedures are used to control both the mobile-originated and mobile-terminated SMS transfer:

• Mobile-originated short message transferThe MO-SMS transfer procedure is used to forward an SM from a mobile subscriber to a Service Centre.

• Mobile-terminated short message transferThe MT-SM transfer procedure is used to forward an SM or several SMs from a Service Centre to a mobile subscriber.

• Short message alertThe 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 reportThe 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.

17


Id:0900d80580570e78

2.4.7 MAP security proceduresThe following MAP security procedures are used:

• IMEI checking procedureThe 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 procedureThe 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 reportingThe authentication failure reporting procedure is used to notify the HLR about the occurrence of an authentication failure in the SGSN or VLR.

• Send identification procedureThe 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 proceduresThe following MAP subscriber information procedures are used:

• AnyTimeInfoEnquiryWith this procedure, the gsmSCF can request information on, for example, sub-scriber 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.

• SubscriberInfoEnquiryThe SubscriberInfoEnquiry is used to request information on, for example, sub-scriber state and location from the VLR or SGSN at any time.

• AnyTimeInfoHandlingWith this procedure, the gsmSCF can interrogate the HLR about the subscriber's subscription information, and can request modifications in the subscriber's subscrip-tion information.

• SubscriberDataModificationNotificationWith this procedure, the HLR informs the gsmSCF of changes in the subscriber data.

2.5 MAP signalling configurationThe 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-

18


Id:0900d80580570e78


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

19


Id:0900d80580570e78

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 MAP general settings

2.6.1 MAP overload controlMAP 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.

20


Id:0900d80580570e78


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 overload-ing 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 countersThe 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 gen-erated. The counters which are used for setting the alarm are independent in each sig-nalling 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 MAPAt 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 setsAuthentication requests with MAP versions 1 and 2 cannot contain information about how many authentication sets are requested by the VLR/SGSN. To handle these situa-tions 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.

21


Id:0900d80580570e78

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 timersMAP 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 typi-cally 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 functionalitiesTo 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 addressesWhen 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 oper-ators. 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)

22


Id:0900d80580570e78


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 modifica-tion 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 fol-lowing 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.

23


Id:0900d80580570e78

The MAP level HLR address is changed in the following result components of MAP oper-ations:

• 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 trafficIf 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 handlingMAP 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 extensionsOn 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.

24


Id:0900d80580570e78


2.7.5 Direction-specific alarms related to MAPThe alarms 2646 PROTOCOL ROUTING FAILURE and 1647 OPERATION TIMER EXPIRY are direction-specific in the sense that they can be blocked to a certain direc-tion. 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 addressesIt 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 contextThe 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 infor-mation. 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 typesThe 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 MAP traffic status information

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

25


Id:0900d80580570e78

Clear codes related to MAP

Clear code Explanation

0005 B SUBSCRIBER BUSY 1. A subscriber is not able to receive an Mobile-Terminated 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 The response received by the MSC/VLR is that an MS is not reachable.

0021 B-SUBSCRIBER BUSY, CCBS POSSIBLE

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 POSSIBLE

MAP sets the clear code if the BusySubscriber 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.

0306 B-CALLS RESTRICTED MAP sets the clear code in the MSC/VLR when a mobile subscriber has activated the supple-mentary service of incoming call barring.

0307 B-NUMBER UNUSED MAP sets the clear code in the MSC/VLR when data of a called MS cannot be found in the HLR.

0308 B-NUMBER CHANGED MAP sets the clear code in the MSC/VLR when the number of a called MS in the HLR has changed.

0310 UNSPECIFIED CUG CALL FAILURE

1. MAP sets the clear code in the MSC/VLR when the HLR has responded with a negative acknowledgement to the SendRoutingInfo oper-ation 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 PROVI-SIONED

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.

0312 TELESERVICE NOT PROVI-SIONED

The response received to an operation is that the teleservice is not provided.

26


Id:0900d80580570e78


0313 ILLEGAL SUBSCRIBER MAP sets the clear code if the IllegalSubscriber error is received from another network element.

0314 UNIDENTIFIED SUBSCRIBER The error is received from another network element.

0315 B SUBSCRIBER HAS CALL DIVER-SION BARRING

The HLR has given a negative response to the SendRoutingInfo operation with cause code For-wardingViolation.

0319 ILLEGAL SUBSCRIBER STATION The error is received from another network element.

031A INCOMING CALLS BARRED WITHIN THE CUG

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 CUG

The HLR has responded to the SendRoutingInfo 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.

0320 CALLED PARTY SUPPLEMEN-TARY SERVICE INTERACTION VIOLATED WITHIN CUG

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.

0405 ERRONEOUS REQUEST FROM CO-PROCESS

Call control has sent the erroneous SendRout-ingInfo request. As a result, MAP sets the clear code in the MSC/VLR.

040C MAP CONGESTION 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.

040E ROAMING NOT ALLOWED MAP sets the clear code if the RoamingNotAl-lowed error is received from another network element.

0410 GT ANALYSIS FAILED 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.

060B OVERLOAD CONGESTION MAP sets the clear code if a CCSU is over-loaded.

0810 FACILITY IS NOT SUPPORTED IN THE PLMN

The negative acknowledgement received to an operation from the other network element is FacilityNotSupported.


27


Id:0900d80580570e78

0811 NETWORK FAILURE The negative acknowledgement received to an operation from another network element is Sys-temFailure.

0812 MAP FAILURE 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.

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.

081C VLR FAILURE No response has been received from the VLR.

081F NETWORK, OVERLOAD CON-GESTION

An overload message has been received from the network.


28


Id:0900d80580570e78


Event codes related to MAP

2.8.2 MAP cyclic buffer for erroneous protocol messagesIf 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 statisticsMAP 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.

Event code Explanation

103E UNAUTHORIZED LCS CLIENT OR REQUEST

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.

29


Id:0900d80580570e78

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

30


Id:0900d80580570e7b

Handling MAP statistics

3 Handling MAP statisticsMAP 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 destinationSteps

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.


3.2 Deleting a fixed destinationSteps

1 Display the destination list (OXY)

Example



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;

31

Mobile Application Part (MAP) Handling MAP statistics

Id:0900d80580570e7b

3 Check the outcome (OXY)

Display the destination list to check that the deleting process has been carried out successfully.

Example



3.3 Starting countersBefore you startThe 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=2005–08–15,STIME=12–00;

3.4 Displaying countersBefore you startThe 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;

32


Id:0900d80580570e7b

Handling MAP statistics

3.5 Stopping countersSteps

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 proceedingIf you want to check how MAP traffic is currently proceeding, you can do it in the follow-ing 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 Stop the MAP meters (OXE)

ZOXE:PROTOCOL=MAP;

2 Set the MAP meters to start today at noon (OXS)

ZOXS:PROTOCOL=MAP:STIME=12–00;

3 After 1 p.m. display general information on the MAP meters for the past hour (OXL)

ZOXL:PROTO-COL=MAP:SNET=MSC:DNET=HLR::CCNET=NA0,SPC=76:AC:GEN;

33

Mobile Application Part (MAP) Defining the MAP version

Id:0900d80580570e7e

4 Defining the MAP versionWhen 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 version-ing 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 fall-back. 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 Repeat step two until all the ACs have the desired version

4 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;

34


Id:0900d80580570e81

Activating MAP error counters

5 Activating MAP error countersThe 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.


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 opera-tions 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 Repeat Step Set the error alarm thresholds for the operation code (OPS) until all the thresholds are correct

4 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

35

Mobile Application Part (MAP) Reading MAP cyclic buffer

Id:0900d80580570e84

6 Reading MAP cyclic bufferIf 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;

36


Id:0900d80580570e87

Modifying the own network element address

7 Modifying the own network element addressThe 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.


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

37

Mobile Application Part (MAP) Modifying the own network element address

Id:0900d80580570e87

Use the OPC MML command to create a network entity address analysis for deter-mining 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;

38


Id:0900d80580570e8a

Denying MAP traffic

8 Denying MAP trafficWith MAP level configuration, you can configure which MAP procedures are allowed from an initiating address. The SCCP level Calling Party Address parameter is analy-sed. 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 sub-scribers 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.


Steps

1 Check the current application context setting (OPH)

ZOPH;

2 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

39

Mobile Application Part (MAP) Denying MAP traffic

Id:0900d80580570e8a

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.

40


Id:0900d80580570e8d

Configuring the default MAP parameters

9 Configuring the default MAP parametersThe 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.


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;

Map

Documents

Transcript of Map