You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

NONRTRIC-944 - Getting issue details... STATUS

Gerrit https://gerrit.o-ran-sc.org/r/nonrtric/plt/sme


Service Manager builds on CAPIF and depends on the Kong API Gateway. CAPIF stands for common API framework and it was developed by 3GPP to enable a unified Northbound API framework across 3GPP network functions, and to ensure that there is a single and harmonized approach for API development. Among CAPIF's key features are the following.

  • Register/deregister APIs
  • Publishing APIs
  • Onboarding/offboarding API invoker
  • Discovery APIs
  • CAPIF events subscription/notification
  • Entity authentication/authorization
  • Support for 3rd party domains i.e., allow 3rd party API providers to leverage the CAPIF framework
  • Support interconnection between two CAPIF providers

CAPIF implements 3GPP TS 29.222 V17.5.0 Common API Framework for 3GPP Northbound APIs. Service Manager also implements 3GPP TS 29.222 V17.5.0 Common API Framework for 3GPP Northbound APIs. Service Manager uses a subset of CAPIF to provide the following APIs.

  • Register/deregister APIs
  • Publishing APIs
  • Onboarding/offboarding API invoker
  • Discovery APIs

If you only need the above APIs, then Service Manager is a plugin-in replacement for CAPIF.

CAPIF core function APIs implemented by Service Manager

The table below lists the CAPIF Core Function APIs that are currently implemented in Service Manager. The Service Names are listed in the order that they would typically be called.

Service Name

Service Operations

Operation Semantics

Consumer(s)

CAPIF_API_Provider_Management_API

Register_API_Provider

POST /registrations

API Management Function

Update_API_Provider

PUT /registrations/{registrationId}

API Management Function

Deregister_API_Provider

DELETE /registrations/{registrationId}

API Management Function

CAPIF_Publish_Service_API

Publish_Service_API

POST /{apfId}//service-apis

API Publishing Function, CAPIF core function

Unpublish_Service_API

DELETE /{apfId/service-apis/{serviceApiId}

API Publishing Function, CAPIF core function

Update_Service_API

PUT /{apfId/service-apis/{serviceApiId}

API Publishing Function, CAPIF core function

Get_Service_API

GET /{apfId}/service-apis

API Publishing Function, CAPIF core function

CAPIF_API_Invoker_Management_API

Onboard_API_Invoker

POST /onboardedInvokers

API Invoker

Offboard_API_Invoker

DELETE /onboardedInvokers/{onboardingId}

API Invoker

Update_API_Invoker_Details

PUT /onboardedInvokers/{onboardingId}

API Invoker

CAPIF_Discover_Service_API

Discover_Service_API

GET /allServiceAPIs

API Invoker, CAPIF core function

Service Manager integration with Kong

When you call the Publish Service API of Service Manager, the requests body contains the IPv4 address and port of the API Publishing Function. In the response body, these values are replaced by the IP v4 Address and port of the Kong Data Plane. This allows us to use Kong as a reverse proxy. Instead of calling the Publishing service directly, our Invoker's API request is proxied through Kong. This gives us the advantages of using a proxied service, such as providing caching and load balancing.

Service Manager Deployment 

Stand-alone Deployment on Kubernetes

For a stand-alone development deployment, please see the `deploy` folder for configurations to deploy Service Manager to Kubernetes. We need the following steps.
 - Deploy a PV for Kong's Postgres database (depends on your Kubernetes cluster)
 - Deploy a PVC for Kong's Postgres database
 - Deploy Kong with Postgres
 - Deploy Capifcore
 - Deploy Service Manager

We consolidate the above steps into the script `deploy-to-k8s.sh`. To delete the full deployment, you can use `delete-from-k8s.sh`. The deploy folder has the following structure.

- sme/
  - servicemanager/
    - deploy/
      - src/
      - manifests/

We store the Kubernetes manifests files in the manifests in the subfolder. We store the shell scripts in the src folder.

In `deploy-to-k8s.sh`, we copy .env.example and use sed to replace the template values with values for testing/production. You will need to update this part of the script with your own values. There is an example sed replacement in function `substitute_manifest()` in `deploy-to-k8s.sh`. Here, you can substitute your own Docker images for Capifcore and Service Manager for local development.

In addition there are 2 switches that are added for developer convenience.
  --repo # allow you to specify your own docker repo
  --env  # allow you to specify an additional env file, and set SERVICE_MANAGER_ENV to point to this file.

`./deploy-to-k8s.sh --repo your-docker-repo-id --env ../../.env.minikube`

When Service Manager starts, it reads a .env file where you can configure information such as the Kong control and data planes' host and port, the CAPIF host and port, and the Service Manager port.

Sample .env

KONG_DOMAIN=<string>
KONG_PROTOCOL=<http or https protocol scheme>
KONG_IPV4=<host string>
KONG_DATA_PLANE_PORT=<port number>
KONG_CONTROL_PLANE_PORT=<port number>
CAPIF_PROTOCOL=<http or https protocol scheme>
CAPIF_IPV4=<host>
CAPIF_PORT=<port number>
LOG_LEVEL=<Trace, Debug, Info, Warning, Error, Fatal or Panic>
SERVICE_MANAGER_PORT=<port number>
TEST_SERVICE_IPV4=<host string>
TEST_SERVICE_PORT=<port number>


  • No labels