Mobile Application Part
The Mobile Application Part (MAP) is an SS7-based application layer protocol standardized by 3GPP for use in GSM, UMTS, LTE, and 5G through interworking mobile networks, enabling signaling communication between core network entities to manage subscriber mobility, authentication, call routing, and supplementary services.[1] It operates atop the Transaction Capabilities Application Part (TCAP) and Signaling Connection Control Part (SCCP) layers of the SS7 stack, facilitating the exchange of PLMN-specific information such as location updates, roaming numbers, and short message transfers.[2] Defined in 3GPP TS 29.002, MAP supports a range of application contexts tailored to specific operations, ensuring interoperability across public land mobile networks (PLMNs).[1] MAP's core purpose is to support essential network functions, including mobility management procedures like location updating and handover control between Mobile Switching Centers (MSCs), as well as subscriber data handling via interactions with the Home Location Register (HLR) and Visitor Location Register (VLR).[2] Key entities involved include the Serving GPRS Support Node (SGSN) for packet-switched services, the Equipment Identity Register (EIR) for device authentication, and the Gateway Mobile Location Center (GMLC) for location-based services.[1] It provides operations for short message service (SMS) relay, such as forwarding mobile-originated messages to SMS centers, and supplementary services like call forwarding and barring through registration and interrogation primitives.[2] Error handling, dialogue management, and fault recovery mechanisms, including data restoration after failures, further enhance its reliability in fault-tolerant environments.[1] Originally developed for second-generation (2G) GSM networks, MAP has evolved through 3GPP releases to accommodate third-generation (3G) UMTS enhancements, such as improved security with authentication quintuplets, and fourth-generation (4G) LTE interworking via entities like the Mobility Management Entity (MME).[2] While SS7 remains its primary transport, adaptations allow limited use over IP in hybrid networks, with MAP retained for legacy interworking in 5G networks that use service-based interfaces over HTTP/2 in the core architecture.[1] This protocol's robustness has made it a cornerstone of global mobile roaming and service provisioning in legacy and transitional systems.[3]Overview
Definition and Role
The Mobile Application Part (MAP) is an SS7 application layer protocol suite designed to deliver mobile services within GSM, UMTS, and LTE (EPS) core networks.[4] It provides the signaling framework for transferring Public Land Mobile Network (PLMN)-specific information, particularly for roaming mobile stations, using the Signalling System No. 7 (SS7).[4] MAP plays a central role in facilitating communication between core network elements, including the Home Location Register (HLR), Visitor Location Register (VLR), Mobile Switching Center (MSC), Equipment Identity Register (EIR), Authentication Center (AuC), Short Message Service Center (SMS-C), Serving GPRS Support Node (SGSN), and Mobility Management Entity (MME).[4] These interactions ensure coordinated operations across the network, such as updating subscriber locations and verifying device identities during handovers or attachments.[4] The primary purpose of MAP is to support user mobility, authentication, and service provisioning in both circuit-switched and packet-switched domains.[4] For instance, it handles location updates to track subscriber positions and authentication procedures to secure access, while also enabling the insertion of subscriber data for personalized services like short messaging.[4] In the SS7 protocol stack, MAP is positioned above the Transaction Capabilities Application Part (TCAP) to enable transaction-oriented messaging for reliable and structured exchanges between network nodes.[4] This layering allows MAP to focus on application-level mobile-specific operations while relying on underlying SS7 components for transport.[4]Historical Development
The development of the Mobile Application Part (MAP) began in the late 1980s as a key component of the Global System for Mobile Communications (GSM) standardization effort led by the European Telecommunications Standards Institute (ETSI) and supported by the GSM Memorandum of Understanding (MoU), which later evolved into the GSMA.[5][6] This work drew influence from Integrated Services Digital Network (ISDN) signaling protocols and early European mobile projects in the 1980s, such as those under the Conference of European Posts and Telecommunications (CEPT), to enable core network functions for digital cellular systems.[7][8] MAP was initially specified in 1991 as part of GSM Phase 1, providing the application-layer protocol for mobility management and call control over the Signaling System No. 7 (SS7) transport.[7] The protocol evolved through GSM Phase 2, finalized in 1995, and Phase 2+, which introduced enhancements including Short Message Service (SMS) support in Phase 1 and General Packet Radio Service (GPRS) integration later.[9][10] A key milestone was the first commercial GSM launch on July 1, 1991, in Finland by Radiolinja, which utilized MAP for network operations.[11] In parallel to GSM MAP, the ANSI-41 standard was developed in North America starting in 1984 by the Telecommunications Industry Association (TIA) for intersystem operations in TDMA (IS-136) and CDMA (IS-95) networks, with its initial version (IS-41 Revision 0) published in 1988.[12] In 1998, ETSI's GSM work transitioned to the 3rd Generation Partnership Project (3GPP), established in December of that year, to integrate MAP into Universal Mobile Telecommunications System (UMTS) as a backward-compatible protocol for 2G/3G interworking.[13] This ensured continuity for roaming and signaling across generations.[14]Technical Specifications
Published Standards
The Mobile Application Part (MAP) was initially specified in the original Global System for Mobile Communications (GSM) standards through 3GPP Technical Specification (TS) 09.02, which covered versions 1 through 7 during the 1990s and addressed GSM Phase 1 through Phase 2+ requirements for core network signaling.[15] These early specifications, developed under the European Telecommunications Standards Institute (ETSI), defined the basic MAP protocols for mobility management and call handling in circuit-switched GSM networks.[16] With the transition to Universal Mobile Telecommunications System (UMTS) and further GSM enhancements, the specifications were unified and evolved into 3GPP TS 29.002 starting from Release 99 in 1999, incorporating extensions for Customised Applications for Mobile networks Enhanced Logic (CAMEL) Phase 3 and General Packet Radio Service (GPRS) support to enable advanced service control and packet data mobility.[1] TS 29.002 has been maintained under 3GPP's global harmonization efforts since 2000, when ETSI transferred primary responsibility for GSM/UMTS specifications to the 3GPP partnership of seven regional standards development organizations, ensuring worldwide interoperability for MAP in 3G networks.[17] The specification continues to be updated for legacy support and interworking, with the latest version V18.0.0 (Release 18) published in May 2024.[4] In parallel, the North American variant of MAP originated with IS-41 (also known as TIA/EIA-41), a standard developed by the Telecommunications Industry Association (TIA) for analog and digital cellular systems based on the IS-95 cdmaOne air interface.[18] This evolved into 3GPP2 specifications, with 3GPP2—formed in 1999 as a counterpart to 3GPP for cdma2000 and competing UMTS technologies—maintaining MAP under X.S0004 from 2004 onward, with updates through version 2.0 in 2007 and further revisions to support intersystem operations in 3G cdma2000 networks.[19] Key evolutions in MAP standards include the addition of location services in 3GPP Release 4 (2001), which introduced procedures for mobile-terminated and mobile-originated location requests to support emergency and value-added services via enhanced MAP operations.[20] Later releases, starting from Release 5 (2002), provided hints for integration with the IP Multimedia Subsystem (IMS) through work items enabling CAMEL-like control over IMS sessions and alignment of MAP with SIP-based signaling for multimedia services.[21]Protocol Architecture
The Mobile Application Part (MAP) operates as an application-layer protocol within the Signaling System No. 7 (SS7) framework, utilizing the services provided by the Transaction Capabilities Application Part (TCAP) to manage remote operations. TCAP, in turn, relies on the Signaling Connection Control Part (SCCP) for connection-oriented or connectionless transport, which is supported by the Message Transfer Part (MTP) layers (MTP3 for routing, MTP2 for link layer, and MTP1 for physical transmission) in the traditional SS7 stack. This layered architecture enables MAP to exchange signaling messages between network entities such as the Home Location Register (HLR), Visitor Location Register (VLR), and Mobile Switching Center (MSC) without direct handling of lower-layer concerns. MAP messages are encoded using Abstract Syntax Notation One (ASN.1) with Basic Encoding Rules (BER), as defined in ITU-T Recommendations X.680 and X.690, to ensure interoperability across diverse network implementations. These messages are structured as TCAP components, including invoke (to request an operation), return result (to convey successful outcomes), return error (to indicate failures), and reject (for protocol errors). Error handling is integrated through dedicated error components that specify the nature of the issue, allowing the receiving entity to respond appropriately.[22] Dialogue handling in MAP is facilitated by TCAP, which supports structured transactions involving multiple related messages, such as a sequence of invokes and results within a single dialogue. This enables complex interactions, like location updates, to be coordinated atomically, with TCAP managing dialogue identifiers and termination conditions to maintain state across exchanges. For transport, MAP traditionally employs dedicated SS7 links for reliable delivery in circuit-switched environments, but it also supports IP-based alternatives through the SIGTRAN protocol suite, particularly the M3UA (MTP3 User Adaptation Layer) protocol, which adapts SCCP messages over Stream Control Transmission Protocol (SCTP) for IP networks. This hybrid capability allows MAP to function in modern converged architectures without altering the upper-layer logic. Core components of MAP include operation codes that identify specific procedures, such as UPDATE_LOCATION (opcode 2) for registering a mobile station's location with the HLR. Error codes provide standardized failure indications, for example, system failure (code 34) signaling internal processing errors at the receiving node. Parameter structures, encoded in ASN.1, include essential identifiers like the International Mobile Subscriber Identity (IMSI) for unique subscriber recognition and the Mobile Station International Subscriber Directory Number (MSISDN) for routing calls and messages.Facilities and Services
Mobility Management
Mobility management in the Mobile Application Part (MAP) encompasses procedures for tracking subscriber locations, supporting roaming across networks, and recovering from faults to ensure continuous service availability in GSM, UMTS, and EPS environments. These operations primarily involve interactions between the Home Location Register (HLR), Visitor Location Register (VLR), Mobile Switching Center (MSC), Serving GPRS Support Node (SGSN), and Authentication Center (AuC), using MAP messages transported over the Signaling Connection Control Part (SCCP).[23] Location management procedures maintain accurate records of subscriber positions to enable efficient paging and service delivery. The UPDATE_LOCATION operation is initiated by the VLR, MSC, or SGSN when a mobile station (MS) registers in a new location area, routing area, or tracking area, providing the HLR with the subscriber's International Mobile Subscriber Identity (IMSI) and the serving entity's address for updates. The HLR responds by inserting subscriber data into the new VLR or SGSN via INSERT_SUBSCRIBER_DATA and may trigger a CANCEL_LOCATION to the previous VLR or SGSN to remove outdated records, ensuring data consistency across the network.[23] Similarly, CANCEL_LOCATION explicitly removes subscriber data from a VLR or SGSN upon detachment, subscription withdrawal, or mobility events, with parameters indicating the cancellation type (e.g., for IMSI detach) to set flags like Mobile Not Reachable (MNRF).[23] These procedures support initial attachment and periodic location updates, governed by timers such as the Subscribed Periodic Location Area Update (LAU) Timer, which prompt the MS to report its position at intervals to refresh HLR records and detect network faults.[23] Roaming support in MAP relies on authentication and location procedures to verify and authorize subscribers in visited networks. The SEND_AUTHENTICATION_INFO operation allows a VLR or SGSN to request authentication vectors (e.g., RAND, SRES, Kc for GSM; or extended sets for UMTS/EPS) from the HLR or AuC using the IMSI, enabling secure access during roaming without exposing permanent keys.[23] Up to five vectors can be requested in a single invocation to support multiple challenges, facilitating international roaming across Public Land Mobile Networks (PLMNs) by coordinating global titles (e.g., E.164 or E.212 formats) for inter-network signaling. For international roaming number portability, MAP procedures like PROVIDE_ROAMING_NUMBER allocate a temporary Mobile Subscriber Roaming Number (MSRN) tied to the subscriber's IMSI, allowing calls to be routed to the visited MSC while preserving the original directory number across borders and operators.[23] This ensures seamless connectivity, with roaming restrictions enforced via HLR parameters to control access in foreign PLMNs. Fault recovery procedures in MAP restore subscriber data after network disruptions, such as VLR restarts or unconfirmed detachments. The RESTORE_DATA operation is invoked by a VLR or SGSN toward the HLR, providing the IMSI or MSRN to retrieve and reinsert essential data (e.g., subscription profiles and location information), often in conjunction with INSERT_SUBSCRIBER_DATA to reinstate service without requiring a full re-registration.[23] This mechanism supports recovery from system failures, updating the Local Mobile Station Identity (LMSI) if provided and ensuring minimal service interruption. Key concepts in MAP mobility management include IMSI-based attachment and detachment, where attachment via UPDATE_LOCATION registers the MS as reachable, and detachment sets IMSI-detached flags in the HLR to block incoming services until reattachment. Periodic location updates, triggered by mobility events or timers, prevent stale data and enable proactive fault detection, while international roaming integrates number portability through MSRN assignments that abstract the subscriber's location for global call routing. An example of MAP's role in mobility is during inter-MSC handovers, where an UPDATE_LOCATION from the target MSC to the HLR updates the serving entity, allowing the HLR to redirect subsequent paging or data to the new MSC for uninterrupted mobility.[23]Call Handling and Supplementary Services
The Mobile Application Part (MAP) facilitates call handling by enabling the routing of mobile-terminated calls through interactions between the Gateway Mobile Switching Center (GMSC), Home Location Register (HLR), and Visitor Location Register (VLR). For incoming calls, the GMSC queries the HLR using the SEND_ROUTING_INFO operation, which retrieves the subscriber's current location and returns routing details such as the serving MSC or VLR address, along with parameters like the International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), and roaming number if applicable.[23] This operation ensures the call is directed to the appropriate serving node, supporting features like Closed User Group (CUG) checks and forwarding counters to manage call diversion scenarios.[23] Once the routing information is obtained, the VLR assigns a temporary Mobile Station Roaming Number (MSRN) via the PROVIDE_ROAMING_NUMBER operation, which the HLR forwards back to the GMSC for actual call setup.[23] This process is critical for roaming scenarios, where the MSRN masks the subscriber's true location, and it includes parameters such as the target cell ID for handover support.[23] MAP supports supplementary services by allowing network entities to manage and invoke user-configured features during active sessions. The InterrogateSS operation enables the VLR or MSC to query the HLR for call forwarding profiles, retrieving details like the forwarded-to number, service codes, and forwarding options (e.g., unconditional, busy, or no reply) to apply diversions without disrupting the call flow.[23] For dynamic updates, supplementary service operations such as ActivateSS, DeactivateSS, and RegisterSS permit the VLR or MSC to register, activate, or deactivate services such as call waiting, call barring, or multi-party calls by modifying the subscriber's service status and options in the HLR, with parameters including the supplementary service code (SS-Code) and subscription options.[23] These operations ensure seamless integration of services like call hold or transfer, maintaining service continuity across network boundaries.[23] Short Message Service (SMS) handling in MAP involves dedicated operations for both mobile-terminated and mobile-originated messages, integrating with the core network's signaling. The MT-ForwardSM operation allows the SMS Center (SMSC) to deliver incoming SMS via the GMSC to the serving MSC or SGSN, passing parameters such as the SMS user data, originating and destination addresses, and delivery status indicators to ensure reliable transport to the mobile station (MS).[23] Conversely, the MO-ForwardSM operation routes outgoing SMS from the MS through the MSC or SGSN to the SMSC, including the message payload and routing addresses to facilitate store-and-forward delivery.[23] These procedures handle errors like delivery failures or absent subscribers, supporting concatenation for longer messages.[23] For packet data services, MAP extends call handling to GPRS and PDP contexts through operations that coordinate with location management. The READY_FOR_SM operation notifies the HLR from the SGSN when the subscriber becomes available for short message delivery over packet domains, providing the IMSI, SGSN address, and alert reasons to update routing preferences.[23] Similarly, SEND_ROUTING_INFO_FOR_GPRS enables the GGSN or SMS-GMSC to query the HLR for the serving SGSN's address during PDP context activation, using parameters like the IMSI and GPRS node indicators to route data sessions or SMS efficiently.[23] These ensure that supplementary services and SMS remain accessible in GPRS environments without interrupting voice calls.[23] Operation and maintenance (O&M) functions in MAP provide real-time access to subscriber data for network diagnostics and service enhancement. The AnyTimeSubscriptionInformation operation allows authorized entities like the GSM Service Control Function (gsmSCF) or Operations and Maintenance Center (OMC) to retrieve comprehensive profile details from the HLR, including location, subscribed services, and identity information via specified request types.[23] This supports proactive call handling by enabling dynamic provisioning of supplementary services and monitoring of routing behaviors.[23]| Operation | Purpose | Key Parameters | Network Role |
|---|---|---|---|
| PROVIDE_ROAMING_NUMBER | Assigns temporary roaming number for call routing | IMSI, MSISDN, roaming number, target cell ID | VLR to HLR; enables GMSC call setup in roaming |
| SEND_ROUTING_INFO | Retrieves location and routing for mobile-terminated calls | MSISDN, IMSI, GMSC address, forwarding count | HLR to GMSC; locates serving MSC/VLR |
| InterrogateSS | Queries status of supplementary services including call forwarding | SS-Code, basic service code, forwarding options | HLR to VLR/MSC; retrieves forwarding profiles |
| ActivateSS/DeactivateSS | Activates or deactivates supplementary services | SS-Code, SS-Status, subscription options | VLR/MSC to HLR; updates service profiles |
| MT-ForwardSM | Delivers incoming SMS to MS | SM-RP-DA/OA/UI, SMS data, more-to-send flag | SMSC via GMSC to MSC/SGSN |
| MO-ForwardSM | Forwards outgoing SMS to SMSC | SM-RP-OA/DA/UI, SMS data | MSC/SGSN to SMSC |
| READY_FOR_SM | Notifies readiness for SMS in packet domain | IMSI, SGSN number, alert reason | SGSN to HLR; triggers SMS routing |
| SEND_ROUTING_INFO_FOR_GPRS | Gets routing for GPRS services/PDP contexts | IMSI, SGSN/GGSN address | HLR to GGSN/SMS-GMSC |
| AnyTimeSubscriptionInformation | Retrieves subscriber data for O&M | IMSI, requested info types, subscriber identity | HLR to gsmSCF/OMC; supports diagnostics |
Implementation and Signaling
Network Implementation
The Mobile Application Part (MAP) is integrated into key core network elements to facilitate database operations and local processing in GSM and UMTS networks. In the Home Location Register (HLR) and Authentication Center (AuC), MAP handles subscriber data management, authentication vectors generation, and location updates by exchanging messages such as Update Location and Authentication Information requests over the SS7 stack.[24] The Visitor Location Register (VLR) and Mobile Switching Center (MSC) utilize MAP for local subscriber processing, including registration and call routing, via interfaces like the D-interface for HLR-VLR communication.[25] For the packet-switched domain, the Serving GPRS Support Node (SGSN) employs MAP over the Gr-interface to interact with the HLR for mobility management and PDP context activation, ensuring seamless integration between circuit- and packet-switched services.[26] MAP signaling is transported over traditional SS7 networks using Time Division Multiplexing (TDM) links, such as E1 (2.048 Mbps) or T1 (1.544 Mbps) lines, which carry SS7 messages at 56 or 64 kbps per channel.[27] In modern deployments, Signaling Transport (SIGTRAN) enables MAP over IP networks, adapting SS7 protocols like MTP3 to IP via Stream Control Transmission Protocol (SCTP) for improved scalability and cost efficiency in hybrid TDM-IP cores.[28] This dual transport approach allows operators to migrate gradually while maintaining compatibility with legacy infrastructure. Open-source implementations of MAP include the OpenSS7 project, which provides a full SS7 stack with MAP support for HLR and VLR emulation in research and testing environments.[29] Similarly, Mobius SS7 offers a Java-based open-source SS7 protocol stack including MAP for mobile services integration.[30] Commercial stacks are embedded in vendor core network products; for instance, Ericsson's HLR and MSC solutions incorporate MAP for SS7-based signaling in 2G/3G cores, supporting high-availability deployments.[31] Nokia's core network elements, such as the HLR/AuC, similarly implement MAP protocols for subscriber management and roaming support.[32] Interoperability challenges arise when bridging GSM and UMTS MAP variants, where differences in message formats and optional parameters require protocol mapping to ensure consistent location updates and authentication across generations.[13] For global roaming, mappings between GSM MAP and ANSI-41 (used in CDMA networks) address discrepancies in operations like intersystem page and handoff, as standardized for subscriber mobility between ETSI and TIA networks.[33] Performance in MAP deployments is constrained by SS7 link capacities, with a typical 64 kbps TDM link supporting 10-50 transactions per second (TPS) depending on average message sizes of 100-500 bytes.[34][35] Redundancy is achieved through mated pairs of Signal Transfer Points (STPs) or core elements like HLRs, where dual configurations route traffic equivalently to prevent single points of failure and maintain uptime during link or node outages.[36]MAP Signaling Procedures
The Mobile Application Part (MAP) signaling procedures operate over the Signaling System No. 7 (SS7) network to facilitate communication between core network elements in GSM and UMTS systems, enabling mobility management, call handling, and supplementary services through structured dialogues and operations. These procedures define the sequence of messages exchanged between nodes such as the Mobile Switching Center (MSC), Visitor Location Register (VLR), Home Location Register (HLR), and Serving GPRS Support Node (SGSN), ensuring subscriber data consistency and service continuity across networks.[37] Key SS7 interfaces underpin these procedures, each serving specific interactions between network elements. The B interface connects the MSC and VLR for local queries, such as handovers via MAP_PREPARE_HANDOVER, and internal authentication procedures using vectors obtained from the HLR. The C interface links the MSC to the HLR for call routing and subscriber information retrieval, including operations like MAP_SEND_ROUTING_INFO and MAP_PROVIDE_ROAMING_NUMBER. The D interface facilitates HLR-VLR or HLR-SGSN exchanges for subscriber data insertion via MAP_INSERT_SUBSCRIBER_DATA and purging with MAP_PURGE_MS, particularly after GPRS location updates using the E.164 SGSN number; location management uses MAP_UPDATE_LOCATION on this interface. Additionally, EIR-related interfaces enable equipment identity checks, where the VLR, MSC, or SGSN queries the Equipment Identity Register (EIR) using MAP_CHECK_IMEI to verify the IMEI or IMEISV, with the EIR address derived from the equipment identity itself.[37]| Interface | Primary Nodes | Key MAP Operations | Purpose |
|---|---|---|---|
| B | MSC-VLR | MAP_PREPARE_HANDOVER, MAP_PROVIDE_ROAMING_NUMBER, MAP_SEND_IDENTIFICATION | Local mobility and call handling queries |
| C | MSC-HLR | MAP_SEND_ROUTING_INFO, MAP_PROVIDE_ROAMING_NUMBER | Call routing and subscriber information retrieval |
| D | HLR-VLR/SGSN | MAP_INSERT_SUBSCRIBER_DATA, MAP_PURGE_MS, MAP_UPDATE_LOCATION | Data updates, cleanup, and location management post-location changes |
| EIR-related | VLR/MSC/SGSN-EIR | MAP_CHECK_IMEI | Equipment identity verification |
| Error Code | Description | Typical Trigger | Consequence |
|---|---|---|---|
| 1 | Unknown subscriber | Unrecognized IMSI in HLR | Dialogue rejection and abort |
| 6 | Illegal equipment | Invalid IMEI in EIR | Equipment check failure and abort |
| 3 | Absent subscriber | Subscriber temporarily unavailable | Temporary denial with retry option |
| 4 | Busy subscriber | Subscriber engaged in another session | Call or service deferral |