Network deployment examples
The network architecture caters for the introduction of new technology, the coexistence of different generations of technology and supporting new use cases
Delivering the full 5G experience will involve enhancing many existing use cases and creating new ones that cannot be fulfilled using current technologies, through for example:
- Deploying 5G NR radio access to deliver capabilities far beyond those of previous cellular generations, including massive system capacity, very high data rates, very low latency, ultra-high reliability and availability, low energy consumption, and energy efficient networks – wherever and whenever needed
- Deploying 5G Core for introduction of cloud-native deployment and operational model including automation of network and service management
- Distributed Cloud, to enable workloads to be placed closer to the network edge for better QoS (shorter latency), transport efficiency and higher integrity of data
As 5G will need to coexist and interwork with 4G (and 2G/3G) for many years to come, we’re likely to see most of these deployments as non-stand-alone initially, as a way of reducing time to market and ensuring good coverage and mobility. Important aspects for 5G migration include
- Efficient spectrum utilization using spectrum sharing between LTE and NR
- NR carrier aggregation for optimal performance
- Tight interworking between 5G Core and EPC with common functionality for devices connecting over both NR and LTE access.
In order to achieve the best time to market and maximize the reuse of existing network resources, a two-phase approach is needed to deploy 5G to ensure that the full potential of 5G can be achieved as quickly as needed:
- Start with non-standalone NR (NSA NR, aka UE connectivity option 3). This option uses LTE/EPC as the control plane anchor and uses either LTE or NR or both for user traffic (user plane). This approach is based on existing LTE/EPC and provides time to market benefits for introduction of NR. Operators can deploy dual connectivity for data (high throughput in NR downlink, best coverage in LTE uplink), while voice traffic is fully on LTE.
- One of the main drivers for going beyond option 3 is to provide 5G Core-enabled capabilities like enhanced network slicing, edge computing support and operational benefits, even though EPC can also support these services to some extent. Another main driver for going beyond option 3 is to be able to deploy standalone NR and get the radio performance benefits of an NR-only based radio interface. Option 2 (standalone NR) is the 5G Core-based option available in UEs and networks.
Even if general NR coverage may initially be limited, option 2 can initially be deployed for specific use cases in local areas, where devices stay within good NR coverage on a mid or high band. Examples include industrial deployments with ultra-reliable low latency communication requirements, and fixed wireless access (FWA).
An operator must consider which functions shall be co-sited, and which functions might be better placed at other sites (separate, or co-sited with other network functions). There are several factors that affect which will be the best solution for each operator:
- Stay with the classic Distributed RAN (DRAN) architecture also when deploying NR. This will provide good performance and has minimum modification of existing network architecture. This architecture is suitable for large parts of an operator’s network.
- Evolve the transport network to support very high user data rates. Dark fiber will in many cases be the most cost-efficient alternative, why deploying a Centralized RAN (CRAN) architecture may be beneficial. Centralized RAN is suitable in urban and in some suburban cases where the site distances are not too large. The benefits are improved coordination between sites with Carrier Aggregation, as well as pooling of baseband hardware.
- Consider virtualized RAN (higher-layer-split of CU and DU) deployments added on top of both DRAN and CRAN. However, it is only recommended when cloud infrastructure is already deployed to reuse the cloud investment
- As much centralization as possible for lowering OPEX based on economy of scale. However, distribution of user plane functionality will be needed for supporting distributed cloud.
- The RCF would be more centrally placed depending on availability of fiber as well as other benefits of centralizing the baseband unit. The placement of the PPF will be dependent on the placement of UPF.
- Deployment of voice related network functions is a compromise based on many factors, for example speech path delay, fast call set-up time, short service interruption time at mobility.
A private LTE/5G network is comprised of 3GPP products but used within an industry (enterprise) for its own data and personal communication needs. There is no public access, only authorized devices/users can use the network resources. In 3GPP terminology a private network is called a “non-public network”.
The standard set of functions for voice and data shall be supported by the network infrastructure to leverage the device eco-system. Special interest groups such as 5G Alliance for Connected Industries and Automation (5G- ACIA) develop the eco-system for industries. In many cases business and mission critical capabilities for survivability are combined with specific communication services such as push-to-talk/video.
Deployment cases range from national public safety networks to small campus systems.
- Wide-area private networks covering a region, or a country are similar to regular public networks in how they are deployed: Examples include public safety, mainline rail and utilities.
- Local networks for manufacturing and public/enterprise venues, hospitals, airports, campus, range in 1000s within a country. The network architecture evolution follows the architecture evolution in 3GPP, but deployment size is much smaller in terms of area covered and number of supported devices. Deployment options are needed ranging from local standalone private networks to different levels of integration to external networks, e.g. with and without roaming/interconnect to other PLMNs and internet.
Private networks have stringent technical requirements (latency, reliability, availability, local mobility, positioning etc.) and additional operational requirements: local O&M, local data, local survivability, integration to existing IT/OT (Information Technology/Operational Technology) systems.
The Private network is a system comprised of RAN (E-UTRAN, NG-RAN), Core (Combined Evolved Packed Core – EPC and 5G Core – IMS/VoLTE, Positioning and Mission Critical Push-to-Talk (MC-PTT). Management is done from an Operational Support System – OSS, typically with management functions for local monitoring and self-service by the enterprises. Business Support System (BSS) may be included but it shall be noted that for local stand-alone system charging is typically not included. Various device types from ruggedized phones to IoT gateways (modems) and Nb-IoT/Cat-M devices etc. can be connected via the private network.
Deployment vary not only between industry segments, but there are also very different scenarios within each segment. For example, the utility segment ranges from wide-area electricity grid network and meters (electricity, gas, water) to local power generation plants: hydro, wind, nuclear. Resilience and survivability are critical aspects and put demands on redundancy schemes (core, radio) and on the management solution.
- Regional or wide area coverage for non-public use (public safety, mainline rail, utilities):
A wide-area solution as for regular public network but typically focus on specific (3GPP) communication services such as MC-PTT. High-availability /resilience including power-backup are required. Typically deployed in low-band spectrum.
- Local standalone deployment for the needs of the OT-domain.
All functionality needed for the specific OT use case is deployed locally to fulfill both technical and non-technical requirements including legal and commercial constraints. Local area spectrum allocation (industry spectrum), indoor coverage and capacity are in focus. The high-availability / ultra-reliable low latency requirements for demanding use-cases will start in local stand-alone deployments.
- Central or shared functions for cases with less stringent requirements on e.g. local survivability and local data. In such cases functionality may be deployed outside the customer premises site at either communication service provider or industry player network sites. This may also happen if industries use cloud-based solutions for data analytics etc.
The figure below shows an example for the case where parts of the functions in the private network are centrally located. The IT domain uses the network infrastructure deployed for the OT domain. In this example, only the RAN infrastructure is shared between IT and OT domains, and all other functionality for the IT domain is deployed outside customer premises. OT communication is isolated entirely from the IT and Internet via a DMZ (De-Militarized Zone) and any interactions towards the OT layer are limited to a very controlled set of data over secure interfaces terminated at the DMZ.
Connected vehicles and road infrastructure are part of a broader IoT ecosystem that is continuously evolving. To ensure cost efficiency and future-proof support, Communication service providers aim to meet the connectivity demands of multiple industry verticals, including the automotive and transport industry, using common physical network infrastructure, network features and spectrum resources. Cellular connectivity for the automotive and transport services is relevant from four perspectives: massive IoT, broadband IoT, critical IoT and industrial automation IoT.
Figure 32 illustrates how cellular connectivity works for vehicles and roadside equipment. It visualizes vehicles as multipurpose devices in which several connectivity-dependent use cases are executed simultaneously. At the same time, each vehicle also contains an internal network that interconnects in-vehicle sensors, actuators and other devices, including driver and passenger smartphones.
Millions of cars are already connected using 4G cellular access, and cellular broadband IoT connectivity (4G/5G) is expected to grow significantly through 2024 as outlined in Ericsson Mobility Report.. Connected vehicles incorporate applications such as fleet management, in-vehicle entertainment, internet access, roadside assistance, vehicle diagnostics, navigation and advanced driver assistance services. The Automotive Edge Computing Consortium (AECC) estimates that the related data traffic has the potential to exceed 10 exabytes per month by 2025, a volume 1,000 times larger than the present numbers.
Most of the data traffic of connected vehicle services have relaxed latency requirements, which can be leveraged by the service provider for more-efficient usage of existing network resources with minimal cost and interference to existing services. The transfer of such data will be opportunistic, which implies it will be delivered in the background of normal data transfer without seizing network resources from normal traffic.
The policy rules for traffic separation can be provided either statically or dynamically using the Service Capability Exposure Function (SCEF), which is provided by the mobile network towards the OEM. The SCEF is evolving into the Network Exposure Function (NEF) in 5G Core.
The more dynamic approach enables a vehicle application to trigger what policies to be applied by the PGW/UPF, such as requesting a policy with lower priority (lower than best effort) with lower tariffs. By that different policies can be applied for different applications running in the same UE.
To alleviate the pressure of high volume of data, the Cellular Network (both EPS and 5G Core) will support data offloading to designated edge servers. The edge servers are typically connected to a center server as in a distributed computing architecture. The deployment of the edge servers shall be selected at appropriate places in the Cellular Network to meet the service requirements on latency, capacity and cost.
Figure 33 depicts an end-to-end architecture using dedicated bearers for traffic separation, considering distributed computing with edge clouds. The edge cloud servers are shielding the central cloud servers by executing the heavy lifting workloads. The central servers coordinate the heavy workload functions and distribute the load across different edge cloud servers and sites. The central cloud servers steer the vehicle’s connection to an appropriate edge, which supports the service and has sufficient computational capacity.
To alleviate the pressure of high volume of data, the Cellular Network (both EPS and 5G Core) will support data offloading to designated edge servers. The edge servers are typically connected to a center server as in a distributed computing architecture reference model. The deployment of the Edge servers shall be selected at appropriate places in the Cellular Network to meet the service requirements on latency, capacity and cost.