Endsem Examination Bank: Unit 5

Section A: Mobile Transport Layer (TCP)

Explain why traditional TCP’s congestion control mechanisms (Slow Start, Congestion Avoidance) fail catastrophically in wireless environments. How does a high Bit Error Rate (BER) mimic network congestion to the TCP sender?

The Transmission Control Protocol (TCP) was architected in the 1970s for highly reliable, wired fiber-optic and copper networks. In these pristine environments, the physical Bit Error Rate (BER) is infinitesimally small (often less than 10^-9). Consequently, the original designers of TCP made a hardcoded, fundamental assumption: if a packet is lost in transit and fails to generate an Acknowledgment (ACK), it is almost certainly because an intermediate router became overloaded and its memory buffer overflowed. This is the definition of Network Congestion.

To prevent the entire internet from collapsing under load, traditional TCP reacts to a lost packet violently. It immediately assumes the network is congested and slashes its transmission rate. It enters the “Slow Start” phase, dropping its Congestion Window to a single packet, and slowly probes the network capacity to avoid further overwhelming the routers.

In a wireless environment, this assumption fails catastrophically. Wireless links suffer from extreme physical degradation due to multipath fading, shadowing, Doppler shifts, and co-channel interference. This results in a highly volatile BER that can spike unpredictably. When a wireless link drops a packet due to a deep fade, the router’s queue is entirely empty—there is absolutely no congestion. However, the TCP sender on the remote server is blind to the physical medium. It only sees a missing ACK. Misinterpreting the radio error as network congestion, the sender throttles its speed drastically. This unnecessarily starves the radio link of data, utterly destroying the throughput of the mobile device.

Describe the architecture of Indirect TCP. How does splitting the connection at the Base Station shield the Fixed Host from wireless packet loss? What is the fundamental violation of TCP semantics introduced by I-TCP?

Indirect TCP (I-TCP) attempts to solve the wireless packet loss problem through architectural isolation. It physically splits the single end-to-end TCP connection into two entirely distinct segments, joining them at the cellular Base Station (or Access Point).

Segment 1 is a standard, unmodified TCP connection running from the Fixed Host (a web server on the internet) to the Base Station over reliable fiber optics. Segment 2 is a highly specialized, wirelessly optimized TCP connection running from the Base Station to the Mobile Node over the volatile radio link.

This architecture effectively shields the Fixed Host. When a packet arrives from the internet, the Base Station instantly sends an ACK back to the Fixed Host, confirming delivery. The BS then buffers the packet and attempts to send it over the wireless link to the Mobile Node. If the packet is lost to fading, the Base Station detects the loss and retransmits the packet locally over Segment 2. Crucially, the Fixed Host on Segment 1 is completely unaware of this struggle. It never sees a missing ACK, never assumes congestion, and therefore maintains a massive transmission window, keeping the pipe full.

However, I-TCP introduces a severe architectural compromise: it breaks the fundamental “End-to-End Semantic” of the TCP protocol. In standard TCP, an ACK strictly guarantees that the final destination has successfully received the data. In I-TCP, because the Base Station ACKs the packet prematurely on behalf of the Mobile Node, a critical vulnerability is created. If the Base Station successfully ACKs a 10MB chunk of data to the Fixed Host, but then suddenly crashes due to a power failure before delivering that data over the wireless link, the Fixed Host believes the transfer was entirely successful. The data is permanently lost, and the application layer on the Mobile Node receives a corrupted or incomplete file without the sender ever knowing.

Explain the operation of Snoop TCP. How does the Base Station intercept duplicate ACKs and retransmit packets locally without breaking the end-to-end semantics of the connection?

Unlike I-TCP’s split architecture, Snoop TCP preserves a single, unbroken, end-to-end connection between the Fixed Host and the Mobile Node, maintaining strict TCP semantics. The Base Station in this model acts as a highly intelligent, transparent proxy rather than a terminating endpoint.

The Snoop module resides in the routing layer of the Base Station. As standard TCP packets flow downstream from the internet, the Snoop module silently copies (caches) them into a local buffer before forwarding them over the air to the Mobile Node. Simultaneously, it “snoops” on the uplink traffic, inspecting the ACKs traveling from the Mobile Node back to the Fixed Host.

If the wireless link drops a packet, the Mobile Node will receive out-of-order packets and immediately generate Duplicate ACKs. When the Snoop module intercepts these Duplicate ACKs, it realizes a radio loss has occurred. It immediately retrieves the lost packet from its local cache and retransmits it to the Mobile Node, executing a lightning-fast local recovery.

The genius of Snoop TCP lies in its handling of those Duplicate ACKs. The Base Station deliberately drops them, preventing them from traversing the wired network. Because the Fixed Host never receives the Duplicate ACKs, it never triggers Fast Retransmit or halves its Congestion Window. Furthermore, because the Base Station only caches packets and never generates artificial ACKs on behalf of the Mobile Node, the End-to-End semantic is perfectly preserved. If the Base Station crashes, the Fixed Host’s timers simply expire, and it retransmits the data naturally.

Describe how M-TCP handles lengthy disconnections caused by handovers. How does the Supervisory Host utilize the “Zero Window Size” advertisement to freeze the Fixed Host’s timers?

M-TCP (Mobile TCP) is a specialized variant designed to handle environments characterized by frequent, lengthy disconnections, such as a user driving through a long tunnel or experiencing a prolonged hard handoff between macrocells.

In a standard TCP connection, if the Mobile Node disappears into a tunnel for 10 seconds, the Fixed Host’s Retransmission Timeout (RTO) will rapidly expire. The Fixed Host will repeatedly attempt to retransmit, doubling the RTO backoff timer each time. By the time the Mobile Node reconnects, the Fixed Host might be waiting a full 60 seconds before probing the network again, causing the connection to appear dead even when signal is restored.

M-TCP solves this by splitting the connection at a Supervisory Host (SH) located deep within the cellular core network. When the SH detects that the Mobile Node has lost its radio link (often via a signal from the Base Station), it executes a highly specific TCP control maneuver. The SH sends a specialized ACK back to the Fixed Host, explicitly advertising a Window Size of Zero.

In the TCP protocol, a Zero Window advertisement forces the sender into “persist mode.” The Fixed Host immediately stops sending data and completely freezes its retransmission timers. Crucially, it does not assume congestion, so it does not drop its Congestion Window. The connection enters a suspended animation state. The moment the Mobile Node emerges from the tunnel and reconnects to a new Base Station, the SH sends an ACK to the Fixed Host reopening the window. The Fixed Host instantly unfreezes its timers and resumes transmission at the exact same high speed it was operating at prior to the disconnection, preventing any stall in the pipeline.

Explain how Selective Retransmission (SACK) saves wireless bandwidth compared to cumulative ACKs. Describe how artificially triggering Fast Retransmit can rapidly restart data flow after a hard handoff.

Traditional TCP utilizes a cumulative acknowledgment scheme. If a receiver successfully receives packets 1, 2, 4, 5, and 6, but packet 3 is lost due to a brief radio fade, the receiver can only send an ACK for packet 2 (the last contiguous packet). The sender is blind to the fact that packets 4, 5, and 6 successfully arrived. Upon timeout, a standard TCP sender will unnecessarily retransmit packet 3, and potentially packets 4, 5, and 6 as well. In a severely bandwidth-constrained wireless environment, retransmitting data that has already been successfully received is a catastrophic waste of spectrum.

Selective Retransmission (SACK) is a TCP extension that completely alters this behavior. SACK allows the receiver to append specific byte-range blocks to its ACKs. In the previous scenario, the Mobile Node would ACK packet 2, but also include a SACK block indicating it has safely buffered packets 4 through 6. The sender processes this explicit topological map of the receiver’s buffer and surgically retransmits only packet 3. This surgical precision saves immense wireless bandwidth.

Additionally, mobile devices can manipulate TCP behavior to recover from hard handoffs. During a hard handoff, the radio physically retunes, causing a brief blackout. A cluster of packets currently in flight from the server will be dropped by the old Base Station. Rather than waiting multiple seconds for the server’s RTO to expire, the Mobile Node can proactively intervene. The exact millisecond it connects to the new Base Station, it can artificially generate and transmit three Duplicate ACKs for the last packet it successfully received. This tricks the server into instantly executing a Fast Retransmit, immediately flooding the new radio link with the lost data burst and bypassing the lengthy timeout penalty.

Section B: Wireless Application Protocol (WAP)

Diagram the WAP architecture. Why was a specialized WAP Gateway required to translate between the mobile client and the Origin Server? Explain the encoding/compression process that occurs at the Gateway.

The WAP architecture operates as a distinct intermediary system: WAP Client (Mobile Phone) <--> Cellular Air Interface <--> WAP Gateway <--> Public Internet <--> Origin Server.

In the late 1990s, mobile phones were severely constrained. They possessed CPUs operating in the low Megahertz, kilobytes of RAM, and communicated over 2G GSM networks providing a maximum throughput of 9.6 kbps. Standard internet protocols like HTTP and HTML were designed for desktop computers on broadband connections. They utilized massive, verbose text headers and heavy markup tags that would instantly overwhelm a 2G mobile link, taking minutes to load a single page.

A specialized WAP Gateway was deployed within the telecom operator’s core network to bridge this technological chasm. When a mobile user requests a webpage, the request travels via the lightweight WAP protocol to the Gateway. The Gateway translates this request into a standard HTTP GET and queries the Origin Server. The Origin Server responds with content written in Wireless Markup Language (WML), an XML-based language specifically designed for small screens.

The true power of the Gateway lies in its encoding engine. When the Gateway receives the textual WML from the Origin Server, it strips out all unnecessary HTTP headers. It then compiles the verbose XML tags into a highly optimized, binary format. For example, a lengthy tag string is replaced by a single hex byte. This aggressive tokenization process compresses the payload to a fraction of its original size. The Gateway then transmits this tiny, binary payload over the slow cellular air interface, drastically reducing bandwidth consumption and ensuring the page loads in seconds rather than minutes.

Compare the layers of the WAP protocol stack (WDP, WTLS, WTP, WSP) with the traditional TCP/IP stack. Why did WTP adopt a transaction-oriented approach rather than a connection-oriented handshake like TCP?

The WAP protocol stack was explicitly engineered from the ground up to operate efficiently over high-latency, low-bandwidth wireless bearers, replacing the heavy TCP/IP stack layer by layer.

At the transport layer, WDP (Wireless Datagram Protocol) replaces UDP/IP, providing unreliable datagram delivery while adapting to the underlying bearer (GSM, CDMA, CDPD). Above this sits WTLS (Wireless Transport Layer Security), which replaces standard TLS/SSL, utilizing bandwidth-efficient algorithms like Elliptic Curve Cryptography to provide encryption without massive certificate overhead. WTP (Wireless Transaction Protocol) replaces TCP. Finally, WSP (Wireless Session Protocol) replaces HTTP, handling session management and binary encoding.

The most critical architectural departure is WTP replacing TCP. TCP is a connection-oriented protocol requiring a heavy three-way handshake (SYN, SYN-ACK, ACK). Simply establishing the connection requires 1.5 Round-Trip Times (RTTs). On a 2G network with 1000ms latency, the user waits three seconds before a single byte of actual data is requested, draining battery power immensely.

WTP abandons this in favor of a transaction-oriented, Request-Reply model. WTP does not establish a connection beforehand. It embeds the actual data request (the URL) directly into the very first packet sent to the Gateway. This cuts the overhead from 3 RTTs to just 1 RTT. The server processes the request and replies immediately. This transaction model is fundamentally better suited to the bursty, high-latency nature of early cellular networks.

Explain the “WAP Gap” in the context of WTLS. Why was the translation process at the WAP Gateway a fundamental security vulnerability for end-to-end encryption?

The “WAP Gap” represents one of the most infamous architectural security flaws in the history of mobile networking. It stemmed directly from the necessity of the WAP Gateway translating between two incompatible protocol stacks.

The mobile device encrypted its air interface traffic using WTLS. However, standard Origin Servers on the public internet (like a bank’s web server) only understood standard TLS/SSL. They could not communicate directly. Therefore, when a user submitted a banking password over their phone, the data was encrypted via WTLS and sent to the telecom operator’s WAP Gateway.

Upon arrival, the WAP Gateway had to decrypt the WTLS payload entirely to translate the WSP request into standard HTTP. For a split second, the user’s password existed in pure plaintext in the RAM of the Gateway. The Gateway then immediately re-encrypted the data using TLS and forwarded it to the bank’s server.

This process completely obliterated the fundamental guarantee of End-to-End encryption. The security of the data was entirely dependent on the physical and network security of the telecom operator’s Gateway. If a rogue employee at the telecom company installed a memory scraper on the Gateway, or if a state-actor compromised the server, they could harvest millions of banking passwords in plaintext as they passed through the “gap,” despite the data being encrypted on the radio link and the internet backbone.

Describe the “Deck and Card” metaphor used in WML. Why was this structure specifically engineered to mask the high latency of early 2G networks?

Standard HTML architecture is fundamentally unsuited for high-latency networks because it dictates that a browser downloads one page at a time. Every time a user clicks a hyperlink, the browser drops the current page, initiates a new DNS lookup, establishes a new TCP connection, and downloads the new page. On an early 2G GSM network, a single click could incur a 10 to 15-second delay while the network struggled to resolve the request.

Wireless Markup Language (WML) bypassed this paralyzing latency by introducing the “Deck and Card” architectural metaphor. A single WML document delivered from the server is referred to as a “Deck.” This Deck contains multiple individual screens, referred to as “Cards.”

When a mobile user navigates to a URL, the WAP Gateway compiles and downloads the entire Deck over the slow cellular network in a single transaction. The phone renders the first Card on the screen. The crucial innovation occurs when the user clicks a navigation link on that Card. Instead of firing a new network request to the server, the WML browser simply drops the current Card and instantly renders the next Card which is already stored in the phone’s local RAM.

Navigating between Cards requires absolutely zero network transmission. To the user, the UI feels lightning-fast and responsive, entirely masking the underlying 10-second network latency by pre-fetching the entire navigation tree in a single burst.

Explain the purpose of the User Agent Profile (UAProf) in dynamically formatting WML content. How does Gateway caching reduce the signaling load on both the cellular network and the public internet?

The mobile hardware landscape in the WAP era was intensely fragmented. Hundreds of different phone models existed with wildly varying screen resolutions, color depths, memory limits, and hardware buttons. Delivering a single, static WML file to all of them would result in broken UI layouts.

The User Agent Profile (UAProf) solved this hardware fragmentation. UAProf is an XML-based schema that explicitly details the exact hardware capabilities of the specific mobile device requesting the data. When the mobile browser sends an HTTP GET request, it attaches its UAProf URL. The Origin Server downloads the profile, parses the screen size and color depth, and dynamically generates a bespoke WML Deck perfectly formatted for that exact device, ensuring optimal rendering and preventing the phone from downloading images it cannot display.

The WAP Gateway further optimizes the network by acting as a massive, aggressive cache. When a major news event occurs, thousands of mobile users might request the exact same WML news deck simultaneously. Instead of forwarding 1,000 identical requests across the internet backbone to the Origin Server, the Gateway queries the server once. It stores the compiled binary WML in its local memory. For the subsequent 999 requests, the Gateway serves the payload directly from its local cache. This drastically reduces the bandwidth load on the public internet, prevents the Origin Server from crashing, and responds to the mobile phones significantly faster, as the data only has to traverse the local cellular link.