The Necessity of Out-of-Band Signaling

Early telecommunications systems utilized “in-band” signaling. The control signals required to set up a call, ring a phone, or tear down a connection were transmitted over the exact same physical audio circuit that carried the user’s voice. This architecture was fundamentally flawed. It severely limited the speed of call setup, and more disastrously, it exposed the core network to massive security vulnerabilities. Attackers could use simple devices (like “blue boxes”) to emit specific audio frequencies over their phone’s mouthpiece, directly manipulating the core network switches to bypass billing systems and make free international calls.

To secure the network and support the massive complexity of mobile roaming, GSM entirely abandoned in-band signaling in favor of a robust, “out-of-band” architecture known as Signaling System No. 7 (SS7). In SS7, the control signals and the actual voice circuits are physically and logically separated. The voice traffic travels over dedicated bearer channels, while the control messages travel over a highly secure, high-speed, packet-switched data network completely inaccessible to the end-user. This separation is the absolute prerequisite for all modern cellular mobility, allowing the network to query databases, authenticate users, and track movement without ever interfering with live audio.

The SS7 Protocol Stack in GSM

The SS7 protocol stack is organized into hierarchical layers, conceptually similar to the OSI model, but engineered specifically for telecom reliability.

1. The Message Transfer Part (MTP 1-3)

The foundation of the stack comprises the Message Transfer Part (MTP) layers 1, 2, and 3. These layers are responsible for the physical connectivity, data link framing, and fundamental network routing of the signaling packets.

  • MTP routing is highly rigid. It relies on hardcoded network addresses known as “Point Codes.” Every MSC, HLR, and VLR is assigned a unique Point Code. MTP routers simply look at the destination Point Code in the packet header and forward it. MTP possesses no intelligence to handle dynamic movement or international roaming.

2. Signaling Connection Control Part (SCCP)

Above MTP sits the Signaling Connection Control Part (SCCP). SCCP provides enhanced, connectionless routing capabilities that MTP lacks, specifically designed to solve the problem of international roaming through a mechanism called Global Title Translation (GTT).

Global Title Translation (GTT)

Consider a scenario where a Japanese tourist roams onto a Mobile Switching Center (MSC) in London. The London MSC must authenticate the user with their Home Location Register (HLR) in Tokyo. The London MSC’s local MTP routing tables only contain Point Codes for European nodes; it has absolutely no idea what the specific Point Code or IP address of the Japanese HLR is.

To solve this, the MSC utilizes the user’s IMSI (International Mobile Subscriber Identity) as a “Global Title.” It passes the IMSI down to the SCCP layer. SCCP analyzes the first few digits of the IMSI, which contain the Mobile Country Code (MCC) and the Mobile Network Code (MNC). SCCP queries a highly distributed, hierarchical DNS-like database to mathematically translate this Global Title into the actual, routable SS7 Point Code of the specific Japanese HLR. This translation allows the authentication request to bypass local routing limits and successfully traverse international network boundaries.

3. Transaction Capabilities Application Part (TCAP)

Layered on top of SCCP is the Transaction Capabilities Application Part (TCAP). TCAP is responsible for managing asynchronous remote database queries. It manages “Dialogues” between nodes, wrapping application-layer commands into structured packets and keeping track of transaction IDs to ensure reliable query execution over connectionless links without requiring a heavy, continuous TCP-like handshake.

4. Mobile Application Part (MAP)

At the very top of the stack resides the Mobile Application Part (MAP). MAP is the supreme application-layer protocol within the GSM signaling architecture. It acts as a comprehensive, standardized API that defines the specific mobility messages. MAP is the language that allows an Ericsson MSC to successfully interrogate a Nokia HLR without compatibility issues.

The Five Service Frameworks of MAP

MAP defines hundreds of specific operations, which are categorized into five primary service frameworks critical for network operation:

  1. Mobility Services: This is the core function of MAP. It handles the continuous tracking of users, executing UpdateLocation queries as users cross geographic boundaries, managing complex inter-MSC Handover procedures, and handling the transport of cryptographic security vectors for Authentication.
  2. Operation and Maintenance (O&M): This framework allows network engineers to remotely trace subscriber activity across the network for debugging. More importantly, it handles critical disaster recovery procedures, such as broadcasting MAP Reset messages to re-synchronize the network when a central database crashes.
  3. Call Handling: When an incoming call arrives at the Gateway MSC from the public internet, MAP is used to fetch the necessary routing information. The Gateway uses MAP to interrogate the HLR, which uses MAP to interrogate the VLR to retrieve a temporary Mobile Station Roaming Number (MSRN) to connect the physical audio circuit.
  4. Supplementary Services: This framework manages user-specific features like call forwarding, call waiting, and call barring. It ensures that if a user configures their phone to unconditionally forward all calls to a specific international number, that configuration is permanently updated in the HLR and respected regardless of where they roam globally.
  5. Short Message Service (SMS) Management: MAP handles the routing and guaranteed delivery of text messages. Because SMS is fundamentally asynchronous (the recipient phone might be turned off), MAP routes texts from the MSC to the central SMS Center (SMSC), which buffers them. When the recipient phone powers back on, MAP signals the SMSC to forward the buffered messages.

TCAP Transaction Management: The Dialogue Lifecycle

While MAP defines the specific commands (e.g., SendAuthenticationInfo), it relies entirely on TCAP to handle the mechanics of transmitting these commands. TCAP manages these operations as structured, stateful Dialogues.

A standard MAP dialogue lifecycle follows a strict sequence of primitives:

  1. BEGIN: The transaction initiates when the requesting node (e.g., a VLR) passes the MAP request down to TCAP. TCAP constructs a BEGIN message. This message contains a unique, locally generated Transaction ID and encapsulates the MAP payload. It is transmitted to the remote node (e.g., the HLR) to open the dialogue.
  2. CONTINUE: If the requested data is massive—such as downloading a complex corporate subscriber profile—it cannot fit into a single SS7 data packet. The HLR will reply using a CONTINUE primitive. This delivers the first chunk of the payload while explicitly instructing the VLR to keep the Transaction ID alive in its RAM because more data packets are en route.
  3. END: Once the HLR successfully processes the entire request and formulates the final response, it wraps this final payload in an END primitive. When the VLR receives the END message, it extracts the data and gracefully tears down the transaction, formally closing the dialogue and freeing up local memory.
  4. ABORT: If a catastrophic error occurs during the dialogue—such as a network timeout, corrupted data, or a database lock—either node possesses the authority to instantly issue an ABORT primitive. This command abruptly and ungracefully terminates the dialogue, preventing memory leaks, terminating the hanging process, and allowing the nodes to restart the procedure from scratch.