The **CAMARA as a Service OSL Add-on** is a prototype service developed by OSL and allows users of OSL to expose CAMARA APIs for their TMF based services. By doing so, it enables runtime operations, such as enforcing profiles on User Equipment (UEs) or updating 5G Network Slice characteristics, using standardized CAMARA API endpoints. The work is in progress for future enhancments (e.g. multitenancy, etc).
The **CAMARA as a Service (CAMARAaaS) OSL Add-on** is a prototype service developed by OSL and allows users of OSL to expose CAMARA APIs for their TMF based services. By doing so, it enables runtime operations, such as enforcing profiles on User Equipment (UEs) or updating 5G Network Slice characteristics, using standardized CAMARA API endpoints. The work is in progress for future enhancments (e.g. multitenancy, etc).
In a nutchel CAMARAaaS add-on makes API transformations from CAMARA API model to TMF API model and vice-versa.
...
...
@@ -10,7 +10,7 @@ The supporintg use case is the following:
- An OSL Service provider (e.g. an Operator) has a running 5G core (e.g. from another service order in OSL)
- The running service exposes already some characteristics (i.e. via TMF Service inventory) that can be configured and thus one can reconfigure it. (e.g. change the quality of a slice via a TMF API service request)
- On a subsequent step, the service provider makes a service order in OSL to expose this running service via a CAMARA API endpoint
- The CAMARAaaService add-on is a wrapper between the CAMARA requests and the TMF API service inventory models. These CAMARA APIs will then be used to control the lifecyle and the operations that shall take place in an already existing OSL Service.
- The CAMARAaaS add-on is a wrapper between the CAMARA requests and the TMF API service inventory models. These CAMARA APIs will then be used to control the lifecyle and the operations that shall take place in an already existing OSL Service.
Therefore, these are the key features of this add-on:
...
...
@@ -91,9 +91,9 @@ This architecture emphasizes automation, modularity, and interoperability betwee
The first image below, displays how normally one can use OSL to deploy and change a running service deployed in a Kubernetes cluster, using Kubernetes CRDs. First the service is requested through a Service Order. For example the service is a Service Specification bundle consisting of:
- a 5GCore Service Specification that will deploy a 5G core through HELM charts
- a 5GController Service Specification (deployed via HELM) that can chage configuration of slices for UEs. This Controller might register further Kubernetes operators for reconfiguring the core, slices, etc. This 5Gontroller is developed by the service provider able to reconfigure via e.g. NEF, scripting, API commands or other means.
- a 5GController Service Specification (deployed via HELM) that can chage configuration of slices for UEs. This Controller might register further Kubernetes operators for reconfiguring the core, slices, etc. This 5GController is developed by the service provider able to reconfigure via e.g. NEF, scripting, API commands or other means.
OSL via a service order deploys the services. Then while the service is in operation (ACTIVE), the user that ordered it can reconfigure it (see loop in figure) by changing characteristics of the sevice. These characteristics are then propagated from OSL orchestrator, through CRIDGE, down to the 5GController kubernetes resource to handle it.
OSL via a service order deploys the services. Then while the service is in operation (ACTIVE), the user that ordered it can reconfigure it (see loop in figure) by changing characteristics of the sevice. These characteristics are then propagated from OSL orchestrator, through CRIDGE, down to the 5GController Kubernetes resource to handle it.
