InFlux DB schema (E Release)

Owned by Matti Hiltunen
Last updated: Nov 19, 2021 by Agustin PozueloVersion comment
2 min read

This page documents the inFlux DB schema used in the E Release for the KPM (and other) information collected from E2 Simulator.

VersionAuthorCommentsDate
0.1

Agustin Pozuelo

Initial DRAFT, calling for comment!

 

DRAFT / Proposal

This schema is open for discussion and contribution from the O-RAN community

Summary / Goals

The goal is to have a generic schema definition for xApps to access timeseries data obtained via E2SM/KPM and possibly the other E2SM protocols.

References

Glossary

  • SDL: Shared Data Layer, a term referring to the services and schemas used to share data among xApps

Essential InfluxDB terms:

  • Database: the highest level unit of storage
  • Measurement: a table inside a database
  • Data point: a row inside a Measurement table.
  • Field: a sort of column of a Measurement table, with name and type of data.
    • Note that not all fields need to be present in all data points
  • Tag: a metadata field that is indexed so queries on them are performant

Guidelines

  • For items not explicitly defined in O-RAN specs, look for relevant 3GPP specs.
  • Field and tag names should be brief because the may pose a direct impact on InfluxDB performance at high loads.
  • For proprietary/enrichment data fields, use a brief vendor prefix e.g. "Viavi."

Proposed Schema for E2SM/KPM data

  • Database name: “E2SM-KPM”

For the labelling of fields we will be using names from E2SM/KPM v2.0 (MeasurementLabel) and TS 28.552 "5G performance measurements" as much as possible.

Following the general ideas in from TS 28.552, using short labels, organized in hierarchical form <topic>[.<subtopic>].<name>

KPM Measurement tables:

  1. "CellReports" table containing the following fields:

    1. Timestamp

    2. PLMN (tag)
    3. KPMNodeID (tag) - The KPM Node identification in string form to accomodate the many binary variants (maybe an hex dump?)
    4. S-NSSAI (tag?) - useful to identify slices?

    5. NRCellIdentity (tag?)

      Any of the fields defined for cell reports in TS 28.552, for example the following are provided by RIC Test scenario generator:

    6. DRB.UEThpDl - Average DL throughput in Kb/s

    7. RRU.PrbUsedDl / RRU.PrbAvailDl

    8. RRU.PrbUsedUl / RRU.PrbAvailUl

    9. QosFlow.PdcpPduVolumeUl - UL PDCP PDU Data Volume (amount of kilobytes in the reporting period)

    10. QosFlow.PdcpPduVolumeDl - DL PDCP PDU Data Volume (amending inconsistency in the case of the final "L" in TS 28.552)

      And proprietary extensions:

    11. Viavi.Geo.x - Non standard / Viavi proprietary extension / External enrichment

    12. Viavi.Geo.y

    13. Viavi.Geo.z

  2. "UeReports" measurement table containing the following fields:

    1. Timestamp

    2. UE.Id - String representation to accomodate the many forms.
      Note: A "UE id resolution" xApp may be needed to match the same UE on different measurements and possibly producing unique ids for this field

    3. Slice.Id

    4. DRB.UEThpDl - TS 28.552 Average DL UE throughput

    5. RRU.PrbUsedDl - TS 28.552 DL PRB used for data traffic

    6. Viavi.Geo.x”, .y, .z...  Viavi proprietary extensions

    7. RF.serving.Id - May be just the PCI or resolved into NRCellIdentity

    8. RF.serving.RSRP (Loosely based on LTE specs)

    9. RF.serving.RSRQ

    10. RF.serving.RSSINR

    11. RF.nb1.CellId - 1st neighbour id

    12. RF.nb1.RSRP, etc. 1st neighbour signal levels

    13. RF.nb2.CellId - 2nd neighbour id

    14. RF.nb2.RSRP, etc. 2nd neighbour signal levels

  3. "cellMeasReport" cell load measurement table has the following fields:
    1. Timestamp
    2. DLOccupyPRBNum – 3GPP supported
    3. CellDLMACRate – proprietary
    4. ULSINR – proprietary
    5. MCS – proprietary
    6. PDCPOccupBuffer – proprietary
    7. PDCPUnusedBuffer – proprietary
    8. DLPacketDiscardNum – proprietary
    9. DLPacketSDUNum – 3GPP supported
    10. DLPacketLossNum – 3GPP supported
    11. DLMACRate – proprietary