Network architecture domains

The telecom industry and academia have been researching 6G wireless technology since more than five years and initial 6G standardization work in 3GPP has started.

6G will act as a foundation for a cyber-physical continuum, merging the digital and physical worlds, supporting extreme usage scenarios and massive scaling, with demanding applications across industries, society, and consumer domains.

Key capabilities such as ultra-low latency, high precision positioning, sensing, etc. will enable advanced industrial and societal applications while merged reality, digital twins, and collaborative robotics, will be driving innovation in mission-critical and consumer services.

Obviously 6G will be AI-native and Agentic AI in place from the start. This will be part of introducing automation, based on intent for self-optimization with a smooth and spectrum-efficient integration leveraging multi-RAT spectrum sharing and evolving 5G core components.

Regarding the introduction of 6G we should remember that we are around mid-way through 5G and a top priority for operators today is how to monetize 5G SA and 5G Advanced capabilities to improve top line revenue reusing and expanding on the evolution of 5G.

At the same time, business efficiency includes the automation of processes handling of the full lifecycle of customers, partners, suppliers, products, orders etc., from both commercial and operational aspects. Automation will complement and eventually replace manual work to develop, deploy, manage and optimize the mobile network and includes intent-based management.

Above evolution includes adoption of Artificial Intelligence and Machine Learning (AI/ML) technology including generative AI as well as AI agents which are needed to simplify network operation and optimization.

Data is recognized as a crucial asset and is already a fundamental part of the CSP’s network.

It is expected that future mobile networks continuously benefit from the continuous breakthroughs in the areas of cloud native adoption, automation of network operations and AI/ML.

A central trend is about network architecture evolution itself. To support the 6G vision and requirements, it is beneficial to standardize a 6G architecture that allows for a smooth introduction of 6G capabilities into future public and private networks.

The top-level view for a 6G network starts with the Global Network Architecture, shown in Figure 1 above, representing a transformational view in how networks must be built, operated, and opened up for innovation. Instead of dedicated, well-defined, and vertically integrated nodes connected in a static network setup, the networks are evolving towards a more dynamically adaptable architecture where Network Functions (NF) and applications are running where and when they are needed to optimize performance, cost, and business agility.

6G should be used to leverage and expand the usage of the network as an innovation platform, realizing more of the platform capabilities in the real networks in parallel with the evolving ecosystem.

Separation through horizontalization between HW, cloud, transport, data pipelines, network applications, management, and monetization will consequently make interfaces supporting this horizontalization more important for multi-vendor deployment.

In this transition, correct modularization of network functionality is crucial. An open radio interface, open RAN-CN interface and global roaming specified in 3GPP are the remaining basis to support the global scale representing a strong ecosystem.  Figure 12, below shows the 6G Network Domain Architecture.

The following categories are examples of such open interfaces are shown:

• Uu, a new stand-alone 6G radio interface operating in new / existing frequency bands, efficient spectrum co-existence with legacy RATs
• Roaming, interconnect for control and user plane evolved from 5G
• RAN-CN interface, as an example of a key network-internal standardized interfaces incl. also RAN internal (LLS), RAN-RAN, CN internal and CN-CN.

In addition to the interfaces shown in Figure 12 there will be interface(s) enabling vendor-specific exposure for data sharing, CI/CD, SW delivery pipelines, managed service, etc.

RAN’s main purpose is to transfer end-user application data, that may have different patterns and needs, between UE and CN, by using provided resources such as spectrum, sites, hardware and transport. Long-term, an automated self-optimizing RAN that optimizes RAN performance in a geographic area (rather than per node/board/cell), steered by intents, (not excluding other solutions) given a set of provided resources can be envisaged.

The performance of a RAN covers several dimensions that increase end-user experience or decrease the CSP’s TCO. Such examples include data rates, latency, capacity, coverage, energy consumption, TCO, ease of use, NRAR, etc.

The importance of above dimensions varies between different contexts and for example, the desired performance in different dimensions will depend on service categories (service differentiation) and end-user groups (subscriber group & slice differentiation), while NRAR will be imperative for Mission Critical Networks.

The long-term evolution of a self-optimizing RAN means that the management interface towards RAN has evolved to describe what RAN shall optimize for (intents for the RAN service) rather than how RAN shall operate (setting thousands of parameters related to traditional FCAPS management).

RAN automation is integrated in all levels of the RAN functional domain and includes high-level RAN automation (rApps and SMO platform capabilities) as well as automation in the RAN NF’s and RAN will be AI native.

The current best thinking of a RAN standard target architecture is shown in Figure 13. It illustrates that the 6G RAN consisting of 6GNB’s, which can internally be connected with an LLS interface (e.g. an evolution of the O-RAN Open Fronthaul interface (OFH)), into a RAN Area function (RANAF) and one or more Radio Units (RU).

High-level automation functions deployed in SMO can manage these RAN network functions via standardized logical interfaces for NF management (based on evolution of O1, A1, R1, m-plane).

Ericsson is embracing all RAN-internal interfaces above as potential Multivendor interfaces, where we need to comply and be prepared to do interoperability testing, at least with basic/limited performance/features. However, it is expected that the main deployment model for multi-vendor RAN will continue to be by RAN vendor geographic areas, using interoperable Inter-RAN Area Mobility i/f.

In 6G the lower-layer-split (LLS)/O-RAN Open Fronthaul (OFH) interface between the RANAF and the RU should be standardized and implemented as a multi-vendor interface. Currently an (typically single-vendor-) LLS is used in practice in all RAN products and deployments thereof.

6G should be a new stand-alone RAT, meaning 6G capable UEs will connect directly to 6G capable base-stations when in coverage. Simultaneous 5G and 6G connectivity (similar to the NSA NR) should not be standardized since it will delay stand-alone 6G deployments, increase the overall development effort (maintain several tracks) and limit the performance potential of the 6G.

The 6G radio standard should support optimized spectrum sharing between 6G and 5G, and non-optimized spectrum sharing between 6G and LTE (incl. NB-IoT), aka Multi-RAT Spectrum Sharing (MRSS). This will quick support and efficient single vendor deployment of 6G in existing 5G bands maximizing spectrum, power and HW usage.

The theoretical overhead of 5G/6G MRSS is small enough to expect 5G/6G MRSS deployments to be very common.

To optimize RAN performance across spectrum and geography, efficient multi-dimension RAN coordination, Figure 14, can be done by using different resources across resource instances. It will be important to handle multiple dimensions of radio resource coordination, including, e.g. :

• Carriers / spectrum (e.g. Carrier Aggregation, and selection of serving sector carrier, UL/DL carrier decoupling)
• Transmission/Reception Points (e.g. Interference management, UL COMP and other multi-TRP / D-MIMO features)
• Inter-RAT spectrum sharing (e.g. 5G-6G spectrum sharing in the same sector carrier)
• Multi-band power pooling (how multiple bands supported by one Radio Unit can share one transmit power resource)
• Agile PIM avoidance (i.e. schedule to avoid PIM and then use full power without backoff)

In addition, there are non-radio resources to be managed, such as transport and processing HW resources. All these resources should as far as possible be treated as pools of resources which can be flexibly used depending on current needs.

Much of this RAN coordination also needs to happen fast enough to match the bursty nature of real traffic patterns.

With massive use of 5G-6G spectrum sharing, enabling use of legacy spectrum for 6G, there is a need for very fast and efficient sharing between the RATs within a sector carrier. This will be a challenge to be solved by RAN vendors and will likely require standards on the Uu to provide enablers for this. Also, other parts of the specifications should take height for that a given sector carrier can be shared between a 5G cell and a 6G cell.

The core networks for initial 6G deployments need to address a range of different aspects to be relevant in 2030 and beyond. A first aspect is to efficiently support multiple access network generations. This applies in particular to 5G SA to provide an optimized mobility between 5G and 6G. This is instrumental for a smooth introduction of 6G.

Therefore it makes sense that 3GPP will use the evolved 5GC as baseline when defining the 6G CN support for a 6G radio network, in contrast to defining a new 6G core network. There may be new features in Core to support the 6G RAN and 6G UEs, but these should be considered from the angle of having limited impact on the overall architecture.

There are several reasons why 6G CN should evolve from 5GC such as the need to support LTE and NR interworking beyond 2030 or simply leveraging industry’s investments already made in 5GC (3GPP, vendors and CSPs) as well as continued monetization leveraging already deployed 5GC enabled services based on e.g., the granular Quality of Service framework, network slicing or time-sensitive communication capabilities.

To address these existing use cases supported by 5GS, the resulting 6G CN is outlined in Figure 15. This basic 6G support impacts all NFs in 5GC to a lesser or larger extent, e.g.

• AMF handling both 6G-RAN and NG-RAN
• SMF and UPF single anchor point with 6G enhancements
• UDM handling 5G & 6G user data
• PCF handling 5G & 6G policy data

Furthermore, to enable new business opportunities the 6G CN will include additional functionality, including new NFs for new 6G specific capabilities and services, which should be defined with the above architecture as a baseline. Following are some examples of such new capabilities under investigation:

Integrated Sensing and Communication (ISAC), described in chapter Integrated Sensing And Communication (ISAC). Anticipated to work in coexistence and leverage other existing NFs like NRF for registration and discovery, and NEF for exposure.

AI will be a central part of the evolution to 6G as outlined in chapter AI in the Network architecture and used as a realization technology inside NFs as well as for optimization tools near the core network.

A distributed data infrastructure, with a network wide framework for data collection and management, required to support many use cases, like AI, see chapter Data handling

Massive-IoT will be part of the first release of 6G, which gives an opportunity to correct some of the drawbacks in the 4G/5G standardization of M-IoT, such as adopting traffic models to actual usage, etc.

6G NTN will further evolve the deployment options and integration between TN and NTN networks. From a core network perspective there are multiple aspects to consider depending on the chosen deployment model. The main integration model between TN (MNO) and NTN (SNO) would be to reuse the roaming interfaces.

Energy efficiency in core network deployments is another area requiring attention, with potential power savings through implementation architecture and cloud infrastructure.

The telco industry view is that IMS will serve as communication engine also in 6G, for 3GPP and non-3GPP access (e.g., Wi-Fi, NTN), providing, at a minimum regulated telephony, emergency services and SMS in wide area networks enabling support by the 4G and 5G IMS solution, with minimal changes. The same position applies to SMS, both for SMS over NAS and IP.

This allows for reuse of the investment and the user experience of these services, simplifying the interworking with 5G and 4G. To protect earlier investments, the 5GS roaming should be reused, with minimal changes, to mitigate the roaming challenge of supporting roaming to 2G/3G still in use in the 2030-time frame.

For a smooth 6G introduction, the CSP should migrate to an IMS based voice solution prior to launching 6G. Only minimal changes to IMS are foreseen, e.g., to address 6G location to enable IMS in 6G system (6G enabled IMS). This will be an evolution of the existing voice in 5GS architecture. It is further recommended to only evolve the SBI interfaces of IMS to avoid evolution of Diameter interfaces for 6G.

The evolution of communication services to immersive communication in 6G will span different technologies like; enabling web experiences in the context of a telephone call (IMS DC), Immersive visual and audio experiences (XR), introducing AI agents/assistants, in the context of telephony, etc.

Technology and architecture for realization of new conversational use-cases is an ongoing industry discussion for 5G already.

Ericsson is exploring and evolving our architecture to embrace the use of AI in service execution. Architecture needs to support interaction with agents, between agents and with supporting AI capabilities like Language models, multi-modal models and tools.

Our aim is to evolve a single IMS architecture to support multiple use-case categories, where application logic can reside fully under CSP control, but also open for interaction with 3rd party, including Exposure/APIs and Media.

High level architecture to enable telephony enrichment use-cases is depicted below, Figure 17 including the examples of web, XR and AI.

Data handling is a cross-cutting concern covering multiple domains of data sources and data of varying characteristics. Data management capabilities will become a fundamental part of the CSP’s architecture as it is key to several processes.

Over the years multiple independent data pipelines for specific purposes have been created by CSPs, creating an unnecessarily rigid and difficult situation, resulting in data handling inefficiency and challenging governance of data.

The benefits of a common consolidated data ingestion for CSPs include significant OPEX and CAPEX cuts and possibly increased average revenue per user (ARPU).

To create this consolidation, Data Meshes can be created in a CSP domain (DMF) using EDCA functionality incorporated into our products and in the Ericsson domain, the Ericsson Federated Data Lake (EFDL). See Data Ingestion Architecture below in Figure 18.

A CSP can leverage consolidation of data in several ways one of which is using it to enable Network Automation. The data could also be exposed through Network APIs or playing a central role in AI/ML model training acting as a pipeline for refinement into a data pipeline for AI/ML created from data ingested using EDCA functionality.

Several data collector instances may exist in a network and be part of multiple functions in the network working in a federated approach – e.g. being part of the SMO as one data set of data islands.

In a customer network, the data mesh concept can be used to tie data islands in several Ericsson products into one data mesh which may also be connected to a corresponding data mesh in the EFDL as shown in the Data Ingestion Architecture below.

By creating a data mesh, data collected in a data mesh island is mirrored to other data mesh islands if the same data is required by these. From an application point of view, data in all data mesh islands can be discovered, consumed and leveraged, provided that the application has the required access- and authorization level.

Applying a data fabric in the customer network and on the Ericsson side, turns the two data meshes into a universal data mesh. The same principle can be applied in the reverse direction and allow Ericsson applications in a customer network to access data in one of the Ericsson application clusters.

The Data Fabric and EFDL will decrease the extra load on the transport network deployment as  manipulations to the data can be made without moving data. This is also referred to as a “no data copy solution” to separate it from centralized solutions.

A CSP can leverage the EFDL for a number of other solutions to improve their network business in areas like support and serviceability, extended AI/ML training, evolved LCM (DevOps, MLOps, etc.).

Another advantage is that a CSP can leverage access to data from the EFDL to draw on analytics insights, reports, data for AI/ML training. This achieved via a Data Fabric which applies the necessary access policies, contracts, legislation adherences, etc.

As a reminder some of the principles for Data Handling are listed below:

• Collect data once, use many times
• Manage Data in a federated approach with multiple Data islands
• Data should be used in transparent, compliant and ethical ways
• Data Quality must be ensured during the data lifecycle
• Data access needs to be authorized to enable legal and ethical use.