Spectral efficiency is an important consideration for 5G-NR radios, as it was for 4G/LTE: The amount of information that fits in a given channel bandwidth or one just say how efficiently can that piece of spectrum be used to transmit information.
There is a hard limit to how much data can be transmitted in a given bandwidth – this limit is well-known as the Shannon-Hartley Theorem and commonly referred to as the Shannon limit.
Spectral efficiency is usually expressed as “bits per second per hertz,” or bits/s/Hz, defined as the net data rate in bits per second (bps) divided by the bandwidth in hertz. Net data rate and symbol rate are related to the raw data rate which includes the usable payload and all overhead.
raw data rate = Payload + Overhead
net data rate = raw data rate – overhead
Spectral efficiency = net data rate in bps / Channel Bandwidth in Hz
For example, a system uses channel bandwidth as 2 MHz and it can support a raw data rate of say 15 Mbps, assuming 2 Mbps as overhead then net date rate will be as 13 Mpbs, then its spectrum efficient can be calculated as follows:
Spectral efficiency= 13 x 10^6 / 2 x 10^6 = 6.5 bits/second/Hz
Calculating Spectral Efficiency for LTE:
An LTE system can support a maximum channel bandwidth as 20 MHz (Not including Carrier Aggregation). Its symbol rate can be calculated as
Symbols/Second = 1200 x 14 x 1000 = 16,800,000 Symbols/Second
Considering 64-QAM as highest modulation for downlink each symbol can carries 6 bits provide raw data rate as follows:
raw data rate = 16,800,000 x 6 = 100.8 Mbps (No MIMO considered)
Consider 4×4 MIMO: theoretically it makes raw data rates four times i.e. 400 Mbps. assuming 25 % as overhead the net data rate will be as 300 Mbps. Similarly data rate can be calculated for uplink . In a 1×1 LTE uplink there is no MIMO, so Max raw data can be 100 Mbps with 64-QAM support in Uplink and after deducted 25% overhead net data rate for uplink will be 75 Mbps. Uplink net date with 16-QAM will be 51 Mbps.
Downlink Spectral Efficiency = 300 x 10^6 bps / 20 x 10^6 Hz = 15 bits/second/Hz
5G New Radio is capable of providing a downlink throughput 2.31 Gbps and uplink throughput of 2.47 Gbps with certain configuration shown below assuming 100 MHz channel bandwidth. (Single carrier component)
Downlink Spectral Efficiency = 2.31 x 10^9 bps / 100 x 10^6 Hz = 23 bits/second/Hz
Uplink Spectral Efficiency = 2.47 x 10^9 bps / 100 x 10^6 Hz = 24 bits /second / Hz
Note: The values shown here are just theoretical value considering sensible baseline assumptions. Real-world network performance may differ.
For Further Information
For more information on Spectral Efficiency of 5G-NR radios,
CBSD devices using CBRS (Citizens Broadband Radio Service) is defined in the USA for Shared Spectrum Access in 4G Band 48 (5G Band n48) in the 3.5GHz spectrum, 3550 MHz to 3700 MHz.
CBRS can be implemented using 4G, 5G or proprietary technology wireless systems
What is a Citizens Broadband Radio Service Device?
As defined by the FCC, an eNodeB which is capable to support CBRS band is referred as Citizens Broadband Radio Service Device. LTE band B42 and B43 mapped to CBRS frequency spectrum. CBSD devices are categorized into two types:
CBSD-Category A
CBSD-Category B
CBSD-Category A :
Category A shall not be deployed or operated outdoors with antennas exceeding a height of 6 meters above average terrain
If it is deployed or operated outdoors with antennas exceeding 6 meters will be classified as, and subject to, the operational requirements of CBSD Category B
Category A base station is permitted Maximum EIRP of 30 dBm (dBm/10 MHz) or 1 Watt
When registering with a spectrum access system (SAS), Category A devices must transmit with their requested authorization status (Priority Access or General Authorized Access), FCC identification number, call sign, user contact information, air interface technology, unique manufacturer’s serial number, and sensing capabilities if supported
CBSD-Category B :
Category B base station is permitted Maximum EIRP of 47 dBm (dBm/10 MHz) or 50 Watt
Its deployment/operation is limited to outdoor and antenna height is expected more than 6 meter above the terrain
Category B base station must be professionally installed
When registering with an SAS, Category B devices must transmit with their requested authorization status (Priority Access or General Authorized Access), FCC identification number, call sign, user contact information, air interface technology, unique manufacturer’s serial number, sensing capabilities (if supported), plus the following additional information: antenna gain, beam-width, azimuth, down-tilt angle, and antenna height above ground level.
End User Device (EUD):
CBRS EUD permitted to Transmit Maximum Power 23dBm or 200 milliwatt
These Device can operate only if they can positively recieve and decode an authorization signal transmitted by CBSD (CBRS base station)
What is the RAN Intelligent Controller (RIC) used in Open RAN (ORAN) Networks?
History: from 2G to now
From the era of 2G and 3G, mobile architectures had specific controllers that were responsible for RAN orchestration and management. Then from 4G, overall network architecture became flatter and the expectation was that, to enable optimal subscriber experience, base stations would use the X2 interface to communicate with each other to handle resource allocation. This scenario created the proverbial vendor lock-in as different RAN vendors had their own flavor of X2, and it became difficult for an Operator/MNO to have more than one RAN vendor in a particular location. The O-RAN Alliance went back to the controller concept to enable best-of-breed Open RAN.
Open RAN Intelligent Controller (RIC) used in modern wireless networks
Why is RIC needed?
As many 5G experiences require low latency, 5G specifications like Control and User Plane Separation (CUPS), functional RAN splits and network slicing, require advanced RAN virtualization combined with SDN. This combination of virtualization (NFV and containers) and SDN is necessary to enable configuration, optimization and control of the RAN infrastructure at the edge before any aggregation points. This is how the RAN Intelligent Controller (RIC) for Open RAN was born – to enable eNB/gNB functionalities as X-Apps on northbound interfaces. Applications like mobility management, admission control, and interference management are available as apps on the controller, which enforces network policies via a southbound interface toward the radios. RIC provides advanced control functionality, which delivers increased efficiency and better radio resource management. These control functionalities leverage analytics and data-driven approaches including advanced ML/AI tools to improve resource management capabilities.
The separation of functionalities on southbound and northbound interfaces enables more efficient and cost-effective radio resource management for real-time and non-real-time functionalities as the RIC customizes network optimization for each network environment and use case.
Virtualization (NVF or containers) creates software app infrastructure and a cloud-native environment for RIC, and SDN enables those apps to orchestrate and manage networks to deliver network automation for ease of deployment.
Though originally RIC was defined for 5G OpenRAN only, the industry realizes that for network modernization scenarios with Open RAN, RIC needs to support 2G 3G 4G Open RAN in addition to 5G.
Source: O-RAN Alliance
Working group 1 looks after overall use cases and architecture across not only the architecture itself, but across all of the working groups.
Working group 2 is responsible for the Non-real-time RAN Intelligent Controller and A1 interface, with the primary goal that Non-RT RIC is to support non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing AI/ML models to near-RT RIC.
Working group 3 is responsible for the Near-real-time RIC and E2 interfaces, with the focus to define an architecture based on Near-Real-Time Radio Intelligent Controller (RIC), which enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface.
Working group 5 defines the Open F1/W1/E1/X2/Xn interfaces to provide fully operable, multi-vendor profile specifications that are compliant with 3GPP specifications.
The RAN Intelligent Controller consists of a Non-Real-time Controller (supporting tasks that require > 1s latency) and a Near-Real Time controller (latency of <1s). Non-RT functions include service and policy management, RAN analytics and model-training for the Near-RT RAN.
A Near Real-Time RAN Intelligent Controller (Near-RT RIC) is a near‐real‐time, micro‐service‐based software platform for hosting micro-service-based applications called xApps. They run on the near-RT RIC platform. The near-RT RIC software platform provides xApps cloud-based infrastructure for controlling a distributed collection of RAN infrastructure (eNB, gNB, CU, DU) in an area via the O-RAN Alliance’s E2 protocol (“southbound”). As part of this software infrastructure, it also provides “northbound” interfaces for operators: the A1 and O1 interfaces to the Non-RT RIC for the management and optimization of the RAN. The self-optimization is responsible for necessary optimization-related tasks across different RANs, utilizing available RAN data from all RAN types (macros, Massive MIMO, small cells). This improves user experience and increases network resource utilization, key for consistent experience on data-intensive 5G networks.
Source: O-RAN Alliance
The Near-RT RIC leverages embedded intelligence and is responsible for per-UE controlled load-balancing, RB management, interference detection and mitigation. This provides QoS management, connectivity management and seamless handover control. Deployed as a VNF, a set of VMs, or CNF, it becomes a scalable platform to on-board third-party control applications. It leverages a Radio-Network Information Base (R-NIB) database which captures the near real-time state of the underlying network and feeds RAN data to train the AI/ML models, which are then fed to the Near-RT RIC to facilitate radio resource management for subscriber. Near-RT RIC interacts with Non-RT RIC via the A1 interface to receive the trained models and execute them to improve the network conditions.
The Near-RT RIC can be deployed in a centralized of distributed model, depending on network topology.
Source: O-RAN Alliance
RIC Summary
The RIC platform provides a set of functions via xApps and using predefined interfaces that allow for increased optimizations in Near-RT RIC through policy-driven, closed loop automation, which leads to faster and more flexible service deployments and programmability within the RAN. It also helps strengthen a multi-vendor open ecosystem of interoperable components for a disaggregated and truly open RAN.
Estimating the Maximum Throughput and 5G Capacity for modern Wireless Networks is complex and requires understanding of the 5G standards. This page is aimed at summarising what’s involved:
5G Maximum Capacity Estimation
Throughput estimation for 5G is complex, involving many factors and deep knowledge of the 5G standards. However, the rough estimation for a maximum throughput can roughly be estimated by following equation:
From:
< 38.306 – 4.1.2 Max data rate without ue-CategoryDL and ue-CategoryUL >
5G Capacity:
The meaning of each parameter in this equation is as follows:
5G Capacity Formula
Explaining the formula in more detail:
For 5G NR, the approximate data rate for given number of aggregated carriers in a band or band combination is calculated using the above equation or formula. The following fields are used in 5G NR throughput calculation:
➤J : number of aggregated component carriers in a band or band combination ➤Rmax : 948/1024 • For the j-th CC, Vlayers(j) is the maximum number of layers ➤Qm(j) : Maximum modulation order, Qm is 2 for QPSK, 4 for 16QAM, 6 for 32QAM, 8 for 256QAM ➤f(j) : Scaling factor, can take any value from 1/0.8/0.75/0.4 ➤μ : 5G NR Numerology, can take any value from 0 to 5. ➤Tsμ : Average OFDM symbol duration in a subframe for μ value, • Tsμ = 10-3/(14*2μ). ➤NPRBBW(j),μ : Maximum RB Allocation in bandwidth, BW(j)with numerology (μ), BW(j) is UE supported maximum Bandwidth in given band or in band combinations. REs are grouped into PRBs (Physical Resource Blocks). Each PRB consists of 12 Subcarriers. ➤OH(j) : Overhead which takes any of the following values. • [0.14] → Frequency Range FR1 for DL • [0.18] → Frequency Range FR2 for DL • [0.08] → Frequency Range FR1 for UL • [0.10] → Frequency Range FR2 for DL
Above mentioned formula has been used along with 5G NR Physical layer parameters and other 5G NR system parameters in order to develop 5G NR throughput calculator. One can refer following pdf which covers snapshot of 3GPP TS 38.306 document for more information on 5G NR data rate calculation. The maximum transmission bandwidth configuration NRB for each UE channel bandwidth and subcarrier spacing are specified in the tables below.
3GPP References
• 3GPP TS 38.306 V15.2.0 (2018-06)
Maximum 5G Throughput & Capacity Calculators
We noted a few of examples of the maximum throughput calculators on the Internet as listed below. Disclaimer: these are what we found on the Internet – results may vary and accuracy is not known or warranted.
An Open Radio Access Network (O-RAN) is a disaggregated approach to deploying mobile fronthaul and midhaul networks built entirely on cloud native principles. O-RAN underscores streamlined 5G RAN performance objectives through the common attributes of efficiency, intelligence and versatility. Open RAN deployed at the network edge will benefit 5G applications such as autonomous vehicles and the IoT, support network slicing use cases effectively, and enable secure and efficient over-the-air firmware upgrades.
O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture, first introduced by the GSMA’s 3GPP in their release 15 (5G version 1) technical specification TS 38.401. The O-RAN Alliance formed to undertake the advancement of NG-RAN philosophies, expanding on the scope of what was originally outlined by the 3GPP. Comprising over 1601 member companies, the O-RAN alliance issues specifications and releases open source software under the auspices of the Linux Foundation.
TS 38.401 decomposed the existing Baseband Unit (BBU) into two functional components, a Distributed Unit (DU) and Central Unit (CU). Conforming to modern control user plane separation (CUPS) constructs, the Central Unit can be further decoupled into distinct control plane (CU-CP) and user plane (CU-UP) functions. Replacing the monolithic BBU with the CU/DU allows for new deployment models which feature centralized packet processing functions, while laying the groundwork for separating baseband functions from the (remote) radio unit (RRU/RU).
ORAN explained: Picture courtesy VIAVI solutions
O-Ran Benefits
Operational efficiencies have been realized through past RAN innovations such as cloud RAN (cRAN), but previous advancements did not free operators from vendor lock-in. By enabling an open, multi-vendor RAN ecosystem, O-RAN introduces cloud-scale economies and competition to the RAN. Marketplace factors, combined with a more elastic and flexible RAN architecture that is already taking shape through virtualization, can enable much faster time to market (TTM) than was previously possible.
Moving away from the vendor-specific RAN paradigm not only enables more flexibility for operators, it also minimizes the “secret sauce” that leaves them reliant on a single vendor for all aspects of RAN implementation and optimization.
Competition and proliferation resulting from of new entrants can potentially drive down O-RAN equipment costs. The inter-carrier, interoperability aspects of Open RAN can also be used to increase efficiencies for existing LTE networks as they continue to incorporate the virtualization and disaggregation that are prerequisite 5G RAN deployment.
A CableFree Remote Radio Head (RRH) used for O-RAN networks
This affords numerous technical and operational advantages, regardless of whether the RRU, DU and CU remain co-located within a 5GNodeB (gNB), like existing NodeB RRU/BBU implementations, or the CU is physically deployed to a more centralized location. The centralization of the CU in an aggregation site reduces costs and accelerates the implementation of dynamic and highly automated multiaccess edge compute (MEC) clouds for the RAN (aka C-RAN). This functional decoupling will also enable the adoption of modern transport protocols which can also align with the 5G core user plane (i.e. SRv6) while easing the addition of new latency, high-bandwidth, AI/ML-driven applications.
The deployment of NG-RAN components is defined as being with or between the fronthaul, midhaul and backbone network. Open interfaces are described as either lower-layer splits (LLS), in the case of the RU to DU connection, or higher-layer splits (HLS) as with the link between the DU and CU. This nomenclature is descriptive of the OSI layer (i.e. L1/L2/L3) exposed by the interface and handled by the NG-RAN function. Where components are instantiated will depend on the requirements of the service slice. A low latency service might demand a CU be co-located with the DU in the access layer while a slice supporting a simple machine to machine communications application would scale more cost effectively with a CU within the network core.
NG-RAN clearly defines the DU and CU plus the F1, E1, Xn and NG between them and the core network but stops short of outlining the service management framework and interfaces required for the RAN to operate within an orchestrated and automated cloud environment. TS 38.401 also fails to address the RU-DU interface. Without further definition, it would be logical to adopt the exiting Common Public Radio Interface (CPRI) defined between the RRU-BBU. Although theoretically a standard, this interface has been heavily modified by individual vendors, effectively locking their RRU to their BBU.
While CPRI is a high-speed serial interface, the bandwidth demands of 5G will stretch the limits of local fiber and increase the need for more radio units. Current implementations do not allow for the DU to reduce this burden by offloading some of its functionality to the RU. While the enhanced CPRI (eCPRI) interface was originally proposed as an alternative, this specification was also developed by just four2 large vendors. The O-RAN Alliance has therefore taking on the task of defining new Open Fronthaul user and management plane interfaces between the DU and RU.
To ensure openness, O-RAN decouples hardware and software into 3 layers: The commercial off the shelf (COTS) merchant silicon (including x86), a hardware abstraction layer and an application layer, where the RAN functions reside. Ensuring each layer is vendor agnostic, the O-RAN alliance has specified a list of requirements for a cloud platform which supports the execution of O-RAN network functions. This is referred to as the O-RAN Cloud Platform, or O-Cloud. Deploying O-RAN functions on x86 hardware in cloud native environments using lightweight (OS virtualization) containers demands a strong emphasis on data plane acceleration. This must be achieved at the application level, as these functions will not have access to the Kernel. As such, solutions may be specific to each O-RAN CNF but leverage standard techniques such as DPDK and FD.io or employ more advanced techniques.
O-RAN challenges
Creating seamless interoperability in a multi-vendor, open ecosystem introduces new test, management and integration challenges that require diligence and cooperation to overcome. In the single-vendor model, accountability is a foregone conclusion and problem isolation and troubleshooting are managed through an established command structure.
Dispersion of vendors could potentially lead to finger pointing when root cause identification is inconclusive. These same complications could plague on-time launch schedules and revenue growth by diluting management and orchestration responsibilities across an array of new O-RAN players.
The enticing Open RAN concept of flexible interoperability also brings challenges for test and integration. To fulfill the O-RAN promise of reduced OPEX and total cost of ownership (TCO), operators must take responsibility for multi-vendor, disaggregated elements and make sure they perform together to maintain QoE standards.
With Open RAN reducing the barrier to entry for dozens of new players, interoperability is a paramount concern for both the O-RAN ALLIANCE and OpenRAN group. An Open Test and Integration Center (OTIC) has been established as a collaborative hub for commercial Open RAN development and interoperability testing. The operator led initiative benefits from the support of global telecom organizations with a shared commitment to verification, integration testing, and validation of disaggregated RAN components.
Summary
Traditional RAN designs and architectures will still persist in being used. Some operators will prefer Open RAN designs and architecture. Many operators will allow for both options in their network evolution and planning.
Why consider Shared Spectrum for Private 5G and 4G LTE networks?
Shared spectrum solutions for 4G and 5G enable the use of the same spectrum range in a single geographic area by more than one organisation. This is different than Unlicensed Spectrum which is uncontrolled and generally suffers interference. Shared Spectrum is licensed and therefore Private 5G can operate in deterministic manner.
Here is a snapshot for 2020: recent examples of spectrum initiatives to private mobile networking are outlined (nonexhaustive list).
Countries with identified private network deployments (4G & 5G)
Which countries are planning Shared Spectrum?
Australia: In August 2020, ACMA launched a consultation on plans for area-wide apparatus licences for wireless broadband in the 24.7–27.5 GHz frequency range of the 26 GHz band; wireless broadband and FSS in the 27.5–29.5 GHz range; and FSS in the 29.5–30 GHz range. It is envisaged these licences would support private network and local WISP use-cases. ACMA is planning to make the spectrum at 24.7–25.1 GHz and 27.5–29.5 GHz available Australia-wide via an administrative process, with applications opening in October 2020 and licences available from December 2020. Licences for spectrum from 25.1 GHz to 27.5 GHz would be available via administrative process only after the conclusion of an auction of spectrum in this range covering key metropolitan and regional areas scheduled for Q1 2021. That administrative process is scheduled to begin in May 2021 with licences issued by the end of June 2021.
Belgium: In December 2019 BIPT launched a consultation on a draft bill and three draft royal decrees concerning among other things, the possibility of authorising local private networks using 4G or 5G in the 3800–4200 MHz band.
Brazil: An auction is expected in H1 2021 covering various bands with spectrum set aside for private networks: 2390–2400 MHz, 3700–3800 MHz, 27.5–27.9 GHz.
Chile: In November 2019 Chile passed a resolution designating spectrum from 3750 MHz to 3800 MHz for private 5G networks.
Croatia: Croatia is planning an auction of multiple spectrum bands. Due to the impact of COVID-19, the auction has been delayed from 2020 to H1 2021. It intends to auction at least 300 MHz in the 3410–3800 MHz range on a national basis, with remaining 90 MHz of spectrum potentially available for local or private networks.
Finland: Spectrum at 24.25–25.1 GHz is being reserved for the construction of local, private networks in the future.
France: At the end of March 2019, applications were closed for requests to run 5G trials at 26 GHz. The French regulator ARCEP accepted 11 schemes backed by public and private network operators. The various private network projects include inter alia deployment of a 5G network at the National Vélodrome in Saint-Quentin-enYvelines, a network at Lyon Part-Dieu station offering both public and private 5G services (the latter to enable station management and train telematics) and a network at The Grand Maritime Port of Le Havre for smart grid and logistics applications. In May 2019, ARCEP opened up the possibility of wider private use of TDD spectrum at 2.6 GHz (2575–2615 MHz) for very-high-speed mobile networks (Air France KLM has already been trialling private LTE in this band for a number of years). Then in September, after a public consultation, it confirmed that it would be allocating the spectrum on a regional basis in order to improve broadband coverage for enterprises. Enterprises must express interest in using the spectrum, which will either be allocated (in the case of no competition for the spectrum) or ARCEP will determine a (possibly competitive) system of allocation. So far three applications have been accepted. ARCEP has also opened the possibility of private network deployment in C-Band spectrum. In order to ensure organisations can get access to mobile services with sufficient coverage and performance, the terms of the licences for C-Band spectrum awarded in September 2020 included commitments to respond to reasonable requests from enterprise and public sector organisations for the supply of services, either through the supply of services on its own network or through sub-licensing of the frequency on a geographically limited basis.
Germany: In November 2019 Germany’s regulator, Bundesnetzagentur, opened up applications for use of the 3700–3800 MHz band for local and regional 5G networks. Stating that it wants Germany to be a pioneer in Industry 4.0, in addition to industrial users, the regulator anticipates the spectrum being leased by organisations in the agricultural and forestry sectors. Frequencies can be used immediately after allocation. The right to apply for spectrum derives from ownership or from another legal right to use the associated land, and fees are related to size of the geographic area covered by the licence, the amount of spectrum allocated and the duration.
The regulator has also been preparing a framework for the assignment of spectrum at 24.25–27.5 GHz for local applications. After consultation it is proposed the entire range be assigned on a technology and service neutral basis (starting with spectrum from 26.5-27.5 GHz). The new plans were opened up to a consultation which ended in August 2020. No limit is proposed for the geographical size of a local frequency assignment, although the licensee must have a plan for service availability throughout that area within a year. The results have not yet been published.
Hong Kong: In July 2019, the regulator OFCA announced that it would be making 400 MHz in the 27.95–28.35 GHz range available for Localised Wireless Broadband Licences (using 5G or other advanced mobile technologies) on a geographic-sharing basis. It opened up applications for assignment of the shared spectrum later the same month. GSA is aware of one active licence. OFCA has also stated plans to assign spectrum at 617–698 MHz and 703–803 MHz for indoor mobile services, with the spectrum available from 2021 at the earliest.
Japan: In December 2019, the Ministry of Internal Affairs and Communications began accepting applications for local 5G licences. The spectrum available spans 28.2–28.3 GHz and can be used within the applicant’s own building or on its own land to provide broadband fixed wireless services. National carriers are not eligible to apply, as the spectrum is not intended to supplement national carriers’ existing holdings. MIC also stated it would consider allocation of spectrum at 4.6–4.9 GHz and 28.2–29.1 GHz for local private services in the future. (In 2017, Japan also made the 1.9 GHz band, Band 39, previously used for PHS and DECT available for private LTE networks as a shared band.)
Malaysia: In January 2020, the MCMC stated that spectrum at 26–28 GHz will be assigned in two parts. Spectrum at 24.9–26.5 GHz will be tendered (beauty contest) to licensees on a national basis. Spectrum at 26.5–28.1 GHz will be assigned on a first-come, first-served basis for the deployment of local/private networks ‘for industrial and enterprise services and applications for, but not limited to, healthcare, ports, transportation, manufacturing, agriculture, public safety and smart city projects’. Proceedings have been delayed, however.
Netherlands: Spectrum at 3.5 GHz is already widely used for local and private network applications, although the government is reorganising the spectrum. It intends to make spectrum at 3500–3700 MHz available nationally from September 2022. Spectrum at 3400–3450 MHz and 3750–3800 MHz is then intended to be made available for local use from 2026. Spectrum at 3450–3500 MHz and 3700–3750 MHz is already used and currently protected for national security reasons. Netherlands’ Digital Connectivity Action Plan foresees the use of spectrum at 26 GHz either for a very large number of local permits or for shared use.
New Zealand: Spectrum at 2.5 GHz (2575–2620 MHz) is available in New Zealand for local or regional Managed Spectrum Park (private) licences (often for regional wireless broadband services). Eighty licences were awarded in 2009 after an initial round of applications. Subsequent licences have been made available on a first-come, first-served basis, with a number of licences awarded during 2019. Licences last for six years. There are limits on geographic coverage of licences held by any single organisation.
Norway: The Norwegian regulator Nkom is considering a joint assignment of various spectrum bands in 2021, two of which – the 2300–2400 MHz band and 3600 MHz – are under consideration for use for allocation to local/regional permits. In June 2020, it launched a consultation on plans to offer local/regional permits at 2300 GHz and 26 GHz.
Poland: In April 2019, Poland launched a consultation about the amount of spectrum to be made available at 3400–3800 MHz, with two options: a) 200 MHz in four lots of 50 MHz or b) 400 MHz (four national lots of 80 MHz plus 80 MHz for local use). In December, it announced a new consultation on the details of an auction of four lots at 80 MHz. Local use details had not been released at the time of writing.
Russia: In December 2019, Russia’s Deputy Minister of Digital Development, Telecommunications and Mass Communications stated that the government was preparing an auction of mmWave spectrum at 25.25–27.5 GHz (with six lots, four federal lots of 400 MHz and two regional lots of 250 and 400 MHz). Then in March 2020, SRCF published its decision that it would open up spectrum use at 24.25–24.65 GHz for an unlimited number of users for the purposes of creating private networks. Russia SRFC is also reportedly planning to allocate chunks of spectrum at 400 MHz for private LTE networks.
Slovenia: In August 2020, Slovenia announced draft terms and conditions on plans for a multi-band spectrum covering various bands. A portion of the spectrum at 2300 MHz (2300–2320 MHz and 2390–2400 MHz) and at 3600 MHz (3400–3420 MHz) is expected to be set aside for local use (including for private use). The latest timetable envisages the completion of the auction before the end of 2020.
Sweden: PTS intends to enable local permits for the use of spectrum in the 3720–3800 MHz range. These will be awarded and managed through an administrative process. PTS initiated consultations on the demand for 5G frequencies in the 24.25–27.5 GHz bands and in December 2019, stated that it intended – as soon as possible – to allocate parts of the spectrum range for both local and large-scale 5G use. In its consultation, launched in April 2020, it proposed before the end of 2021 authorising the use of spectrum at 24.25–25.1 GHz for local 5G services, with licences valid to end 2025 and limited to indoor use.
UK: Following consultations, in July 2019, Ofcom announced plans to initiate spectrum sharing with localised licensing of key spectrum bands. Its aim is to open up use of the spectrum to private network operators such as enterprises and utilities. The spectrum that will be available through local licences includes: • 3800–4200 MHz • 1781.7–1785 MHz/1876.7–1880 MHz) (called 1800 MHz shared spectrum by Ofcom) • 2390–2400 MHz (called 2300 MHz shared spectrum). The spectrum is available on a coordinated first-come, first-served basis. Ofcom indicated that localised licenses can be applied for immediately
Ofcom has also decided to enable localised access to spectrum in the 26 GHz band (24.25–26.5 GHz) available on a sharedspectrum basis, but only for indoor use. (Spectrum in the 26.5–27.5 GHz range is used by the military. Ofcom will continue to review possible ways of making this spectrum available in the future.)
USA: There are more than 200 organisations holding PAL spectrum licences for CBRS deployments in the USA, including for private enterprise purposes, and more organisations intending to use General Authorized Access (GAA) spectrum. Initial commercial deployments of CBRS were given the go-ahead in September 2019. Full-blown commercial deployments were authorised in January 2020, initially only using General Authorized Access (GAA) spectrum. The auction of Priority Access CBRS spectrum at 3.5 GHz was completed in August 2020 enabling launch across all relevant spectrum ranges. The CBRS bands is expected to be used extensively for private mobile network deployments in the USA.
Private network deployments by technology (base with identified private network deployments, pilot and commercial (base 156 networks)
Content on Shared Spectrum (C) GSA and reproduced courtesy of GSA.
For Further Information
Find out more about Shared Spectrum & Spectrum Sharing for Private 5G and Private LTE Networks: Please Contact Us
5G-NR Modulation and Coding as used by 5G Base Stations (gNodeb) and CPE devices:
For any communication technology, Modulation and Coding Scheme (MCS) defines the numbers of useful bits which can carried by one symbol. In contrast with 5G or 4G, a symbol is defined as Resource Element (RE) and MCS defined as how many useful bits can be transmitted per Resource Element (RE) . MCS depends on radio signal quality in wireless link, better quality the higher MCS and the more useful bits can be transmitted with in a symbol and bad signal quality result in lower MCS means less useful data can be transmitted with in a symbol.
In other words, we can say MCS depends Blocker Error Rate (BLER). Typically there is a BLER threshold defined that equal to 10%. To maintain BLER not more than this value in varying radio condition Modulation and Coding Scheme (MCS) is allocated by gNB using link adaptation algorithm. The allocated MCS is signalled to the UE using DCI over PDCCH channel e.g. DCI 1_0, DCI 1_1
A MCS basically defines the following two aspects:
Modulation
Code rate
Modulation
Modulation defines how many bits can be carried by a single RE irrespective of whether it’s useful bit or parity bits. 5G NR supports QPSK, 16 QAM, 64 QAM and 256 QAM modulation . With QPSK there are 2 bits can be transmitted per RE, with 16QAM it can be 4 bits, with 64QAM it can be 6 bits and with 256QAM it can 8 bits. These 16, 64 and 256 are know as modulation order of QAM Modulation and The no. of bits for each modulation order can be calculated using following formula.
Code Rate
Code rate can be defined as the ratio between useful bit and total transmitted bit (Useful + Redundant Bits). These Redundant bits are added for Forward Error Correction (FEC). In other words we can it is the ratio between the number of information bits at the top of the Physical layer and the number of bits which are mapped to PDSCH at the bottom of the Physical layer. We can also say, it a measure of the redundancy which is added by the Physical layer. A low coding rate corresponds to increased redundancy.
5G NR Modulation and Coding Scheme (MCS) Characteristics
Modulation and Coding Scheme (MCS) defines the numbers of useful bits per symbols
MCS selection is done based on radio condition and BLER
MCS is change by gNB based on link adaptation algorithm
MCS information is provided to UE using DCI
5G NR supports QPSK,16 QAM, 64 QAM and 256 QAM modulation for PDSCH
There are about 32 MCS Indexes (0-31) are defined and MCS Index 29,30 and 31 are reserved and used for re-transmission
3GPP Specification 38.214 has given three tables for PDSCH MCS namely 64 QAM Table, 256 QAM Table and Low Spectral Efficiency 64 QAM Table
Modulation and Coding Scheme Tables
64 QAM table may be used when gNB or UE is not supporting 256 QAM or in poor radio condition where 256 QAM table decoding is not successful and gNB needs to allocated QPSK order modulation
256 QAM table may be used whenever 256QAM is to be allocated in very good radio conditions
Low spectral efficiency (Low SE) 64 QAM table is suitable for applications which need reliable data transfer, e.g. applications belonging to the URLLC category. This table includes MCS which have low Spectral Efficiency i.e. a reduced coding rate which increase channel coding redundancy
64 QAM Table
256 QAM Table
Low SE 64 QAM Table
Which Table to select:
gNB instructs the UE to select a specific MCS table using a combination of RRC signalling (IEs) and Phy layer signalling (RNTI).
RRC signalling configure PDSCH-Config and SPS-Config parameter with the mcs-Table IE for a semi-static configuration which can be further modified using RRC signalling
Phy layer uses a dynamic selection of the RNTI which scrambles the CRC bits belonging to the PDCCH payload, e.g. switching between the C-RNTI and MCS-C-RNTI can influence the selection of the MCS table.
MCS Table Selection Example:
With this example, we can show that MCS table selection initially configured with RRC signaling and further can be controlled using only Physical layer signaling.
Consider a UE has been configured with parameter PDSCH-Config with mcs-Table= ‘qam256’ and allocated an MCS-C-RNTI alng with traditional a C-RNTI
If the UE receives a PDSCH resource allocation using DCI 1_ 1 with the C-RNTI, then the UE will select the 256 QAM MCS table
If the same UE receives a PDSCH resource allocation using DCT 1_ 0 with the C-RNTI, then UE will select the 64 QAM MCS table
If the same UE receives a PDSCH resource allocation using either DCI 1_ 1 or 1 _ 0 with the MCS-C-RNTI, then the UE will select the Low SE table.
A 5G Remote Radio Head (RRH) comprises several key component parts. Here we look at some of the key technologies involved
5G Band n77 Remote Radio Head (RRH)
Remote Radio Head (RRH) Transceiver, (TRX)
In a modern RRH The Transceiver module may be a single high density PCB containing high speed logic, RF, slow speed analogue and management functions.
The RF processing stages will include complex technologies such as Digital Predistortion (DPD) and Crest Factor Reduction (CFR) which are key to ensure high fidelity of transmitted signals across the airside interface.
The high speed logic may be implemented in a Field Programmable Gate Array (FPGA).
High speed interfaces may include CPRI and/or 10Gbps Ethernet (IP) eCPRI interfaces. More modern Open RAN (ORAN) and Virtualised RAN (VRAN) networks require Ethernet interfaces and more complexity inside the RRH.
Lower speed interfaces may be used to control antenna arrays and other functions.
Front End Module (FEM)
An FEM is used in TDD variants as a highly integrated module. The Front End Module (FEM) contains the following key elements:
Power Amplifier (PA)
Low Noise Amplifier (LNA)
Transmit-Receive switch
FEM Model variants used in Remote Radio Heads to cover different frequency bands and power levels. Please note this is only a partial list of examples:
The Power Amplifier takes signals from the Transceiver (TRX) and boosts to high power levels needed for over-the-air transmission. The output power may vary from 100mW up to 80W per chain (channel) depending on the specific model and application.
Low Noise Amplifier (LNA)
The Low Noise Amplifier (LNA) takes low level input signals from the antenna and boosts them to suitable levels to feed to the Transceiver (TRX) module. The LNA must be suitable shielded to prevent unwanted signals entering, including from other items within the RRH.
RF Duplexer or Filter
Depending whether the RRH is being used in FDD or TDD mode, an RF Duplexer or Filter is used. TDD units feature a filter, and FDD units feature a Diplexer
This RF stage is key to remove unwanted harmonics from the transmission, and also block any unwanted signals from adjacent bands entering the sensitive RF receiver
DC-DC Power Supply (PSU)
The DC-DC Power Supply (PSU) takes input power (typically 36-72V, nominally 48V DC) and converts to smooth, stable power voltage rails to power the key items within the Remote Radio Head.
For Further Information on Remote Radio Head (RRH) technology:
CPRI, or Common Public Radio Interface, defines key interface specification between REC (Radio Equipment Control) and RE (Radio Equipment) of radio base stations used for cellular wireless networks. It is a protocol of choice for fronthaul communications between towers and base stations (BSs) through several generations of wireless networks. CPRI has efficient and flexible I/Q data interfaces for various standards, such as GSM, WCDMA, LTE, etc.
CPRI for 5G: Common Public Radio Interface
CPRI defines key interface specification between REC (Radio Equipment Control) and RE (Radio Equipment) of radio base stations used for cellular wireless networks. CPRI is the short form of Common Public Radio Interface. CPRI is popular standard for transporting baseband I/Q signals to the radio unit in traditional BS (Base Station). CPRI allows efficient and flexible I/Q data interface for various standards e.g. GSM, WCDMA, LTE etc.
eCPRI for 5G: Enhanced Common Public Radio Interface
eCPRI was created and published after CPRI. The eCPRI standard defines specification which connects eREC and eRE via fronthaul transport network. It is used for 5G systems, LTE-Advanced and LTE-Advanced Pro.
The Purpose of development of CPRI and eCPRI is as follows. Radio BSs should offer flexibility during deployment to MNOs( mobile network operators). This is achieved by simplifying BS architecture by dividing radio BS functionality into two modules viz. eREC and eRE. Both parts may be physically separated where in eRE is kept close to RF antenna where as eREC kept at a distant end. Both are connected via a transport network. The eREC contains part of PHY layer functions and upper layer functions of the air interface whereas eRE contains the other part of the PHY layer functions and the analog radio frequency (ARF) functions. The different functions can be located either in the eREC or in the eRE.
Interfaces used for Fronthaul in 4G and 5G Wireless Networks
Both CPRI and eCPRI can be used in 5G fronthaul. While, eCPRI is more suitable in 5G fronthaul. Here are the network line rates:
CPRI Line Rate
Line Bit Rate (Gbps)
Line Coding
Bits/Word
Transport Capacity (#WCDMA AxC)
Transport Capacity (#20 MHz LTE AxC)
Rate-1
0.614
8B/10B
8
4
–
Rate-2
1.2288
8B/10B
16
8
1
Rate-3
2.4576
8B/10B
32
16
2
Rate-4
3.0720
8B/10B
40
20
2
Rate-5
4.9152
8B/10B
64
32
4
Rate-6
6.1440
8B/10B
80
40
5
Rate-7A
8.1100
64B/66B
128
64
8
Rate-7
9.8304
8B/10B
128
64
8
Rate-8
10.1376
64B/66B
160
80
10
Rate-9
12.1651
64B/66B
192
96
12
Rate-10
24.3302
64B/66B
384
192
24
CPRI line rates used in 4G and 5G
This table shows the different transport capacity at different line rates. Since 5G requires tremendous bandwidth expansion, line rate option 10, the newest standard, can meet latest 5G requirements. However, this processing capacity has reached the upper limit of the standard, causing doubt about whether 5G can be used with CPRI for future expansion.
Management, Orchestration and Charging for 5G networks
Key topics for modern 5G networks include Management, Orchestration and Charging. In December 2017, the 3GPP passed two major milestones for 5G by approving the first set of 5G NR specs and by putting in place the 5G Phase 1 System Architecture. These achievements have brought about the need for new management standards, as 5G adds to the ever-growing size and complexity of telecom systems.
3GPP management standards from working group SA5 are approaching another major milestone for 5G. With our studies on the 5G management architecture, network slicing and charging completed last year, we are now well under way with the normative work for the first phase in 3GPP Release 15, which includes building up a new service-oriented management architecture and all the necessary functionalities for management and charging for 5G networks.
SA5’s current work also includes several other work/study items such as management of QoE measurement collection and new technologies for RESTful management protocols. However, this article will focus on the new 5G Rel-15 architecture and the main functionalities, including charging.
5G networks and network slicing
Management and orchestration of 5G networks and network slicing is a feature that includes the following work items: management concept and architecture, provisioning, network resource model, fault supervision, assurance and performance management, trace management and virtualization management aspects. With the output of these work items, SA5 provides specified management interfaces in support of 5G networks and network slicing. An operator can configure and manage the mobile network to support various types of services enabled by 5G, for example eMBB (enhanced Mobile Broadband) and URLLC (Ultra-Reliable and Low Latency Communications), depending on the different customers’ needs. The management concept, architecture and provisioning are being defined in TS 28.530, 28.531, 28.532 and 28.533.
Network slicing is seen as one of the key features for 5G, allowing vertical industries to take advantage of 5G networks and services. 3GPP SA5 adopts the network slice concept as defined in SA2 and addresses the management aspects. Network slicing is about transforming a PLMN from a single network to a network where logical partitions are created, with appropriate network isolation, resources, optimized topology and specific configuration to serve various service requirements.
As an example, a variety of communication service instances provided by multiple Network Slice Instances (NSIs) are illustrated in the figure below. The different parts of an NSI are grouped as Network Slice Subnets (e.g. RAN, 5GC and Transport) allowing the lifecycle of a Network Slice Subnet Instance (NSSI) to be managed independently from the lifecycle of an NSI.
Provisioning of network slice instances
The management aspects of a network slice instance can be described by the four phases:
1) Preparation: in the preparation phase the network slice instance does not exist. The preparation phase includes network slice template design, network slice capacity planning, on-boarding and evaluation of the network slice requirements, preparing the network environment and other necessary preparations required to be done before the creation of a network slice instance.
2) Commissioning: provisioning in the commissioning phase includes creation of the network slice instance. During network slice instance creation all needed resources are allocated and configured to satisfy the network slice requirements. The creation of a network slice instance can include creation and/or modification of the network slice instance constituents.
3) Operation: includes the activation, supervision, performance reporting (e.g. for KPI monitoring), resource capacity planning, modification, and de-activation of a network slice instance. Provisioning in the operation phase involves activation, modification and de-activation of a network slice instance.
4) Decommissioning: network slice instance provisioning in the decommissioning phase includes decommissioning of non-shared constituents if required and removing the network slice instance specific configuration from the shared constituents. After the decommissioning phase, the network slice instance is terminated and does not exist anymore.
Similarly, provisioning for a network slice subnet instance (NSSI) includes the following operations:
Create an NSSI;
Activate an NSSI;
De-active an NSSI;
Modify an NSSI;
Terminate an NSSI.
Roles related to 5G networks and network slicing
The roles related to 5G networks and network slicing management include: Communication Service Customer, Communication Service Provider (CSP), Network Operator (NOP), Network Equipment Provider (NEP), Virtualization Infrastructure Service Provider (VISP), Data Centre Service Provider (DCSP), NFVI (Network Functions Virtualization Infrastructure) Supplier and Hardware Supplier.
Depending on actual scenarios:
Each role can be played by one or more organizations simultaneously;
An organization can play one or several roles simultaneously (for example, a company can play CSP and NOP roles simultaneously).
Management models for network slicing
Different management models can be used in the context of network slicing.
1) Network Slice as a Service (NSaaS): NSaaS can be offered by a CSP to its CSC in the form of a communication service. This service allows CSC to use and optionally manage the network slice instance. In turn, this CSC can play the role of CSP and offer their own services (e.g. communication services) on top of the network slice instance. The MNSI (Managed Network Slice Instance) in the figure represents a network slice instance and CS represents a communication service.
2) Network Slices as NOP internals: network slices are not part of the CSP service offering and hence are not visible to CSCs. However, the NOP, to provide support to communication services, may decide to deploy network slices, e.g. for internal network optimization purposes.
Management architecture
SA5 recognizes the need for automation of management by introducing new management functions such as a communication service management function (CSMF), network slice management function (NSMF) and a network slice subnet management function (NSSMF) to provide an appropriate abstraction level for automation.
The 3GPP SA5 management architecture will adopt a service-oriented management architecture which is described as interaction between management service consumer and management service provider. For example, a management service consumer can request operations from management service providers on fault supervision service, performance management service, provisioning service and notification service, etc.
Network Resource Model (NRM) for 5G networks and network slicing
To support management and orchestration of 5G networks, the Network Resource Model (NRM) representing the manageable aspects of 5G networks needs to be defined, according to 5G network specifications from other 3GPP working groups as well as considering requirements from 5G management architecture and operations.
The 5G NRM specifications family includes 4 specifications: TS 28.540 and TS 28.541 for NRM of NR and NG-RAN, TS 28.542 and TS 28.543 for NRM of 5G core network.
According to content categorization, 5G NRM specifications can be divided into 3 parts:
Requirements, also known as stage 1,
Information Model definitions also known as stage 2, and
Solution Set definitions also known as stage 3.
Identified in the specifications of 5G NRM requirements (TS 28.540 and TS 28.542), the NRM of 5G network comprises NRM for the 5G core network (5GC) and NRM for 5G radio access network (i.e. NR and NG-RAN). The 5GC NRM definitions support management of 5GC Network Functions, respective interfaces as well as AMF Set and AMF Region. The NR and NG-RAN NRM definitions cover various 5G radio networks connectivity options (standalone and non-standalone radio node deployment options) and architectural options (NR nodes with or without functional split).
The 5G Information Model definitions specify the semantics and behavior of information object class attributes and relations visible on the 5G management interfaces, in a protocol and technology neutral way (UML as protocol-neutral language is used). The 5G Information Model is defined according to 5GC, NR and NG-RAN specifications. For example, in 3GPP TS 38.401, the NR node (gNB) is defined to support three functional split options (i.e. non-split option, two split option with CU and DU, three split option with CU-CP, CU-UP and DU), so in the NR NRM Information Model, corresponding Information Object Class (IOC) is defined for each network function of gNB specified, and different UML diagrams show the relationship of each gNB split option respectively. Further, in the 5G Information Model definitions, the existing Generic NRM Information Service specification (TS 28.622) is referenced to inherit the attributes of generic information object classes, and the existing EPC NRM Information Service specification (TS 28.708) is referenced for 5GS / EPS interworking relationships description.
Finally, NRM Solution Set definitions map the Information Model definitions to a specific protocol definition used for implementations. According to recommendation from TR 32.866 (Study on RESTful based Solution Set), JSON is expected to be chosen as data modelling language to describe one 5G NRM Solution Set.
Fault Supervision of 5G networks and network slicing
Fault Supervision is one of the fundamental functions for the management of a 5G network and its communication services. For the fault supervision of 5G networks and network slicing, the following 3GPP TSs are being specified:
1) TS 28.545 “Management and orchestration of networks and network slicing; Fault Supervision (FS); Stage 1”, which includes:
The use cases and requirements for fault supervision of 5G networks and network slicing.
The definitions of fault supervision related management services (e.g. NetworkSliceAlarmAcknowledgement, NetworkSliceAlarmListReading, NetworkSliceAlarmClearance, NetworkSliceAlarmNotification, NetworkSliceAlarmSubscription, etc.)
2) TS 28.546 “Management and orchestration of networks and network slicing; Fault Supervision (FS); Stage 2 and stage 3”, which includes the definition of:
Interfaces of the fault supervision related management services; (Stage 2)
Notifications; (Stage 2)
Alarm related information models (e.g. alarmInformation, alarmList, etc.); (Stage 2)
Solution set(s) (e.g. RESTful HTTP-based solution set for Fault Supervison); (Stage 3)
New event types and probable causes if necessary.
Assurance data and Performance Management for 5G networks and network slicing
The 5G network is designed to accommodate continuously fast increasing data traffic demand, and in addition, to support new services such as IoT, cloud-based services, industrial control, autonomous driving, mission critical communications, etc. Such services may have their own performance criteria, such as massive connectivity, extreme broadband, ultra-low latency and ultra-high reliability.
The performance data of the 5G networks and NFs (Network Functions) are fundamental for network monitoring, assessment, analysis, optimization and assurance. For the services with ultra-low latency and ultra-high reliability requirements, any faults or performance issues in the networks can cause service failure which may result in serious personal and property losses. Therefore, it is necessary to be able to collect the performance data in real-time (e.g., by performance data streaming), so that the analytic applications (e.g., network optimization, SON, etc.) could use the performance data to detect any network performance problems, predict the potential issues and take appropriate actions quickly or even in advance.
For network slicing, the communication services are provided on top of the end-to-end network slice instances, so the performance needs to be monitored from end-to-end point of view.
The end to end performance data of 5G networks (including sub-networks), NSIs (Network Slice Instances) and NSSIs (Network Slice Subnet Instances) are vital for operators to know whether they can meet the communication service requirement.
The performance data may be used by various kinds of consumers, such as network operator, SON applications, network optimization applications, network analytics applications, performance assurance applications, etc. To facilitate various consumers to get their required performance data, the following items are being pursued by this WI:
A service based PM framework and a list of PM services as described in the table below:
Management service name
Management service description
NF measurement job control service
The management service for creating and terminating the measurement job(s) for the NF(s).
NF measurement job information service
The management service for querying the information of the measurement job(s) for the NF(s).
NF performance data file reporting Service
The management service for reporting the NF performance data file.
NF performance data streaming service
The management service for providing streaming of NF performance data.
NSSI measurement job control service
The management service for creating and terminating the measurement job(s) for the NSSI(s).
NSSI measurement job information service
The management service for querying the information of the measurement job(s) for the NSSI(s).
NSSI performance data file reporting Service
The management service for reporting the NSSI performance data file.
NSSI performance data streaming service
The management service for providing streaming of NSSI performance data.
NSI measurement job control service
The management service for creating and terminating the measurement job(s) for the NSI(s).
NSI measurement job information service
The management service for querying the information of the measurement job(s) for the NSI(s).
NSI performance data file reporting Service
The management service for reporting the NSI performance data file.
NSI performance data streaming service
The management service for providing streaming of NSI performance data.
Network measurement job control service
The management service for creating and terminating the measurement job(s) to collect the network performance data that is not specific to network slicing.
Network measurement job information service
The management service for querying the information of the measurement job(s) to collect the network performance data that is not specific to network slicing.
Network performance data file reporting service
The management service for reporting the network performance data file that is not specific to network slicing.
Network performance data streaming service
The management service for providing network performance data streaming that is not specific to network slicing.
Performance measurements (including the data that can be used for performance assurance) for 3GPP NFs;
End to end KPIs, performance measurements (including the data that can be used for performance assurance) for NSIs, NSSIs and networks (where the performance data is not specific to network slicing).
Management and virtualization aspects of 5G networks
For 5G networks, it is expected that most of the network functions will run as software components on operators’ telco-cloud systems rather than using dedicated hardware components. Besides the virtualization for Core Network (including 5GC, EPC and IMS), the NG-RAN architecture is being defined with functional split between central unit and distributed unit, where the central unit can also be virtualized.
SA5 has conducted a study on management aspects of the NG-RAN that includes virtualized network functions, and has concluded in TR 32.864 that the existing specifications (related to management of mobile networks that include virtualized network functions) need some enhancements for 5G. The enhancements are mainly on the interactions between 3GPP management system and external management systems (e.g., ETSI NFV MANO) for the following aspects:
Management requirements and architecture;
Life Cycle Management (e.g., PNF management);
Configuration Management;
Performance Management;
Fault Management.
There are gaps identified between 3GPP SA5 requirements and ETSI ISG NFV solutions in terms of the required enhancements, and 3GPP SA5 is in cooperation with ETSI ISG NFV to solve these gaps.
Although the need for enhancements were found in the study for 5G, SA5 has reached the conclusion that they can be the used for 4G as well. So the specifications for management of mobile networks that include virtualized network functions are being made generally applicable to both 4G and 5G networks.
Study on energy efficiency of 5G networks
Following the conclusions of the study on Energy Efficiency (EE) aspects in 3GPP Standards, TSG SA#75 recommended initiating further follow-up studies on a range of energy efficiency control related issues for 5G networks including the following aspects:
Definition and calculation of EE KPIs in 3GPP Systems
Energy Efficiency control in 3GPP Systems
Coordinated energy saving in RAN and other subsystem in 3GPP Systems
Power consumption reduction at the site level
Energy Efficiency in 3GPP systems with NFV
Energy Efficiency in Self-Organizing Networks (SON).
TR 32.972 (Study on system and functional aspects of energy efficiency in 5G networks) aims to:
Identify EE KPI definitions made by ETSI TC EE, ITU-T SG5, ETSI NFV ISG, etc., which are relevant for 5G networks, in addition to definitions made in SA TR 21.866. Such EE KPIs can be defined at various levels, incl. network and equipment levels (potentially, at virtualized network function and virtualized resource level), and per deployment scenario (dense urban, rural, etc.). With 5G, potentially, EE KPIs can be defined at network slice level;
Identify metrics to be defined by 3GPP so as to be able to calculate the above EE KPIs for 5G networks. Such metrics might relate to data volumes, coverage area or energy consumption;
Assess whether existing OA&M mechanisms enable to control and monitor the identified metrics. In particular, check if the IRP for the control and monitoring of Power, Energy and Environmental (PEE) parameters for Radio Access Networks (RAN) (TS 28.304, 28.305, 28.306) can be applied to 5G networks. If not, identify potential new OA&M mechanisms;
Elaborate further on the EE control framework defined in TR 21.866 and identify potential gaps with respect to existing management architectures, incl. SON and NFV based architectures;
Examine whether new energy saving functionalities might enable the 3GPP management system to manage energy more efficiently. In particular, the applicability of ETSI ES 203 237 (Green Abstraction Layer; Power management capabilities of the future energy telecommunication fixed network nodes) to the management of 5G networks is to be evaluated;
Identify potential enhancements in existing standards which could lead to achieving improved 3GPP system-wide energy efficiency.
This study requires interactions with other 3GPP working groups and SDOs working on related topics, including ITU-T SG5, ETSI TC EE, ETSI NFV ISG.
5G Charging system architecture and service based interface
Commercial deployment of the Rel-15 5G System will not be possible without capabilities for Operators to be able to monetize the various set of features and services which are specified in TS 23.501, TS 23.502 and TS 23.503. This is defined under the charging framework, which includes e.g. real-time control of subscriber’s usage of 5G Network resources for charging purpose, or per-UE data collection (e.g. for CDRs generation) which can also be used for other purposes e.g. analytics.
SA5 has investigated, during a study period in 2017, on how charging architecture should evolve, which key features should be specified as part of charging capabilities, and which alternative amongst charging solutions should be selected, to better support the first commercial 5G system deployment. Based on the study results, the charging architecture evolution and selected Rel-15 key functionalities for 5G system are under ongoing normative phase through development of a complete set of specifications (architecture, functionalities and protocols) A brief overview of the charging coverage for the Rel-15 5G system is provided in this article.
Service Based Interface
One key evolution of the charging architecture is the adoption of a service based interface integrated into the overall 5G system service based architecture, enabling deployments of charging functions in virtualized environment and use of new software techniques. The new charging function (CHF) introduced in the 5G system architecture, as shown in the picture below, allows charging services to be offered to authorized network functions. A converged online and offline charging will also be supported.
While offering the service based interface to the 5G system, the overall converged charging system will be able to interface the billing system as for the existing system (e.g. 4G) to allow Operators to preserve their billing environment. These evolutions are incorporated in the TS 32.240 umbrella architecture and principles charging specification. The services, operations and procedures of charging using Service Based Interface will be specified in a new TS 32.290, and TS 32.291 will be the stage 3 for this interface.
5G Data connectivity charging
The “5G Data connectivity charging”, achieved by SMF invocation of charging service(s) exposed by the charging function (CHF), will be specified in a new TS 32.255, encompassing the various configurations and functionalities supported via the SMF, which are highlighted below.
For 3GPP network deployments using network slicing, by indicating to the charging system which network slice instance is serving the UE during the data connectivity, the Operator will be able to apply business case charging differentiation. Further improvements on flexibility in charging systems deployments for 5G network slicing will be explored in future releases.
The new 5G QoS model introduced to support requirements from various applications in data connectivity, is considered to support QoS based charging for subscriber’s usage. 5G QoS-based charging is also defined to address inter-Operator’s settlements (i.e. between VPLMN and HPLMN) in roaming Home-routed scenario.
All charging aspects for data services in Local breakout roaming scenarios will be further considered.
In continuation with existing principles on Access type traffic charging differentiation, the two Access Networks (i.e. NG-RAN and untrusted WLAN access) supported in Rel-15 are covered.
Charging capabilities encompass the various functionalities introduced in the 5G system to support flexible deployment of application functions (e.g. edge computing), such as the three different Session and Service Continuity (SSC) modes and the Uplink Classifiers and Branching Points.
Charging continuity for interworking and handover between 5G and existing EPC is addressed.
In 5G Multi-Operator Core Network sharing architecture (i.e. shared RAN), identification of the PLMN that the 5G-RAN resources were used for to convey the traffic, allows settlements between Operators.
The stage 3 for “5G data connectivity charging” will be available in TS 32.298 for the CDRs’ ASN.1 definition and in TS 32.291 for the data type definition in the protocol used for the service based interface.
