Latency for Real-Time Machine-to-Machine Communication in LTE-Based System Architecture Navid Nikaein and Srdjan Krco Achieving LOw-LAtency in Wireless Communications (www.ict-lola.eu) FP7 ICT Objective 1.1 The Network of the Future The research leading to these results has received funding from the European Community's Seventh Framework Programme under grant agreement n 248993. 1
Notions on Latency Control Plane : the time taken by the first packet to successfully reach the receiver reference point In LTE/LTE-A: transition time between ECM (EPS Connection Management) IDLE to CONNECTED Data Plane (transport delay): one-way transit time between a packet being available at the IP layer of the sender and the availability of this packet at the IP layer of the receiver In LTE/LTE-A: delay between UE and EPC edge nodes (S/PGW) 3
LTE-Based M2M System Architecture 4
M2M components and latency M2M Capillary Smart devices and gateways, a range of short or wide range communication technologies reusable across a number of application domains Latency application processing, transferring and gateway/ue access delays M2M Access Connecting M2M devices with M2M services Latency depend on the UE state: LTE IDLE, LTE ACTIVE, RRC IDLE, RRC CONNECTED Delay highest during the UE power-up (LTE IDLE LTE ACTIVE), 0 if in the LTE ACTIVE state u-plane latency: depends on scheduling policy, buffering and processing, TTI and frame alignment, number of retransmissions, and IP access delays 5
M2M components and latency M2M Core Providing interconnectivity and extendable by relevant M2M services (registry, request analyzer, control), 3rd party services (e.g. location, charging, processing of data) and LTE services (e.g. AAA, IMS) Latency Interconnection between M2M devices/gw and servers/users via IP backbone or IP Packet exchange (IPX), delay depends on the region as well as the number of nodes in the network, and processing delays in the nodes M2M Application Including domain specific processing and visualization of information, and the end user applications interacting with the smart devices through a common platform Latency M2M service enabler delay influenced by service publishing and lookup, increases with the number of devices registered in the system Application server processing delays are in the order of a few milliseconds and may increase with the number of M2M devices and users connected to the application server
Auto-pilot for ITS Scenario M2M Capillary : 4.5 25 ms M2M Access : 57 378 ms M2M core : 15 150 ms M2M Application : 1 3 ms 7
Autopilot Traffic Characteristics Keep-alive periodic low data rate messages (GPS, speed, time) from M2M devices to the backend system (once per minute, in the order of 500B per message); Burst event-driven, high data rate emergency signals from M2M backend to M2M devices including warning and actuation commands (each burst in the order of 1-2kB). 8
Virtual Race for M2M Game M2M Capillary : 6 10 ms M2M Access : 112 748 ms M2M core : 42 122 ms M2M Application : Biker S-GW P-GW MME enodeb EPC Server Biker Biker enodeb enodeb S-GW P-GW MME Evolved Packet Core (EPC) Internet Gaming Server 9
Virtual Race Traffic Characteristics A periodic constant low data rate transmission between M2M devices shorter periods as the end of the race is getting closer (1kb packet with frequency 70-100 ms) 10
Smart Environment for AAL M2M Capillary : 9 54 ms M2M Access : 180 1290 ms M2M core : 15 150 ms M2M Application : 1 3 ms Femto-base station Backhaul link IP Network Local Command enter Location tracking Ground Sensor network UAV sensors 11
Smart Environment Traffic characteristics Event driven Low data rate burst of control messages amongst M2M devices and/or from M2M users; Event-driven High data rate burst of data amongst M2M devices/gateways and/or to M2M servers/users. 12
LTE-Based M2M System Architecture 13
Instead of conclusions The main bottleneck at the access layer procedures core network latency non-negligible either Bottlenecks vary depending on the applications DRX delay for the ON-OFF traffic model Handover and HARQ delays for home/mobility based scenarios Access and processing delays for high density scenarios Overall delay also depends on actual system/traffic load outage probability radio propagation conditions
BACKUP SLIDES 15
Latency Budget for M2M Capillary and Application Domain Latency Estimates Description 1-3ms Application processing and collecting delays - M2M gateway (1-3ms) - M2M device (1ms) 1-3 ms M2M device/gateway formatting and transferring delays 1.5-20ms 1ms M2M gateway access delay (e.g. Zigbee) UE terminal access delay (e.g. USB) Latency Estimates 15-150ms 300-500ms 1-3ms 15-150ms Description Network access delay through* - Internet (15-150ms) - IP exchange (42-122ms) Service enablers delay - Service publishing (300ms) - Service lookup (300-500ms) Application access/processing delay Network access delay through* - Internet (15-150ms) - IP exchange (42-122ms) 16
Latency Budget for M2M Access Domain Latency Estimates 0 77.5ms 0 28.5 ms 6ms 1-4ms 1-4ms 1.5ms 1.5-2.5ms 1-4ms Latency Element C-plane establishment delay - LTE idle to LTE active (47.5ms +2Ts1c*) - RRC idle to LTE active (37.5ms+2Ts1c*) - RRC connected to LTE active (13.5ms) - LTE active (0ms) *Ts1c (2-15ms) is the delay on S1 c-plane interface U-plane establishment delay - LTE idle to LTE active (13.5ms+Ts1u*) - RRC idle to LTE active (3.5ms+Ts1u*) - RRC connected to LTE active (3.5ms) - LTE active (0ms) *Ts1u (1-15ms) is the delay on S1 u-plane interface U-plane Scheduling delay (request and grant) U-plane UE processing delay U-plane (H/D)eNB/RN processing delay U-plane TTI and Frame alignments U-plane Retransmission 30%-50% for 5ms HARQ RRT U-Plane S/P-GW processing delay 1-2ms U-plane M2M core IP access delay (S/P-GW) 17
Latency Budget for M2M Access Domain Latency Estimates 10-512ms 5-150ms 12ms Description Length of DRX cycle - Short DRX cycle (10-320ms) - Long DRX cycle (10-512ms) U-plane data forwarding latency for handover from source to target enb: - (D)eNB/RN over the X2 interface (5ms) - HeNB/eNB over the Internet (15-150ms) C-plane radio layer processing (DL sync., UL resource request/grant, timing advance) 18
Possible Improvements Based on the knowledge of UL/DL activity requirements for an UE DRX delay can be significantly reduced through prudent selection of various DRX parameters Depending on the traffic pattern, a certain ontime can be set to keep the UE awake by scheduling it within a certain time window
Possible Improvements Handover delay increases noticeably in scenarios involving HeNB The worst case is handover between HeNBs Packet forwarding delay in a handover can be optimized Tight cooperation of the source and the destination (H)eNBs with the S/P-GW for both uplink and downlink traffic
Possible Improvements DRX retransmission timer defined UE does not have to wait for a full DRX cycle for an expected retransmission that has been lost UE wake up time can be considerably improved by sending multiple copies of the paging message to the UE
Conclusions Latency is becoming a key issue for network operators solutions to support new real-time M2M applications Significant latency improvements possible careful selection of various parameters and technologies Currently, LTE latency on the order of 10ms latency for the E- UTRAN in the ACTIVE state Core network adds a significant amount of delay depending on the region and the proximity of the server with respect to the access network serving the device It should be possible to attain 50ms end-to-end delay in many situations