Data Management Service
The Data Management Service (DMS) maintains the service registry and coordinates interaction between data producers and consumers in the R1 environment.
The Data Management Service provides a pre-release and pre-standard API supporting the functionality provided by the Service Management and Exposure (SME) and Data Management and Exposure (DME) services being defined by ORAN. The API is expected to change as O-RAN Alliance standards mature.
Any R1 platform service or rApp must register to the service registry of the DMS to gain access to the system, make other services aware of the new service's existence, and discover other services.
Incoming services discover the location of the service registry component of the DMS using the Bootstrap Service, register with the service registry, and request the location of the producer and consumer components of the DMS.
Once registered, a service must send regular heartbeats (as PATCH requests to /services/{id}) to the service registry or be marked as disabled, and thus undiscoverable. If a data producer is marked disabled, data-requests for data-types the producer produces will not be routed to that producer. If there are no enabled producers for a data-type, data-requests for that type cannot be satisfied.
At this time authentication and authorization are not implemented. When those features are standardized, the service registry component of the DMS will play a key role.
A data producer produces one or more types of data. Each producer registers the data types it produces and then, when ready, announces that it is available to handle "job requests" for those types. Note that there may be more than one producer for any given data type.
A data consumer discovers which data types are available in the environment and may create jobs that satisfy consumption requirements. The Data Management Service finds producers that can satisfy the jobs. Depending on the data-types involved, the job requests may be satisfied by immediate access to results or notifications or callbacks that include the results or include a URL where the results may be retrieved. Note that a consumer may create a request for a data type with no corresponding active producer, in which case the DMS will not enable the job until there is an active producer of that type.
The format of a "job request" is described by either a schema built into the DMS, or a schema provided when a producer registers a data-type. The details of a schema may be retrieved using the getInfoTypeConsumer operation (note: the term info-type is a holdover from earlier iterations of R1, data-type is now the preferred term).
The "job request" expresses the constraints to be satisfied when querying or filtering the data provided by the producer. This might be a time range, a set of cell IDs, a set of parameter names, or some combination. The exact details of how a job can be expressed are entirely controlled by the data-type definition.
As above, authorization is not yet implemented in job handling. When it is, a job could be rejected as forbidden for this session, despite being correctly formed, due to access policy constraints.
The APIs in the Data Management Service are presented via three facets and base paths. The facets appear in the Service Registry as separate services: "service", "producer" and "consumer". "service" is discovered via the Bootstrapper Service and allows an rApp to discover one or both of "producer" and "consumer" depending on its needs.
Notes:
In the current iteration of the VMware Centralized RIC, the primary job interaction is via callbacks that include a job result URL.
The Data Management Service API is based on the Enrichment Coordinator Service produced by the ORAN Software Community of the O-RAN alliance. Terminology used is the result of an evolution of requirements and may include inconsistencies. Paths are duplicated from that API. Both of these may change.
The Data Management Service API is pre-standard and subject to change as the R1 Interface matures.