blob: 5113fe4d135eeac321762d677888ba4c3af6c741 [file] [log] [blame]
..
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 Scale support:** 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 with single instance. We will be pushing for higher limits in upcoming changes.
To achieve this limit, AMF & SMF has seen numerous architecture level changes. SD-Core 4G is
built on top of OMEC project. 4G is tested for 16000 calls at the rate of 100 calls per second.
All these results are achieved with distributed user plane. Vertical scaling can be done easily
to achieve higher call setup rates.
**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"``