| .. |
| SPDX-FileCopyrightText: © 2020 Open Networking Foundation <support@opennetworking.org> |
| SPDX-License-Identifier: Apache-2.0 |
| |
| SD-Core 1.0 Release |
| =================== |
| |
| SD-Core supports 4G & 5G network functions. SD-Core provides APIs for configuration, telemetry, policy |
| management. Access network can connected to AMF or MME depending on type of access used. Below is the |
| summary of the features delivered in SD-Core. |
| |
| Highlights |
| ---------- |
| |
| **Support of REST APIs to configure SD-Core:** Configuring multiple network functions to enable/disable a |
| service in a network is complex. Single entry point for REST api based configuration is easy to use |
| and less error prone. Our main motivation behind this work item was to hide the complexity of the network |
| and make APIs more intuitive for the operator. These APIs work well for both 4G & 5G network functions. |
| |
| **Subscriber Management Interface**: 3gpp requires user security keys to be configured in the network function. |
| We have provided two interfaces to configure subscribers in SD-Core. One of the way to configure subscribers |
| is through REST api calls to SD-Core. The other way is to add/delete/modify subscription through helm charts. |
| APIs are extensible and can be easily integrated with 3rd party sim provision solution. Also while operator |
| is updating the subscriptions, there is no need to restart any of the SD-Core components. This interface |
| to SD-Core is access agnostic and same interface works for 4G as well as 5G access. |
| |
| **3gpp defined procedures validation and hardening for error scenarios:** SD-Core has been deployed in Aether |
| Network for more than 2 years now and in the year 2021 we added 5G support in the SD-Core. SD-Core is used in |
| couple of operator trials. Also multiple Aether sites using different access networks to connect to |
| centralized SD-Core control plane. |
| This exercise has helped 4G/5G 3gpp procedures validations with multiple access networks, tools and user equipments. |
| Some of the widely used procedures are UE Registration/De-registration, UE PDU Establishment/modification/Deletion, |
| Xn handover, UE Context Release & Service request etc. This activity also includes handling of retransmission of |
| messages, retrying the messages when packet loss is observed over the network, handling no response from the peer |
| network functions,handling of network function failures or handling of reject responses from peer network functions. |
| |
| |
| **Operations support to manage multiple PLMN within Core Network:** SD-Core supports configuration |
| of multiple slices with different PLMN. This helps in sharing the same core network among multiple |
| operator networks. Each SD-Core network function is capable of handling multiple PLMN in the network. |
| |
| **Multiple User plane support using APN (4G) and Slice Id (5G) using CUPS call flows:** SD-Core |
| supports connections from multiple user planes. Even multiple user planes from the same edge can |
| connect to same control plane. Control plane uses APN or Slice ID to identify user plane. |
| |
| **Metrics exposure to get visibility of radio network connections and UE connections:** SD-core |
| uses prometheus to export metrics. These metrics are useful to get the status of various |
| gNodeB/eNodeB connected to Core Network. Also SD-Core gives the metrics to share current user |
| connectivity status. |
| |
| **SD-Core support 5000 calls at the rate of 10 calls per second per instance:** SD-Core 5G |
| solution is build on top of free5gc open source code. Numerous enhancements done on the base |
| code to get the production quality stability. One of the important goal we achieved was getting |
| 5000 subscribers with 10 subscribers attach per second. We will be pushing for higher limits in |
| upcoming changes. To achieve this limit, AMF & SMF has seen numerous architecture level |
| changes. |
| |
| **Application Filtering Support:** Network slice really becomes |
| useful when operator has the capability to apply access control. Operator can deploy multiple |
| applications at the edge or internet and can restrict the users from accessing it based on the |
| slice user belongs to. This adds extra layer of security in the edge app deployment. |
| |
| |
| **Policy framework to support QoS at multiple levels** SD-Core makes use of policy network |
| function (PCF/PCRF) to enforce qos decisions on the subscriber session. Policies are configured |
| per network slice using configuration interface. PCF/PCRF binds those policies to the subscribers. |
| APIs gives the flexibility to Operator to assign UE level QoS, per application QoS and also slice level QoS. |
| |
| Testing |
| ------- |
| For various testing related details refer (see :ref:`sdcore-testing`) |
| |
| Documentation |
| ------------- |
| |
| SD-Core documentation is available at `docs.sd-core.opennetworking.org |
| <https://docs.sd-core.opennetworking.org>`_ |
| |
| |
| Known Issues and Limitations |
| ---------------------------- |
| |
| - Same IMSI can not part of multiple device groups |
| - Only 5 application filtering rules can be added per Slice |
| - Application filtering should be configured with only /32 endpoint address. Subnet is not supported |
| - Application filtering does not work if port ranges are used in filter configuration |
| - Each device group should have unique DNN configuration |
| |
| .. note:: |
| For any 3gpp release compliance refer - (:ref:`4g-compliance`) and (:ref:`5g-compliance`) |
| |
| Component Versions in the 1.0 Release |
| ------------------------------------- |
| |
| Helm Chart Versions and their component charts and containers: |
| |
| * sdcore-helm-chart: ``0.9.16`` |
| * omec-control-plane: ``0.9.15`` |
| * hssdb: ``registry.aetherproject.org/proxy/omecproject/c3po-hssdb:master-771c0c3`` |
| * hss : ``registry.aetherproject.org/proxy/omecproject/c3po-hss:master-771c0c3`` |
| * pcrf : ``registry.aetherproject.org/proxy/omecproject/c3po-pcrf:pcrf-a6bdc3d`` |
| * pcrfdb : ``registry.aetherproject.org/proxy/omecproject/c3po-pcrf:pcrf-a6bdc3d`` |
| * config4g : ``registry.aetherproject.org/omecproject/5gc-webui:onf-release3.0.5-e29f159`` |
| * spgwc : ``registry.aetherproject.org/omecproject/spgw:master-144bd86`` |
| * mme : ``registry.aetherproject.org/proxy/omecproject/nucleus:master-ccdbf69`` |
| * omec-sub-provision: ``0.3.2`` |
| * simapp: ``registry.aetherproject.org/omecproject/simapp:main-329c82d`` |
| * 5g-control-plane: ``0.5.5`` |
| * amf: ``registry.aetherproject.org/omecproject/5gc-amf:onf-release3.0.5-9683d5c`` |
| * smf: ``registry.aetherproject.org/omecproject/5gc-smf:onf-release3.0.5-46dfe2d`` |
| * nrf: ``registry.aetherproject.org/omecproject/5gc-nrf:onf-release3.0.5-13304e8`` |
| * nssf: ``registry.aetherproject.org/omecproject/5gc-nssf:onf-release3.0.5-aa3a60b`` |
| * pcf: ``registry.aetherproject.org/omecproject/5gc-pcf:onf-release3.0.5-9f7734b`` |
| * udm: ``registry.aetherproject.org/omecproject/5gc-udm:onf-release3.0.5-c28433a`` |
| * udr: ``registry.aetherproject.org/omecproject/5gc-udr:onf-release3.0.5-deef506`` |
| * ausf: ``registry.aetherproject.org/omecproject/5gc-ausf:onf-release3.0.5-be7d4ac`` |
| * User Plane ``0.5.3`` |
| * bess: ``"registry.aetherproject.org/proxy/omecproject/upf-epc-bess:master-152a5eb"`` |
| * pfcpiface: ``"registry.aetherproject.org/proxy/omecproject/upf-epc-pfcpiface:master-152a5eb"`` |