ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 1 | .. |
| 2 | SPDX-FileCopyrightText: © 2020 Open Networking Foundation <support@opennetworking.org> |
| 3 | SPDX-License-Identifier: Apache-2.0 |
| 4 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 5 | SD-Core as a Cloud Managed Service |
| 6 | ================================== |
ajay | 60fd69f | 2021-11-23 22:38:10 -0800 | [diff] [blame] | 7 | |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 8 | * SD-Core is a flexible, agile, scalable and configurable dual-mode 4G/5G core |
| 9 | network platform that builds upon and enhances ONF’s OMEC and free 5GC core |
| 10 | network platforms to support LTE, 5G NSA and 5G SA services. |
| 11 | |
| 12 | * The SD-Core control plane provides the flexibility of simultaneous supports |
| 13 | for 5G standalone, 5G non-standalone and 4G/LTE deployments. |
| 14 | |
| 15 | * SD-Core provides a rich set of APIs to Runtime Operation Control (ROC). |
| 16 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 17 | * Operators can use these APIs to provision the subscribers in the mobile core |
| 18 | and their associated access and connectivity policies. |
| 19 | * Control runtime configuration of network functions e.g. management of Network slices |
| 20 | * ROC includes built-in adapters for SD-Core to translate its monitoring and configuration |
| 21 | APIs to customer and operator portals as well as third-party applications with corresponding |
| 22 | levels of abstraction. Third party applications can leverage telemetry data to create |
| 23 | applications for closed loop control. |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 24 | |
| 25 | .. image:: ../_static/images/SD-Core-Architecture.png |
| 26 | :width: 700px |
| 27 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 28 | SD-Core Architecture |
| 29 | -------------------- |
| 30 | SD-Core architecture enables the following distinct features: |
| 31 | |
| 32 | - All SD-Core components follow 3GPP standards to interface with others as well as the |
| 33 | external networks and systems (e.g., RAN, communication services, etc.). As such, |
| 34 | components can be consumed independently and be used as part of a multi-vendor |
| 35 | mobile core deployment. |
| 36 | - SD-Core’s 5G core control plane functions leverage seed code from the free5GC project, |
| 37 | upon which the SD-Core community has implemented numerous architectural changes that |
| 38 | are integrated and optimized with SD-Core’s set of UPF solutions along with several |
| 39 | new features |
| 40 | - The solution enables 4G, 5G Standalone (SA) and 5G Non-Standalone (NSA) connectivity. |
| 41 | - The architecture is fully disaggregated, composed of containerized components. Helm charts are |
| 42 | provided to deploy SD-Core on K8s cluster. |
| 43 | - The platform is configurable in runtime via an extensible set of APIs. |
| 44 | - The solution is consumable as a cloud-managed service. |
| 45 | - All interfaces are designed to be robust in order to handle all network errors including but |
| 46 | not limited to packet loss, peer network function failure, and duplicate packets. |
| 47 | - SD-Core’s 4G Core is designed to have a CUPS (Control-User Plane Separation) compliant architecture and |
| 48 | uses the 3GPP Packet Forwarding Control Protocol (PFCP) to implement CUPS |
| 49 | - SD-Core’s 4G control plane has been enhanced to provide functional support for 5G Nonstandalone |
| 50 | operation with compliant eNBs and gNBs as per 3GPP specifications. 5G NSA related enhancements |
| 51 | include support of the extended bearer rates on required interfaces as well as the 5G NSA attributes |
| 52 | in the HSS. |
| 53 | |
| 54 | .. image:: ../_static/images/Sd-Core-NFs.png |
| 55 | :width: 700px |
| 56 | |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 57 | Multiple Distributed User Planes |
| 58 | -------------------------------- |
| 59 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 60 | SD-Core has two User Plane Functions (UPFs) designed to be deployed throughout |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 61 | the network edge. Each UPF is optimized to handle specific classes of application |
| 62 | and take advantage of various hardware acceleration options. Deployments can |
| 63 | intermix the UPF variants. |
| 64 | |
| 65 | * P4-Based UPF optimized for private enterprise deployments, and providing fine-grained |
| 66 | visibility for verifiable performance and secure operations |
| 67 | * Containerized Dual-Core UPF optimized for private enterprise deployments, capable of |
| 68 | processing LTE and 5G traffic simultaneously |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 69 | |
| 70 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 71 | In SD-Core, a connected device is assigned to a UPF based on the network-wide slice configuration. |
| 72 | Specifically, in 5G core, the SMF uses the network slice information received in the user session |
| 73 | context as well as the Data Network Name (DNN) information received from AMF to select the serving |
| 74 | UPF. In the case of 4G core, the SPGW-C uses the the Access Point Name (APN) information to select |
| 75 | the serving UPF. |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 76 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 77 | Network Slicing |
| 78 | --------------- |
ajay | b3f4098 | 2021-12-08 14:26:11 -0800 | [diff] [blame] | 79 | |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 80 | Network slicing is one of the most important features of the 5G core network. Network |
| 81 | slicing helps in isolating the network for various business and use cases. In the disaggregated |
| 82 | service-based architecture of 5G core, this isolation may include only the UPF or also a subset |
| 83 | of the control plane services such as the SMF. However, mobile core control functions that |
| 84 | are responsible for managing user mobility, user authentication, and network slicing need |
| 85 | to remain centralized across all slices. SD-Core provides the necessary APIs to manage |
| 86 | network slices using external agents. ONF’s ROC, pre-integrated with SD-Core, allows for this |
| 87 | central management via portals as well as automation. If the management requires |
| 88 | instantiation of a new UPF and/or a new SMF instance, ROC oversees this by interacting with |
| 89 | edge cloud or hyperscale container management services to provision such new network |
| 90 | function instances. |
| 91 | |
| 92 | Once all mobile core service instances are provisioned for a new slice, ROC uses SD-Core |
| 93 | APIs to configure the slice as well as all required central network functions. SD-Core provides |
| 94 | APIs to create and configure network slices and assign resources to each slice. Operators can |
| 95 | assign a slice for a group of users/devices based on the use case. The behavior of each slice |
| 96 | is configurable and can be dynamically changed during run time. SD-Core’s architecture |
| 97 | supports assigning dedicated network functions to a specific slice or providing logical |
| 98 | separation if network functions are to be shared among various slices. Various QoS and |
| 99 | access policies can be applied to each slice to control the assigned resources as well as IP |
| 100 | connectivity and access control within each slice. |
| 101 | Operators can create new slices based on criteria such as isolating devices allowed to access |
| 102 | specific packet data networks/edge applications or keeping all devices or flows with the |
| 103 | same QoS classification grouped under one slice. Network slice selection is achieved through |
| 104 | 3GPP-specified network functions like Network Slice Selection Function (NSSF) and Network |
| 105 | Repository Function (NRF). NSSF helps in mapping the device/flow to a specific slice and |
| 106 | steering the device/flow traffic to the right set of core network elements. SD-Core’s 5G |
| 107 | implementation natively includes both NSSF and NRF for slice selection. |
| 108 | As described earlier, SD-Core’s P4-based dual-core UPF allows for the monitoring of all |
| 109 | 4G/5G traffic with fine-grained granularity using INT. This effectively means that with the P4- |
| 110 | based dual-core UPF, it is possible to conduct per packet network monitoring to track |
| 111 | whether slice-specific SLAs are being met and automatically adapt network behavior by |
| 112 | changing per slice resource allocations, QoS priorities etc., to automatically sustain the |
| 113 | required network performance using closed-loop control. |
| 114 | |
| 115 | SD-Core Deployment Options |
| 116 | -------------------------- |
| 117 | |
| 118 | The level of disaggregation and associated optimizations achieved for each component of |
| 119 | its 4G and 5G control plane makes SD-Core suitable for a wide variety of deployment |
| 120 | options. These optimizations include the capability for the 4G and 5G control planes to |
| 121 | oversee many UPFs, potentially instantiated at geographically diverse locations, as illustrated |
| 122 | It is possible to deploy all components of SD-Core collocated in an edge cloud or a central |
| 123 | cloud for private consumption. It is also possible to distribute the components of SD-Core |
| 124 | across multiple clouds, edge and central, to deliver a cloud-managed multi-tenant |
| 125 | connectivity service. In this distributed deployment option, SD-Core’s control plane will run |
| 126 | on a central/hyperscaler cloud and control multiple user planes running on different onpremises |
| 127 | edge clouds, potentially serving distinct customers as illustrated in Figure 8. In this |
| 128 | deployment, the 4G and 5G control plane functions can scale as necessary. Each customer |
| 129 | site can have more than one UPF deployed depending on the use cases and network slices |
| 130 | configured. Operators can also decide to deploy UPFs in the central cloud for certain |
| 131 | customers and their use cases where latency and data privacy is not a concern. SD-Core |
| 132 | brings the flexibility to define network slices for each customer in such a way that one |
| 133 | deploys a distinct UPF for each slice and instantiates the various components of the solution |
| 134 | at the customer edge or in the central cloud, as needed and best suited. |
| 135 | |
| 136 | |
| 137 | .. image:: ../_static/images/hybrid-cloud.png |
| 138 | :width: 700px |
| 139 | |
| 140 | SD-Core’s hybrid cloud deployment is an important enabler for a managed 4G/5G |
| 141 | connectivity service where each customer site may be deployed to serve a different set of |
| 142 | use cases and may have different types of underlying cloud environments. The 4G/5G core |
| 143 | control planes running on the central cloud have been designed and optimized to support |
| 144 | distributed edge sites which are spread across different locations across the world. The |
| 145 | SD-Core control plane uses PFCP to communicate with the UPFs at the edge sites. The hybrid |
| 146 | cloud deployment architecture has been optimized to handle variability in encountered |
| 147 | delays communicating with the remote edge sites and is equipped to handle potential |
| 148 | packet losses and retransmissions to support a multi-tenant, distributed geography |
| 149 | deployment. |
| 150 | |
| 151 | |
ajay | 60fd69f | 2021-11-23 22:38:10 -0800 | [diff] [blame] | 152 | |
| 153 | Architecture Diagram of SD-Core 4G block |
| 154 | ---------------------------------------- |
ajay | b5ad6db | 2021-12-09 15:23:24 -0800 | [diff] [blame] | 155 | - show configPod, config distribution, Cassandra DB, SIMApp, 4G network Functions |
ajay | 60fd69f | 2021-11-23 22:38:10 -0800 | [diff] [blame] | 156 | |
| 157 | Architecture Diagram of SD-Core 5G block |
| 158 | ---------------------------------------- |
| 159 | - show configPod, config distribution, MongoDB, SIMApp, 5G network functions |
| 160 | |
| 161 | Configuration Distribution Architecture |
| 162 | --------------------------------------- |
| 163 | - how grpc, rest is used to distribute the configuration |
| 164 | |