release/1.0.rst - sdcore-docs - Gitiles

 ..
    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 not 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 year now and in the year 2021 we added 5G support in the SD-Core. SD-Core is used in couple of
 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.

 **Slice Application Access Control using policy configuration:** 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 slices 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 - (see :ref:`4g-compliance`) and (see :ref:`5g-compliance`)

 Component Versions in the 1.0 Release
 -------------------------------------

 Helm Chart Versions and their component charts and containers:

 * sdcore-helm-chart: ``0.9.14``
     * 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``
	..
	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 not 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 year now and in the year 2021 we added 5G support in the SD-Core. SD-Core is used in couple of
	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.

	Slice Application Access Control using policy configuration: 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 slices 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 - (see :ref:`4g-compliance`) and (see :ref:`5g-compliance`)

	Component Versions in the 1.0 Release
	-------------------------------------

	Helm Chart Versions and their component charts and containers:

	* sdcore-helm-chart: ``0.9.14``
	* 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``