Part #4: This article is part of a series of blogs on 5G network slicing and slice management.
E2E Network Slicing spans from a set of devices to applications going through access network, transport, edge & core. While 3GPP has started to specify core network slicing and some principals for E2E with NSSAI identifier in the device, and management stack for slice management, it is still not clear how slicing will be performed with open standard APIs across multi-vendor disaggregated RAN.
As discussed in previous blogs Network Slicing is a concept that is generating lots of expectations with 5G networks to optimize network resources but more importantly also offer new business opportunities by selling granular customized E2E virtual network capabilities to enterprise, 3rd party operators or service providers, government entities and industry verticals.
In terms of access network, it is quite clear that one of the benefits of 5G is to offer a common core for heterogeneous access. This would include cellular with 4G and 5G, but also Wifi, fixed line, broadband and cable typically as described in blog #1 [2]. Which implies that any of these access network should provide a standard mechanism to define and operate network slices, with open APIs to support multi-vendor disaggregated virtualized distributed dynamic access network environments that optimize resources between devices and access network capabilities.
Let’s start with the RAN topology. First there are different types of 5G cellular base stations: macro cells, small cells, indoors, outdoors, point to point mmwave, beamforming multipoints, etc. Also there are different types of antennas … 1. SISO (Single Input Single Output) 2. SIMO (Single Input Multiple Output) 3. MISO (Multiple Input Single Output) 4. MIMO (Multiple Input Multiple Output). Antennas, particularly passive antennas, have RRH (Remote Radio Head) attached to the radio that would perform all RF functionality, such as the transmit and receive functions, filtering, and amplification but also some monitoring and control functions and connect to the baseband unit (BBU) digital that processes digital signal back and forth between the RRH-Antenna entity and the core network. Nowadays some smart antennas do not need RRH anymore. They imbed signal processing algorithm to determine direction of signal for beam optimization whether it is switched beam antennas (fixed set of beams) or adaptive array antenna where the beam is steering to target direction while nulling interferences. These antennas connect directly to DU (Distributed Unit) and CU (Central Unit). Different frequency bands can also be supported with single band or multi-band antennas. Ultimately software defined artificial intelligence for air interface should enable to change programmatically numerology and adapt antenna parameters based on the device, use case and environment metrics … more work for 6G! These antennas connect directly to DU (Distributed Unit) and CU (Central Unit). A DU can support multiple antennas, so multiple RUs and a CU supports multiple DUs. More and more RAN are virtualized, meaning CU and DU software are provided by vendors as VNF (Virtual Network Functions). Moreover some resources may be shared across operators. Typically RAN sharing is more and more popular especially for public venues.
In summary we have a multi-vendor, multi RAT, multi operator, more and more virtualized environment that should enable some level of RAN slicing.
Figure 1: 5G RAN environments
If we look into the above diagram and consider operator #1. Let’s say this operator wants to start with some basic 3 slices:
- Slice #1 for Fixed Wireless Access
- Slice #2 for mobile broadband outdoor + indoor venues
- Slice #3 for IoT
- Slice #4 for mission critical general alert broadcast
We assume he has defined 5G core slices for these 3 slices. Now for the RAN slicing:
- Slice #1 would define a RAN subnet slice with CUs, DUs, Smart Macro 28HGz band in the locations where FWA is deployed and associated FWA cells – as well as the links between these different entities with a given bandwidth in line with the topology and traffic planning.
- Slice #2 would define another RAN subnet slice with all CUs & DUs associated to all passive antenna, macro cells and small cells with frequency bands 800MHz, 2.6GHz, 3.5GHz – as well as the links in between these different entities with a given bandwidth in line with the topology and traffic planning.
- Slice #3 would define an IoT RAN subnet slice which would focus on LTE-M and embrace CUs, DUs and radio resources with frequency band 800MHz support and the LTE-M 1.4MHz 6 PRBs (Physical resource block) for IoT. Plus all the links between antenna, DU, CU and core with proper bandwidth.
- Finally Slice #4 would define a V2X slice including the 5.9GHz road side units, transport layer and virtual links to connect these entities and associated resources in terms of DU-CUs.
Figure 2: RAN Slices example
More specifically when composing the RAN subnet slices, network resources should carefully be taken into account as well, making sure the RAN resources, radio, DUs and CU-UP / CU-CP are properly stitched and associated to the subnet slices.
Figure 3: RAN Subnet Slice including Fronthaul, Midhaul, Backhaul
Generally DU and CUs would be closer to the antenna than to the core, in edge sites or aggregation sites, small data centers with virtualized infrastructure including some high performance compute resources, managed by the back end NFV management stack.
So now, how do we deploy and manage this RAN slicing!
First we need to understand the infrastructure available and the components to deploy. Typically the sites, RAN sites, MEC-aggregation sites, transport network between the sites: their location, infrastructure available on site in terms of HW and NFVI (NFV Infrastructure). Then understand which RAN split options different RAN vendor support and which level of virtualization they provide knowing that 3GPP specifies Split 2 [5], Small Cell Forum Split 6 [6] and ORAN Split 7 [7] unlike LTE which was generally Option 8 split. However with 5G antenna multi MIMO and large amount of ports, given a need of 491Mbps per 10MHz and antenna port, the bandwidth that would be required in the 5G fronthaul with option 8 and multiple ports is quickly becoming impossible …
This clearly drives the split options to higher layer levels to reduce the need for bandwidth and low latency. However going to high level split reduces the opportunity to centralize some functions. So an optimization needs to be engineered when deploying 5G RAN depending on the use cases, the antennas being used, the link capacities in the fronthaul, the infrastructure available and location of Point of Presence (PoP). This will determine the scenarios for deployment of the RAN with split option, DUs and CUs VNF placement, the RAN information model but also the open APIs that may be available from vendors to configure and monitor different RAN parameters.
Figure 4: 5G RAN Split Options
Then we need to understand the number of interfaces, connection points each of these RAN entities will have with virtual links and the specifics of these virtual links in terms of bandwidth and latency depending on the traffic being carried, whether it is control plane, user plane, uplink or downlink, or management plane information such as configuration, fault or performance data.
Some other elements may be available such as network switches for instance.
Figure 5: modeling 5G RAN simplified view example
This modeling will drive the 5G RAN information model that will be used as a baseline to deploy the different instances and maintain a dynamic model of the 5G RAN topology. Then the slicing information model with the hierarchy of customer service – network slice – subnetwork slice with network services, PNF, VNF and Links – will interact with this 5G RAN information model to associate some 5G RAN resources to subnet slices / network slices / customer services.
Figure 6: information modeling 5G RAN
Based on the slicing model being used, the services being sold and the way operator want to deploy, place and allocate their resources, Antennas, RUs, DUs and CUs could be shared or dedicated to a slice. CU-UP instances could typically be dedicated to given slice as described in Fig 3. While CU-Cs and DUs could be shared. However if some dedicated antennas for instance are deployed for IoT, it could be that the entire set of RU-DUs and CUs that control those antennas are dedicated to that IoT slice. Similarly for a V2X service, if specific antennas are deployed on RSU (Road Side Units) with DUs and CUs on a MEC site to meet the < 1ms latency, all these antennas/RU-DUs/CUs could be dedicated to a V2X slice. On the opposite when antennas support both eMBB and LTE-M for instance, the antennas, the RU-DUs and CU-Cs are shared among eMBB slices and IoT slices. Then based on the QoS, different flows will be assigned to different DRB (Data Resource Block) by the SDAP (Service Data Adaptation Protocol) layer in the CU-UP of the NG RAN [8].
Fig 7 – Slice / QoS Flow / DRB mapping
In some cases if the antennas are close to a Core data center (ex < 10km) and do not serve services requiring uRRLC, DUs and CUs could be placed in the core data center. Then for enterprise MEC with local antennas on site, DUs and CUs could be on site or on aggregation/public MEC sites, depending on the local infrastructure capacity and the latency required on the enterprise services.
Fig 8: 5G RAN subnet slices deployment models
As illustrated in Fig 8, depending on the services being offered, placement of the different functions may vary. Some antennas may be deployed in public areas or in enterprise, for instance small cells; then traffic may flow to the core or break-out at the edge, in public domain or in an enterprise. If low latency is required, or operator want to process traffic at the edge, DUs and sometimes CUs may be deployed at the edge or in the enterprise itself. These policies are defined when defining the E2E service and associating that service to an E2E slice, which in turn will define a RAN subnet slice with certain policies.
In summary there are many options deploying 5G RAN, they are multiple ways to architecture the RAN, different split options, different open APIs between 3GPP, SmallCellForum and ORAN. And there is no standard way to define and deploy 5G RAN today. Which means that it is very much dependent on vendor implementations, APIs provided, and operator decisions on services to offer and way to deploy.
This requires a flexible rich slice management & orchestration system that will be able to cope with different underlying RAN and RAN controller systems, but also SDN networks, NFV MANO and vendor specific systems. Then overall environment is following the lifecycle of virtualized environment as discussed in previous blogs [2] [3] [4] with design – creation/instantiation – operation/monitoring – decommissioning.
References
[1] white Paper - 5G Network Slice configuration and service slice lifecycle management
[2] Blog #1 - 5G Network Slicing: the most promising 5G use case for digital infrastructure
[3] Blog #2 - 5G Network Slice Management and Orchestration
[4] Blog #3 - 5G: How many Slices? Few or many … that is the question
[5] 3GPP TS 38.300, NR; NR and NG-RAN Overall Description; Stage 2
[6] Small Cell Forum (SCF); nFAPI and 5G FAPI (functional application platform interface)
[7] ORAN Alliance: www.oran.org
[8] 3GPP TS 38.401; NG RAN; Architecture Description
[9] 3GPP TS 37.324; Service Data Adaptation Protocol (SDAP) specification
MP_odini
GreenG, sustainability, 5G, IoT, NFV, big Data, blockchain
