configuration/config.rst

..
   SPDX-FileCopyrightText: © 2020 Open Networking Foundation <support@opennetworking.org>
   SPDX-License-Identifier: Apache-2.0

Configuration Overview
======================

SD-Core has been developed with a cloud-based deployment and consumption model as
its foundation. It has a rich and extensible set of APIs to allow for runtime configurability of
subscriber management, access management, session management, and network slice
management. This configuration may be conducted via ONF’s Runtime Operational Control
(ROC) platform directly for consumption as a cloud-managed service, or the APIs can be
used by third-party automation and management platforms.

Reference helm chart
--------------------

    - `SD-Core Helm Chart Repository <https://gerrit.opencord.org/admin/repos/sdcore-helm-charts>`_
    - Sub components in sdcore-helm-charts

        - omec-control-plane: 4G Network functions helm charts
        - 5g-control-plane: 5G Network functions helm charts
        - omec-sub-provision: Simapp helm charts
        - 5g-ran-sim : gNBSim helm charts

Configuration Methods
---------------------
SD-Core supports 2 ways to configure network functions and micro services.

    - Helm Chart

        - Each individual network function and microservice has its own helm chart.
        - User needs to provide override values and deploy the network functions as per their need.
        - Use above helm charts appropriately and provide override values and install 4G/5G NFs.

    - REST Config Interface

        - Basic static configuration is still passed through helm chart ( logging level, image,...)
        - Dynamic *Network Slice* management  APIs are provided through REST interface.
        - REST APIs are defined to create/modify/delete network slice.
        - REST APIs are also provided to provision subscribers and grouping the subscribers under device Group.

.. note::
        - Simapp is the example of REST interface based configuration to provision subscribers in SD-Core
        - Simapp is also used to provision Network Slices in SD-Core in the absence of Portal
        - Aether ROC Portal used REST interface to configure Network Slices in SD-Core

.. image:: ../_static/images/config_slice.png
  :width: 500px
  :align: center



Configuration Steps
-------------------
This Configuration describes what to configure at high level from RoC/SIMAPP. ConfigPod stores this configuration
and publish to respective clients over REST/grpc.

    - Step1 : Provision subscriber in 4G/5G subsystem

        - This step is used to configure IMSI in the SD-Core
        - This procedure is used to configure security keys for a subscriber
        - Subscribers can be created during system startup or later

    - Step2 : Device Group Configuration

        - Group multiple devices under device group
        - Configure QoS for the device group
        - Configure IP domain configuration for the device group e.g. MTU, IP Pool, DNS server


    - Step3: Network Slice Configuration

        - Configuration to create a Network Slice
        - Add device Group into Network Slice
        - Slice contains the Slice level QoS configuration
        - Site configuration including UPF, eNBs/gNBs assigned to the slice
        - Applications allowed to be accessed by this slice (see :ref:`application-filtering`)

4G, 5G Configuration Differences
--------------------------------
One of the most important difference in 4G & 5G configuration is around network slice. 5G has
network slice Ids sent in protocol messages whereas 4G does not have any slice Id in messages.
We implement slicing in 4G using APNs. Let's go over these difference in detail below,

- **Slice Id** : Since 4G does not have slice Id in any protocol messages, configured slice Ids
  are ignored in 4G components. So it also means that even if configured slice Ids are
  duplicate it will not have any impact. But its still a good practice to have unique Slice
  Id per slice.

- **APN/DNN configuration**: In case of 4G each slice should have separate APN. This is required
  because APN is used as slice identifier internally in the 4G modules. This is not true in
  case of 5G because 5G has slice Id along with APN/DNN. So in general its good practice to
  keep APN/DNN in the slice unique so same slice can work for 4G & 5G configuration.


- **UE Address Allocation**: In the Slice API you will see that we provide UE IP pool configuration.
  Its important to know how UE IP address allocation is supported in SD-Core 4G & 5G components.

  In case of 4G, Control Plane supports UE address allocation from UPF. So it also means that even
  if you have specified UE address pool in the slice config, you still need to add the address pool
  configuration in the UPF deployment.

  In case of 5G, control plane has the capability to manage multiple IP pools so SMF uses the UE
  address pool configuration received in the network slice APIs
  and use them to appropriately assign UE address. But remember SD-Core 5G does not support UE IP
  address allocation from UPF. So in case of 5G UPF configuration, even if you don't configure address
  pool configuration it is still fine. We plan to add support of UPF UE address allocation in  next
  release.

- **DNN/APN in Initial Attach/Register Message** : In case of 4G, if UE has set any random APN then
  MME overrides the APN based on the user profile in HSS. So its important to note that even if APN
  is not matching with configured APN we are still good.  In case of 5G, apn name & Slice ID coming
  from UE is used to select SMF, so its important to have UE configured with correct APN/DNN name.
  Core network passed allowed slice IDs to UE in the registration accept message.