-
Epic
-
Resolution: Unresolved
-
Medium
-
None
-
[RIC-A-F33] RIC supports control loop latency measures (RIC to RAN to RIC (or RAN-to-RIC-to-RAN) via E2 termination)
Note this item is about latency.We have separate items for other statistics from E2T (E2M). I.e., RIC-178.
This item depends on RIC-126 being implemented first.
Collect the latency for each control loop execution, report min/max/avg latency for each control loop via the Prometheus metrics collection; Correlator is the E2 Call Process ID (octet). One option for a latency measurement is that the RIC healthcheck ping would be used to measure latency (see RIC-95), but this healthcheck ping is currently an operator-initiated one only. Note that RIC-95 idea is to also put timestamps into the output. So operators might see latency from that.
The latency measurmeents could employ some sampling mechanism as well.
- relates to
-
RIC-358
RIC E2T to feed into RIC statistics system the metrics on E2 message received and sent by gNB
-
- Done
-
-
RIC-178
collect number of messages for each E2 connection in E2T, but do not feed into any statistics system
-
- Done
-
-
RIC-69
actual metrics from platform components and from sample xApp
-
- To Do
-
-
RIC-126
Statistics: Support O1-level statistics from xApps via RMR to prometheus to O1 (instead or in addition to REST solution)
-
- To Do
-
