Selected Topics in Communication Networks Amr El Mougy amr.elmougy@guc.edu.eg C7.207

Mobile Networks

Mobile Technology Statistics

Migration to 3G

History Frequency reuse allows more users Handover as caller moves from cell to another

Frequency Allocation Examples

Medium Access in Mobile Networks Ex: 2G

Multi-Access Radio Technology

Architecture of Mobile Networks Radio Access Network is responsible for managing radio resources Directly controls the air interface Manages handovers Core network responsible for intra-network and inter-network routing Manages user accounts and locations

3G Architecture

HSDPA/HSUPA

4G Technology Specifications HSPA+ is still dominant because it achieves high rates without the cost of the parallel infrastructure LTE is rapidly penetrating the market

Architecture Comparison PSTN PDNs PDNs Core Network EPC CS domain PS domain GERAN UTRAN E-UTRAN

Trusted non 3GPP IP Access LTE Architecture GERAN SGSN GPRS Core UTRAN HSS eNode B S3 S6a Uu S1-C UE Uu S1-C MME PCRF X2 S11 Uu S1-U Gx UE S5 PDN-GW Uu S1-U eNode B S-GW SGi Trusted non 3GPP IP Access

MIMO Support Diversity for more reliable communications Multiplexing for higher data rates SDMA for higher cell capacity Beamforming for improved coverage

User Device Categories HSPA UE categories The user device is the second half of the picture UEs have different CPUs, storage capacity, memory, and radio capabilities The speed depends on the UE Operating 8x MIMO is similar to operating 8 radios  very high energy consumption LTE UE categories

Radio Resource Controller Controls all operations between UE and radio tower Is in full control of the operations of the UE’s radio (even determines its transmit power) RRC assigns dedicated resources to each UE, depending on its needs Contention only happens when requesting access Has a profound impact on latency, throughput, and battery life

Energy Efficiency: WiFi vs. RRC Device chooses the transmit power Somewhere between 30-200mW, depending on distance to AP Radio is active by default. Can go to sleep when idle Delivery traffic indication message (DTIM) sent in the beacon to notify the device that it should receive Saves energy at the expense of latency RRC chooses the transmit power Somewhere between 1000-3500 mW when transmitting!! UE can be instructed to go to sleep state by the RRC Paging messages can alter the state of the UE to high power More efficient when idle, much less efficient when transmitting

LTE RRC State Machine Idle: low power state (<15 mW). Listening only to control messages No network context, no assigned resources. Device cannot send or receive data Needs to synchronize with network, negotiate resources, and switch to active to start sending or receiving. Needs several roundtrips to synchronize (up to 100ms in LTE) Active: high power state (1000-3500mW). Established network context, allocated resources

LTE RRC State Machine Short discontinuous reception (DRX): established context but no allocated resources UE only listens to periodic broadcasts and sleeps in between. However, since context is maintained, transition to active is fast (up to 50ms in LTE) Long discontinuous reception (DRX): same as above, but the UE sleeps for longer intervals

LTE RRC State Machine One-way latency is 5ms in LTE Transitions from active to short to long DRX is through timers

HSPA(+) RRC State Machine Idle and DCH in RRC are almost identical to idle and active in LTE FACH is designed for delay-tolerant, non interactive applications Low rate data transfer can take place in this state Transition from DCH to FACH to idle is through timers Transition from FACH back to DCH is based on the amount of data in the buffer LTE is more power hungry, especially with many MIMO streams

The Problem of Periodic Transfers Consider the case of HSPA+, where the transition from DCH to FACH is after 10 sec of inactivity Now imagine an application that schedules a transfer every 11sec High energy waste, the radio remains in high energy state for most of the time, without transferring any data Best to burst as much data as you can, then go to sleep for as long as possible

Latency Due to Handovers Each tower covers a certain range. UEs have to be “handed over” to a new tower if they move This process takes up to hundreds of ms and may disrupt the application LTE does it in an energy-efficient way Every group of eNodeB’s form a logical tracking area If the UE is in idle mode and does a handover, there is no need to wake it up The eNodeB’s will manage the handover without informing the core Once the UE becomes active, the core is informed of the new location Problem: the core knows the tracking area of every UE all the time, but the actual tower only some of the time  latency for the sake of energy efficiency

Connectivity Issues Within a mobile network, the PGW assigns IP addresses to UEs Since IP addresses are scarce, the PGW may assign the same IP address to many devices (same as NAT) The differentiation is done using unique IDs within the network and port numbers PGW is also the connection termination point in the network When radio resources are torn down, this does not affect the TCP/UDP state Thus a TCP connection will remain open when the UE goes to idle state

Inbound vs. Outbound Packet Flow Initial latency maybe high if transition from idle to active Core latency is not guaranteed MME will be contacted to determine the tracking area All towers may send pages to find the UE

Where is the Bottleneck Only the air interface is guaranteed (state transition times and one-way latencies) Delay in the core is up to the carrier Every tower needs a fiber optic link to support the large number of users and high rates (10+ Mbps per user for a large number of users) Massive infrastructure cost

Optimizing Performance over Mobile Networks

Battery Power Radio is second highest consumer of energy Using radio at full power can drain battery life completely in a few hours Radio requirements keep increasing with newer mobile generations Energy consumption has a nonlinear relationship with data transfer Transmit more when the radio as active Extend idle times

Periodic Data Transfer The energy cost of a packet cannot be measured only by its size Polling, real-time analytics, measurement pings are expensive when done periodically  avoid at all cost Aggregate transfers, preferably to the time when the radio is already active Google cloud messaging (GCM) offers an API for servers that detects when a mobile is active Use push delivery whenever possible. However, periodic pushes can be just as harmful Ask yourself, is this transmission critical? Most of them aren’t!! Even real-time analytics often can be replaced with periodic logs that are transferred when radio is active

Keepalive Connections TCP and NAT connections have an independent termination lifetime from the radio The radio timeout (transition to idle) is typically much shorter (NAT timeouts can be anywhere between 5 – 30 mins) Thus, keepalive pings need to take much longer periods to avoid waking up the radio needlessly

End-to-End Delay Many roundtrips are typically required until you get a response for your HTTP request Best case scenario is when the radio is already active, DNS is already resolved, and previous TCP connection already exists and can be reused Otherwise, many additional roundtrips are required

End-to-End Delay Example: assume RTT = 100ms for LTE and RTT = 200ms for 3G You may need extra roundtrips to: Renegotiate context with control plane TCP handshake TLS handshake HTTP exchange

The Illusion of Instant Feedback Decouple UI feedback from network communications When a user submits a request that requires network communications, provide instant feedback from the UI and initiate the request in the background Latency cannot be controlled Smart UI design can make the application “seem” as if the network is fast

Adapt to Variable Availability of Resources Never assume that the network interface will be always available, even if a high quality initial connection is made Monitor network status continuously Use a set of set of strategies to recover from failures that include Retry attempts Backoff strategy (do not loop forever) Caching

Data Pre-Fetching Whenever possible, download data that may be needed in the future Ex: download entire music file for streaming ahead of time. Or download ads ahead of time to be displayed when needed This policy collides with another one: limiting data transfer on mobile connections Balance three constraints: Number of transferred bytes Impact on battery Variable air link quality Decide what are the primary goals of the application and plan accordingly