Endsem Examination Bank: Unit 3

Section A: GSM Signaling and MAP

Outline the layers of the Signaling System No. 7 (SS7) protocol stack used in GSM. Explain the specific role of the Signaling Connection Control Part (SCCP) and Global Title Translation (GTT) when an MSC queries an unknown HLR.

The Signaling System No. 7 (SS7) is the critical, out-of-band signaling backbone that governs all call setup, mobility management, and billing in GSM networks. It is physically and logically separated from the voice bearers.

At the bottom of the stack are the Message Transfer Part (MTP) layers 1 through 3, which handle physical connectivity, data link framing, and basic network routing using rigid, hardcoded Point Codes. Above MTP sits the Signaling Connection Control Part (SCCP), which provides enhanced, connectionless routing capabilities. Layered on top of SCCP is the Transaction Capabilities Application Part (TCAP), which manages asynchronous remote database queries. Finally, at the application layer, sits the Mobile Application Part (MAP), which defines the specific GSM mobility messages.

The necessity of SCCP becomes apparent in international roaming scenarios. If a user from Japan connects to a Mobile Switching Center (MSC) in London, the London MSC must authenticate the user with the Japanese HLR. However, the London MSC’s routing tables only contain the specific SS7 Point Codes for local European nodes; it has no idea what the specific Point Code or IP of the Japanese HLR is.

To solve this, the MSC utilizes the user’s IMSI as a “Global Title.” It passes the IMSI down to the SCCP layer. SCCP performs Global Title Translation (GTT). It analyzes the Mobile Country Code (MCC) and Mobile Network Code (MNC) embedded within the IMSI. SCCP queries a distributed database to resolve this Global Title into the actual, routable SS7 network address (Point Code) of the specific Japanese HLR, allowing the authentication request to be routed successfully across international network boundaries.

Describe the Mobile Application Part framework. Categorize the five primary service frameworks defined by MAP.

The Mobile Application Part (MAP) is the supreme application-layer protocol within the GSM signaling architecture. It acts as a comprehensive, standardized API that allows Mobile Switching Centers (MSCs), Home Location Registers (HLRs), Visitor Location Registers (VLRs), and Authentication Centers (AuCs) to communicate seamlessly, regardless of which vendor manufactured the hardware. It defines the exact messages and state machines required to provide global mobility.

MAP operations are categorized into five primary service frameworks.

First, Mobility Services. This is the core of MAP, handling Location Updates as users roam, executing Handover procedures between MSCs, and managing the transport of security triplets for Authentication.

Second, Operation and Maintenance (O&M). This framework allows network operators to remotely trace subscriber activity for debugging and handles critical disaster recovery procedures, such as broadcasting HLR and VLR Reset messages when a database crashes.

Third, Call Handling. When an incoming call arrives, MAP is used to fetch the necessary routing information. The Gateway MSC queries the HLR, which uses MAP to interrogate the VLR to retrieve a temporary Mobile Station Roaming Number (MSRN) to connect the circuit.

Fourth, Supplementary Services. This framework manages user-specific features like call forwarding, call waiting, and call barring. It ensures that if a user sets their phone to forward calls to voicemail, that configuration is updated in the HLR and respected regardless of where they roam globally.

Fifth, Short Message Service (SMS) Management. MAP handles the routing of text messages. Because SMS is an asynchronous service, MAP guarantees delivery by routing texts from the MSC to the central SMS Center (SMSC), which buffers and forwards them when the recipient becomes available.

Explain how MAP utilizes TCAP for transaction management. Describe the lifecycle of a MAP dialogue using the BEGIN, CONTINUE, END, and ABORT primitives.

While MAP defines the specific commands (e.g., UpdateLocation or SendAuthenticationInfo), it relies entirely on the Transaction Capabilities Application Part (TCAP) to handle the mechanics of transmitting these commands across the network. TCAP manages asynchronous, remote procedure calls, wrapping MAP commands into structured “Dialogues” to ensure reliable query execution without requiring a heavy, continuous connection.

A standard MAP dialogue lifecycle begins when the initiating node, such as a VLR requiring authentication data, passes the MAP request down to TCAP. TCAP constructs a BEGIN message. This message contains a unique Transaction ID and encapsulates the MAP payload. It is sent to the remote node (the HLR) to initiate the dialogue.

If the requested data is massive (e.g., a massive subscriber profile) and cannot fit into a single SS7 packet, the HLR will reply using a CONTINUE message. This delivers a chunk of the payload while explicitly instructing the VLR to keep the transaction ID alive because more data is coming.

Once the HLR successfully processes the request and has formulated 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, freeing up local memory.

However, if a catastrophic error occurs—such as a network timeout, corrupted data, or a database lock—either node can instantly issue an ABORT primitive. This command abruptly and ungracefully terminates the dialogue, preventing memory leaks and allowing the nodes to restart the process.

The entire GSM mobility architecture rests on a delicate distributed database system. The Home Location Register (HLR) is the master record, storing the permanent profile and the definitive pointer to the user’s current location. The Visitor Location Register (VLR) acts as a temporary, localized cache, storing a copy of the profile while the user is physically present in its geographic area. To successfully route incoming calls, the HLR’s location pointer must perfectly match the actual VLR holding the active cache. Maintaining this strict consistency across an asynchronous network is a massive distributed computing challenge.

Consider a highly destructive scenario involving a link failure during movement. A user physically drives from the territory of VLR-A into the territory of VLR-B. The user’s mobile station detects the new Location Area and transmits a registration request to VLR-B. VLR-B initiates a MAP UpdateLocation transaction, sending a message up to the HLR.

The HLR receives the update and modifies its internal routing pointer to indicate that the user is now located at VLR-B. To maintain consistency, the HLR must now purge the stale cache at VLR-A. It dispatches a MAP CancelLocation message toward VLR-A.

If the SS7 link connecting the HLR to VLR-A physically fails or suffers severe congestion at that exact millisecond, the CancelLocation message is lost. The system is now critically inconsistent. Both VLR-A and VLR-B have active, valid cache records for the user. However, the HLR only points to VLR-B. If the user uses a supplementary service app on their phone to alter a call forwarding rule while parked in VLR-A (perhaps before the radio link fully degraded), VLR-A will attempt to execute it using its stale cache. This split-brain scenario can corrupt the user’s billing state and disrupt call routing until the cache in VLR-A naturally times out hours later.

Section B: Location Management

Detail the step-by-step MAP signaling message flow that occurs when a Mobile Station crosses a Location Area (LA) boundary and registers with a new VLR.

The Location Update procedure is the most frequent and critical signaling event in a cellular network, guaranteeing that the core network can always find a roaming device to deliver incoming calls.

First, the Mobile Station (MS) constantly monitors the broadcast control channel of its current cell. As it crosses a geographical boundary, it detects a new Location Area Identity (LAI) that does not match its internal memory. The MS initiates the process by transmitting a Location Update Request over the radio link to the newly discovered VLR. Crucially, this request includes the old LAI where it was previously parked, and its current Temporary Mobile Subscriber Identity (TMSI) to preserve anonymity.

Second, the New VLR receives the request but cannot interpret the TMSI because it was generated by a different machine. The New VLR parses the old LAI to determine the network address of the Old VLR. It sends a MAP SendIdentification request to the Old VLR, passing the TMSI. The Old VLR looks up the TMSI, extracts the user’s true IMSI and remaining authentication security vectors, and securely transfers them to the New VLR.

Third, after cryptographically authenticating the mobile station using the transferred vectors, the New VLR officially takes ownership of the subscriber. It sends a MAP UpdateLocation message up to the user’s Home Location Register (HLR).

Fourth, the HLR updates its internal routing pointer to point to the New VLR. It then takes responsibility for cleaning up the network state by dispatching a MAP CancelLocation message to the Old VLR. Upon receiving this, the Old VLR deletes the user’s stale cache, freeing up memory.

Finally, the HLR sends an UpdateLocationAck back to the New VLR, transferring a fresh copy of the user’s service profile. The New VLR generates a completely new, mathematically random TMSI, stores the IMSI-TMSI mapping locally, and transmits the new TMSI back to the Mobile Station over the encrypted radio link, completing the procedure.

Describe the specific sequence of events that occurs when a VLR crashes and reboots with an empty database. How does the VLR reconstruct a user’s profile during Mobile Originated (MO) activity versus Mobile Terminated (MT) activity?

A VLR crash is a localized disaster. Because the VLR stores all data in volatile RAM for speed, a crash instantly wipes out all temporary TMSI mappings and user profiles for millions of subscribers currently in that city. When the VLR reboots, it awakens with an entirely empty database. It cannot blindly poll the HLR to ask “who is here?” because the HLR relies on the VLR to tell it where users are. The VLR must organically reconstruct its database through user activity.

Reconstruction occurs differently depending on the direction of the call. During Mobile Originated (MO) Activity (when the user attempts to make an outbound call), the mobile station sends a call setup request containing its assigned TMSI. The rebooted VLR receives this TMSI but finds no matching record in its empty database. Recognizing the error, the VLR suspends the call setup and initiates an Identity Request procedure over the air, forcing the mobile station to transmit its true IMSI. Once the VLR receives the IMSI, it executes a MAP UpdateLocation query to the HLR to download the user’s full profile. It generates a new TMSI, caches the profile, and then allows the outbound call to proceed.

During Mobile Terminated (MT) Activity (when an incoming call arrives for the user), the scenario is more complex. The Gateway MSC queries the HLR, which sees its pointer still indicating the user is at the crashed VLR. The HLR asks the VLR for a Mobile Station Roaming Number (MSRN) to route the call. The VLR receives this request but has no record of the IMSI provided by the HLR.

Realizing it has lost the user’s data, the VLR immediately requests the user’s profile from the HLR. It then initiates a massive, desperate search. It actively pages the mobile station across every single cell tower in all of its controlled Location Areas, using the true IMSI rather than a TMSI. When the mobile station hears its IMSI, it responds. The VLR re-establishes the exact location, assigns a new TMSI, caches the profile, generates the MSRN, and sends it back to the HLR, allowing the incoming call to successfully connect.

Explain the catastrophic implications of an HLR crash. Upon restoring from backup, how does the HLR utilize the “Unconfirmed by VLR” flag and the MAP Reset broadcast to self-heal its stale location pointers?

An HLR crash is a catastrophic, network-wide failure. The HLR is the central brain of the mobility architecture. If it goes offline, the network loses the ability to map phone numbers to physical locations. No incoming calls can be routed, no SMS messages can be delivered, and new users cannot authenticate. The network effectively ceases to exist for inbound traffic.

When an HLR crashes, it must eventually reboot and restore its data from non-volatile disk backups. However, this restored data is inherently stale. In the minutes or hours between the last backup and the reboot, thousands of subscribers physically moved to new cities, and their location pointers in the backup are now pointing to the wrong VLRs.

To prevent routing calls into the void, the rebooting HLR executes a brilliant self-healing protocol. First, it iterates through its entire restored database and sets an internal software flag labeled “Unconfirmed by VLR” for every single subscriber record.

Second, the HLR broadcasts a massive MAP Reset message across the SS7 network to every single VLR in the country.

When a VLR receives this Reset message, it realizes its master database has suffered amnesia. The VLR scans its own local cache and flags every user associated with that specific HLR. The next time one of those flagged users performs any action—such as making a call, sending a text, or executing a periodic location update—the VLR intercepts the action. Before processing the call, the VLR forces an UpdateLocation transaction up to the HLR.

As these UpdateLocation messages arrive at the HLR, they organically overwrite the stale pointers with fresh, accurate location data, and the HLR clears the “Unconfirmed” flag for that user. Over a few hours, normal network traffic completely self-heals the shattered database without requiring any manual intervention.

Compare the O-I (Option I) and O-II (Option II) algorithms used by a new VLR to identify a user’s previous VLR during a location update. Why is the heuristic O-II approach superior in dynamic network topologies?

When a mobile station moves into a new VLR’s territory, it provides its old Location Area Identity (LAI). The new VLR must use this LAI to locate the old VLR to fetch the user’s security vectors. The GSM standard defines two algorithmic options for resolving this address.

In the O-I (Option I) Algorithm, the new VLR utilizes a static, hardcoded translation table maintained in its local memory. It simply looks up the old LAI string and maps it directly to the predefined ISDN address of the old VLR. The primary advantage of O-I is speed; it requires zero external signaling to resolve the address. However, it is incredibly brittle. If the old VLR suffers a hardware failure and the operator fails over to a backup VLR with a new IP address, the static table in every other VLR in the country becomes instantly invalid, breaking location updates globally until manual patches are applied.

In the O-II (Option II) Algorithm, the new VLR acts heuristically. Instead of relying on static tables, it queries the supreme source of truth: the HLR. The new VLR sends the old LAI and the user’s IMSI/TMSI up to the HLR. Because the HLR maintains dynamic, real-time mappings of Location Areas to actively functioning VLRs, it processes the query and returns the correct, current address of the old VLR back to the new VLR.

While the O-II approach adds an extra SS7 signaling hop (increasing latency slightly), it provides immense fault tolerance. It inherently supports dynamic network restructuring, failovers, and load balancing, ensuring that the network can organically route around damaged nodes without requiring manual table updates. This resilience makes O-II vastly superior in modern, dynamic topologies.

Section C: Handoff Strategies

List and explain the primary factors evaluated by a network before initiating a handoff. Define the “Ping-Pong Effect” and explain how introducing a Handoff Margin (Hysteresis) mitigates it.

Executing a handoff is a resource-intensive procedure that momentarily degrades call quality and consumes significant signaling bandwidth. Therefore, the network continuously evaluates multiple distinct metrics before authorizing the transition.

The most fundamental factor is the Received Signal Strength Indicator (RSSI), which measures the raw, absolute power of the radio wave hitting the antenna. However, raw power is insufficient. The network also evaluates the Signal-to-Interference-plus-Noise Ratio (SINR). A user might have a massive RSSI value, but if they are experiencing severe co-channel interference from a distant tower, the signal is undecodable. SINR dictates the actual quality of the link. Finally, the network evaluates Network Load. A handoff may be triggered entirely independent of fading; the BSC may force a user with a perfectly good connection to hand off to an adjacent, weaker cell simply to execute load balancing and free up capacity in a congested sector.

A major pathological issue in cellular networks is the “Ping-Pong Effect.” This occurs when a user stands stationary exactly on the geographical boundary between Cell A and Cell B. Because of minor, transient Rayleigh fading (perhaps a truck drives by), the signal from Cell A drops slightly below Cell B. The network hands the user to Cell B. A second later, the truck passes, Cell A becomes stronger again, and the network hands the user back. This rapid, continuous switching back and forth wastes massive signaling bandwidth and often leads to dropped calls.

To mitigate this, networks introduce a Handoff Margin, mathematically known as Hysteresis. Instead of simply switching when RSSI_B > RSSI_A, the network enforces a strict threshold. A handoff is only initiated if the new cell’s signal is stronger than the old cell’s signal plus a fixed, predefined margin (e.g., RSSI_B > RSSI_A + 3dB). This hysteresis buffer acts as a shock absorber, ensuring that trivial, transient fluctuations in signal strength do not trigger unnecessary, cascading handoffs.

Contrast the “Break-Before-Make” hard handoff used in GSM with the “Make-Before-Break” soft handoff used in UMTS (W-CDMA). Explain how Macrodiversity improves call reliability during a soft handoff.

The evolution from 2G GSM to 3G UMTS introduced a fundamental paradigm shift in how handoffs are executed at the physical layer, moving from abrupt severing to fluid transitions.

GSM utilizes a Hard Handoff, fundamentally characterized as “Break-Before-Make.” Because adjacent GSM cells operate on entirely different FDMA frequency channels to avoid interference, a mobile phone cannot physically communicate with both towers simultaneously using a single radio. When a handoff is ordered, the phone must completely sever its radio link with the old Base Station, mechanically retune its radio synthesizer to the new frequency, synchronize with the new Base Station’s TDMA framing, and re-establish the connection. This process causes a mandatory, perceptible blackout of approximately 50 milliseconds, which can disrupt data streams and occasionally drop voice calls if the new cell is congested.

UMTS (W-CDMA) utilizes a Soft Handoff, characterized as “Make-Before-Break.” Because W-CDMA spreads all users across the exact same massive 5 MHz frequency block universally, adjacent cells share the same spectrum. When a user approaches a cell boundary, the mobile phone uses its correlators to connect to the new Node B while simultaneously maintaining its active, locked connection to the old Node B.

This simultaneous connection enables Macrodiversity. During the transition zone, the mobile phone actively transmits its data stream to both Node Bs at the same time. Both Node Bs receive the signal, decode it, and forward the packets up the backhaul to the Radio Network Controller (RNC). The RNC acts as a master synthesizer. It aligns the two incoming data streams in time, evaluates the checksums, and dynamically selects the highest-quality frames from either stream on a millisecond-by-millisecond basis. This “Make-Before-Break” approach, coupled with Macrodiversity, provides massive resilience against deep fades at the cell edge, practically eliminating dropped calls during transitions.

Define a vertical handoff in the context of heterogeneous networks. Discuss the extreme technical challenges involved in maintaining QoS, IP addressing, and security context across disparate bearer networks.

A standard Horizontal Handoff involves moving a connection between two nodes operating on the exact same underlying technology (e.g., moving from one GSM cell tower to another GSM cell tower). A Vertical Handoff is an exponentially more complex procedure: it involves seamlessly migrating an active, live data session across entirely different architectural technologies and bearer networks, such as a user stepping out of an office building and shifting a live VoIP call from a corporate Wi-Fi network to a public 4G LTE cellular network.

Executing a Vertical Handoff without dropping the call introduces extreme technical challenges across multiple layers of the OSI model.

The first major challenge is IP Addressing. The corporate Wi-Fi network and the public LTE network operate on entirely different subnets and are governed by different DHCP servers. If the phone simply switches radios, it receives a new IP address, and the active TCP socket for the VoIP call instantly breaks. Maintaining the session requires the implementation of Mobile IP or advanced SIP mobility protocols to anchor the IP address and tunnel traffic during the transition.

The second challenge is QoS Translation. Wi-Fi (802.11) and LTE handle Quality of Service using fundamentally different philosophies and tagging mechanisms. Wi-Fi uses best-effort contention, while LTE uses strict, dedicated hardware bearers. The core network must seamlessly renegotiate bandwidth, latency, and jitter guarantees across the technological boundary to ensure the VoIP audio doesn’t suddenly degrade into robotic stuttering.

The third, and most critical, challenge is the Security Context. The user on the Wi-Fi network is authenticated using WPA3 enterprise credentials. The moment they step outside, the phone must instantly re-authenticate with the 4G network’s Home Subscriber Server (HSS) using cryptographic keys hardcoded in the physical SIM card. Executing this massive cryptographic handshake, generating new session keys, and establishing a secure IPsec tunnel on the LTE network—all within the 100-millisecond window before the Wi-Fi signal completely fades—requires immense computational speed and tight integration between the disparate network cores.