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 fromthe European Community's Seventh Framework Programme undergrant 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 :

Server

Internet

Gaming

Server

S-GW

P-GW

MME

Evolved Packet

Core (EPC)

eNodeB

eNodeB

Biker

S-GW

P-GW

MME

EPC

eNodeB

Biker

9

Biker

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

Ground Sensor

network

Backhaul link

Location tracking

UAV sensors

Femto-base station

Local Command enter

IP Network

Smart Environment for AAL

• M2M Capillary : 9 – 54 ms• M2M Access : 180 – 1290 ms• M2M core : 15 – 150 ms• M2M Application : 1 – 3 ms

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 M2M gateway access delay (e.g. Zigbee)

1ms UE terminal access delay (e.g. USB)

16

Latency Estimates Description

15-150ms Network access delay through*- Internet (15-150ms)

- IP eXchange (42-122ms)

300-500ms Service enablers delay- Service publishing (300ms)

- Service lookup (300-500ms)

1-3ms Application access/processing delay

15-150ms Network access delay through*- Internet (15-150ms)

- IP eXchange (42-122ms)

Latency Budget for M2M Access DomainLatency Estimates Latency Element

0 – 77.5ms

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

0 – 28.5 ms

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

6ms U-plane Scheduling delay (request and grant)

1-4ms U-plane UE processing delay

1-4ms U-plane (H/D)eNB/RN processing delay

1.5ms U-plane TTI and Frame alignments

1.5-2.5ms U-plane Retransmission 30%-50% for 5ms HARQ RRT

1-4ms 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 Description

10-512ms Length of DRX cycle

- Short DRX cycle (10-320ms)

- Long DRX cycle (10-512ms)

5-150ms 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)

12ms 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 on-time 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