Network architecture domains

The goal of 6G is to improve performance by meeting high demands on traditional performance indicators such as capacity, coverage, bitrates, and short latency, as well as new performance indicators related to service availability and assurance, predictability, network resilience and trustworthiness all while improving energy performance and sustainability. All above while ensuring a cost-effective deployment and smooth introduction into existing networks must be ensured.

To support the 6G visions and requirements, it is beneficial to standardize a 6G architecture that allows for a smooth introduction of 6G capabilities into the future public and private networks. We foresee that the 6G architecture will build on the ongoing trend of network horizontalization enabling the 6G RAN and Cor Network(CN) functions to benefit from the fast evolution of cloudification, IT frameworks, automation, open interfaces, and AI/ML.

Overall Architecture Direction

The 6G architecture needs to support the expected new use cases and service requirements for the 2030 timeframe and beyond. This will for example include enhanced support for immersive communication and new capabilities like sensing and zero-energy devices. 

The seamless reality of the future will provide new ways of meeting and interacting. New possibilities to work from anywhere, and new ways to experience faraway places and cultures making digitalization of industries and management of smart cities, enabling e.g. improved personal safety, less waste and improved sustainability possible.

Below Figure 12 illustrates network evolution trends towards 6G and the 2030 timeframe.

A top priority for operators today is to monetize 5G capabilities to improve top line revenue capture. This ongoing journey will continue in 6G to make it possible for 6G networks from day one to reuse and expand on the evolution of 5G exposure and monetization functionality.

Automation of business processes includes the automation of processes handling the full lifecycle of customers, partners, suppliers, products, orders etc., both from commercial and operational aspects. A successful automation also includes aligned and easy to use APIs, exposing relevant services to external actors, to enable the automation processes to spawn business borders, e.g. application provider – aggregator – connectivity provider. 

Yet another trend is the leveraging of the IT eco-system, realized by the adoption of cloud native design and deployment. The cloud native design with containerized deployments enables an efficient separation of SW from HW.

A final trend is about network architecture evolution itself. It will be key to focus on network architecture being an evolution of the 5G System (5G SA) to 5G Advanced and further to 6G.

In addition to the above trends, the 6G architecture will be impacted by the need to support existing and evolving telecom specific deployment, service, mobility, and regulatory requirements. It is expected that 6G needs to have full support for telephony services, emergency calls, as well as support for seamless inter-RAT/system mobility, and reuse of existing sites and transport networks. 

There is a need for an aligned industry view of a single 6G architecture, avoiding the multiple architecture options defined in 5G which caused delayed availability of 5GS network capabilities. This will help to reduce the overall complexity of the 6G standard. Reducing complexity is important, as it will cut down the time to market for new 6G features and the costs for integration and testing in mobile networks. Drawing on the experience from 5G, the 6G should be an evolution of 5GC, the 6G RAT should be specified in standalone mode only and the 6G architecture should be based on an evolutionary approach with only key open interfaces standardized. 

The 6G architecture is based on the principle of horizontal separation of the network functions from the underlying platform and overlying e2e management and exposure.  More detailed aspects of this architecture are further discussed in the following sections. 

The 5G standard specification of multiple connectivity options, including Non-Standalone (NSA) 5G (NSA) and Standalone 5G (SA), lead to a fragmentation in the market, and a delay of introducing 5G services. Based on these experiences, the 6G RAT should be specified only in a Standalone mode, avoiding the diversion of the 5G two-step approach. This provides an aligned industry focus, avoiding the need for launching multiple versions of 6G whilst simplifying the technical architecture.

In 2030, the legacy spectrum assets (FDD, mid-band TDD and high-band TDD) are expected to be extended with new centimetric range spectrum (7-15 GHz) for 6G, possibly subject to co-existence with incumbent non-3GPP use.  A 6G-connected UE should have better performance than a 5G UE in the same location. This means that 6G must be able to use potential new centimeter-wave bands together with legacy FDD and TDD bands, to improve throughput aggregation and uplink performance/ coverage. 

The 5G standard included two methods to combine with legacy spectrum, namely Multi-RAT Dual Connectivity (= Non-Standalone 5G) and 4G-5G Dynamic Spectrum Sharing. The NSA and Dual Connectivity solution in 5G, proved to be technically complex for the industry, with large impact on the old RAT and simultaneous uplink transmission in UEs. The split control of the UE connection between the gNB and the eNB implies a tight coupling of the nodes, given that the RATs share a common set of UE capabilities. Hence, an efficient dynamic spectrum sharing mechanism needs to be standardized from the start, allowing 5G and 6G UEs to share a common pool of resources. Given that 5G has significantly less need for always-on reference signals than 4G, there are opportunities to significantly improve efficiency compared to 4G-5G spectrum sharing. 

With 6G deployed on a mix of legacy and new spectrum, 6G needs to provide a good spectrum aggregation solution. To allow full RAN optimization and avoid complex interactions such as the Dual Connectivity in 5G, this should be based on a single instance in the network to control a given UE, with mechanisms for fast adaptation on what spectrum is used at any point in time. Thus the full set of cells used for a UE connection is decided in one place, considering the full capability of the UE for different band combinations. 

To meet increasing demands on efficiency using deployed resources (spectrum, radio sites), and increasing requirements of energy efficiency, a higher degree of elasticity and pooling of radio resources is needed. This includes using multiple radio sites and spectrum resources for connected mode transmission (e.g. Distributed-MIMO), when needed, but also the ability to power-down radio sites or spectrum resources when not needed. This dissolves to some degree the concept of a “node” in RAN to be represented by a physical base station at one radio site. Instead, RAN performance will be optimized per geo-graphical areas, using the radio sites and spectrum in that area per current needs. 

In such a RAN system, the functional dependencies between different parts of the system controlling the resources will be even higher than today. The industry must be very careful to select the key interfaces to be standardized for potential multi-vendor integration, considering both the business values and the feasibility from a separation of concerns perspective. A possible high-level 6G RAN architecture is illustrated in Figure 14. 

The LLS interface is included as a key interface natively supported in 6G RAN, splitting the RAN into two logical network functions – the Radio Unit Function (RUF) , and the RAN Area Function (RANAF) . The complex control of resources across radio sites and spectrum is hence contained within the RANAF, allowing e.g. efficient carrier aggregation across RUFs from different vendors. This architecture opens the door for a RAN to optimize across a geographic area by connecting multiple radio sites with LLS to one RANAF, while maintaining the LLS as a key standardized interface.

Another key interface is an inter-RANAF mobility interface between two RANAF instances. Focus is on transfer of the UE control from a source RANAF to a target RANAF, and not on a complex interface to share control for the same UE (e.g. for Dual Connectivity).

From a management point of view, the 6G RAN will be automated exposing a standardized intent-based management interface via the SMO-based RAN automation functions. Automation will be done in both the Network Functions themselves, and in RAN automation functions (“rApps”), leveraging AI/ML technologies. There will also be standardized network function management between the RAN automation functions and the RUF and the RANAF.

The evolution of 5G has provided valuable insights for defining future network architectures. A notable development is the introduction of the Service-Based Architecture (SBA), inspired by cloud-native design principles. This architecture makes 5G Core Network (5GC) more adaptable to cloud environments by exposing the services of Network Functions (NFs) through Service-Based Interfaces (SBIs) rather than traditional point-to-point protocols. The aim was to create a more flexible and extensible system, with a side-effect of a sharp increase in number of NFs from 22 in 3GPP Release 15 to 45 in Release 17.

While this flexibility facilitates the introduction of new features, it also adds complexity to standardization, development, and operational deployment. For example, the Service Communication Proxy (SCP) introduced in Release 16 brought various modes for inter-NF communication, complicating configuration across multi-vendor environments. There is a need to minimize this complexity, potentially through automation and optimization strategies.

Looking ahead to 6G, it is fundamental to leverage existing investments in 5GC. This includes utilizing the granular Quality of Service framework, network slicing, and time-sensitive communication capabilities. Future enhancements could involve simplifying the SBA, reducing NF dependencies, and strategically bundling functionalities to manage the growth of NFs and SBIs. 

Additional functionality including new NFs for new 6G specific capabilities and services is expected and should be defined with the evolved 5GC target architecture as baseline. These new capabilities being investigated includes but are not limited to Sensing, AI, data infrastructure, M-IoT and NTN.

Energy efficiency in core network deployments is another area requiring attention, with potential power savings through implementation architecture and cloud infrastructure. It is important to learn from the experiences of the standardization of 5G and use the evolved 5GC as a baseline for standardizing a core network for 6G instead of again start from a clean slate. This will enable operators to be better positioned in capitalizing 6G from the start.

An IMS-based communication system has been the foundation for voice services in 4G and 5G. It is assumed that IMS will be the communication engine also for future regulatory telephony communication services like voice and emergency services in 2030/6G timeframe. The main reasons include the maturity and wide support in both networks and device eco-system. It can also be expected that 6G interworking with 5G (and 4G) using IMS will be required.

Technology and architecture for realization of new conversational use-cases is an ongoing industry discussion for 5G already. New use cases will be adopted in a 2030+ timeframe, using 5G deployments and later 6G. One such use case is immersive communications, which may require a combination of time critical communication capabilities, computational offloading resources (e.g., for rendering), and appropriate deployment practices (e.g., use of high-capacity bands, densification, etc.). 

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

Over the years multiple independent data pipelines for specific purposes have been created by CSPs, which has created an unnecessarily rigid and difficult situation, resulting in data handling inefficiency and a situation where data has become difficult to govern.

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

To create this consolidation, Data Meshes can be created in a CSP network (EDCA). See Data Ingestion Architecture below in Figure 15. 

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 and will play a central role in AI/ML model training such as acting as a pipeline for refinement into a data pipeline for AI/ML created from data ingested using EDCA principles.

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 Ericsson Federated Data Lake (EFDL) as shown in the Data Ingestion Architecture in Figure 15 below.

By creating a data mesh, data collected by one data mesh island can be 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 and consumed 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 distinguish 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.