QoE Metrics Reporting - M1 Provisioning - samplingPeriod can be negative

[dsilhavy]

Description

TS 26.512 Table 7.8.3-1 defines the samplingPeriod as follows:

The time interval the 5GMS Client should wait between sampling the QoE metrics specified by this metrics reporting configuration.

In my opinion, a negative value does not make sense here, although it is not explicitly mentioned in the specification. The type of the samplingPeriod is DurationSec which is defined in TS29571_CommonData as :

    DurationSec:
      type: integer
      description: indicating a time in seconds.

Suggested Solution

A negative time in seconds seems to be unreasonable. I suggest adding the following to TS26512_M1_MetricsReportingProvisioning.yaml for samplingPeriod:

minimum: 0
exclusiveMinimum: true

The textual description in TS 26.512 might be changed to

The time interval the 5GMS Client should wait between sampling the QoE metrics specified by this metrics reporting configuration. The value shall be greater than zero.

[rjb1000]

Rel-18 change to TS 26.510 committed to 3GPP Forge project:

• https://forge.3gpp.org/rep/sa4/5gms_pro_ph2/-/tags/DurationSec-minima

Rel-17 fix will require a formal Change Request, but @davidjwbbc will provide a temporary workaround.

[rjb1000]

Change Request contributed to MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.512 (OpenAPI YAML change only)
  • Rel-16: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-17 as a starting point.
  • Rel-17: CR0069 "[5GMS3, TEI17] Metrics reporting corrections" in S4aI240047.
  • Rel-18: Changes to be handled directly in TS 26.510 V1.2.1.

[rjb1000]

Change Request treated at MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.512
  • Rel-17: CR0069 "[5GMS3, TEI17] Metrics reporting corrections" in S4aI240047.
  • Endorsed and will be resubmitted to SA4#128 for agreement.
  • Rel-18: Changes to be handled directly in TS 26.510 V1.2.1.
  • Editor to check TS 26.510 prior to contribution.