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. As well as meeting these performance indicators 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 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 network sensing and zero-energy devices.

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 and at the same time reducing the overall complexity of the 6G standard. Drawing on the experience from 5G, the 6G core should be an evolution of 5GC. This will not only reduce time to market for new 6G features but lower the costs for integration and testing in the operators’ network.

This 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 16 illustrates trends for network 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 process 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.

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.

The 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. For example, 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.

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 specified 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, whereby the UE is connected only to 6G from the start. 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. Besides the reasons to avoid NSA stated above, the Dual Connectivity solution also 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 LTE, 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 18.

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 evolves to 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 evolving AI/ML technologies. There will also be standardized network function management between the RAN automation functions and the RUF and the RANAF.

By 2030, the RAN needs to optimize for a mix of 5G and 6G, including wide use of 5G-6G spectrum sharing on many legacy bands. Also 4G, especially for m-IOT, needs to be supported, but not optimized for, and hence not described further here.

The vision is that RAN performance is self-optimized by the RAN solution:

• Given available network resources(e.g. , spectrum, sites, transport) and UE population, RAN controls available resources to optimize performance in a geographic area, according to operators’ intent
• Performance dimensions: throughput, latency, capacity, energy consumption, NRAR, scalability, TCO, ease of use, security, …
• Differentiate by service types and user groups / slices
• Intents to balance between performance dimensions, service types, user groups and UEs with different radio conditions

The need to achieve the full optimization potential, aggregation/coordination between frequency bands and between radio sites as discussed above for 6G will apply also to 5G, although naturally limited by 5G specifications and UE capabilities. One possible solution could be a scalable scheduler architecture, that can provide full performance potential to coordinate over a high number of sector-carriers in e.g. Centralized RAN deployments, also possible to be scaled down to a medium or low number of sectorcarriers for traditional Distributed RAN deployments, and everything between.

RAN should leverage possibilities with a multipoint fronthaul, using IP routing for flexibility and resilience, pooling gains by decoupling RU resources from user-plane processing in baseband, reducing needs to peak dimensioning the fronthaul transport network and automated orchestration between RAN and transport domains.

By 2030, a common architecture supporting deployments on Cloud infrastructure, Purpose-built infrastructure or a mix should be available leveraging the continuously evolving solutions from the IT industry, such as cloud infrastructure, data pipelines, automation and AI/ML support functions.

The development of 5G provides some learnings worth noting when defining the future network architecture. Since cloud native design and deployment offers new implementation technologies and improved ways of working including software LCM, it inspired the introduction of the Service Based Architecture (SBA). This made the functional architecture of the 5G Core Network (5GC) in 3GPP more suitable for cloud deployment. The SBA makes the Network Functions (NFs) expose services via Service-based Interfaces (SBIs) instead of 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 is proven by the continuous increase of the number of NFs in the 5GC, from 22[1] in 3GPP Rel. 15 to 452 in Rel. 17. The number of SBIs has increased almost at twice the rate as the NFs, reaching more than 110 SBI in Rel. 17. The increase of NFs and NF services is strongly related to the introduction of new features and functions in the 5GC.

However, the flexibility of 5GC also drives complexity in standardization, development, and operational deployment in commercial networks. E.g., the Service Communication Proxy (SCP) introduced in Release 16 added several modes of operation of the inter-NF communication. These modes of operation need to be applied on a 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. This intricacy opens for the need of optimizations when evolving the architecture further by, e.g., considering how to minimize additional complexity at system level at introduction of new functionality. Preparation to manage the complexity in all steps from specification, development to operations will be important, e.g., using automation.

To further smoothen the introduction of 6G, the reuse of the industry's investments in 5G Core is important. This includes the granular QoS framework, the comprehensive support of network slicing, support for time-sensitive and reliable communication, and exposure of these network capabilities to address new end-user service opportunities. A part of the evolution of 5GC also includes possibilities for optimizations and simplification of the SBA, for example by reducing the dependencies across NFs or removing unnecessary flexibility to make the standardized architecture future proof. It could also be considered to bundle new features and functions with existing NFs, e.g., based on main consumer of the function, to reduce the pace of increase of the number of NFs and SBIs.

While 5GC is expected to evolve with NFs being common to 5G and 6G, 6G-only NFs must be expected. Other aspects that need further exploration is the area of energy efficiency in the core network deployments. This can partly be addressed in the functional architecture to support new RAN efficiency methods. Still the major opportunity is to enable power savings in the implementation architecture and the underlying cloud infrastructure, rather than in the 3GPP standardized architecture.

With the approach to base the core network on an evolved 5GC as opposed to start from a clean sheet of paper, the operators will be best positioned to monetize 6G from the beginning.

[1] Not all NFs expose SBIs in the release where they are introduced, but often consume SBIs.

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) and Wi-Fi voice using IMS will be required.

Technology and architecture for realization of new conversational use-cases is an ongoing industry discussion for 5G already. A prime example is XR conversational services, which are studied in 3GPP. Different models are considered, ranging from IMS extension to pure OTT models. We anticipate the usage in 5G will be the baseline for 6G.

Data is key to several processes and currently CSPs have created multiple independent data pipelines for specific purposes, to rigid and difficult to evolve.

The result is inefficiency by replicating the same data multiple times as well as bringing an approach which is hard to govern. We foresee an evolution where data management capabilities become a fundamental part of the CSP’s architecture and are introduced in a way that enables a stepwise and multivendor approach. Data management is a cross-cutting concern covering multiple domains, data sources and data of varying characteristics.

There are a few principles to follow:

• Collect once, use many
  Data is collected once and can be used by many consumers
• Data is managed in a federated approach
  There can be multiple data islands that are federated.
• Data is used in transparent, compliant and ethical ways
• Data Quality is ensured during the data lifecycle
• Data access is authorized enabling legal and ethical use.

Technically this also means that:

• An application can discover data which it can consume.
• An application can request to receive data to be consumed.
• Any resulting insights can be feedback as data into the data management functionality.
• Data lineage is supported.
• This enables data governance.

The data ingest architecture (for which further details can be read in below article Ericsson Technology Review -Data ingestion architecture for telecom applications ) is represented below:

Several data collection instances may exist in a network and such an instance can be part of multiple functions in the network which work in a federated approach – e.g. it can be part of the SMO as one data set of data islands.