6G network architecture – a proposal for early alignment

Enablers of monetization and exposure are critical to the development of 6G. Monetizing 5G capabilities is already a top priority for communication service providers today [4] and it is obvious that it will continue to be important in the 6G time frame as well. 6G networks must be able to reuse and expand on the evolution of 5G exposure and monetization functionality from day one.

The automation of network operations is another important trend impacting 6G development. As network complexity increases – with more radio-access technologies (RATs), new band combinations, more network slices, different functionalities and so on – it will become ever more difficult to find good optimization points manually. AI/ML functionality that replaces the manual work of developing, deploying, managing and optimizing the mobile network, including intent-based management [5], must, therefore, be a core component of 6G.

Cloud-native design and deployment is the third major technology trend impacting the development of future networks. A cloud-native design with containerized deployments enables an efficient separation of software from hardware. This form of disaggregation creates a possibility to separate evolution and innovation in the cloud-native applications running as workloads and the underlying cloud infrastructure and associated tooling. Additionally, it affects processes in the operation of the networks, such as tools for life-cycle management (LCM) and the automation of integration and deployment. Greater use of AI/ML technology will simplify network operation and optimization and is likely to have wider implications in terms of design and deployment.

The fourth and final trend shown in Figure 1 is network architecture evolution, which is the primary focus of this article. In our view, there are three main aspects of network architecture evolution that require early industry alignment:

1. Migration and spectrum aggregation
2. Radio-access network architecture evolution
3. Core network architecture evolution.
   
   

Migration and spectrum aggregation

Since carrier aggregation was introduced in 4G, any new RAT must be able to aggregate more spectrum than its predecessor to improve performance. Further, because the new spectrum that comes with new RATs is typically on higher bands, there is a greater need to combine with lower bands to achieve sufficient uplink performance and coverage.

5G was specified with multiple standardized connectivity options for how to combine 4G and 5G RAT. To avoid market fragmentation [6], the ecosystem settled for only two: non-standalone (NSA) New Radio (NR) and standalone (SA) NR. Even this has proven challenging, splitting the industry focus and pushing some communication service providers (CSPs) to launch 5G twice. The interworking between 4G RAN and 5G RAN for NSA has also proven technically complex for the whole ecosystem, with a large impact on networks and devices. The split control of the user equipment (UE) connection between the gNodeB and the eNodeB implies a tight coupling of the nodes, given that the RATs share a common set of UE capabilities.

In addition, for spectrum aggregation within 5G, two methods were specified (carrier aggregation and dual connectivity), driving extra complexity for interoperability between UE and networks.

5G also provided another solution to the migration problem, by allowing 5G to share spectrum on legacy bands with 4G using dynamic spectrum sharing. Although this provided a paradigm shift for how to migrate RATs, it brought challenges, specifically for overhead, due to 4G having many always-on signals.

Based on experiences from 5G, we believe it would be best to avoid specifying multiple connectivity options for migration to 6G and multiple spectrum aggregation methods within 6G. This decision will reduce complexity and help the industry to focus on a common track.

Radio-access network architecture evolution

Apart from the work done in the traditional standardization bodies, it is important to note that the industry move toward Cloud RAN opens a new multi-vendor environment with a separation of the software application from the cloud infrastructure.

Successful deployment of a standardized multi-vendor interface requires both significant business value and separation of concern to ensure that optimizations in one part of the system can be introduced without affecting other parts. The RAN-CN interface, with multi-vendor deployments all over the globe, is an excellent example of this. Other examples like RAN-UE and RAN-RAN mobility (X2, Xn) require more work because of more technical dependencies but the clear business value motivates the interoperability testing and integration costs.

In addition to the widely deployed multi-vendor interfaces in use today, a lower-layer split (LLS)/fronthaul interface has been identified as an important candidate for 6G and is currently being standardized for 5G. While the business value of an LLS/fronthaul interface seems to be increasing, there is a challenge with respect to the separation of concern, as small inefficiencies may directly lead to performance losses if not addressed properly.

Core network architecture evolution

Cloud-native design and deployment has provided new implementation technologies and improved ways of working such as software LCM. This development inspired the introduction of the Service-Based Architecture (SBA) of the 5G Core (5GC) network in the 3GPP (3rd Generation Partnership Project), which has made the functional architecture more suitable for cloud deployment by, for example, adopting cloud-friendly protocols. In the SBA, the network functions (NFs) expose services through Service-Based Interfaces (SBIs) instead of using point-to-point protocols, as in previous generations. The purpose of this change was also to create a more flexible and extensible architecture.

The extensibility of the 5GC that the SBA has enabled is demonstrated by the continuous increase in the number of NFs in the 5GC, which has risen from 22 in 3GPP release 15 to 45 in release 17. The number of SBIs has increased at almost twice the rate as the NFs, reaching more than 110 in release 17. The increase of NFs and NF services is strongly related to the introduction of new features and functions in the 5GC.

The flexibility of the 5GC also drives complexity in standardization, development and operational deployment in commercial networks, however. For example, the Service Communication Proxy introduced in release 16 added several modes of operation of the inter-NF communication [7] that need to be applied per SBI and NF service consumer. With different NFs supporting different modes of operation, this leads to a configuration complexity for multi-vendor SBIs of networks in operation.

While continuing to take advantage of the flexibility of the 5GC, further evolution of the architecture should aim to minimize complexity at system level when introducing new functionalities. The ability to manage the complexity in all the steps from design and development to operations will require greater reliance on automation techniques.

By combining existing 5GC extensibility with the potential improvements to the 5GC architecture proposed above, we believe that an evolved 5GC could support a new 6G RAT.

Key assumptions for the 6G architecture

The 6G architecture needs to support the expected new use cases and service requirements for the 2030 time frame and beyond, including enhanced support for immersive communication and new capabilities such as network sensing and zero-energy devices [1].

There is a need for an aligned industry view of a single 6G architecture, avoiding the multiple architecture options defined in 5G that caused delayed availability of 5G system 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.

In addition to the technology trends presented in Figure 1, the 6G architecture will be impacted by the need to support existing and evolving telecom-specific deployment, service, mobility and regulatory requirements. For example, it is expected that 6G will need to provide full support for telephony services and emergency calls, support seamless inter-RAT/system mobility, and reuse existing sites and transport networks.

Based on our understanding of the requirements, the technology trends and experience of 5G, as well as our belief in the need for an evolutionary approach, we have designed the 6G architecture proposal shown in Figure 2, which includes the key open interfaces between domains. The architecture is based on the principle of horizontal separation of the NFs from the underlying platform and overlying end-to-end (E2E) management and exposure.

6G radio-access network as a new standalone radio-access technology

Based on experiences from the 5G migration, Ericsson believes that the 6G RAT should be specified in standalone mode only, with UE that is connected to 6G alone. This would provide an aligned industry focus, avoiding the need to launch multiple versions of 6G. It also simplifies the architecture to have only one control point for the UE connection in the 6G RAN.

6G-connected UE should perform better than 5G UE in the same location. This means that 6G must be able to use potential new centimeter-wave bands together with legacy frequency division duplex and time division duplex bands. An efficient, dynamic spectrum-sharing mechanism therefore needs to be standardized from the start, allowing 5G and 6G UE 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 with 4G-5G spectrum sharing.

With 6G deployed on a mix of legacy and new spectrum, a good spectrum aggregation solution will be of critical importance. To allow full RAN optimization, and avoid complex interactions, this should be based on a single instance in the network to control a given UE, with mechanisms for fast adaptation regarding the spectrum that is used at any point in time. This means the full set of radio resources used for a UE connection is decided in one place, considering the full capability of the UE for different band combinations.

To meet increased demands on efficiency using deployed resources (spectrum and radio sites) and increased energy efficiency, a larger degree of elasticity and pooling of radio resources is needed. This includes using multiple radio sites and spectrum resources for connected mode transmission (distributed MIMO (multiple-input, multiple-output) [8], for example) when needed, but also the power down of radio sites or spectrum resources when not needed. Rather than using the concept of nodes represented by a physical base station at one radio site as the basis for optimizing RAN performance, in 6G it should be possible to optimize RAN performance per geographical area, using the radio sites and spectrum in that area according to 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. One possible standardized 6G RAN architecture is illustrated in Figure 3. 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 (RU) function and the radio network area (RNA) function. The complex control of resources across radio sites and spectrum is therefore contained within the RNA. This architecture opens the door for a RAN to optimize across a geographic area by connecting multiple radio sites with LLS to one RNA function, while maintaining the LLS as a key standardized interface.

Another key interface is an intra-RAN mobility interface between two RNA instances. The focus here is on the transfer of the UE control from a source RNA to a target RNA, and not on a complex interface to share control for the same UE (for dual connectivity, for example).

From a management point of view, the 6G RAN will evolve to be increasingly automated and expose a standardized intent-based management interface through the service management and orchestration (SMO)-based RAN automation functions [5]. Automation will occur both in the NFs themselves and in RAN automation functions (rApps) based on evolving AI/ML technologies. There will also be standardized NF management between the RAN automation functions and the RU function and RNA functions respectively.

Evolving the 5G Core to support the 6G radio-access network and new use cases

The strongest argument for building on the industry’s previous investments in the 5GC network, rather than starting from scratch, is that it will enable a smoother introduction of 6G and help position CSPs to monetize on it from day one. The most important 5GC features to build on and evolve into 6G include the granular quality-of-service framework, comprehensive support of network slicing and support for time-sensitive and reliable communication, as well as the exposure of these network capabilities to address new service opportunities.

The evolution of the 5GC also includes possibilities for optimizations and simplification of the SBA by, for example, reducing the dependencies across NFs or removing unnecessary flexibility to make the standardized architecture future proof. Reducing the pace of increase in the number of NFs and SBIs by bundling new features and functions with existing NFs (based on the main consumer of the function, for example) is an idea worth considering.

The extensibility of the 5GC architecture proves it can evolve to support a new 6G RAT. However, the 6G use case requirements will make it necessary to evolve some existing functionality and/or introduce new functionality into the CN. While 5GC is expected to evolve with NFs that are common to 5G and 6G, 6G-only NFs cannot be excluded.

Other aspects that need further exploration include the area of energy efficiency in CN deployments. This can partly be addressed in the functional architecture to support new RAN efficiency methods. But the major opportunity is to enable power savings in the implementation architecture and the underlying cloud infrastructure, rather than in the 3GPP standardized architecture.

A cloud-native approach with automation and artificial intelligence/machine learning from start

The 6G network should be designed to enable it to take advantage of the operational benefits that cloud-native design and deployment and network automation provide. This is particularly relevant with respect to the implementation domain and the adoption of relevant automation tools in operations of the network. At Ericsson, we believe that 6G standardization should focus on standardizing the functionality and interfaces needed for multi-vendor interoperability and avoid standardizing functionality that can better be handled in implementation and deployment.

At the same time, we think that the functional architecture standardized by the 3GPP should facilitate the cloud-native and automated deployment model where it makes sense. This includes considering functional dependencies of the underlying cloud infrastructure capabilities at a level that is high enough to allow the underlying technologies to evolve more independently to make it possible to benefit from the rapid evolution of cloud-native technologies. Other aspects include considering data pipeline and management that is more integrated into the architecture shown in Figure 2 and further defined in the AI-native definition [9]. This enables and enhances support of continuous service assurance monitoring, to handle the growing complexity in managing and optimizing the network automation transition toward zero-touch network operation.

Conclusion

At Ericsson, we believe that the whole telecommunications industry will benefit from early alignment on the key architectural principles of the future 6G network architecture. It is our position that the migration to 6G should be standardized as a single step, based on a new standalone 6G radio-access technology that is available on all needed spectrum bands and connected to a core network that is based on an evolution of the 5G Core network. This single step will ensure a strong industry focus and build on existing investments, while evolving the network capabilities needed for 6G.

We strongly recommend that 6G standardization focus on interfaces, network functions and services that are relevant for multi-vendor deployments to provide openness where it matters and enable increased focus in the standardization process. In addition, 6G solutions must be able to take advantage of the rapid evolution that is occurring outside of mobile industry standardization in areas such as cloud-native, artificial intelligence, machine learning, automation and related technologies, which should be included in the 6G system as a part of the implementation architecture and associated operational processes.

We are confident that early agreement on these principles will lead to both simplification and focus for 6G introduction, and ultimately enable early monetization by communication service providers.