Is the RAN MAC scheduler the major bottleneck in E2E 5G slicing?

Network slicing has repeatedly emerged as a key business-enabling feature of 5G technology. The 5G network can be rightly seen as an enabling platform for the industrial internet, exposing the APIs for the diverse service providers/develpers.

The main idea of the article is that the performance of the RAN (Radio Access Network) MAC scheduler, which responsible for radio spectrum schedule, is a crucial influencer on end-to-end (E2E) slicing.

What E2E slicing is exactly?

Network slicing is a network architecture that enables the multiplexing of virtualized and independent(isolated) logical networks on the same physical infrastructure. Each slice is an isolated and tailored to fulfill the diverse requirements of a particular application.

The key concepts here are 'logical' and 'isolated.' This is similar to the VLAN concept, where the VLAN Identifier in VLANs and S-NSSAI (Single Network Slice Selection Assistance Information) in network slicing are used for traffic tagging and routing decision-making. This concept also finds its analogy in the RAN MOCN (Multiple Operator Core Network) sharing concept.

Why are these concepts crucial for understanding network slicing?

Operations at the logical layer enable flexibility to tailor different architectures to meet services SLAs from a technological feasibility perspective.

The isolation allows the assignment of the required resources on the shared underlying layers (server CPU/memory, transport channels throughput, radio spectrum). The isolation ensures that each slice operates independently of the others, providing the required performance and reliability as per its SLA. Without the isolation, different network services could interfere with each other, leading to degraded performance and failure to meet SLAs.

The availability of resources defines the network bottleneck, and it's especially actual in the context of network slicing. Every new slice brings additional load

Let's further review the network slicing architecture to define the most likely resources bottleneck

Basic architecture of end-to-end slicing

The slicing realization will be most beneficial with an end-to-end deployment approach, where the RAN is identified as a potential bottleneck. Generally speaking there are nothing new, RAN has historically been a capacity-constrained element in wireless networks.

Network slicing concept just itroduces a new layer of complexity to the operation of the Radio Access Network (RAN), Especially in the scarce spectrum resources allocation

Let's look at the basic architecture of E2E slicing based on O-RAN

?Each domain resource orchestration is divided into RAN, TN, and Core domains. Each domain resource orchestration is implemented in existing technologies or products (ETSI NFV-MANO, Near-Real-Time RIC, Non-Real-time RIC, NSSMF, etc.).

The main 3GPP enablers are network slice selection assistant information? (NSSAI) and data network name?(DNN). During attach and session requests, single-NSSAI and DNN allocate the NF instances that will serve the user.

5GC and Transport domains

The slicing implementation on the 5G Core (5GC) domain is natively supported by design, leveraging the Service-Oriented Architecture (SOA) and Virtual Network Functions (VNFs) concepts.

In the 5GC domain, the underlying physical layer (NFVI) is usually not expected to pose complex problems if NFVI utilization is maintained at least at the mid level.

In other words, you generally do not bother about efficiency in NFVI resource utilization. If you need additional capacity in the cluster, you can simply follow the old approach of 'throwing resources at a problem' to enable dynamic scaling based on network demand. It is a matter of defining the right capacity management procedure.

In the transport domain, the situation is generally the same because optical networks provide enormous capacity and scalability today. This conclusion was drawn with the premise that operators invest in upgrading fronthaul, backhaul, and backbone infrastructure to launch the 5G network.

?The above statements are oversimplified intentionally to focus on the main topic of the article

What is the slicing on RAN domain?

From a RAN perspective, E2E network slicing provides further means for allocating and prioritizing the limited RAN resources (both radio spectrum and hardware resources) to support SLA fulfillment.

? gNB splitting

In the 5GC domain the slicing leverages the Service-Oriented Architecture and the RAN domain also has been decomposed ?from monolith to module architecture. It brings the possibility to instantiate the isolated entities for planned slices.

NG-RAN – the RAN for 5G – supports splitting a gNB into two parts: a centralized unit (CU) and one or more distributed units (DUs). The gNB-CU can be further split into two parts: a control plane (CP) part and one or more user plane (UP) parts.

The logical gNB-CU hosts the Non-RT protocols ( PDCP/RLC) and gNB-DU host the RT protocols(MAC/PHY) that are slice aware and execute slice specific resource allocation and isolation strategies Need to mention that there are more splitting options but for the article purpose it is enough.

?

Let's look at this functional split from network slicing perspective

?

A Network Slice Instance (NSI) is a managed entity with a independent lifecycle. eMBB, URLLC, and mMTC services in 5G are typically realized as NSI(s)

gNB-CU(Non-RT). HW resources

Following the Cloud-RAN paradim the gNB-CU are fully virtualized and deployed on the regional/EDGE DCs. This is low complexity task now to deploy the composition of isolated gNB-CUs instances to meet the slicing requirement but but it is labor intensive on the slicing early stage.

The underlying physical layer resources allocation is similar to 5GC domain and capacity management approach is also the same: 'throwing resources at a problem' to enables dynamic scaling based on network demand

gNB-DU(RT). HW and spectrum resources

The gNB-DU can be also virtualized withn ability to deploy logical entities.

We are at the point now where the slicing concept on the RAN domain is relayed on the common radio spectrum resources. As a MAC entity in the 5G NR system, the scheduler is the key player here.

In contrast to hardware, there are no simple ways to add new spectrum on demand

In this case, we are confronted with an optimization task that is far more complex than linear capacity expansion. To make it worse, the radio resources are not deterministic.

What is the optimization task?

Owing to the trade-off among latency, reliability and spectral efficiency, sharing of radio resources between eMBB and uRLLC slices , heads to a challenging scheduling dilemma

Service-aware MAC scheduler assigns specific scheduling weights based on a standardized 5G QoS Identifier (5QI) and NSSAI to provide different special treatments required by services SLA. The treatment is the allocation of required frequency resources in the granularity of resource blocks (RBG) every Transmission Time Interval (TTI) among registered UEs across slices.

Abstracting from details, MAC scheduler treats the network slicing as more granular QoS

It is the solution for legacy networks limitation where Qos differentiation can distinguish between different? types of traffic but cannot distinguish and differentially? treat the same type of traffic coming from different? sources.? QoS differentiation does not have the ability to perform E2E traffic isolation.

The composition of network slicing and QoS is able to discriminate between the same? types of traffic coming from different tenants/slices.

?

What is mitigation strategy?

There are two main touchpoints in the lifecycle to mitigate the MAC scheduler risks:

1. The decision on the solution on the bidding phase;

2. The spectrum policy allocation desicion on the planning phase.

Network slicing means the emergence of diverse services that is impossible to predict in the bidding phase. You need the openness and flexibility to be ready to cope with the future demands. You need the RAN programmability

Putting myself in charge of the network planning, I seek more control over the MAC scheduler compared to the current LTE system, which relies solely on pre-optimized settings from a single vendor. This approach fails to meet the diverse and rapidly evolving needs of the emerging NaaS business model.

I prefer solutions where RAN functionalities on gNB-DU and gNB-CU are open, providing the ability to run xApps that adjust MAC scheduler parameters in close alignment with the local context. For instance, some xApp developers might specialize in a scheduler for eMBB service, while others excel in scheduling for URLLC service.

The nature of scheduling aligns well with AI-based xApps. I favor a solution that allows for additional training of AI models on local data. The major players RAN portfolios include now an intent-based AI/ML-enabled automation platforms, open and highly flexible to scale.

In the ideal case I will seek the opportunity to get the MAC scheduler with the predictive capability to forecast future network demands and adjust scheduling accordingly

?

O-RAN Slicing Reference Architecture (ETSI NFV-MANO based example)

?The RIC (RAN Intelligent Controller) is an AI-based intelligent function. To construct AI/ML models for deployment in the Near-RT RIC, the Non-RT RIC retrieves slice-specific performance metrics, configuration parameters, and required attributes of the RAN slice subnets from the SMO framework. The output of these algorithms can lead to non-real-time optimization of the slice-specific parameters of Near-RT RIC, O-CU, and O-DU.

The Near-RT RIC is the component that communicates the necessary parameters to O-CU and O-DU, executing the slicing-related xApps, e.g., applying MAC scheduler policies

?

In the planning phase, the primary strategy for SLA assurance is the degree of hard radio spectrum allocation and demand control via admission control to the SLA-critical slice

?For example, URLLC services require a reliable channel propagation environment and a high probability of successful data transfer to satisfy real-time operations. In this case of local deployment, you define localized, stringent radio spectrum allocation settings to guarantee availability. Additionally, you can explicitly configure how the Network Slice Admission Control Function (NSACF) monitors and controls the number of registered UEs/PDU Sessions per S-NSSAI.

Conclusion

I hope that this article has provided some new insights into network slicing conceptand you will challenge the 5G network development projects

[1] WG1.Slicing-Architecture-R003-v11.00. O-RAN (2023).

[2] 5G. Management and orchestration; ETSI TS 128 100 V17.0.0 (2022-05)

[3] Study on Network Slice Capability Exposure for Application Layer Enablement, Release 18; GPP TR 23.700-99 (2022 09).