Configuration Management Interface

The Configuration Management Interface (cmi) provides a producing data source for reading and writing CM data in the R1 environment.

The cmi provides a pre-release API that is expected to change as O-RAN Alliance standards mature.

It allows getting and setting individual CM values for individual identifiers as well as setting multiple values for one or more identifiers. An identifier (ID) denotes a network entity such as gNB ID, DU ID, CUCP ID, etc., but in most cases, it is a cell global ID (CGI). To describe the API usages, this document uses cell for convenience.

The service is accessible as a direct data type (that is, once data-type discovery via the dms has been used to find the service) and via job requests mediated by the Data Management Service (dms).

The following data-types are exposed:

• cmread_direct: Read one parameter for one cell.
• cmwrite_direct: Write one parameter for one cell.
• cmread: Read multiple parameters for one or more cells.
• cmwrite: Write multiple parameters for one or more cells.
• cmtrack: Create subscriptions for change notifications of one ore moe cells.

The _direct types may, as the name implies, be used directly (that is with direct HTTP requests to cmi) from an rApp once the consuming rApp has discovered the type and the URI of an available producer.

cmread and cmwrite are used by creating jobs on the dms and asynchronously waiting to be notified of results.

cmtrack is used by creating jobs on the dms and creating subscription for change notifications on cmi. This job should be preserved to deliver multiple change notifications of the CM parameters in the job. Only when a new job is created to update the subscription list, the previous job stored on dms and cmi are deleted.

Notes:

• The data format used for representing CM parameters is a simple format designed to allow early experimentation prior to a standard being formalized by the O-RAN alliance. It may be insufficiently expressive for some use cases. Please provide feedback when this is the case.

• These formats are likely to change.

• The cmwrite format is designed to allow ordered collections of multiple CM changes to a mix of cells and parameters. Depending on the CM system behind the CMI, the collections can be associated with an optional policy, TRANSACTION or NON_TRANSACTION, which describes what happens in the event of one or more failures in the changes in the collection. With NON_TRANSACTION partial failures are allowed. With TRANSACTION, if the backend supports it, a rollback will be attempted when there is any failure.

  Each change in a collection may be associated with an optional operation: set, add, remove. These mean:

  • set: The stored value is changed to the provided value.
  • add: The stored value is updated to have the provided value or values (if it is a list) added if it is not already present.
  • remove: The stored value is updated to have all entries of the provided value or values removed.

  add and remove only work for values that are already in list form (including an empty list).

  The behavior of add and remove results in list values being de-duplicated. If duplicate values are required, set must be used.