A Healthy And Private Catalyst

This article dives deeper into these requirements, specifically the importance of Private Evolved Packet Core (EPC) and Disaggregated RAN (Radio Access Network) Infrastructure.

Thankfully, 5G-based private networks can power that connectivity for a million IoT devices over a half-mile radius, enabling devices to be managed, and data to be collected, in near-real-time for analysis and optimization.

These private 4G/5G networks can be dedicated to a specific Enterprise, venue, or geographic area. They can then leverage flexible spectrum access technologies with the ability to operate over unlicensed (WiFi), shared (CBRS), licensed (CBRS) spectrum along with CSP MVNO agreements in order to handover traffic outside their coverage area. Thus, they can offer the seamless connectivity and high-grade reliability required for the future. (See Figure 1.)

CORE NETWORK

Multi-Access Evolved Packet Core (EPC) Network

A multi-access EPC Core should support 4G, 5G NSA, and 5G-SA, with the ability to successfully integrate with multiple third party RAN suppliers, (including major OEMs like Nokia, Ericsson, Samsung, and Airspan). EPC could be located in servers on-premises or hosted as a SaaS offering. This core network function microservice should independently scale according to the service type or workload demand. These core functions should be deployed with a small CPU/memory footprint to support small/special groups of UEs, or with a large CPU and/or memory footprint to support large scale UEs. 

Private LTE Multi-Access EPC deployment should support dual-SIM or embedded soft-SIM environment. As an example, consider a soft-SIM solution where an OTA download is triggered by scanning a barcode. Based on relative signal strength and chosen service, the User Equipment or IoT device will either be instructed to attach to a PLM-ID associated with the local Enterprise network or to the PLMN-ID of the adjacent CSP. Users will attach to this macro-eNB when they roam outside the Enterprise coverage area or when they attempt to place an IMS/VoLTE (if capable) telephone call.

Cloud-Hosted

As hospital branches expand, more 5G features will likely be added. Therefore, the core should have the ability to host the CU and DU components as disaggregated gNB in the cloud. It should also have the ability to deploy anywhere, such as hyperscale Public Cloud (Google, Amazon), Hybrid, or 100% on premises.

Hospitals can also host EPC in an existing data center using Dell R740 or equivalent servers. In this situation, connection and session states are check-pointed to the DB. The core logic microservices are running with cached states and retrieve states from the DB on demand. So, if a microservice fails, a newly- spawned microservice can easily take over the work.

Single-Threaded Database 

A Redis-like state storage database for the core network functions allows flexibility without sacrificing performance. Client-side DB libraries provide advanced functionality for distributed Redis DB usage through individual Redis instances or by utilizing a Redis cluster. This provides the flexibility of deployment to utilize a single Redis server for multiple network functions, per network function type or per network function. 

Because Redis is a single-threaded database and a Redis cluster provides client redirects, scalability becomes a matter of introducing client-side libraries to realize those benefits. Since Redis is an in-memory store, it keeps latency down, enabling high performance at scale. 

Ultimately, a DBaaS would allow all scalability concerns to be separated from the client and to achieve optimal web scale performance. This architecture would also allow multi-access core network functions to provide local redundancy within a VNF, intra-site local redundancy, and inter-site geographical redundancy.

Packet Data Network Gateway (PGW) 

A flat architecture makes private LTE extremely adaptable, with local traffic staying o-nsite. This is done through a packet data network gateway (PGW) so the private network maintains a link to the outside world. The PGW provides data oversight such as packet filtering and serves as a connection point between: 3GPP and non-3GPP technology, cloud-native, fully containerized 5G multi-access Combo Core (4G and 5G), and 5G ORAN radio. These could meet the needs of today’s CBRS 4G installations, and 5G networks in the future.

ePDG 

Cloud-native ePDG supports high quality voice-over-WiFi calls over a common IMS back-end network. The ePDG enables a WiFi (non 3GPP access solution) and LTE EPC core network (3GPP access solution) is in commercial deployment. With hospitals running seamless VoLTE < > VoWiFi handovers, a Core EMS/S-VNFM solution that offers FCAPS and role-based access controls while managing CNFs is critical.

RADIO ACCESS NETWORK

Disaggregated RAN

The radio signal processing stack in both 5GNR and LTE is a service chain of functions which are processed sequentially. These functions are controlled using signaling derived from the packet core, specifically the MME in the evolved packet core (EPC), and the access and mobility management function (AMF) in 5GC.

Connected hospitals need Cloud-based RAN architecture that can quickly scale for both 4G and 5G networks. A step towards reducing such costs comes with the design of Cloud-RAN (C-RAN). This allows the monolithic BSs to be decomposed into (i) distributed radio elements with much smaller footprints and (ii) remote pools of baseband units that centralize the remaining RAN functions. (See Figure 2.)

The C-RAN concept evolves to a more flexible deployment by disaggregating RAN entities into Radio Unit (RU) equipment, Distributed Unit (DU), and Centralized Unit (CU). The concept of disaggregated RAN retains the benefits of centralization to enable coordinated and cooperative processing. Additionally, it allows a flexible deployment of services at the DU and CU located in cloud infrastructures offering which facilitates simpler network densification at the RU level.

In addition, because the system retains the benefits of cloud centralized RAN and edge cloud distributed RAN deployment models, real-time and non-real-time functions can be co-deployed deeper in the network.

The decomposition maps function in the stack as follows:

• The CU location is excellent for deploying user plane function (UPF) in the decomposed packet core architectures. The decomposed packet core is known as CUPS in 3GPP R14 and 5GC in 3GPP R15.10,11. Service delivery adaptation protocol (SDAP) (in NR only), packet data convergence protocol (PDCP), and RadioResource Control protocol (the control functions) are managed from a CU. These stack functions are packet-level manipulations (header compression, over-the-air ciphering) that aren’t timing sensitive and can be easily implemented in a virtualized environment. Midhaul link connects the CU to the DU functions.
• Time sensitive functions like radio link control (RLC), medium access control (MAC); and physical (PHY) layers map to a distributed unit (DU). The DU performs significant preparation for the RF layer including rate adaptation, channel coding, modulation, and scheduling. For the MAC layer, the functions of the DU are time sensitive because a transport block of duration of the Transmit Time Interval (1 ms in LTE) is produced for consumption by the PHY layer. The DU link to the downstream entity is called front and transports digitized RF samples in either the time domain or frequency domain.
• Finally, baseband radio functions, up and down conversion, and amplification along with any analog beamforming map into a remote unit (RU) deployed at the cell-site also known as a remote radio head (RRH). In some cases, a LO-PHY can also be integrated into the RRH. The interface to the DU to the RU is typically implemented using well-known interface standards such as Common Public Radio Interface (CPRI or eCPRI.9)

This decomposition and isolation of functions, along with the well-defined interfaces between them, allow operators to disaggregate software from hardware. Operators can procure software capabilities that execute in hardware supplied by a different vendor. This disaggregation is natural and relatively simple for the centralized unit (CU) because those functions can be easily virtualized. Disaggregation of the Distributed Unit (DU) is more challenging because of the real-time processing requirements of the MAC and PHY layers.

Splitting the architecture as described earlier creates 2 additional transport domains known as fronthaul and midhaul. These domains are implemented when RRH/DU split or CU/DU splits are exposed. In some cases, it’s possible to implement fronthaul over dark fiber, which is basically transport of time domain or frequency domain baseband samples between the DU and the RU/RRH. In other cases, transport techniques that rely on Ethernet, IP, or WDM, must be employed. Midhaul is basically the transport of GTP-u packets and associated control plane between the CU and the DU. This type of transport is easily implemented over IP.

PRIVATE NETWORKS = A PERFECT CATALYST

As the RAN and core become decomposed, it’s logical to create an intermediate location. This location consolidates the CU workloads and a user plane function (UPF) from the mobile core. These distributed UPFs facilitate offload, enabling local virtualized services or more efficient peering at a metro level. This unified platform approach supports infrastructure workloads and a variety of service-oriented workloads. 

Choosing the right architecture with Multi-Access core and Disaggregated RAN is critical in the digital transformation journey of smart hospitals or any Enterprise’s digital transformation. New architecture can support business-to-business (B2B) services such as tenancies offered to other businesses, and business-to-consumer (B2C) services in support of the operator consumer business, essentially transforming the way patients are monitored and eventually how decisions are made. 

At Cyient, we have been working with Enterprises, like hospitals, in their Digital transformation journey for over 2 decades. Our proven deployment approaches and customized solutions, proven processes, and extensive equipment knowledge, can help combat the various challenges CSPs must address for future 5G success.

For more information, please email [email protected] or visit https://www.cyient.com/. Follow Prasad on Twitter @Prasad71448876, on LinkedIn https://www.linkedin.com/in/prasadbhandaru/, and follow Cyient on Social Media and Twitter @Cyient.