docs/sections/apis/ves-hv/supported-domains.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 .. _domains_supported_by_hvves:
   5
   6 Domains supported by HV-VES
   7 ===========================
   8
   9 .. _perf3gpp:
  10
  11 perf3gpp domain - delivery of equipment Performance Monitoring (PM) data, based on 3GPP specifications
  12 ------------------------------------------------------------------------------------------------------
  13 The purpose of the **perf3gpp** domain is frequent periodic delivery of structured RAN PM data commonly referred to as Real Time PM (RTPM). The equipment sends an event right after collecting the PM data for a granularity period.
  14
  15 The characteristics of each event in the **perf3gpp** domain:
  16
  17 - Single measured entity, for example, BTS
  18 - Single granularity period (collection *begin time* and *duration*)
  19 - Optional top-level grouping in one or more PM groups
  20 - Grouping in one or more measured objects, for example, cells
  21 - One or more reported PM values for each measured object
  22
  23 Due to the single granularity period per event, single equipment supporting multiple concurrent granularity periods might send more than one event at a given reporting time.
  24
  25 The **perf3gpp** domain is based on 3GPP specifications:
  26
  27
  28 - `3GPP TS 28.550 <http://www.3gpp.org/ftp//Specs/archive/28_series/28.550/>`_
  29
  30 - `3GPP TS 32.431 <http://www.3gpp.org/ftp//Specs/archive/32_series/32.431/>`_
  31
  32 - `3GPP TS 32.436 <http://www.3gpp.org/ftp//Specs/archive/32_series/32.436/>`_
  33
  34 The event structure is changed in comparison to the one presented in 3GPP technical specifications. The 3GPP structure is enhanced to provide support for efficient transport.
  35
  36 Definitions for the **perf3gpp** domain are stored in Perf3gppFields.proto and MeasDataCollection.proto, listed below:
  37
  38 .. literalinclude:: Perf3gppFields.proto
  39     :language: protobuf
  40
  41 .. literalinclude:: MeasDataCollection.proto
  42     :language: protobuf
  43
  44 Selecting Complimentary fields for population of **perf3gpp** event
  45 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  46
  47 Context: at the upper level, *VesEvent.eventFields* is an opaque bytes field, and in the case of the **perf3gpp** domain (that is VesEvent.commonEventHeader.domain=="Perf3gpp"), *eventFields* maps to a structure defined by *Perf3gppFields*.
  48
  49 *Perf3gppFields* contains two main sub-structures:
  50
  51   - *eventAddlFlds*: the usual optional VES per-event data (*HashMap*, name/value pairs)
  52   - *measDataCollection*: the actual payload, based on 3GPP specifications, but modified in order to optionaly reduce the size of the event
  53
  54 Usage of *measDataCollection*:
  55
  56  The *measDataCollection* structure offers flexibility in the way an equipment provides the Performance Monitoring (PM) data.
  57  The following table gives an outline of the two main options:
  58
  59 - Following 3GPP standard as closely as possible
  60 - Reducing the message size
  61
  62 Each row of the table corresponds to one field where a choice is to be made. For each main option it describes whether an optional field is relevant or not, or which subfield to provide for a "oneof" GPB field.
  63
  64   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  65   |                            |          | Focus 1: 3GPP compatibility | Focus 2: Minimum event size |          |
  66   | *MeasDataCollection* field | Type     | (send textual IDs)          | (send numerical IDs)        | Notes    |
  67   +============================+==========+=============================+=============================+==========+
  68   | MeasData.measObjInstIdList | optional | <not provided>              | <mandatory>                 | [1]_     |
  69   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  70   | MeasValue.MeasObjInstId    | oneof    | sMeasObjInstId              | measObjInstIdListIdx        | [1]_     |
  71   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  72   | MeasInfo.MeasInfoId        | oneof    | sMeasInfoId                 | iMeasInfoId                 | [2]_     |
  73   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  74   | MeasInfo.MeasTypes         | oneof    | sMeasTypes                  | iMeasTypes                  | [2]_     |
  75   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  76   | Notes:                                                                                                       |
  77   |   .. [1] *MeasData.measObjInstIdList* and *MeasValue.MeasObjInstId.measObjInstIdListIdx* are interdependent  |
  78   |   .. [2] Numerical IDs normally require the mapping to textual IDs to be provided offline in a PM dictionary |
  79   |                                                                                                              |
  80   +----------------------------+----------+-----------------------------+-----------------------------+----------+
  81
  82 .. note:: The division between focus 1 and focus 2 above is illustrative, and a mix of choices from both options is possible.
  83
  84 .. note:: *MeasResult.p* can be used to reduce the event size when more than half of the values in the event are zero values, and these values are not sent to ONAP. Only non-zero values are sent, together with their *MeasInfo.MeasTypes* index (*MeasResult.p*).
  85
  86
  87 .. _stndDefined_domain:
  88
  89 stndDefined domain
  90 ------------------
  91
  92 The purpose of 'stndDefined' domain was to allow collection of events defined by standard organizations using HV-VES,
  93 and providing them for consumption by analytics applications running on top of DCAE platform.
  94
  95 All events, except those with 'stndDefined' domain, are routed to DMaaP topics based on domain value. Events with
  96 'stndDefined' domain are sent to proper topic basing on field 'stndDefinedNamespace'.
  97
  98 This is the only difference from standard event routing, specific for 'stndDefined' domain. As in every other event
  99 routing value is being mapped for specific Kafka topic. Mappings to Kafka topics are located in HV-VES Helm Chart
 100 values.yaml file. Four of them are by default available in HV-VES:
 101
 102 +-------------+--------------------------------+--------------------------------------+
 103 | Domain      | StndDefinedNamespace           | Kafka topic                          |
 104 +=============+================================+======================================+
 105 | stndDefined | ves-3gpp-fault-supervision     | SEC_3GPP_FAULTSUPERVISION_OUTPUT     |
 106 +-------------+--------------------------------+--------------------------------------+
 107 | stndDefined | ves-3gpp-provisioning          | SEC_3GPP_PROVISIONING_OUTPUT         |
 108 +-------------+--------------------------------+--------------------------------------+
 109 | stndDefined | ves-3gpp-heartbeat             | SEC_3GPP_HEARTBEAT_OUTPUT            |
 110 +-------------+--------------------------------+--------------------------------------+
 111 | stndDefined | ves-3gpp-performance-assurance | SEC_3GPP_PERFORMANCEASSURANCE_OUTPUT |
 112 +-------------+--------------------------------+--------------------------------------+