@@ -28,7 +28,7 @@ In order to support interaction with OSL’s CAMARAaaS APIs, the operator servic
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 characteristics to store the provisionings that were enforced by the operator’s service. We can define this characteristic as *camaraResults*.
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:
@@ -47,7 +47,7 @@ Therefore, for an operator’s service to be controlled by OSL’s CAMARA APIs,
Additional characteristics are fully supported. Those can be custom characteristics that are required by the Operator’s Service.
In regard to the *camaraResults* characteristics, 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.**
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
