Jakub Dudycz | e6b4289 | 2018-11-05 16:32:19 +0100 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License. |
| 2 | .. http://creativecommons.org/licenses/by/4.0 |
| 3 | |
| 4 | .. _supported_domains: |
| 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 | |
kjaniak | e284409 | 2018-11-14 15:42:03 +0100 | [diff] [blame] | 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 | |
Jakub Dudycz | e6b4289 | 2018-11-05 16:32:19 +0100 | [diff] [blame] | 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 | |
| 88 | |
| 89 | |
| 90 | |