How Multiband-Cells are used for MORAN RAN Sharing

In the previous blog post I have explained the concept of multi-band cells in LTE networks and promised to explain a bit deeper how such cells can be used in Multi-Operator RAN (MORAN) scenarios. 

MORAN is characterized by the fact that all network resources except the radio carriers and the Home Subscriber Server (HSS) are shared between two or more operators. 

What this means in detail can be see in Step 1 of the figure below. 

The yellow Band #1 spectrum of the multi-band cell is owned by Network Operator 1 while the blue spectrum of Band #2 and Band #3 belongs to Network Operator 2.

Band #1 is the default band. This means if a UE enters the cell is always has to establish the initial RRC signaling connection on Band #1 as shown in step 1.

The spectrum owned by Network Operator 2 comes into the game as soon as a dedicated radio bearer (DRB), in the core network known as E-RAB, is established in this RRC connection. 

Then we see intra-frequency (intra-cell) handover to Band #2 where the RRC signaling connection is continued. Band #3 is added for user plane transport as a secondary "cell" (the term refers to the 3GPP 36.331 RRC specification). 

The reason for this behavior can be explained when looking a frequency bandwidths. 

The default Band #1 is a low frequency band with a quite small bandwidth, e.g. 5 MHz. as it is typically used for providing good coverage in rural areas. Band #2 is also a lower frequency band, but Band #3 is a high frequency band with maximum bandwidth of 20 MHz. So Band #3 brings the highest capacity for user plane transport and that is the reason for the handover to the spectrum owned by Network Operator 2 and the carrier aggregation used on these frequency bands. 

However, due to the higher frequency the footprint of Band #3 is lower compared to the other two frequency bands. 

For UEs at the cell edge (or located in buildings while being served from the outdoor cell) this leads quite often to situations where the radio coverage of Band #3 becomes insufficient. In such cases the UE typically sends a RRC measurement event A2 (means: "The RSRP of the cell is below a certain threshold."). 

If such A2 event is received by the eNB it stops the carrier aggregation transport and releases the Band #3 resources so that all user plane transport continues to run on the limited Band #2 resources as shown in step 3.

And now in the particular eNB I observed a nice algorithm starts that could be seen as a kind of zero-touch network operation although it does not need big data nor artificial intelligence. 

10 seconds after the secondary frequency resources of Band #3 have been deleted they are added again to the connection, but if the UE is still at the same location the next A2 will be reported soon and carrier aggregation will be stopped again for 10 seconds and then the next cycle starts.

This automation loop is carried out endlessly until the UE changes its location or the RRC connection is terminated. 

Related Posts:

• The 3G4G Blog: What is a Multi-Band Cell? 

DCCA Features and Enhancements in 5G New Radio

In another new whitepaper on 5G-Advanced, Nokia has detailed DCCA (DC + CA) features and enhancements from Rel-15 until Rel-18. The following is an extract from the paper:

Mobility is one of the essential components of 5G-Advanced. 3GPP has already defined a set of functionalities and features that will be a part of the 5G-Advanced Release 18 package. These functionalities can be grouped into four areas: providing new levels of experience, network extension into new areas, mobile network expansion beyond connectivity, and providing operational support excellence. Mobility enhancements in Release 18 will be an important part of the ‘Experience enhancements” block of features, with the goal of reducing interruption time and improving mobility robustness.

Fig. 2 shows a high-level schematic of mobility and dual connectivity (DC)/Carrier Aggregation (CA) related mechanisms that are introduced in the different 5G legacy releases towards 5G-Advanced in Release 18. Innovations such as Conditional Handover (CHO) and dual active protocol stack (DAPS) are introduced in Release 16. More efficient operation of carrier aggregation (CA), dual connectivity (DC), and the combination of those denoted as DCCA, as well as Multi-Radio Access Technology DC (MR-DC) are introduced through Releases 16 and 17.

For harvesting the full benefits of CA/DC techniques, it is important to have an agile framework where secondary cell(s) are timely identified and configured to the UE when needed. This is of importance for non-standalone (NSA) deployments where a carrier on NR should be quickly configured and activated to take advantage of 5G. Similarly, it is of importance for standalone (SA) cases where e.g. a UE with its Primary Cell (PCell) on NR Frequency Range 1 (FR1) wants to take additional carriers, either on FR1 and/or FR2 bands, into use. Thus, there is a need to support cases where the aggregated carriers are either from the same or difference sites. The management of such additional carriers for a UE shall be highly agile in line with the user traffic and QoS demands; quickly enabling usage of additional carriers when needed and again quickly released when no longer demanded to avoid unnecessary processing at the UE and to reduce its energy consumption. This is of particular importance for users with time-varying traffic demands (aka burst traffic conditions).

In the following, we describe how such carrier management is gradually improved by introducing enhancements for cell identification, RRM measurements and reduced reporting delays from UEs. As well as innovations related to Conditional PSCell Addition and Change (CPAC) and deactivation of secondary cell groups are outlined.

The paper goes on to discuss the following scenarios in detail for DCCA enhancements:

• Early measurement reporting
• Secondary cell (SCell) activation time improvements
• Direct SCell activation
• Temporary RS (TRS)-based SCell Activation
• Conditional Secondary Node (SN) addition and change for fast access
• Activation of secondary cell group

The table below summarizes the DCCA features in 5G NR

Related Posts: 

• The 3G4G Blog: ATIS Webinar on '5G Standards Development Update in 3GPP Release 17 and 18'
• The 3G4G Blog: 3GPP's 5G-Advanced Workshop Summary
• The 3G4G Blog: What Is the Role of AI and ML in the Open RAN and 5G Future?
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G
• Free 6G Training: Deep Learning in the 6G Air Interface
• Free 6G Training: Kyocera Develops Transmissive Metasurface Technology for B5G and 6G
• Free 6G Training: 6G and B5G Prospects for Vertical Industry
• Free 6G Training: The Potential of Full Duplex in Beyond 5G and 6G
• Free 6G Training: Using a Dielectric Waveguide as a Pinching Antenna for B5G and 6G 

Managing 5G Signalling Storms with Service Communication Proxy (SCP)

When we made our 5G Service Based Architecture (SBA) tutorial some four years back, it was based on Release-15 of the 3GPP standards. All Network Functions (NFs) simply sent discovery requests to the Network Repository Function (NRF). While this works great for trials and small scale deployments it can also lead to issues as can be seen in the slide above.

In 3GPP Release-16 the Service Communication Proxy (SCP) has now been introduced to allow the Control Plane network to handle and prioritize massive numbers of requests in real time. The SCP becomes the control point that mediates all Signalling and Control Plane messages in the network core.

SCP routing directs the flow of millions of simultaneous 5G function requests and responses for network slicing, microservice instantiation or edge compute access. It also plays a critical role in optimizing floods of discovery requests to the NRF and in overall Control Plane load balancing, traffic prioritization and message management.

A detailed whitepaper on '5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)' by Strategy Analytics is available on Huawei's website here. This report was a follow on from the 'Signaling — The Critical Nerve Center of 5G Networks' webinar here.

Related Posts:

• 3G4G: 5G Service Based Architecture (SBA)
• The 3G4G Blog: Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Everything you need to know about 5G Security
• 3G4G: 3GPP 5G Specifications

AI/ML Enhancements in 5G-Advanced for Intelligent Network Automation

Artificial Intelligence (AI) and Machine Learning (ML) has been touted to automate the network and simplify the identification and debug of issues that will arise with increasing network complexity. For this reason 3GPP has many different features that are already present in Release-17 but are expected to evolve further in Release-18. 

I have already covered some of this topics in earlier posts. Ericsson's recent whitepaper '5G Advanced: Evolution towards 6G' also has a good summary on this topic. Here is an extract from that:

Intelligent network automation

With increasing complexity in network design, for example, many different deployment and usage options, conventional approaches will not be able to provide swift solutions in many cases. It is well understood that manually reconfiguring cellular communications systems could be inefficient and costly.

Artificial intelligence (AI) and machine learning (ML) have the capability to solve complex and unstructured network problems by using a large amount of data collected from wireless networks. Thus, there has been a lot of attention lately on utilizing AI/ML-based solutions to improve network performance and hence providing avenues for inserting intelligence in network operations.

AI model design, optimization, and life-cycle management rely heavily on data. A wireless network can collect a large amount of data as part of its normal operations. This provides a good base for designing intelligent network solutions. 5G Advanced addresses how to optimize the standardized interfaces for data collection while leaving the automation functionality, for example, training and inference up to the proprietary implementation to support full flexibility in the automation of the network.

AI/ML for RAN enhancements

Three use cases have been identified in the Release 17 study item related to RAN performance enhancement by using AI/ML techniques. Selected use cases from the Release 17 technical report will be taken into the normative phase in the next releases. The selected use cases are: 1) network energy saving; 2) load balancing; and 3) mobility optimization.

The selected use cases can be supported by enhancements to current NR interfaces, targeting performance improvements using AI/ML functionality in the RAN while maintaining the 5G NR architecture. One of the goals is to ensure vendor incentives in terms of innovation and competitiveness by keeping the AI model implementation specific. As shown in Fig.2 (on the top) an intent-based management approach can be adopted for use cases involving RAN-OAM interactions. The intent will be received by the RAN. The RAN will need to understand the intent and trigger certain functionalities as a result.

Ericsson White Paper - 5G Advanced: Evolution towards 6G - https://t.co/9ZKnC8PDxX#Free5Gtraining #Ericsson #5G #B5G #5GAdvanced #6G #5GNR #5GC #Timeline #XR #RedCap #NetworkAutomation #EnergySavings #DeterministicNetworking #IoT pic.twitter.com/eeI4SKvIRC

— Free 5G Training (@5Gtraining) July 21, 2022

AI/ML for physical layer enhancements

It is generally expected that AI/ML functionality can be used to improve the radio performance and/or reduced the complexity/overhead of the radio interface. 3GPP TSG RAN has selected three use cases to study the potential air interface performance improvements through AI/ML techniques, such as beam management, channel state information feedback enhancement, and positioning accuracy enhancements for different scenarios. The AI/ML-based methods may provide benefits compared to traditional methods in the radio interface. The challenge will be to define a unified AI/ML framework for the air interface by adequate AI/ML model characterization using various levels of collaboration between gNB and UE.

AI/ML in 5G core

5G Advanced will provide further enhancements of the architecture for analytics and on ML model life-cycle management, for example, to improve correctness of the models. The advancements in the architecture for analytics and data collection serve as a good foundation for AI/ML-based use cases within the different network functions (NFs). Additional use cases will be studied where NFs make use of analytics with the target to support in their decision making, for example, network data analytics functions (NWDAF)- assisted generation of UE policy for network slicing.

If you are interested in studying this topic further, check out 3GPP TR 37.817: Study on enhancement for data collection for NR and ENDC. Download the latest version from here.

Related Posts: 

• The 3G4G Blog: What Is the Role of AI and ML in the Open RAN and 5G Future?
• The 3G4G Blog: 3GPP Release-18 Work Moves Into Focus as Release-17 Reaches Maturity
• The 3G4G Blog: NWDAF in 3GPP Release-16 and Release-17
• The 3G4G Blog: 5G-Advanced Flagship Features
• The 3G4G Blog: 3GPP's 5G-Advanced Technology Evolution from a Network Perspective Whitepaper
• Free 6G Training: Qualcomm Pushing the boundaries of AI research 

GSMAi Webinar: Is the Industry Moving Fast Enough on Standalone 5G?

I recently participated in a webinar, discussing one of my favourite topics, 5G Standalone (5G SA). If you do not know about 5G SA, you may want to quickly watch my short and simple video on the topic here.

Next week I am participating in a webinar, "Open for Debate: Is the Industry Moving Fast Enough on Standalone 5G?" along with Peter Jarich, Radhika Gupta and Tim Hatt. Hope to see you there: https://t.co/TQ8Aa5LXYP #3G4G5G #5G #5GNetworks #5GTechnology #5GNR #5GStandalone #5GSA pic.twitter.com/Rd7hGvvCNe

— Zahid Ghadialy (@zahidtg) July 15, 2022

Last year I blogged about GSA's 5G Standalone webinar here. That time we were discussing why 5G SA is taking time to deliver, it was sort of a similar story this time. Things are changing though and you will see a lot more of these standalone networks later this year and even early next year. 

The slides of the webinar are available here and the video is embedded below:

Here are some of my thoughts on why 5G SA is taking much longer than most people anticipated:

• 5G SA will force operators to move to 5G core which is a completely new architecture. The transition to this is taking much longer than expected, especially if there are a lot of legacy services that needs to be supported.
• Many operators are moving towards converged core with 4G & 5G support to simply the core. This transition is taking long.
• For taking complete advantage of 5G architecture, cloud native implementation is required. Some operators have already started the transition to cloud native but others are lagging.
• 5G SA speeds will be lower than NSA speeds hence some operators who don't have a lot of mid-band spectrum are delaying their 5G SA rollouts.
• Many operators have managed to reduce their latency as they start to move to edge datacentres, hence the urgency for 5G standalone has reduced.
• Most operators do not see any new revenue opportunities because of 5G SA, hence they want to be completely ready before rolling out 5G SA
• Finally, you may hear a lot about not enough devices supporting 5G SA but that's not the device manufacturers views.  See this tweet from GSA 👇

#Supporting5Gstandalone

With 5G SA networks now being launched, GSA is already aware of 842 announced devices with claimed support for 5G SA, up 202% from 278 at the end of 2020.

Full report on: https://t.co/8f1fw4R2fI#5G | #SA | #Devices | #GSA pic.twitter.com/7LEoyasplm

— GSA (@gsacom) July 11, 2022

Do you agree with my reasoning? If not, please let me know in the comments.

Related Posts: 

• The 3G4G Blog: The Status of 5G Standalone (5G SA) Networks - March 2021
• The 3G4G Blog: What will 5G Standalone deliver?
• The 3G4G Blog: The Politics of Standalone vs Non-Standalone 5G & 4G Speeds
• The 3G4G Blog: 5G Reality Check - Data Rates
• Operator Watch Blog: Germany gets Two 5G Standalone Networks
• The 3G4G Blog: Minimum Bandwidth Requirement for 5G Non-Standalone (NSA) Deployment
• The 3G4G Blog: 5G Dual Connectivity, Webinar and Architecture Overview
• The 3G4G Blog: What about 5G Network Architecture Option 4 (a.k.a. NE-DC) ?
• Free 5G Training: 5G Use Cases
• Free 5G Training: 5G Adverts
• 3G4G: 5G for Absolute Beginners