Functionality to be deployed in different locations

Network architecture domains

The Network Architecture needs to provide for various types of functionality and at the same time be able to deploy that functionality in different physical locations.


Figure 19 High-Level Network Architecture

Figure 19 High-Level Network Architecture

The Future Network Architecture needs to provide for a lot of various types of functionality and at the same time it is required to be able to deploy that functionality in different physical locations. Therefore, the architecture is separated into functional domains and topological domains.

Horizontal domains:

  • “Access - Mobility - Network applications” contains functionality securing access as well as network integrated applications. Is divided into Access, Packet Core and Communication services
  • “Transport” contains functionality for transmission and transport primarily between sites but also within sites
  • Cloud infrastructure, Data pipeline” contains functionality for secure processing and storage of both network functionality as well as application functionality. The data pipeline supports all network domains with collection, storage, distribution and processing of data.
  • “Management, Orchestration, Monetization” contains functionality to manage and control the network as well as running the business management of customers to the network. Further it contains the exposure of network functionality to external applications
  • “Applications” contains network external applications and is utilizing the network for communication, execution and storage

Vertical domains:

  • “Devices / Local networks” – The actual device used by a user or a network set-up by a user or enterprise outside the control of the service providers
  • “Access sites” – Local sites which are as close as possible to the users
  • “Distributed sites” – Sites which are distributed for reasons of execution or transport efficiency or for local breakout
  • “National sites” – National sites which are typically centralized within a service providers’ network
  • “Global sites” – Centralized sites which are publicly accessible from anywhere, typically a large data center

Listed below the picture are some important attributes that the network is providing:

  • Sustainable – it is used for many, if not all, communication purposes with little or no damage to the environment
  • Reliable & Resilient – it is always available
  • Cloud native – the network itself is implemented being cloud native as well as supporting cloud native implementation of applications
  • Secure – it supports the trust needed in being the communication platform for the entire society
  • Data driven - data is generated and used to manage and orchestrate the network as well as supporting the applications with relevant information

Global connectivity and services have by tradition been deployed in a federated model, where the interfaces are well standardized and offered by one service providers. The complexity with multiple networks has been hidden through interoperability and inter service providers exchange models. However, the rapid deployment of new features makes the traditional standardized federated model hard to use. New methods of enabling exposure of assets from multiple networks is needed, like network asset facilitation and exchange or, on service providers request, aggregation into a single offer

Figure 20 Network architecture business interfaces

Figure 20 Network architecture business interfaces

The architecture supports various types of business interfaces:

  • Service exposure of network capabilities to applications & a 2-sided business model irrespective if the application resides in or outside a service providers domain
  • Network access and transport for devices and local networks
  • Roaming and interconnect between service providers


The external interfaces of the Radio Access Network (RAN) domain are standardized under 3GPP, as is the functional behavior of the RAN domain. Below the high-level specification, 3GPP leaves room for innovation to enhance the network with RAN-internal value-add features — a flexibility that has over many years resulted in continuous improvement in many areas, including spectrum efficiency, energy efficiency, and enhancements to service characteristics. To determine the optimal architectural split, however, the RAN architecture needs to be examined with a finer level of granularity than that offered by 3GPP. Based on function and interface characteristics, preferred execution environment, and spectrum efficiency, the target functional composition includes the following logical ran nodes,

The RAN consists of a set of functions; mobility, radio-link control, beamforming, scheduling, etc. realized by software executing in infrastructure located in various radio sites. The radio unit (RF) with its antenna system, the distributed unit (RPF) and the central unit (RCF/PPF) build up the RAN and may be placed at different locations, connected through a transport network to each other and by that covering the functions of a RAN.

Figure 21 RAN Architecture

Figure 21 RAN Architecture

For RAN there are two horizontal interfaces relevant for the ability to geographically distribute functions across the RAN SW stack:

  • The interface denoted F1 or Higher Layer Split (HLS) that separates the Distributed Unit from the Central Unit as specified in 3GPP.
  • The Fronthaul (FH) or Lower Layer Split (LLS) between the RF and the RPF that separates the radio from the digital processing as partly specified in O-RAN Alliance.

From a functional perspective, cloud RAN is a system (of HW and SW) where the RAN functions can dynamically be allocated in time and location.  This means that the SW realizing the function can appear where and when it is needed. In this way the functions can be dynamically allocated across different hardware and sites.

  • Radio function — RF
    The RF requires special radio hardware and includes functions such as modulation, D/A conversion, filtering, and signal amplification. A beamforming function is introduced and may be co-located with either the RF or the RPF.
  • Radio processing function — RPF
    Given the stringent requirements for spectrum efficiency, the RPF benefits from being placed on a special purpose processor. The RPF includes user-plane functions that are synchronous to the Hybrid automatic repeat request (HARQ) loop and it is also the anchor point for carrier aggregation and soft combining. The RPF contains the fast radio scheduler, and is also responsible for the coordinated multi point, for the selection of the MIMO scheme, and for beam and antenna elements.
  • Packet processing function — PPF
    The PPF, which is suitable for virtualization, contains user-plane functions that are asynchronous to the HARQ loop, and includes the PDCP layer — such as encryption — and the multipath handling function for the dual connectivity anchor point and data scheduling.
  • Radio control function — RCF
    The RCF handles load sharing among system areas and different radio technologies, as well as the use of policies to control the schedulers in the RPFs and PPFs. At the user and bearer level, the RCF negotiates QoS and other policies with other domains and is responsible for the associated service level agreement (SLA) enforcement in the RAN. The RCF controls the overall RAN performance relative to the service requirement, creates and manages analytics data, and is responsible for the RAN SON functions. Like the PPF, the RCF is suitable for virtualization.

In a deployment, each function (RF, RPF, PPF, and RCF) is instantiated. An instance of the radio functions will be associated with many antenna elements at an antenna site, and a set of RF instances are connected to one instance of the RPF. Each antenna element (RF) is associated with one RPF. Hence, an RPF instance handles the cells corresponding to the RF antenna elements it is associated with. Local mobility is hidden under the RPF and not visible to the PPF or the Packet Core.

Each instance of the RCF can handle a small or a large set of PPFs — and all the associated RPFs. In this way, the RCF can keep a holistic view of an area that is just a single cell, up to an area consisting of thousands of cells. With this architecture, RRM coordination and spectrum efficiency within a system area can be maximized, using the full suite of RRM features available.

Packet Core

The core will exist in an environment that is cloud-based, applying cloud native design principles for scalability, dynamic orchestration of network resources, and a modular and highly resilient base architecture. Moving to 5G there will exist different migration paths, either based on Evolved Packet Core (EPC) or based on a newly defined core network architecture, 5G Core. EPC with functional additions to support the NR radio access though Multi-RAT Dual connectivity together with LTE provides a relatively light weight effort to migrate to 5G. 5G Core is built on a new architecture paradigm, Service Based architecture, with new reference points and services used between network functions in the control plane. While 5G Core has advantages over EPC, it is worth highlighting that it is a new architecture and network paradigm that shall be deployed in the service provider’s network.  5G Core is for NR stand-alone deployments and interworking with EPC will remain important to maintain service continuity with EPC, especially in the initial phases and until NR is available on lower bands.


Figure 22 EPC architecture

Figure 22 EPC architecture

The EPC consists of the following functions including sub-functions:

  • Mobility Management Entity (MME)
    is the key control function in the EPC network. The main functionality of the MME is attach and detach of UE, authentication, choosing SGW and PGW for the UE, and management of PDN connections and EPC bearers. It also handles mobility procedures, UE tracking, and paging.
  • PDN Gateway (PGW)
    is the gateway between the internal EPC network and external PDNs, for example, the Internet or a corporate LAN. The PGW provides IP connectivity towards external PDNs, policy and admission control, and packet filtering per user. The PGW can also be used for charging.
  • Serving Gateway (SGW)
    routes and forwards the user packet data from the UE to the PGW or from the PGW to the UE. The SGW acts as a local mobility anchor for the user plane during inter-eNodeB handovers and provides charging functionality.
  • Policy & Charging Rules Functions (PCRF)
    handles policy control decisions and flow-based charging control functionality. The main functionality is to evaluate operator policies that are triggered by events received from various functions and to provide rules for application and service data flow detection, gating, QoS and flow-based charging
  • Home Subscriber Server (HSS)
    is a central database that contains user-related and subscription-related information. The functions of the HSS include functionalities such as storage of the long-term security credentials, subscriber profiles, access authorization, mobility management support
  • Service Capability Exposure Function (SCEF)
    is used to securely expose the services and capabilities provided by 3GPP network interfaces. The functionality is brought to 3GPP for standardization through a function called Application Network Interaction Function (ANIF).
  • User Plane (UP) includes e.g. functionality for mobility anchor point, external PDU session point of interconnect, packet routing & forwarding, QoS handling for user plane, packet inspection and policy enforcement lawful intercept

5G Core

The key principles of the 5G Core architecture are as follows:

  • A flexible and extendable service-based network architecture
  • Allows for different core network configurations in different network slices and allow for resource isolation between network slices
  • Allow for a user equipment to be simultaneously connected to multiple network slices (more advanced than multiple APN)
  • Support subscriber identification and authentication based on IMSI as well as non-IMSI identities a unified EAP based authentication framework
  • Separation of Control plane (CP) and User plane (UP) to:
    • Allow scalability of UP and CP functions independently
    • Allow for a flexible deployment of UP separate from the CP, i.e. central location or distributed (remote) location (i.e. with no restriction in the location compared to the CP).
  • Support a generic user-plane function that enables both centralized and distributed deployments in a network, and the possibility to have different instances of the UP function centralized and distributed at the same time
  • Unified Policy framework with extensions from the policy framework in EPC
  • Abstract the transport domain from 3GPP network functions to allow for independent evolution and to enable service providers to use different transport technologies (e.g. Ethernet, MPLS, SDN-based transport, etc.).
  • Support wireline and wireless access convergence. An architecture supporting both legacy and 5G Core capable residential gateway is needed. User planes support multiple accesses and is optimized for high throughput
Figure 23 5G Core architecture

Figure 23 5G Core architecture

The 5G Core consists of the following network functions:

  • Access & Mobility management Function (AMF) includes e.g. the following functionality:
    • Termination of RAN CP interface (N2)
    • Access Authentication and Authorization support
    • Mobility management
    • AMF selection for handovers with AMF change
    • Handling of policies for mobility management
    • Lawful intercept (for MM events and interface to LI System)
  • Application Function (AF)
  • Authentication Server Function (AUSF) includes e.g. the following functionality:
    • Interacts with the UDM for retrieval of the corresponding security credentials for the user.
    • Terminates the request to select and trigger the execution of the authentication of the user.
  • Charging Handling Function (CHF) allows charging services to be offered to authorized network functions
  • Location Management Function (LMF) supports location determination for a UE
  • Network Data Analytics Function (NDAF) provides network analytics information to a network function on a network slice instance level
  • Network Exposure Function (NEF) provides a means to securely expose the network services and capabilities, Similar functionality as ANIF/SCEF.
  • Network Repository Function (NRF) includes functionality to find network functions and services to support e.g. the establishment of a PDU Session. Network function service discovery enables network functions to discover instance(s) that provide the expected service(s).
  • Policy Control Function (PCF) includes e.g. the following functionality:
    • Supports unified policy framework to govern network behavior.
    • Evaluates operator policies that are triggered by events received from various functions.
    • Provides rules for application and service data flow detection, gating, QoS and flow-based charging.
  • Session Management Function (SMF) includes e.g. the following functionality:
    • Selection and control of user plane function
    • Session management including session authorization
    • UE IP address allocation & management
    • Policy & Charging rules handling
    • Lawful intercept
    • Roaming functionality
  • SMS Function (SMSF) activates/deactivates SMS service for a service user and send SMS payload
  • Unified Data Repository (UDR) is a repository of subscriber information and can be used to service several network functions
  • Unified Data Management (UDM) is an evolution of the HSS/AuC and includes e.g. the following functions:
    • Storage of the long-term security credentials.
    • Information storage of subscriber profiles and related management.
    • Access authorization.
    • Location/mobility management support.
  • User Plane Function (UPF) includes e.g. the following functionality:
    • Anchor point for mobility
    • External PDU session point of interconnect
    • Packet routing & forwarding
    • QoS handling for user plane
    • Packet inspection and policy enforcement
    • Lawful intercept
    • Traffic accounting and reporting
  • Non-3GPP Interworking Function (N3IWF) is used to connect e.g. untrusted WLAN

Further reading

Communication services

Communication services has been a fundamental part of telecom networks since the networks appeared. Most networks were originally created for a single service, voice telephony. Communication services can be divided into two categories;

  • Communication services that are interoperable between communication service providers / operators and supported in most devices and networks.
  • Communication services provided by a single service provider with co-designed client/devices.

Interoperable communication services of today must be backward compatible to the legacy and support interoperability to older generations of the services still in use.

The fundamental service definitions and network architecture for interoperable communication services such as telephony, messaging, etc. are already in place. The services and their IMS based architecture will be reused for all 3GPP access also in the 5G era, in order to provide services with Quality of Service (QoS) also in challenging radio and mobility conditions. This means that the 5G Core and NG RAN must include similar capabilities as in 4G VoLTE to ensure voice KPIs. In addition, seamless mobility between EPC and 5G Core meeting voice KPI’s are introduced to support migration, since extremely few networks will have full NR SA coverage the day 5G core is introduced.

New communication service opportunities will be enabled by 5G engagements into non-traditional segments/customers and their communication need. In most cases communication services are not the focus of the initial engagements. Communication services are however expected either as a utility, or as a value add leveraging the initial investments and deployments. It is in these engagements and new segments we expect new innovative services and communication means like XR, holographic conferencing to emerge. The offerings and the supporting architecture must fit the emerging business models and more complex value chains which will arise in these new segments. The network architectural impacts come from both the service and its delivery model as well as the need for flexibility and automation.

The IMS architecture is still being evolved in 3GPP to support service-based interfaces to the 5G packet core (5G Core). IMS will be able to use 5G Core via new service-based interfaces (SBI) as an alternative to legacy Diameter interfaces.

Figure 24 New service-based interfaces between IMS and 5G Core

Figure 24 New service-based interfaces between IMS and 5G Core

Evolved management architectures in cloud environments will fundamentally change how IMS applications are deployed and managed. This does not mean that the traffic view of IMS network architecture must or will change. The cloud mechanisms and functions are complementary to the mechanisms and traffic functions in the IMS Network architecture. The network scaling functionality in IMS is required for geographic redundancy purposes.

Figure 25 Communication services functions

Figure 25 Communication services functions

The Figure 25 above is a conceptual illustration of the heart of the Communication Services architecture; the IMS parts. The IMS architecture supports IP communication services over any access technology (e.g. NR, LTE, WiFi and Fixed) and interworks with 2G/3G networks. It consists of an IMS core providing a multitude of functions such as: SIP session handling (e.g. registration, authentication, routing and service invocation), emergency calls, Interconnect and Roaming, NNI enforcement, charging, accounting, number portability, restoration procedures. It also consists of IMS application functions for, IMS telephony and IMS Messaging. Communication service evolution may enrich existing application functions or introduce new ones. An example of a new application function is Mission Critical Push-To-Talk (MC-PTT) which recently has been standardized in 3GPP.

Further reading

Cloud infrastructure

The cloud infrastructure ensures the robustness, performance, security and interoperability needed for modern applications. This requires a system that beside traditional cloud capabilities provide telco apps with a real-time network support, while providing new sets of enablers that act as a bridge to cloud-empowered telco applications and solutions.

Application scalability and the introduction of new technologies are both facilitated by the independent life cycles of application components and the services they use. Container as a Service (CaaS) increases the portability of the applications to several IaaS solutions, and thus helps reduce the number of cloud execution platforms that need to be supported.

The cloud native application is composed from set of independent services each with different capabilities and/or functionalities. Services are grouped into functional areas, that is, each functional area offers a set of different building blocks to be used by application architects. A functional area is defined for application services with unique capabilities which are characterizing that application.

An application, with its different instances, can be deployed into a single container execution environment. It is managed by a single container orchestrator entity. The APIs is used both by network applications and by network external applications.

To make cloud ready to support telco and mission critical applications, availability requirements are to be met as well as several others:

  • Automation of management operations
  • Monitoring support
  • Logging support
  • Security
  • Tenant isolation
  • Upgrade support
  • Backup and restore
  • Quick restart time
  • Independent restart
  • Network protocol support
  • Alarms
  • Performance counters
  • Trace support
  • Soft real-time
Figure 26 Cloud architecture

Figure 26 Cloud architecture

  • Cloud execution environment provides basic cloud services typically provided by an IaaS environment or bare metal.
  • CaaS contains functionality that is common to all services running on top of the CaaS e.g. policy management, container orchestration, networking, container runtime, deployment support etc.
  • Generic services contain services that are common to all type of applications, also many cases for the rest of the industry e.g. data management, key/value store, relational data service, data warehouse, malware protection, firewall etc. As part of the generic services we can find specialized platform services, providing very specialized services for horizontal use cases that would span across several application categories.
  • Core services contains services that are common to all type of services (whether they are application services or belongs to any of the layers in the platform). Examples are trace, log, alarm, performance management, backup & restore, license management etc.
  • Domain Specific Services contains services that are common to a specific domain, for example IoT, media, OSS/BSS.
  • Application Category Services contains services that are common to an application category within a vertical.

Further reading

Management, Orchestration, Monetization

Management of the virtualized environment and new services becomes even more important as all services has a need to be managed in real-time. This dynamic and competitive environment requires management of the networks and their supporting systems to be:

  • Less expensive to manage and maintain
  • Self-provisioned to drive down costs in an instant-access, cloud, and application-driven world
  • Flexible and modular to support “network slices” and “micro services” for new use cases driven by market needs
  • Deployable at speed to roll out new services with “zero touch” fulfillment
  • Scalable, with an agile IT operational model.
  • Bridge the physical and virtual environment

The virtualization/NFV promises to bring cost efficiencies, time-to-market improvements and innovation to the telecommunication industry infrastructure and applications. The new environment will achieve these functionalities through disaggregation of the traditional roles and technology involved in telecommunications applications.

The architecture will support creation of a management system that will provide an easy adaptation of business processes to the ever-changing business landscape which allow for a fast introduction of new products and services helping the service providers to keep be ahead of competition.

The architecture will enable a highly automated operation striving towards zero touch operations. This will lead to drastically reduced OPEX for the service providers.

There is also a drive for openness to with the notion of reducing cost for integration and lower barrier for innovation. From an overall level, there is a clear shift away from standardization, or more specifically standardization only, as the forms of industry alignment. This shift towards an open source approach is visible in three ways:

  • Service providers are working more with their own architectures (alone or with selected traditional and non-traditional vendors) and the large service providers are making a subset of their architecture public to influence the community. 
  • There is a continued increase in open source initiatives in orchestration and management. ONAP being the most prominent but also others like Open Source Mano have impact.  Some of the open source initiatives align with standards (or promote certain standards) though this is not the case with all.
  • Service providers are producing their own operational support systems using both in-house components and open source components.

The following are the founding principles based on which future reference architecture will be built for an environment possible for real time management of the ecosystem:

  1. An open and transparent architecture
  2. Micro service-based architecture
  3. Data centric applications – where the application logic should have control on how, what, and when the data can be exposed
  4. Support and expose open APIs to allow easy access to management data
  5. SDK (Development runtime, tooling, documentation, and reference applications) where applicable
  6. Repository of reusable, deployable, and runnable applications. (that can be further integrated and/or extended)
  7. To a high degree based on open source technologies
  8. Platform agnostic execution environment
Figure 27 OSS/BSS Architecture

Figure 27 OSS/BSS Architecture

The architecture needs to embrace automation and the movement towards autonomic networks to tackle the complexity increase brought by the technology innovation. This reflects both the possibilities enabled by technology as well as need of service providers to introduce new offerings to the market quickly and reduce their cost of operation. Automation and network governance will become essential for avoiding this spiral of complexity. This automation must be combined with machine learning and in the longer term also artificial intelligence algorithms applied to life cycle management operations, with domain policies to facilitate and improve speed in development of automation functionality.

The domain management functions serve the underlying functional domains, from the basic management point of view, they take a role of element management functions and more advanced domain specific OSS functions.

Network exposure focuses on community innovation; service development across domains via component assembly and flexible business and commercial models to expose the network capabilities to the applications that are used by external developers, consumers and enterprises. Network exposure will provide an integrated environment where service creation (“the real-time call flow”) and management workflow creation (OSS/BSS support) come together.

The network capabilities are made available to the application developers via defined APIs e.g. basic connectivity management services, transport optimization services, identity services, security services etc. There is potentially a need for brokering between the application providers and network service providers. For example:

  • The cloud execution can utilize the cloud infrastructure provided by a network service provider, a public cloud provider or be a private cloud.
  • The facilitation has the potential to reduce complexity and fragmentation when exposing network assets from many service providers.
  • The aggregation aggregate capabilities from many networks and address the many-to-many problem between a network service provider and application providers.

The developer shall not need to consider the integration of each network service provider. Which in practice means that interfaces to multiple network service providers shall be consolidated.


The latest demands on the transport network come from areas such as increasing RAN and mobile broadband service capacity, new 5G-enabled services and the dynamic deployment flexibility of the 5G RAN split architecture, with its tight transport characteristics. These characteristics are especially manifested in the fronthaul portion of RAN transport where the latency and synchronization requirements are very challenging. Enhanced automation capabilities in the operations and management domain represent a key requirement to meet these challenges.

The strong drive towards virtualization of network functions will have a clear impact on transport flexibility. As soon as a VNF moves, the transport must immediately be reconfigured to support the new topology. The major challenges for transport are programmability, flexibility, and finding the right balance of packet and optical technologies to provide the demanded capacity. This will be a major OPEX driver in the transport network unless it is fully automated. This is especially true in the mobile-centric part of the network.

To achieve this software-defined networking (SDN) will be an important entity that offers a programmatic interface towards the higher layers of transport control. SDN can be used along with an intelligent application, the transport intelligent function (TIF), to design an optimal 5G transport network architecture.

The optimal 5G transport network is built as a self-contained infrastructure underlay with an SDN-controlled overlay for a variety of RAN and user services. The distributed control plane in the underlay maintains the basic infrastructure and handles redundancy and quick restoration in case of network failures. The service and characteristics aware overlay are handled by the SDN controller with the TIF application, and this creates a dynamically controlled and orchestrated transport network that requires minimum manual interaction. In other words, the underlay network described here handles the infrastructure connectivity and the network overlay handles the services running on top of the underlay.

During a long transition time there will exist both SDN controlled equipment as well as legacy transport equipment, so the higher layers transport control will have to operate with a multitude of protocols. The figure below exemplifies this by illustrating how transport setup can optimized by using information from both RAN and the transport network and using different legacy protocols when reconfiguring the network.

Figure 28: Interaction between RAN and transport

Figure 28: Interaction between RAN and transport

There is a need for Analytics, Policy, Control functions and specific Northbound APIs for service orchestration and SLA reporting. Collection, presentation and correlation of various Transport service level parameters on a per service basis is one of the key capabilities required. Also, necessary level of isolation and prioritization between the various network services needs to be maintained.

The main propositions of the future transport architecture can be summarized as:

  • Service agility, programmability, enhanced visibility & cross domain orchestration
  • There are 4 major components for this layer to support the mentioned characteristics: Configuration Management, Path Management, Topology Management and Utilization management
  • Specific applications for both local Transport domain optimization but also to support cross-domain orchestration functions will be needed.
  • The infrastructure layer is built using a stacked underlay/overlay architecture. A service-based overlay providing L2 or L3 VPN service endpoints with MPLS-SR TE on top of a fully routed underlay topology based on IP and IS-IS.  IPv6 based forwarding plane is also one of the industry directions for the future
  • All management functions that can be centralized will be centralized and only the most needed functions will stay in the infrastructure layer like OAM monitoring and fast reroute solutions.
  • Ubiquitous transport service e.g. using Ethernet VPNs (EVPNs) from all the way from the access to termination in a datacenter and between datacenters is envisaged

Further reading