Non-RT RIC RAN PM Measurement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Parent repository for components implementing Non-RT RIC RAN PM Use-case.
+Parent repository for components implementing Non-RT RIC RAN PM Use-cases.
********
The picture illustrates the components involved.
* The PM Data File Collector fetches the XML files from the RAN.
-* The PM Data Converter converts these to a Json format. The structure and the contents
+* The PM File Converter converts these to a Json format. The structure and the contents
is the same as the XML format.
* The PM Producer handles filtering and distribution of PM data to subscribers. These subscribers can be rApps.
* The Influx Logger stores selected PM mesurements into a time series database.
-* HTTPS-SERVER is for testing and implements functionality to simulate file transfer from thye RAN nodes.
+* HTTPS-SERVER is for testing and implements functionality to simulate file transfer from RAN nodes.
The third party products used are:
For more detailed documentation of the components:
* :doc:`Non-RT RIC - RAN PM - PM Data File Collector (Documentation site) <datafilecollector:index>`.
-* PM Data Converter TBD
+* :doc:`Non-RT RIC - RAN PM - PM File Converter (Documentation site) <pm-file-converter:index>`.
* :doc:`Non-RT RIC - RAN PM - PM Producer (Documentation site) <pmproducer:index>`.
* :doc:`Non-RT RIC - RAN PM - Influx Logger (Documentation site) <influxlogger:index>`.
* `Non-RT RIC - Information Coordinator Service (Documentation site) <https://docs.o-ran-sc.org/projects/o-ran-sc-nonrtric-plt-informationcoordinatorservice/en/latest/>`_.
-* HTTPS-SERVER TBD
-
-
+* HTTPS-SERVER TBD
*********
Data Flow
2. The VES event is put on a Kafka topic and picked up by the Data File Collector.
3. A PM report file is fetched from the RAN node by a file transfer protocol. Which protocol to use is defined in the VES event.
4. The collected file is stored
-5. A File collected object is put on a Kafka topic and is picked up by the PM Data Converter.
+5. A File collected object is put on a Kafka topic and is picked up by the PM File Converter.
6. The file data is read from the file store.
7. A PM report in json format is stored (compressed with gzip).
8. A message (a Json object) indicating that a new PM report (in Json format) is available is put on a Kafka topic and is picked up by the PM Data Producer.
PM Subscriber design time dependencies
**************************************
-An rApp uses the ICS API, which is avaiable in `Non-RT RIC - Information Coordinator Service (Documentation site) <https://docs.o-ran-sc.org/projects/o-ran-sc-nonrtric-plt-informationcoordinatorservice/en/latest/>`_.
+An rApp uses the ICS API to create and manage the subscription of PM Measurements.
+The API documentation is avaiable in `Non-RT RIC - Information Coordinator Service (Documentation site) <https://docs.o-ran-sc.org/projects/o-ran-sc-nonrtric-plt-informationcoordinatorservice/en/latest/>`_.
The schema for the PM Mesaurement information jobs is defined in :doc:`Non-RT RIC - RAN PM - PM Producer (Documentation site) <pmproducer:index>`.
This schema defines parameters used in the subscription (info job) and defines which measurements to subscribe for and on which
kafka topic the information shall be delivered to.
-An application retrieving logged PM data from the Influx database needs to know how the data is stored. That is
+An application retrieving logged PM data from the Influx database needs to consider how the data is stored (the schema). That is
defined in :doc:`Non-RT RIC - RAN PM - Influx Logger (Documentation site) <influxlogger:index>`.
.. image:: ./DesignTimeDependencies.png
- :width: 500pt
\ No newline at end of file
+ :width: 500pt