2 Installing SEPP

This section describes how to install SEPP on a cloud native environment. It contains the following topics:

SEPP Prerequisites

This section includes information about the necessary prerequisites for SEPP deployment.

The 5G SEPP requires the following environment:
  • Kubernetes Cluster must be available with Core DNS configured to talk to operator's DNS server.
  • Service FQDN of SEPP should be discoverable from outside of cluster (i.e., publicly exposed if ingress messages to SEPP can come from outside of K8S).
  • The user must have their own repository for storing the SEPP images and repository should be accessible from his Kubernetes cluster.

Following are the prerequisites to install and configure SEPP:

SEPP Software

The SEPP software includes:
  • SEPP Helm charts
  • SEPP docker images

The following software must be installed:

Software Version
Kubernetes v1.16.7 and v1.17.1
HELM v2.14.3 and v3.2

Additional software that needs to be deployed as per the requirement of the services:

Software Notes
elasticsearch Needed for Logging Area
elastic-curator Needed for Logging Area
elastic-exporter Needed for Logging Area
logs Needed for Logging Area
kibana Needed for Logging Area
grafana Needed for Metrics Area
prometheus Needed for Metrics Area
prometheus-node-exporter Needed for Metrics Area
metallb Needed for External IP
metrics-server Needed for Metric Server
tracer Needed for Tracing Area

Note:

If any of the software specified in the table above is not installed in CNE, install the software. If OCCNE is the platform, refer Cloud Native Environment Installation Guide.
To check the installed software items, execute:
helm ls

Use the helm command with admin.conf file, if requried:

helm --kubeconfig admin.conf

SEPP Microservices and Images

The following are the SEPP Microservices and images:

No Micro Service Name Image Name
1 <Releasename>-cn32c-svc ocsepp-cn32c-svc
2 <Releasename>-pn32c-svc ocsepp-pn32c-svc
3 <Releasename>-config-mgr-svc ocsepp-config-mgr-svc
4 <Releasename>-cn32f-svc ocsepp-cn32f-svc
5 <Releasename>-pn32f-svc ocsepp-pn32f-svc
6 <Releasename>-plmn-ingress-gateway ocingress_gateway
7 <Releasename>-plmn-egress-gateway ocegress_gateway
8 <Releasename>-n32-ingress-gateway ocingress_gateway
9 <Releasename>-n32-egress-gateway ocegress_gateway
10 <Releasename>-nrf client nrf-client
11 <Releasename>-perf-info perf_info
12 <Releasename>-config-server config_server
13 <Releasename>-appinfo app_info

Note:

The Releasename represents the helm release name.

SEPP Pre-deployment Configuration

This section describes about the various SEPP pre-deployment configuration steps. It includes the following:
  1. Verify and Create kubernetes Namespace
  2. Create MySql Database and User for OCSEPP
  3. Create a Kubernetes secrets for enabling HTTPS/ HTTP over TLS

Verify and Create kubernetes Namespace

This section explains how a user can verify the existence of a required namespace in the system. If the namespace does not exist, the user must create it.

Procedure
  1. Verify whether required namespace already exists in system by executing the following command:
    $ kubectl get namespaces 
  2. If the output of the above command does not display the required namespace, create the namespace by executing the following command:
    $ kubectl create namespace <required namespace>
    Example:
    $ kubectl create namespace seppsvc

Create MySQL Database and User for OCSEPP

  1. Login to the server or machine which has permission to access the SQL nodes of NDB cluster.
  2. Connect to the SQL nodes of NDB cluster one at the time.
  3. Login to the MySQL prompt using root permission or user who has permission to create users with permissions as mentioned below.

    Example:
    mysql -h 127.0.0.1 -uroot -p
  4. Check whether OCSEPP network function user already exists. If the user does not exist, create an OCSEPP network function user by executing the following queries:
    1. Execute
      $ SELECT User FROM mysql.user;
      to list the users.
    2. If the user does not exist, create the new user by executing:
      $ CREATE USER '<OCSEPP User Name>'@'%' IDENTIFIED BY '<OCSEPP Password>';
    3. Example:
      $ CREATE USER 'seppusr'@'%' IDENTIFIED BY 'sepppasswd';
  5. Check if OCSEPP network function database already exists. If it does not exist, create an OCSEPP network function database and provide permissions to OCSEPP username created in the previous step by executing the following commands:
    1. Execute
      $ show databases; 
      to check if database exists.
    2. If database does not exist, execute
      $ CREATE DATABASE IF NOT EXISTS <OCSEPP Database> CHARACTER SET utf8;
      for Database creation.

      Example:
      $ CREATE DATABASE IF NOT EXISTS seppdb CHARACTER SET utf8; 
    3. Granting permission to user:
      $ GRANT SELECT,INSERT,CREATE,ALTER,DROP,LOCK TABLES,CREATE TEMPORARY TABLES,
       DELETE,UPDATE,EXECUTE ON <OCSEPP Database>.* TO '<OCSEPP User Name>'@'%';

Create a Kubernetes Secrets for Enabling HTTPS/ HTTP over TLS

Creation of Secrets for Enabling HTTPS in plmn OCSEPP Egress/Ingress Gateway

This section explains the steps to create secret for HTTPS related details. This section must be executed before enabling HTTPS in plmn OCSEPP Egress/Ingress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files below.
To create kubernetes secret for HTTPS, following files are required:
  • ECDSA private key and CA signed certificate of OCSEPP (if initialAlgorithm is ES256)
  • RSA private key and CA signed certificate of OCSEPP (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

  1. Execute the following command to create secret:
    $ kubectl create secret generic < ocsepp-plmn-secret > --fromfile=<ssl_ecdsa_private_key.pem>
     --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt>
     --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n 
    <Namespace of OCSEPP ocegress Gateway secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.
    Example: The names used below are same as provided in custom values.yaml in OCSEPP deployment.
    $ kubectl create secret generic  ocsepp-plmn-secret --fromfile=ssl_ecdsa_private_key.pem
     --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt 
    --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocsepp
  2. Verify the secret created using the following command:
    $ kubectl describe secret <ocsepp-plmn-secret> -n <Namespace of OCSEPP 
    ocegress Gateway secret>
    Example:
    $ kubectl describe secret  ocsepp-plmn-secret -n ocsepp

Creation of Secrets for Enabling HTTP over TLS in n32 OCSEPP Egress/Ingress Gateway

This section explains the steps to create secret for HTTP over TLS related details. This section must be executed before enabling HTTP over TLS in n32 OCSEPP Egress/Ingress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files below.
To create kubernetes secret for HTTP over TLS, following files are required:
  • ECDSA private key and CA signed certificate of OCSEPP (if initialAlgorithm is ES256)
  • RSA private key and CA signed certificate of OCSEPP (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

  1. Execute the following command to create secret:
    $ kubectl create secret generic < ocsepp-n32-secret > --fromfile=<ssl_ecdsa_private_key.pem>
     --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<ssl_truststore.txt> --from-file=<ssl_keystore.txt>
     --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n 
    <Namespace of OCSEPP ocegress Gateway secret>

    Note:

    Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.
    Example: The names used below are same as provided in custom values.yaml in OCSEPP deployment.
    $ kubectl create secret generic ocsepp-n32-secret --fromfile=ssl_ecdsa_private_key.pem
     --from-file=rsa_private_key_pkcs1.pem --fromfile=ssl_truststore.txt --from-file=ssl_keystore.txt 
    --from-file=caroot.cer --fromfile=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocsepp
  2. Verify the secret created using the following command:
    $ kubectl describe secret <ocsepp-n32-secret> -n <Namespace of OCSEPP 
    ocegress Gateway secret>
    Example:
    $ kubectl describe secret ocsepp-n32-secret -n ocsepp

SEPP Installation Sequence

This section provides details about the sequence in which SEPP must be installed.

  1. Installation Preparation: This includes downloading the required files and loading the files to the system.
  2. Configure the ocsepp-custom-values-1.4.0.yaml file: This step includes configuring the following based on the deployment:
    • Repository path
    • Primary and Secondary db node
    • SEPP local profile
    • Gateway Secret details
    • NRF Information

    Note:

    Other configurations might be changed based on the deployment.
  3. SEPP deployment: SEPP can be deployed in either of the following ways:
    • With HELM repository
    • With HELM tar
  4. Verify SEPP deployment: In this step if the services and pods are up and running is verified.

SEPP Installation Preparation

The following procedure describes the steps to download the SEPP Images and Helm files from OSDC.

For more information about configuring docker image and registry, refer to chapter OCCNE Docker Image Registry Configuration in OCCNE Installation Guide.
  1. Download the SEPP package file:

    Customers are required to download the SEPP package file from Oracle Software Delivery Cloud (OSDC). Package is named as follows:

    <nfname>-pkg-<marketing-release-number>

    Example: ocsepp-pkg-1.4.0.0.0.tgz

  2. Untar the SEPP Package File:

    Untar the SEPP package to the specific repository:

    tar -xvf <<nfname>-pkg-<marketing-release-number>> 
    The package file consists of following:
    • SEPP Docker Images File

      ocsepp-images-1.4.0.tar

    • Helm File

      ocsepp-1.4.0.tgz

    • Readme txt file

      Readme.txt (Contains cksum and md5sum of tarballs)

  3. Check the checksums:

    Check the checksums of tarballs mentioned in Readme.txt. Refer to the Readme.txt file for commands and checksum details.
  4. Load the tarball to system:

    Execute the following command to load the tarball to system:

    docker load --input ocsepp-images-1.4.0.tar 
  5. Check if all the images are loaded:

    Execute the following command to check whether alll the images are loaded:

    docker images

  6. Push docker images to docker registry:

    Execute the following commands to push the docker images to docker registry:

    docker tag <image-name>:<image-tag> <docker-repo>/<image-name>:<image-tag>
    docker push <docker-repo>/<image-name>:<image-tag> 
  7. Untar Helm Files:

    Execute the following command to untar the helm files:

    tar -xvzf ocsepp-1.4.0.tgz
    
  8. Download the Network Slice Selection Function (SEPP) Custom Template ZIP file:

    Download the Network Slice Selection Function (SEPP) Custom Template ZIP file from OHC:

    • Go to the URL, docs.oracle.com
    • Navigate to Industries >Communications >Signaling & Policy >Cloud Native Core
    • Click the Network Slice Selection Function (SEPP) Custom Template link to download the zip file.
    • Unzip the template to get the following files:
      • ocsepp-custom-values-1.4.0.yaml 
      • seppAlertRules.yaml.
      • ocseppDashboard.json

SEPP Installation and Deployment

This section includes information about SEPP deployment.

Following are the parameters and definitions used during SEPP deployment:

Table 2-1 Parameters and Definitions

Parameters Definitions
<helm chart> It is the name of the chart that is of the form <helm repo>/ocsepp.
<OCSEPP version> It is the software version (helm chart version) of the SEPP. This is optional, if omitted, the default version is the latest version available in helm repository.
<release> It is a name provided by the user to identify the helm deployment.
<k8s namespace> It is a name provided by the user to identify the kubernetes namespace of the SEPP. All the SEPP microservices are deployed in this kubernetes namespace.

SEPP Deployment on Kubernetes

Note:

To configure the parameters, refer Customizing SEPP.

Create Database User and Group

The SEPP uses a MySQL database to store the configuration and run time data.

The SEPP deployment using MySQL NDB cluster requires the database administrator to create a user in the MYSQL DB and to provide the user with necessary permissions to access the tables in the NDB cluster.

  1. Login to the server where the ssh keys are stored and the SQL nodes are accessible.
  2. Connect to the SQL nodes.
  3. Login to the Database as a root user.
  4. Create a user and assign it to a group having necessary permission to access the tables on primary SQL nodes:
    
    CREATE USER '<username>'@'%' IDENTIFIED BY '<password>';
    DROP DATABASE if exists seppdb;
    CREATE DATABASE seppdb CHARACTER SET utf8;
    GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY
    TABLES, DELETE, UPDATE,
    EXECUTE ON seppdb.* TO '<username>'@'%';
    USE seppdb;
    
  5. Grant necessary permissoins to access the tables on seconary SQL nodes:
    GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY
    TABLES, DELETE, UPDATE,
    EXECUTE ON seppdb.* TO '<username>'@'%';
    USE seppdb;
    

    Note:

    The <username> and <password> is created by the Database Administrator.
  6. Exit from database and logout from SQL node.

SEPP Deployment

  1. Create customized ocsepp-custom-values-1.4.0.yaml file :

    Create the customized ocsepp-custom-values-1.4.0.yaml with the required input parameters.

    To configure the ocsepp-custom-values-1.4.0.yaml, refer to Customizing SEPP.

    or,

    The ocsepp-custom-values-1.4.0.yaml template can be downloaded from OHC.

    Download the package ocsepp-custom-configTemplates-1.4.0.0.0.zip and Unzip to get ocsepp-custom-values-1.4.0.yaml file.

    Note:

    • For connecting services to the database, ensure the following parameters must be customized: envMysqlHost, mysql.primary.host, mysql.primary.port, mysql.secondary.host, mysql.secondary.port.
    • The database secret (dbCredSecretName) must be provided.
  2. Go to the unzipped OCSEPP package:

    Go to the following directory:

    cd OCSEPP-pkg-1.4.0.0.0

  3. Deploy OCSEPP:

    Execute the following command:

    For helm 2 based:

    helm install ocsepp/ --name <helm-release> --namespace <k8s namespace> -f <ocsepp_customized_values.yaml> 
    Example: helm install ocsepp/ --name ocsepp --namespace ocsepp -f ocsepp-custom-values-1.4.0.yaml

    Example:

    helm install ocsepp/ --name ocsepp --namespace ocsepp -f ocsepp-custom-values-1.4.0.yaml 

    For helm 3 based:

    helm3 install <helm-release> ocsepp/ --namespace <k8s namespace> f <ocsepp_customized_values.yaml>  
    
    Example:
    helm3 install ocsepp ocsepp/ --namespace ocsepp -f ocsepp-custom-values-1.4.0.yaml  
  4. Check status of the deployment:

    Execute the following command to check the status of the deployment:

    For helm 2:

    helm status --name <helm-release> 
    Example:
    helm status --name ocsepp 

    For helm 3:

     helm3 status --name <helm-release> 
    Example:
    helm3 status --name ocsepp
  5. Check status of the services:

    Execute the following command to check the status of services:
    kubectl -n <k8s namespace> get services

    Example:

    kubectl -n ocsepp get services

    Note:

    If metallb is used, EXTERNAL-IP is assigned to<helm release name>-endpoint. ocsepp is the helm release name.
  6. Check status of the pods:

    Execute the following command to status of the pods:
    kubectl get pods -n <k8s namespace> 

    Status column of all the pods must indicate 'Running'.

    Ready column of all the pods must be n/n, where n is number of containers in the pod.

    Example:

     kubectl get pods -n ocsepp
    Sample output :
    
    NAME                                          READY   STATUS  RESTARTS     AGE
    ocsepp-appinfo-7687997858-2vn4r               1/1     Running   0          20m
    ocsepp-cn32c-svc-845f689879-r8zcr             1/1     Running   0          20m
    ocsepp-cn32f-svc-6655cdf7bc-8sxrl             1/1     Running   0          20m
    ocsepp-config-mgr-svc-6c8c5c968d-qqd4f        1/1     Running   0          20m
    ocsepp-n32-egress-gateway-76bdbc7546-t7msc    2/2     Running   0          20m
    ocsepp-n32-ingress-gateway-5545f455c-br2cv    2/2     Running   0          20m
    ocsepp-ocpm-config-854dd8b7b5-j2lgg           1/1     Running   0          20m
    ocsepp-plmn-egress-gateway-655886df4f-b9rl6   2/2     Running   0          20m
    ocsepp-plmn-ingress-gateway-6586fbfc59-9f4lx  2/2     Running   0          20m
    ocsepp-pn32c-svc-55d5748b76-p6p4t             1/1     Running   0          20m
    ocsepp-pn32f-svc-846558995b-5wvpt             1/1     Running   0          20m
    ocsepp-sepp-nrf-client-nfmanagement
                -7c94cf8dbf-lxbsb                 1/1     Running   0          20m