diff --git a/Documentation/CAMARAaaS-Architecture.png b/Documentation/CAMARAaaS-Architecture.png index 618a1eeb77809e3e2dd5189c61764b5277c72031..77efc3199e9a3f2e4490dc483e47730fb3b4d438 100644 Binary files a/Documentation/CAMARAaaS-Architecture.png and b/Documentation/CAMARAaaS-Architecture.png differ diff --git a/QoDProvisioning/README.md b/QoDProvisioning/README.md index 3acc181ac161e5bb1dc25df9fe1be8e4bf48ff18..c115a7d29382bcf34b7ffea8e9e80f45a6f65ede 100644 --- a/QoDProvisioning/README.md +++ b/QoDProvisioning/README.md @@ -10,48 +10,11 @@ Such API has the following endpoints: ![](Documentation/Pictures/CAMARA-QoDProvisioning-API-Endpoints.png) -### Mapping to TMF Service Characteristics (of the operator’s Service) +Last, our solution needs to be deployed in a Kubernetes cluster. A 5G Core is needed for proper implementation as well as your own 5G core controller. -Having chosen the candidate API, the first step is to find a way to map the possible requests to TMF Service characteristics of the operator’s service. By looking at API’s specification, it is clear that at least 3 operations are required: (i) the creation of a QoD profile, (ii) its deletion, and (iii) listing all active QoD profiles. Therefore, we can proceed with evaluating the payload required for creating a QoD Provisioning. This payload involves various fields, which can be translated to the TMF Service Characteristics: +## General concepts of the OSL CAMARAaaS as a TMF Service Specification -- *qodProv.device.phoneNumber* -- *qodProv.device.networkAccessIdentifier* -- *qodProv.device.ipv4Address.privateAddress* -- *qodProv.device.ipv4Address.publicAddress* -- *qodProv.device.ipv4Address.publicPort* -- *qodProv.device.ipv6Address* -- *qodProv.qosProfile* -- *qodProv.sink* -- *qodProv.sinkCredential.credentialType* - -In order to support interaction with OSL’s CAMARAaaS APIs, the operator service must be designed, at least, with these characteristics. - -Still, since there are various operations that can take place (CREATE and DELETE), it is also needed a characteristic to map this. Therefore, the operator’s service must also have a characteristics titled *qodProv.operation*. The DELETE operation is achieved based on a provisioning Id, and therefore another characteristics is needed: *qodProv.provisioningId.* - -Finally, it is required a characteristic to store the provisionings that were enforced by the operator’s service. We can define this characteristic as *camaraResults*. - -Therefore, for an operator’s service to be controlled by OSL’s CAMARA APIs, it needs to be designed with, at least, the following characteristics: - -- *qodProv.device.phoneNumber* -- *qodProv.device.networkAccessIdentifier* -- *qodProv.device.ipv4Address.privateAddress* -- *qodProv.device.ipv4Address.publicAddress* -- *qodProv.device.ipv4Address.publicPort* -- *qodProv.device.ipv6Address* -- *qodProv.qosProfile* -- *qodProv.sink* -- *qodProv.sinkCredential.credentialType* -- *qodProv.operation* -- *qodProv.provisioningId* -- *camaraResults* - -Additional characteristics are fully supported. Those can be custom characteristics that are required by the Operator’s Service. - -In regard to the *camaraResults* characteristic, to allow interoperability, it must store a Stringified JSON Array with the enforced QoD Provisionings. **The schema of each provisioning should be the one defined in CAMARA’s QoD Provisioning API Specification.** - -### TMF Service Characteristics of the CAMARAaaS APIs - -Considering the interactions that shall take place between the CAMARAaaS API and the Operator’s running Service and the architecture introduced before, it is clear that CAMARA APIs must interface with OSL’s Active MQ broker. Therefore, TMF Specific Service Characteristics are required to pass this information to the CAMARA APIs deployed through OSL: +First step is to design and expose the OSL CAMARA API service via the TMF APIs. The OSL CAMARA API service uses as backend connectivity the OSL message bus (OSL’s Active MQ broker). It exposes the CAMARA API, translates and forards the requests to TMF model via the service bus. Therefore, considering the interactions that shall take place between the CAMARAaaS API and the Operator’s running Service and the architecture introduced before, the OSL CAMARAaaS must interface with OSL’s Active MQ broker.Moreover for this first prototype the OSL CAMARAaaS will be instantiated via a Service Order. To enable this, we need to design it in OpenSlice as a Service Specification, so in general some TMF service characteristics are required to pass this information to the OSL CAMARAaaS which will be orchestrated, deployed and configured through OSL: - messageBroker.address - OSL's ActiveMQ Address (e.g. 10.10.10.10) - messageBroker.port - OSL's ActiveMQ Port @@ -71,7 +34,7 @@ Considering that the CAMARA API will be orchestrated by OSL, the client does not Additionally, you may create a characteristic titled “*camaraAPI.results*”, which you can use to have visibility of the QoD Provisionings processed by the API, at OSL level. Still, this characteristic is not required. -Therefore, OSL’s CAMARA APIs must offer the following TMF Service Characteristics: +Therefore, OSL’s CAMARAaaS will contain the following TMF Service Characteristics: - messageBroker.address - messageBroker.port @@ -91,11 +54,11 @@ This API has a *ServiceEventManager* class that communicates with OpenSlice's Ac - `CATALOG.UPD.SERVICE`: Topic for catalog updates. - `EVENT.SERVICE.ATTRCHANGED`: Topic for service attribute changes. -#### CATALOG.UPD.SERVICE +### CATALOG.UPD.SERVICE Whenever a new provisioning is created for an UE, the *ServiceEventManager*'s *update_service* method is called. This method sends a a service update message through OpenSlice's *CATALOG.UPD.SERVICE* topic. When OSL receives the request, it updates the Service with the new characteristics, which are then caught by the correspondent K8s Operator. After processing the request, the Operator adds the result to the Service-related CR *camaraResults* characteristic. -#### EVENT.SERVICE.ATTRCHANGED +### EVENT.SERVICE.ATTRCHANGED The *ServiceEventManager* subscribes to this topic to obtain and process the update messages regarding the specified UE QoD Profile Enforcer OSL service. Whenever this service's characteristics are updated in OSL, this class catches the update message. Then, the class extracts the *camaraResults* characteristic, which contains all QoS provisionings applied to the UEs. @@ -103,11 +66,59 @@ These results are then processed by the *CamaraResultsProcessor* class, which up +## General concepts of the QoD service (the 5G core provider service) and design it as OSL TMF Service Specification + +Having chosen the candidate API, the first step is to find a way to map the possible requests to TMF Service characteristics of the operator’s service. Our apporach in general is the following: -## How To / Demonstration +- Design the QoD service that will accept the neccessary QoD related characteristics +- Implement the QoD service as a controller able to manage your 5G core +- Deploy it in a kubernetes cluster that OSL can manage (via CRIDGE) -### 1. Dummy Operator Service Service Design -We will start by looking at the dummy operator’s service we have created to demonstrate this Add-on. This Service will be offered as simple Custom Resource. You may find its Custom Resource Definition under `/DummyOperatorService/crd.yaml` Look at the CRD fields. Please notice that these were defined according what we disclosed before. +By looking at API’s specification, it is clear that at least 3 operations are required: (i) the creation of a QoD profile, (ii) its deletion, and (iii) listing all active QoD profiles. Therefore, we can proceed with evaluating the payload required for creating a QoD Provisioning. This payload involves various fields, which can be translated to the TMF Service Characteristics: + +- *qodProv.device.phoneNumber* +- *qodProv.device.networkAccessIdentifier* +- *qodProv.device.ipv4Address.privateAddress* +- *qodProv.device.ipv4Address.publicAddress* +- *qodProv.device.ipv4Address.publicPort* +- *qodProv.device.ipv6Address* +- *qodProv.qosProfile* +- *qodProv.sink* +- *qodProv.sinkCredential.credentialType* + +In order to support interaction with OSL’s CAMARAaaS APIs, the QoD service must be designed, at least, with these characteristics. + +Still, since there are various operations that can take place (CREATE and DELETE), it is also needed a characteristic to map this. Therefore, the operator’s service must also have a characteristics titled *qodProv.operation*. The DELETE operation is achieved based on a provisioning Id, and therefore another characteristics is needed: *qodProv.provisioningId.* + +Finally, it is required a characteristic to store the provisionings that were enforced by the operator’s service. We can define this characteristic as *camaraResults*. + +Therefore, for an operator’s service to be controlled by OSL’s CAMARA APIs, it needs to be designed with, at least, the following characteristics: + +- *qodProv.device.phoneNumber* +- *qodProv.device.networkAccessIdentifier* +- *qodProv.device.ipv4Address.privateAddress* +- *qodProv.device.ipv4Address.publicAddress* +- *qodProv.device.ipv4Address.publicPort* +- *qodProv.device.ipv6Address* +- *qodProv.qosProfile* +- *qodProv.sink* +- *qodProv.sinkCredential.credentialType* +- *qodProv.operation* +- *qodProv.provisioningId* +- *camaraResults* + +Additional characteristics are fully supported. Those can be custom characteristics that are required by the QoD operator’s Service. + +In regard to the *camaraResults* characteristic, to allow interoperability, it must store a Stringified JSON Array with the enforced QoD Provisionings. **The schema of each provisioning should be the one defined in CAMARA’s QoD Provisioning API Specification.** + + +# How To / Demonstration + +## 1. Dummy QoD Kubernetes Operator Service Design + +For this prototype, since we cannnot deliver a QoD service implementation for a specific commercial core, we created a Dummy QoD Kubernetes Operator Service which emulates the 5G Core configuration. In future releases of OSL we will offer solutions for some open source 5G cores. + +We will start by looking at the Dummy QoD Kubernetes Operator Service we have created to demonstrate this Add-on. This Service will be offered as simple Custom Resource deployed in a Kubernetes cluster. You may find its Custom Resource Definition under `/DummyOperatorService/crd.yaml` Look at the CRD fields. Please notice that these were defined according with what we discusssed inm previous section. The first step is then to install this CRD in your kubernetes cluster. To this end, you may use the following command: `make create-dummy-operator-crd` @@ -115,18 +126,19 @@ After creating the CRD in your Kubernetes cluster, you may access OSL’s Resour ![](./Documentation/Pictures/DummyOperatorService-ResourceInventory.png) -The next step is to create a RFS Service to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/) documentation page. +We need now to start offering this as a service ready to be ordered from the service catalogue. So, +the first step is to create a Resource-Facing-Service (RFS) Specification to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/) documentation page. Regarding the RFS Service, you must set the following characteristics: - _CR_CHECKVAL_AVAILABLE = RUNNING - _CR_CHECK_FIELD = spec.status -By setting this characteristics, you will rely on the value of `spec.status` to set the service as `active`. Ideally, the operator would have implemented an Operator for this Custom Resource. However, for demonstration purposes, we will use a Supervision rule to set `spec.status` to `RUNNING` +By setting this characteristics, you will rely on the value of `spec.status` to set the service as `active`. Ideally, the 5G core provider would have implemented a proper Kubernetes Operator for this Custom Resource to implement the requested QoD. However, as discussed already, for demonstration purposes, we will use ahort-circuit the behavior and will add a Supervision rule to set `spec.status` to `RUNNING` immediatelly after provisioning. -Then, you can proceed to create a CFS Service, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service characteristics, you may use the Service Specification available at `/DummyOperatorService/OSLArtifacts/DummyOperatorService-CFS-Specification.json` . You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to *[{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification](https://www.notion.so/CAMARAaaS-OSL-15e11fa2ed8d80808254c87d9393cf51?pvs=21).* +Then, you can proceed to create a Customer-Facing-Service (CFS) Specification, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service characteristics, you may use the Service Specification available at `/DummyOperatorService/OSLArtifacts/DummyOperatorService-CFS-Specification.json` . You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to *[{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification](https://www.notion.so/CAMARAaaS-OSL-15e11fa2ed8d80808254c87d9393cf51?pvs=21).* -After creating the Service Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships” and add the RFS Service. +After creating the Customer-Facing-Service (CFS) Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships” and add the previous created Resource-Facing-Service (RFS) Specification. Regarding the LCM Rules for the CFS Service, you should configure the following ones: @@ -199,18 +211,18 @@ After that, you may expose this service via OSL’s Service Catalog, and order i ![DummyOperatorService-ServiceOrder.png](./Documentation/Pictures/DummyOperatorService-CustomResource.png) -### 2. CAMARA QoD Provisioning API +## 2. OSL CAMARAaaS QoD Provisioning API -Then, we can proceed to design the CAMARAaaS QoD Provisioning API. To this end, OSL’s team has implemented CAMARA’s QoD Provisioning API, created a CRD to offer it, and developed a Kubernetes Operator to deal with its internal logic. Start by packaging the API in a docker image and pushing it to a docker repository. +Then, we can proceed to design the CAMARAaaS QoD Provisioning API in OSL catalogue. To this end, OSL’s team has implemented in Python the CAMARAaaS QoD Provisioning API, created a CRD to offer it, and developed a Kubernetes Operator to deal with its internal logic. Start by packaging the API in a docker image and pushing it to a docker repository. Open the file `Makefile` and update the repository to where you will push the docker image. Update the variable `REPOSITORY_HOST` . You may also choose to update the other variables, but it is not required. After this, run `make build-api-docker-image`. This command will build, tag, and push the API docker image to the repository you chose. -### 3. CAMARA QoD Provisioning API - Kubernetes Operator +## 3. OSL CAMARAaaS QoD Provisioning API - Kubernetes Operator -The previous docker image shall make available the CAMARA QoD Provisioning API. However, these APIs will be made available through Custom Resources of Type `CAMARAaaS-QoDProvisiongAPI` . Therefore, we also need a Kubernetes Operator to manage these resources. The Operator’s code can be found under `/QoDProvisioningAPI/Operator` . There, you have the source code of the Operator, as well as an Helm Chart to install it. +The previous docker image shall make available the CAMARA QoD Provisioning API. However, these APIs will be made available through Custom Resources of Type `CAMARAaaS-QoDProvisiongAPI` . Therefore, we also need a Kubernetes Operator to manage these resources. The Operator’s code can be found under `/QoDProvisioningAPI/Operator` . There, you have the source code of the KubernetesOperator, as well as an Helm Chart to install it. -Start by building and pushing the Operator’s docker image to your repository. Run `make operator-docker-image`. Then, install the operator in your Kubernetes cluster. This action will result in the creation of the Custom Resource Definition for the CAMARA QoD Provisioning API Resources, and deploy the operator in the cluster. It is this operator that will manage the CAMARA QoD Provisioning API Resources, being responsible, for instance, for the deployment a Kubernetes pod and service that expose the CAMARA QoD Provisioning API. To install the Operator, run the following command: +Start by building and pushing the Kubernetes Operator’s docker image to your repository. Run `make operator-docker-image`. Then, install the operator in your Kubernetes cluster. This action will result in the creation of the Custom Resource Definition for the CAMARA QoD Provisioning API Resources, and deploy the operator in the cluster. It is this operator that will manage the CAMARA QoD Provisioning API Resources, being responsible, for instance, for the deployment a Kubernetes pod and service that expose the CAMARA QoD Provisioning API. To install the Operator, run the following command: ```bash helm install camaraaas-qod-prov-operator ./QoDProvisioningAPI/Operator/chart --set operator.image= --set camaraQoDAPI.image= --namespace --create-namespace @@ -237,11 +249,11 @@ When the Custom Resource is created, its operator will deploy the CAMARA QoD API If you see this page, the CAMARA QoD Provisioning API Custom Resources and their operator is working. You may delete the Custom Resource you created. Run the following command: `make delete-operator-test-cr`. -### 4. CAMARA QoD Provisioning API - Service Design +## 4. OSL CAMARAaaS QoD Provisioning API - TMF Service Specification Design -Now we can proceed to create a Service Specification that maps the CAMARA QoD Provisioning APICustom Resource. +Now we can proceed to create a OSL TMF Service Specification that maps the CAMARAaaS QoD Provisioning API Custom Resource, ready to be ordered in your OSL service specification catalogue. -The next step is to create a RFS Service to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/) documentation page. +The first step is to create a RFS Service to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/) documentation page. Regarding the RFS Service, you must set the following characteristics: @@ -336,12 +348,11 @@ Confirm that the service order was completed, both RFS and CFS Services are acti ![](./Documentation/Pictures/CAMARAaaS-QoD-Prov-API-CR.png) - Additionally, in OSL, you may see the URL where the QoD Provisioning API is exposed. To do so, please see the characteristics of the CAMARAaaS QoD Provisioning API CFS. See image below. ![](./Documentation/Pictures/CAMARAaaS-QoD-Prov-API-Characteristics.png) -### 5. Validation +## 5. Validation Now we can test if the two services are communicating. To do so, you should create a QoD Provisioning via the API that was just deployed. You may do that, using this command: @@ -415,4 +426,7 @@ You should receive the following response. {"device":{"phoneNumber":"+987654321","networkAccessIdentifier":"987654321@example.org","ipv4Address":{"publicAddress":"203.0.112.12","privateAddress":null,"publicPort":59765},"ipv6Address":"2001:db8:85a3:8d3:1319:8a2e:370:7344"},"qosProfile":"QOS_PROFILE_A","sink":"https://endpoint.example.com/","sinkCredential":{"credentialType":null},"provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483","startedAt":"2024-12-15T11:00:00","status":"AVAILABLE","statusInfo":null} ``` -Notice the `"status":"AVAILABLE"` . This means the 2 services are communicating. Now, you just have to implement your own Operator Service Kubernetes Operator, and you may use OSL’s CAMARAaaS Add-on to expose it through a CAMARA API. \ No newline at end of file +Notice the `"status":"AVAILABLE"` . This means the 2 services are communicating. + + +Now, you just have to implement your own Kubernetes Operator for your 5G Core configuration, and you may use OSL’s CAMARAaaS Add-on to expose it through a CAMARA API. \ No newline at end of file diff --git a/README.md b/README.md index 74f4127c0ef8eed1d6b892290348739ed36407fe..bac050cb7cd3d7985ae56d7b3fb44459392444c0 100644 --- a/README.md +++ b/README.md @@ -1,37 +1,116 @@ # CAMARAaaS Add-on -The **CAMARA as a Service OSL Add-on** allows telecom operators and customer service providers to expose OSL services through CAMARA APIs. 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. Thus, this add-on enables the orchestration of CAMARA APIs, which will then be used to control the lifecyle and the operations that shall take place in an already existing OSL Service. +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. + +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 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: - **Seamless Integration**: Operators can expose their existing OSL services through CAMARA APIs, maintaining consistency with the OSL framework while offering additional accessibility. -- **Dynamic Service Control**: Allows runtime updates to characteristics of 5G-related Services, such as UE profiles or Network Slices, via CAMARA REST API calls. The updated of the characteristics of a Service can then be consumed by a Kubernetes Custom Resource that will produce an operation according to the updated characteristics. +- **Dynamic Service Control**: Allows runtime updates to characteristics of 5G-related Services, such as UE profiles or Network Slices, via CAMARA REST API calls. The updated characteristics of a Service can then be consumed by a Kubernetes Custom Resource that will produce an operation according to the updated characteristics. -## Architecture and Interactions +## Architectural approach and service interactions -The add-on introduces a generic **CAMARA API Service**, which acts as a wrapper for existing (running) services. The architecture ensures: +The add-on introduces a generic **CAMARA API Service**, which acts as a wrapper for existing (running) services registered in TMF Service Inventory. The architecture ensures: 1. **API Exposure**: CAMARA APIs are orchestrated by OSL (offered as a service) and their endpoints are exposed to the end clients. 2. **Service Mapping**: The CAMARA API Service references a running service (identified by a UUID), enabling targeted operations. The invoking of CAMARA API endpoints will results in updates in the running service’s characteristics. -3. **Operational Flow**: Updates triggered via CAMARA APIs are propagated to the operator's service through OSL0s message queue (Active MQ), ensuring synchronization of service characteristics. +3. **Operational Flow**: Updates triggered via CAMARA APIs are propagated to the operator's service through OSL's message queue (Active MQ), ensuring synchronization of service characteristics. -This architecture is presented in the figure below: +This architectural approach is presented in the figure below: ![CAMARAaaS-Architecture](Documentation/CAMARAaaS-Architecture.png) -As already mentioned, the step “PATCH Characteristics” is achieved by send a message to OSL’s message bus. +### **Components in the Architecture** + +1. **Service Specification Catalogue**: + - Stores the service specifications. + - Contains the `CAMARA API Controller` service specification, which defines the profile enforcer functionality. + +2. **Service Inventory Catalogue**: + - Tracks service instances (e.g., RFS - Resource-Facing Services) and their configurations. + - Includes services such as: + - CAMARA API Exposure Profile Enforcer. + - 5G Network Slice. + - Network profiles and UE (User Equipment) services. + +3. **Resource Inventory Catalogue**: + - Holds information about resources provisioned in the system. + - Contains resources like: + - CAMARA API Exposure. + - Profile Enforcer. + - 5G Core + - Configmaps (used for managing Kubernetes configurations). + +4. **Kubernetes Cluster**: + - Hosts and manages the 5G Core components. + - Hosts all our operators (OSL can manage all these through CRIDGE - not depicted) + - Facilitates configuration updates via ConfigMap and resource values. + +5. **CAMARA API Controller**: + - Processes API exposure requests and orchestrates resources for API exposure. + - Generates the CAMARA API Exposure resource on demand. + +--- + +### **Processes in the Workflow** + +There are two workflows depicted -For OSL’s community to get the full grasp of this architecture, we also make available a sequence diagram with all interactions that take place. +1. **Service Order Creation**: + - A service order is initiated to expose a service CAMARA API Exposure with parameter(`ExposeServiceUUID=Profile Enforcer`) using the TMF Service order API. + - This triggers the service provisioning process in the Service Inventory Catalogue. + - A custom resource is created and request via the CAMARA API controller to create the CAMARA API Exposure for Service Profile Enforcer + - The `CAMARA API Exposure` resource is created and populated with configuration values. + - The API Exposure is finalized and made available for consumption via the CAMARA API Exposure created service in the cluster. + + +2. **CAMARA API Usage**: + - The API request includes QoD (Quality of Delivery) parameters and is accessible via a specified NodePort and endpoint URL e.g. (`portal.osl/{serviceAUUID}/camaraapiFQDN`). + - A client makes a CAMARA QoD Request + - TMF request is used to patch and customize Profile enforcer service configurations in the inventory + - This is passed through OSL orchestrator and CRIDGE down to The `5G Core Controller` + - The `5G Core Controller` modifies configurations such as: + - Slices (5G Network Slice profiles). + - User equipment (UE) profiles. + - These changes are propagated to the Kubernetes-managed 5G Core components. +- Resources in the Resource Inventory Catalogue are updated to reflect the service requirements. +- Updates are made to the `Configmap` resource to align with the latest service configurations. +- These changes ensure the 5G Core components operate with updated slice, profile, and UE configurations. +--- + +This architecture emphasizes automation, modularity, and interoperability between CAMARA APIs and 5G Core infrastructure, leveraging Kubernetes for seamless management and deployment. + +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 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. ![CAMARAaaS-Workflow-OSLToday](Documentation/CAMARAaaS-Workflow-OSLToday.png) +Since we have the service running in previous step, we request to expose it via a certain CAMARA API. We order the CAMARA controller to expose this service via CAMARA API, we just need to pass during the Service Order the UUID identifier of the service in TMF Service Inventory. + ![CAMARAaaS-Workflow-ServiceOrdering](Documentation/CAMARAaaS-Workflow-ServiceOrdering.png) +Since we have now a new CAMRAS API service, clients can use this new API to reconfigure the service. This request is passed through the service bus to the TMF API and then down to the 5GController service. +As already mentioned, the step “PATCH Characteristics” is achieved by send a message to OSL’s message bus. + + ![CAMARAaaS-Workflow-ServiceOperation](Documentation/CAMARAaaS-Workflow-ServiceOperation.png) + + ## Important Considerations -The OSL CAMARA as a Service Add-on depends on 2 Services: +The CAMARAaaS Add-on depends on 2 Services: - The OSL CAMARA API Service - Is a generic CAMARA API wrapper service implemented by the OSL team