Qoe Metrics Report: Send metrics to AF

[dsilhavy]

Feature description

TS 26.512 defines serverAddresses as part of the clientMetricsReportingConfigurations:

A list of 5GMS AF addresses to which metrics reports shall be sent.

When receiving the metrics from the Media Stream Handler, the Media Session Handler should send them to one of the AF addresses defined in serverAddresses. See clause 11.4.2:

Metrics reports related to a specific metricsReportingConfigurationId shall be submitted to one of the URLs selected from the ClientMetricsReportingConfiguration.serverAddresses array of the ServiceAccessInformation resource (see clause 11.2.3).

The path of the URL should conform to the following general format:

{apiRoot}/3gpp-m5/{apiVersion}/metrics-reporting/{provisioningSessionId}/ {metricsReportingConfigurationId}

where {provisioningSessionId} shall be substituted by the 5GMS Client with the relevant Provisioning Session identifier and {metricsReportingConfigurationId} shall be substituted with the relevant Metrics Reporting Configuration identifier.

The only HTTP method supported by this endpoint is POST.

[dsilhavy]

One discussion item here is how do we map a metrics report to a metricsReportingConfigurationId. Currently the workflow is as follows:

1. Upon expiration of the metrics timer the Media Session Handler requests the metrics for a specific scheme from the Media Stream Handler via an IPC message. The message contains the following payload:

   data class PlaybackMetricsRequest(
   var scheme : String = "",
   var reportPeriod: Long? = 0,
   var metrics : ArrayList<String>? = ArrayList()
   ) : Parcelable

2. The Media Stream Handler derives the metrics according to metrics and scheme and send an IPC message to the Media Session Handler. Currently, this contains only the final XML metrics report. At this point, we lose the mapping to the metricsReportingConfigurationId.

Note that we maintain a HashMap for mapping a client to a ClientSessionModel in the Media Session Handler:

private var clientsSessionData = HashMap<Int, ClientSessionModel>()
data class ClientSessionModel(
    var messenger: Messenger?,
    var serviceAccessInformation: ServiceAccessInformation? = null,
    var metricReportingTimer: LinkedList<Timer> = LinkedList(),
    var serviceAccessInformationApi: ServiceAccessInformationApi? = null
)

Each message of the Media Stream Handler contains a unique client id that is used as the key for the HashMap. Consequently, we can always derive the corresponding provisioningSessionId.

The following questions should be clarified:

• Is it reasonable/allowed to define multiple clientMetricsReportingConfigurations entries with the same scheme? Otherwise we can simply use the scheme as an ID and map it back to the metricReportingConfigurationId
• Is it allowed to send the metricReportingConfigurationId from the Media Session Handler to the Media Stream Handler. In this case the PlaybackMetricsRequest class can be extended with an attribute metricReportingConfigurationId which is then included in the PlaybackMetricsResponse:

  data class PlaybackMetricsResponse(
  var metricsString : String = "",
  var metricsReportingConfigurationId : String = ""
  ) : Parcelable

[rjb1000]

Some thoughts on your questions:

Is it reasonable/allowed to define multiple clientMetricsReportingConfigurations entries with the same scheme?

It's not prohibited by the specification. I can imagine a Use Case where more than one MetricsReportingConfiguration with the same scheme identifier is provisioned at reference point M1, but with different other permutations of parameters. For example, a different subset of QoE metrics reported with a different sample percentage and/or reporting interval; or a different set of URL filters applicable to a different Data Network Name (DNN).

Is it allowed to send the metricsReportingConfigurationId from the Media Session Handler to the Media Stream Handler?

I don't see why this couldn't be exposed on a 3GPP-defined API between two subcomponents of the 5MGS Client.

[dsilhavy]

Implemented according to the description and discussion above. Some final comments

• As discussed, the metricsReportingConfigurationId is sent back and forth between Media Session Handler and Media Stream Handler
• A random entry from the ClientMetricsReportingConfiguration.serverAddresses is chosen as the reporting endpoint for each new streaming session

Currently my "test/dummy" data for the implementation looks like this:

  5: {
        provisioningSessionId: 5,
        provisioningSessionType: 'DOWNLINK',
        streamingAccess: {
            entryPoints: [
                {
                    locator: 'https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd',
                    contentType: 'application/dash+xml',
                    profiles: [
                        'urn:mpeg:dash:profile:isoff-live:2011'
                    ]
                }
            ]
        },
        clientMetricsReportingConfigurations: [
            {
                metricsReportingConfigurationId: "metrics-id-5",
                serverAddresses: [
                    'http://192.168.178.78:3003/3gpp-m5/v2/',
                ],
                scheme: "urn:3GPP:ns:PSS:DASH:QM10",
                dataNetworkName: "tbd",
                reportingInterval: 10,
                samplePercentage: 100.0,
                urlFilters: [],
                metrics: []
            }]
    },

I would like to verify that the serverAddresses has the right format and I need to investigate what dataNetworkName does exactly.

[rjb1000]

I would like to verify that the serverAddresses has the right format

TS 26.512 V17.5.0 added the following clarification:

Each address shall be an opaque base URL, following the 5GMS URL format specified in clause 6.1 up to and including the {apiVersion} path element.

So I would say that your example http://192.168.178.78:3003/3gpp-m5/v2/ is compliant, although arguably the final slash should be omitted in the Service Access Information. Your code could test for a slash when subsequently forming the full URL to send a metrics report to the 5GMS AF, and could conditionally add one if not already present. This would then avoid the risk of ending up with a double slash in the URL.

[rjb1000]

I need to investigate what dataNetworkName does exactly.

This is what TS 26.512 has to say:

The DNN which shall be used when sending metrics reports. If not specified, the name of the default DN shall be used.

The idea is that the 5GMS AF can tell the Media Session Handler to send QoE metrics reports to a 5GMS AF endpoint in a different Data Network (i.e. not via the default mobile broadband PDU Session). If set, the Media Session Handler needs to resolve the host name in the chosen serverAddress in the context of the correct Data Network because it will likely have a different IP address there.

(Your example serverAddress contains a pre-resolved IP address which obviously doesn't need any DNS resolution, so bypasses this mechanism.)

[dsilhavy]

I would like to verify that the serverAddresses has the right format

TS 26.512 V17.5.0 added the following clarification:

Each address shall be an opaque base URL, following the 5GMS URL format specified in clause 6.1 up to and including the {apiVersion} path element.

So I would say that your example http://192.168.178.78:3003/3gpp-m5/v2/ is compliant, although arguably the final slash should be omitted in the Service Access Information. Your code could test for a slash when subsequently forming the full URL to send a metrics report to the 5GMS AF, and could conditionally add one if not already present. This would then avoid the risk of ending up with a double slash in the URL.

Thanks I added the check for the final slash

[dsilhavy]

Implemented in #56