MAP Operations
This document describes the MAP (Mobile Application Part) operations implemented by OmniMSC, including dialogue management, subscriber location procedures, authentication, SMS forwarding, USSD, and error handling. For configuration, see Configuration Reference. For the SMS-layer view of MO-ForwardSM and MT-ForwardSM, including CP/RP protocol details, see SMS. For authentication vector handling and the Auth FSM, see Security. For how InsertSubscriberData populates the subscriber profile visible in the control panel, see Control Panel Guide.
MAP Client
OmniMSC operates a MAP client that manages dialogues with remote MAP peers (HLR, SMSc, USSD gateway). The MAP client handles dialogue lifecycle, TCAP transaction correlation, and dialogue timeout supervision.
When a subsystem (VLR, SMS handler, SS handler) needs to invoke a MAP operation, it requests a new dialogue from the MAP client. The client allocates a local transaction ID (otid), opens a TCAP BEGIN towards the peer, and monitors the dialogue for a configurable timeout period. If the peer does not respond within the timeout, the client aborts the dialogue and notifies the requesting subsystem of the failure.
For incoming MAP dialogues initiated by remote peers (such as InsertSubscriberData from the HLR or MT-ForwardSM from the SMSc), the MAP client accepts the TCAP BEGIN, correlates it with the remote transaction ID (dtid), spawns a handler process, and supervises the dialogue until completion.
UpdateLocation
The MSC sends MAP UpdateLocation to the HLR when a subscriber performs a Location Update. The message carries the subscriber IMSI and the VLR number (the E.164 address of this MSC/VLR). The HLR uses the VLR number to route future MT transactions (calls, SMS, USSD) to the correct MSC.
On receiving the UpdateLocation result, the VLR marks the Location Update as complete and the LU FSM proceeds to TMSI allocation. If the HLR returns an error (unknown subscriber, roaming not allowed), the MSC rejects the Location Update towards the mobile station with the appropriate cause.
InsertSubscriberData
The HLR sends MAP InsertSubscriberData to the MSC during the UpdateLocation procedure, and also proactively when the subscriber profile changes (e.g., supplementary service activation via the HLR provisioning interface). The message carries the subscriber profile including:
- MSISDN (the subscriber's directory number)
- CS bearer services and teleservices
- Operator Determined Barring (ODB) categories
- Supplementary service data (call forwarding numbers, barring status, CLIR mode, CW status)
- CAMEL subscription information (service keys, gsmSCF addresses)
The VLR stores this data in the subscriber record. Subsequent call setup, SMS delivery, and SS operations reference this locally cached profile to avoid round-trips to the HLR.
SendAuthenticationInfo
The MSC sends MAP SendAuthenticationInfo to the HLR to fetch authentication vectors for a subscriber. The request carries the IMSI, the number of requested vectors, and optionally re-synchronisation data (AUTS) if the UE reported a sequence number failure.
The HLR returns authentication vectors from the AuC: quintuplets (RAND, XRES, CK, IK, AUTN) for UMTS-capable subscribers or triplets (RAND, SRES, Kc) for GSM-only subscribers. The MSC stores the vectors in the VLR and uses them for subsequent authentication attempts without contacting the HLR again until the vector supply is exhausted.
PurgeMS
The MSC sends MAP PurgeMS to the HLR when a subscriber performs an IMSI detach. The message carries the IMSI and the VLR number. On receiving PurgeMS, the HLR clears the VLR address from the subscriber record. This ensures correct T-ADS (Terminating Access Domain Selection) routing: without a valid VLR address, the HLR knows the subscriber is not reachable via CS domain and can route MT services accordingly (e.g., trigger the MNRF flag for SMS, return absent subscriber for MT calls).
MO-ForwardSM
The MSC sends MAP MO-ForwardSM to the SMS Centre for mobile-originated short messages. The message carries the SM-RP-DA (destination, typically the SMSc address), SM-RP-OA (originator, the subscriber MSISDN), and the SM-RP-UI (the TPDU containing the SMS payload).
The SMSc acknowledges with a return result on successful acceptance, or a return error if the message cannot be processed (e.g., SMSc congestion, invalid destination).
MT-ForwardSM
The SMS Centre sends MAP MT-ForwardSM to the MSC for mobile-terminated short message delivery. On receiving this operation, OmniMSC spawns a dedicated map_handler process that manages the delivery attempt and holds the MAP dialogue open until the outcome is known.
The handler looks up the subscriber in the VLR, pages if necessary, and delivers the SM via DTAP. Once the mobile station acknowledges delivery (RP-ACK) or reports failure (RP-ERROR), the handler sends a TCAP End containing either a returnResult (successful delivery) or a returnError (delivery failure with cause) back to the SMSc.
If delivery fails (subscriber absent, memory exceeded, protocol error), the handler returns the appropriate MAP error:
| Error | Cause |
|---|---|
| Absent Subscriber | Subscriber not reachable (not registered or no paging response) |
| SM Delivery Failure | MS returned RP-ERROR (memory full, unspecified error) |
| System Failure | Internal processing error |
ProcessUnstructuredSS-Request
OmniMSC relays USSD requests to the HLR via MAP ProcessUnstructuredSS-Request when the USSD string targets a service that requires HLR processing (e.g., supplementary service management, balance queries). The MSC forwards the USSD string and DCS (data coding scheme) to the HLR, which processes the request and returns a response string to be displayed on the mobile station.
For operator-defined USSD codes that are handled by an external USSD gateway rather than the HLR, the MSC routes the MAP dialogue to the configured gateway address instead.
TCAP Transaction Management
MAP dialogues are carried within TCAP transactions. OmniMSC maintains a transaction table that correlates local and remote transaction identifiers across the dialogue lifecycle.
| TCAP Message | MAP Dialogue Phase | Description |
|---|---|---|
| TC-BEGIN | Opening | Initiator sends first invoke; carries originating transaction ID (otid) |
| TC-CONTINUE | Active | Both parties exchange components; response carries destination transaction ID (dtid) matching the peer's otid |
| TC-END | Closing | Final message; carries result or error components; dialogue terminated |
| TC-ABORT | Abort | Abnormal termination; protocol error or timeout |
The MAP client tracks each active dialogue by its otid/dtid pair. When a TCAP CONTINUE or END arrives, the client matches the dtid to a local otid to locate the corresponding handler process. This correlation is essential for multiplexing many concurrent MAP dialogues over a single SCCP connection.
Dialogue Timeout
Each MAP dialogue has a configurable timeout. If the remote peer does not respond within the timeout period, the MAP client sends a TC-ABORT (locally initiated) and notifies the requesting subsystem. This prevents resource leaks from unresponsive peers.
MAP Error Handling
OmniMSC handles MAP errors at both the component level (return error within a dialogue) and the dialogue level (abort, provider error).
Common MAP Errors
| Error | Typical Operation | MSC Handling |
|---|---|---|
| Absent Subscriber | MT-ForwardSM, SendRoutingInfo | Report delivery failure to SMSc; set MNRF in VLR |
| SM Delivery Failure | MT-ForwardSM | Forward TP failure cause to SMSc |
| Unknown Subscriber | UpdateLocation | Reject Location Update |
| Roaming Not Allowed | UpdateLocation | Reject Location Update with appropriate cause |
| System Failure | Any | Retry or report failure to requesting subsystem |
| Data Missing | SendAuthenticationInfo | Authentication cannot proceed; reject service |
| Unexpected Data Value | InsertSubscriberData | Log and reject the offending parameter |
Dialogue-Level Failures
When a TCAP ABORT is received or a dialogue times out, the MAP client determines which subsystem initiated the dialogue and delivers a failure notification. The subsystem then applies its own recovery logic (e.g., the LU FSM rejects the Location Update, the SMS handler returns a delivery failure to the SMSc).
Point Code Routing
When OmniMSC receives an incoming MAP dialogue (e.g., MT-ForwardSM from the SMSc, InsertSubscriberData from the HLR), the M3UA layer records the originating point code from the incoming message's routing information. When the MSC sends the response (TCAP Continue or End), it uses this recorded point code as the destination point code (DPC) for the outgoing M3UA message.
This mechanism ensures that responses are routed back to the correct originating node, even when multiple HLRs or SMScs with different point codes are reachable via the same STP. The routing_info from the incoming M3UA association is stored per-dialogue and used for all subsequent messages within that dialogue.
3GPP Specification References
| Specification | Title | Relevance |
|---|---|---|
| TS 29.002 | Mobile Application Part (MAP) Specification | All MAP operations, error codes, dialogue procedures |
| ITU-T Q.771-Q.775 | Transaction Capabilities Application Part (TCAP) | TCAP transaction management, component handling |
| ITU-T Q.711-Q.716 | Signalling Connection Control Part (SCCP) | SCCP addressing and routing for MAP dialogues |
| RFC 4666 | MTP3 User Adaptation Layer (M3UA) | M3UA transport, point code routing |