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.

• C-Plane Latency
• U-Plane Latency
• C-Plane Latency Sequence
• Reference

C-Plane Latency

The control plane figure is the one with a hard target attached to it. 36.913 states that target as a transition time, and the sequence further down this page is one network working through that transition. The quotation below is the requirement itself.

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.

That requirement has not moved. The page quotes 36.913 v12.0.0, and clauses 7.2.1 and 7.2.2 of v19.0.0 carry the same words. Less than 50 ms from idle to connected, and less than 10 ms out of a dormant state, are still what the technical report asks for.

36.912 shows where the 50 ms goes. Its Annex B analyses the Release 8 procedure component by component, and its clause 16.2 repeats the analysis with the Release 10 improvements applied. The table below sets the two beside each other, in milliseconds.

Two things are worth reading off that table. The first is that the Release 8 procedure misses the target: 76 ms at best and 80 ms on average, against a requirement of less than 50. The second is where the saving comes from.

36.912 clause 10.1 names it. The RRC Connection Request and the NAS Service Request are combined, so the eNB and the MME work in parallel, and that saves about 20 ms. Components 11 to 14 are then absent from the total, because the NAS half finishes inside the time the RRC half takes. Two processing delays are trimmed as well, component 9 from 15 ms to 12 and component 17 from 20 ms to 16.

The rest is almost all node processing. The same clause puts it at around 75 percent of the idle to connected transition once the requests are combined. The five transmission components of that 50 ms add up to 5.5.

• The target has not changed : 36.913 v19.0.0 clauses 7.2.1 and 7.2.2 carry the same text the page quotes from v12.0.0.
• Release 8 did not reach it : 36.912 Annex B puts the same procedure at 76 ms at best and 80 ms on average.
• The saving is a parallel NAS exchange : 36.912 clause 10.1 combines the RRC Connection Request with the NAS Service Request and takes about 20 ms out.
• Most of the budget is processing : the same clause puts it at around 75 percent, and the five transmission components come to 5.5 ms.
• The S1-C transfer sits outside the number : 36.912 leaves components 12 and 14 out of its total, and 36.913 excludes the S1 transfer delay from the requirement.

U-Plane Latency

The user plane figure has no procedure behind it. It is a one way transit time for a UE that already holds a grant, which makes it far easier to state than to measure. The two quotations below define it twice, once for LTE-Advanced and once as the original E-UTRA requirement.

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).

The question left open above has an answer in 36.912. Its clause B.2.1 works the FDD user plane latency out as a sum: 1.5 plus 1 plus 1.5, and then 8 ms for every HARQ retransmission. The report writes it as 4 plus 8n.

The three fixed terms say where the measurement points are. The 1 ms is the TTI. The two terms of 1.5 ms are fixed node processing, radio frame alignment included, one at each end of the radio link. The sum includes no term for S1, for a serving gateway, or for anything past the eNB. So the assumption above, that the RAN edge node sits at the S1 side of the eNB, is the one this arithmetic supports.

The same clause gives two worked values. At 0 percent HARQ block error the one way latency is 4 ms. At 10 percent, which the clause calls the more reasonable setting, it is 4.8 ms.

That changes how the ping figures above read. A turnaround of 11 ms is two one way transits plus whatever the far end adds. Half of it, the 5 to 6 ms the page derives, is within a fraction of the 4.8 ms the report predicts. The distance between 5 ms and the 50 ms of a live network is not the radio link. It is everything behind the radio link.

• The 5 ms is one way, not a round trip : 25.913 measures it from the IP layer in the UE to the IP layer in the RAN edge node.
• 36.912 puts the FDD figure at 4 ms : 1.5 ms of node processing, 1 ms of TTI, and 1.5 ms of node processing again, with no retransmission.
• A 10 percent block error rate makes it 4.8 ms : each HARQ retransmission adds 8 ms, and the clause weights that by the error probability of the first transmission.
• The sum stops at the eNB : it has no term for S1, the gateways or the server, which is why a ping never reaches the figure.
• A ping turnaround of 11 ms agrees with it : half of that is close to the 4.8 ms the report gives for 10 percent block error.

C-Plane Latency Sequence

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.

That sequence and the 36.912 budget describe one transition at two resolutions. The report counts seventeen components. The table above counts thirty-three transactions, because it shows the acknowledgements and the scheduling requests that the report folds into its processing terms.

The rough figures agree where they can be compared. The report allows 3 ms at minimum and 5 ms on average for preamble detection and the random access response. The table above marks step 2 as 3 to 12 ms for the same stretch.

Step 14 is the line worth pausing on. It is marked around 30 ms. In the report's flow the same message follows components 11 to 15: 4 ms of eNB processing, 15 ms in the MME, and 4 ms of eNB processing again. Twenty-three of that thirty is accounted for before either S1-C transfer is counted, and the report counts neither.

• The table records transactions and the report records components : thirty-three against seventeen, because the acknowledgements and scheduling requests live inside the report's processing terms.
• Step 2 agrees with the report : 3 to 12 ms for preamble to response, against 3 ms minimum and 5 ms average in 36.912.
• Step 14 is where the core network appears : 36.912 puts 4, 15 and 4 ms of processing before that message, and excludes the two S1-C transfers around them.
• The report compresses what the table separates : components 16 and 17 cover both messages in 1.5 ms, where steps 14 to 30 above carry them with acknowledgements between.

Reference

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

[2] TR 36.913 : 3GPP - Requirements for further advancements for E-UTRA, v19.0.0. Clause 7.2.1 gives the C-plane transition targets and clause 7.2.2 the U-plane definition, both unchanged from the version quoted above.

[3] TR 25.913 : 3GPP - Requirements for Evolved UTRA and Evolved UTRAN, v9.0.0. That is the latest version published, and it is the one quoted above.

[4] TR 36.912 : 3GPP - Feasibility study for further advancements for E-UTRA, v19.0.0. Annex B.1.1.1 gives the Release 8 C-plane budget, clause 16.2 the 50 ms version of it, clause 10.1 the combined request, and Annex B.2.1 the FDD user plane sum.