Quick Reference - Latency                  Home : www.sharetechnote.com

 

 

Latency is a kind of Time Delay in data transmission between one point to another point. The Latency would vary depending on how to define the source of the data transmission and the destination (check point) of the data.

In Cellular communication, we measure roughly two different type of latency called C-Plane Latency and U-Plane Latency. These terms are defined in 3GPP documents as below.

 

3GPP TR 36.913 version 12.0.0 Release 12 - 7.2.1 C-plane latency states on C-Plane latency as below :

 

The overall C-Plane latency shall be significantly decreased compared to EPS Rel-8. The C-Plane latency takes into

account RAN and CN latencies (excluding the transfer latency on the S1 interface) in unloaded conditions.

The target for transition time from Idle mode (with IP address allocated) to Connected mode is less than 50 ms

including the establishment of the user plane (excluding the S1 transfer delay).

The target for the transition from a "dormant state" in Connected Mode (i.e. DRX substate in Connected Mode in

E-UTRAN) is less than 10 ms (excluding the DRX delay).

 

In reality, there can ve wide variations on this latency in real network. Refer to a sample cases that is described in the sequence below in this page.

 

3GPP TR 36.913 version 12.0.0 Release 12 - 7.2.2 U-Plane latency as below :

 

Advanced E-UTRA and Advanced E-UTRAN should allow for reduced U-plane latency compared to Release 8 EUTRA

and E-UTRAN, specifically in situations where:

- The UE does not have a valid scheduling assignment

- The UE needs to synchronise and obtain a scheduling assignment

The U-Plane latency is defined as the minimum achievable user plane latency with the system configurations optimized for latency

 

3GPP TR 25.913 version 9.0.0 Release 9 - 6.2.2 U-Plane Latency states as follows.

 

U-Plane Delay Definition U-plane delay is defined in terms of the one-way transit time between a packet being available at the IP layer in either the UE/RAN edge node and the availability of this packet at IP layer in the RAN edge node/UE. The RAN edge node is the node providing the RAN interface towards the core network.

Specifications shall enable an E-UTRA U-plane latency of less than 5 ms in unload condition (ie single user with single data stream) for small IP packet, e.g. 0 byte payload + IP headers E-UTRAN bandwidth mode may impact the experienced latency

 

To be honest, it is not so clear to me exactly what it mean by 'RAN edge node/UE' indicates. I assume that it is around S1 or X2 interface of eNB. If we go further than that, it would be very difficult to meet the value of '5 ms'. If my assumption is correct, the data path in U-Plane latency definition would be like  (4) <--> (5) <--> (3) <--> (6) <--> (7) <--> (8) <--> (9) <--> (14) <--> (13) <--> (12) <--> (11) <--> (10) of Figure 2 . However, in reality this end point would not always open to everybody for the testing.  In most testing in real network or even in test lab in network operator, it is highly likely that the end point will be over ePDG. In that case, the data path would be like (4) <--> (5) <--> (3) <--> (6) <--> (7) <--> (8) <--> (9) <--> (14) <--> (13) <--> (12) <--> (11) <--> (10) <--> (37) <--> (36) <--> (35) <--> (34) <--> (33) <--> (42) <--> (41) <--> (40) <--> (39) <--> (38) <--> (43) <--> (44) <--> (45) <--> (46) <--> (47)<--> (48) <--> (49)' of Figure 2. If you do with simple ping turn around time, the number will be much greater than 5ms. In case you use the test equipment, it is highly likely that you will see shorter turn around time, but the value would vary widely depending on the implementation of the equipment. One example of test equipment data path is shown in Figure 3. You would see much simpler structure in test equipment comparing to real network, but even in such a simple structure. It would be hardly the case when you see 5 ms latency.

 

As far as I experience, we tend to see much wider variations in U plane latency comparing to C-plane latency. Also, it is not so easy to correctly measure the U-Plane latency. Most commonly used method for U-Plane measurement would be 'ping test'. But in ping test, I have never got such a short latency like 5 ms even with the test equipment. Test equipment would be a kind of ideal condition that would give the best performance since data server is directly connected to the test equipment and there is no intermediate hops (like routers and physical PGW/SGW). The smallest value as Ping turnaround time is around 11 ms which can be interpreted as around 5~6 ms one way latency as mentioned in Ping Test in LTE - Test Equipment.  In the lab test in carrier lab which may get real PGW/SGW and some remote server involved, the ping turnaround time would reach around 20~50 ms even in good condition. In live network test, the value get easily extended to over 50 ms and even 100 ms.

 

As far as I am aware, all of these definition is still at the stage of TR(Technical Report) and not fixed as TS (Technical Specification) yet. So you may take this as a reference. I also did some test on this long time ago both in test equipment environment and live network. and I saw pretty wide variation of the result depending on network condition and signaling variation (for example, in some network I saw some message (e.g, RRC Connection Reconfiguration + NAS is splitted into multiple segment and conveyed to UE through multiple PDSCH. Also, some network always go through Security Mode Command process for every RRC session but some network may skip this).

 

Following is the sequence of transactions that would give you rough estimation of C-Plane Latency but the detailed value would vary with network configuration and resource allocation during the communication, but I hope this can give you some insight on what are major factors affecting the latency.

Step

Direction

Message

Memo

1 UE <--> SS < Idle Mode >  
2 UE ---> SS

PRACH

3~12 ms :

Refer to the section Exactly when and where Network transmit RACH Response of RACH page

 

< NW >

PHY_PRACH_IND
 

< NW >

MAC_DATA_IND
3 UE <--- SS

RACH Response

 

< NW >

MAC_DATA_REQ
 

< NW >

PHY_PRACH_REQ
 

< NW >

PHY_PRACH_IND
 

< NW >

MAC_DATA_IND  
 

< NW >

RLC_DATA_IND  
4 UE ---> SS

RRC Connection Request

 
 

< UE >

UE MAC start mac-ContentionResolutionTimer

 
5 UE <--- SS ACK (PHICH)  
6 UE <--- SS Contention Resolution

Greater than 15 ms.

Exact time depends on CR Timer and RRC Delay. Also additional delay happens due to HARQ/SR/Grant process

Refer to RACH Procedure on Initial Registration of RACH page

 

< UE >

UE MAC stop mac-ContentionResolutionTimer

 

< NW >

MAC_DATA_REQ
 

< NW >

PHY_PRACH_REQ
7 UE <--- SS

RRC Connection Setup

 

< NW >

RLC_DATA_REQ
 

< NW >

MAC_DATA_REQ
 

< NW >

PHY_DATA_REQ
8 UE ---> SS ACK (PUCCH)
9 UE ---> SS Scheduling Request(PUCCH)
10 UE <--- SS UL Grant (DCI 0, PDCCH)
 

< NW >

PHY_DATA_IND
 

< NW >

MAC_DATA_IND
 

< NW >

RLC_DATA_IND
 

< NW >

PDCP_DATA_IND
11 UE ---> SS

RRC Connection Setup Complete

+ Attach Requeset

+ (PDN Conn Request)

12 UE <--- SS ACK(PHICH)
13 UE <--- SS RLC ACK
14 UE <--- SS

RRC Security Mode Command

Around 30 ms
 

< NW >

PDCP_DATA_REQ
 

< NW >

RLC_DATA_REQ
 

< NW >

MAC_DATA_REQ
 

< NW >

PHY_DATA_REQ
15 UE ---> SS ACK (PUCCH)
16 UE ---> SS Scheduling Request(PUCCH)
17 UE <--- SS UL Grant (DCI 0, PDCCH)
 

< NW >

PHY_DATA_IND
 

< NW >

MAC_DATA_IND
18 UE ---> SS RLC ACK
19 UE ---> SS Scheduling Request(PUCCH)
20 UE <--- SS UL Grant (DCI 0, PDCCH)
 

< NW >

PHY_DATA_IND
 

< NW >

MAC_DATA_IND
 

< NW >

RLC_DATA_IND
 

< NW >

PDCP_DATA_IND
21 UE ---> SS

RRC Security Mode Complete

22 UE ---> SS ACK (PHICH)
23 UE <--- SS RLC ACK
 

< NW >

MAC_DATA_REQ  
 

< NW >

PHY_DATA_REQ  
24   < Many other message can be added here depending on NW >  

25

UE <--- SS

RRC Connection Reconfiguration

+ Attach Accept

+ Activate Default EPS Bearer Context Request

Around 20 ms

 

< NW >

PDCP_DATA_REQ
 

< NW >

RLC_DATA_REQ
 

< NW >

MAC_DATA_REQ
 

< NW >

PHY_DATA_REQ
26 UE ---> SS ACK (PUCCH)
27 UE ---> SS Scheduling Request(PUCCH)
28 UE <--- SS UL Grant (DCI 0, PDCCH)
 

< NW >

PHY_DATA_IND
 

< NW >

MAC_DATA_IND
29 UE ---> SS RLC ACK
 

< NW >

PHY_DATA_IND
 

< NW >

MAC_DATA_IND
 

< NW >

RLC_DATA_IND
 

< NW >

PDCP_DATA_IND
30 UE ---> SS

RRC Connection Reconfiguration Complete

+ Attach Complete

+ Activate Default EPS Bearer Context Accept

31 UE <--- SS ACK (PHICH)
32 UE <--- SS RLC ACK
 

< NW >

MAC_DATA_REQ  
 

< NW >

PHY_DATA_REQ  
33   < IP Data Traffic if needed >  

 

 

Reference :

 

[1] Why Latency Matters (YouTube) - O3b Networks