Latency Considerations in RAN Slicing
Truminds Software Systems
Global Presence - San Diego | Greater Boston | Gurgaon | Hyderabad | Bangalore
In pursuance of the effort to satisfy the latency requirements of 5G services, an operator must ensure that the physical locations of the User plane function (UPF) or other Edge computing?functions are close enough to the user. This can potentially put a strict limit on the degree to which these computing/ storage?functions can be centralized. The benefits of distributed UPFs are realized when content (or service in case of hosted web-apps or compute) is also local. If user?traffic needs to traverse large distances on the internet,?then the latency benefit is lost. On the other hand,?- and in contrast to this,?there is an incentive to centralize functionality as much as possible in order to maximize benefits such as pooling gains. The ideal locations for functions to be placed in the network is therefore a compromise that each operator must evaluate for each slice/ service?and then ensure that these physical locations have the necessary transport and compute capability. In other words, the best compromise heavily depends on the slice SLA/ services being offered.?
Further, in the case of URLLC (Ultra Reliable Low Latency Communications) slices, the latency requirements are extremely stringent, and this places significant constraints not only on the distances?in?the front-haul network but also on the design, topology and components of the front-haul transport network itself. In such cases, a time-sensitive network (TSN) can help.?
Latency vs Pooling gains?
Network Physical Architecture: Bird's eye view?
It is instructive to start with a?view of the physical topology of the network as shown in the figure below.?
The table below provides some indicative values of the relative number of sites and of the indicative latencies involved.? (Source: NGMN overview on 5G RAN Functional Decomposition)
Table 1 Example latency figures for 5G RAN aggregation sites
For example, for every 1000 edge/local data center sites, there are only 100 aggregation data-center?sites. If a CU-UP and the UPF are housed in an edge?site, then 1000 edge sites will all have to run their own instance of that UPF. If the UPF?is moved into an aggregation DC?site, then only 100 instances of that UPF are required. This level of pooling benefit can save an operator considerable cost in running the UPF. However, the UPF can only be centralized so far as the latency budget is still met, plus other constraints such as transport capability too are satisfied. From an O-RAN components point of view, the obvious restriction is that the DU and CU-UP would not typically be more centralized than the UPF itself.?
From the latency values shown in the table above, we can see that for an URLLC slice, the UPF needs to be located at an edge-DC (or at the cell site itself).?As?for the eMBB (enhanced mobile broadband) service, it would be difficult to locate a 5G UPF in a core DC site as the service latency is probably too high. E.g., 16.4ms. However, for a 5G service with approximately 10ms latency requirement an operator will have to look very carefully at edge and aggregation DC?locations. While the edge DC has slightly better latency performance, the aggregation DC can provide significant cost benefits.?
In accordance with the discussion above, the figure below provides an example of how various services can be deployed in a hierarchy of data centers.
One significant point to note here is that with CU-CP/ CU-UP separation, the number,?capacity and locations?of CU-UPs needed can be independent of those for the CU-CPs.?The figure below illustrates this concept.?Note that there is a dedicated CU-UP + UPF pair for each type of service (URLLC and eMBB). However, a single O-CU-CP is handling both services.
URLLC Slices: TSN for fronthaul?
Low latency is a cornerstone of the URLLC set of use cases and it is one of the primary differences between 5G and previous mobile generations. These latency requirements are hard to meet even if the CU-UP and UPF are located at the edge DC, especially considering?the fact that?edge-DCs are intended?to serve multiple cell towers/ Radio resource heads. The front-haul transport networks have a role to play here, as distance and latency are directly related and any network processing within the transport adds further delay along a route. Moreover, transport network technology needs to satisfy additional criteria if the overall solution is to be scalable and economical. Thus, it is important to consider this topic from a "fronthaul requirements" point of view as well as from a "converged network transport" point of view. The IEEE P802.1CM "time-sensitive networking for fronthaul " standard is relevant here as it helps us achieve both goals.
Fronthaul requirements?
The hybrid automatic repeat?request (HARQ) protocol?typically limits the fronthaul transmission delay to 100 μs (one way). With fiber-imposed latency at 5 μs/km, physics restricts fronthaul connectivity to 20 km or less. Because of these restrictions, fronthaul links to date have been point-to-point connections over dark fiber or wavelengths on fibers – regardless of whether the fronthaul protocol is CPRI or e-CPRI (enhanced- common public radio interface). Intermediate processing adds latency, particularly in switched and routed networks. The IEEE 802.1CM (TSN) standard specifies ways to reduce this fronthaul latency. It specifies an Ethernet bridged network for connecting radio equipment (RU functionality) to a remote controller (DU functionality). In this sense, the front haul network topology looks similar to any other bridged Ethernet network as shown below but with one important differentiator -- the switches below are 'TSN capable switches'.
Converged Network Transport
A?fully converged mobile network extends beyond fronthaul to include mid-haul and backhaul. A physical macro cell site may serve as a fronthaul location for small cell traffic, but also a mid-haul/backhaul location for other cells/ nodes. TSN for Fronthaul-equipped switches supports a unified network architecture that can accommodate traffic from all segments - including non-3GPP traffic. Using TSN for Fronthaul, time-sensitive traffic can be transported in the same packet network as non-time-sensitive traffic without being negatively affected.
Transport profiles in TSN for Fronthaul?
领英推荐
The IEEE 802.1CM standard seeks to reduce latency for the aggregation and switching portions of the fronthaul network. Latency in aggregation is significant because, at an aggregation node, frames may contend for the same port at the same time, leading to buffering (delay) as well as delay variation.?
The standard specifies two transport profiles, both of which apply to CPRI and e-CPRI protocols. Profile A sends user data?as a high priority class above control and management data. Profile B includes components of Profile A but also adds a TSN feature called “frame preemption”?to prioritize different traffic types.
TSN Profile A vs Profile B
Table 2 TSN profile A and profile B comparison
As mentioned in the table above, the key differences are:
While frame preemption (Profile B) provides performance gains through bounded latency, it does require more sophisticated network equipment, which is why the IEEE standard positions Profile A as the simpler option of the two. The real value of frame preemption is its ability to deliver a bounded latency, which cannot be guaranteed with prioritization alone.
Summary?
A bunch of exciting technologies are available (and continuing to evolve) in the 5G world to help operators meet the latency related challenges while still reaping the benefits of pooling gains whenever possible. Disaggregation of the RAN into O-DU, O-CU-CP and O-CU-UP provides a lot of flexibility in this regard. From a transport point of view, TSN can be a game-changer for the front-haul as well as for the converged transport in general.
References
[1]??? NGMN overview on 5G RAN functional decomposition.
[2]??? Samsung Technical White Paper: “Network Slicing”
[3]??? O-RAN WG9 publication “Xhaul Packet Switched Architectures and solutions”
[4]??? NGMN Overview on 5G-RAN functional decomposition
[5]??? IEEE P802.1CM (TSN for fronthaul)
Link to RAN slicing - Why is it needed and how can it be leveraged? (Part 1)
Link to Network Slicing Architecture and the Non-RT RIC (Part 2)
Link to Slicing the RAN: Architecture, roles and responsibilities (Part 3)
Articulated by Venkatesh Potdar, AVP Engineering at Truminds.....