TS 26.532: Clarification on UE Communication report scope

[davidjwbbc]

Based on TS 26.532 v18.1.0

It is unclear if the UE Communication Report is only meant to report on network data usage related to the externalApplicationId bound to the DataReportingSession or if it is supposed to be for all traffic going to or from the UE.

If it's for all traffic, not just that for a specific externalApplicationId, then:

• What externalApplicationId should it be logged against?
• Is there a "well known" externalApplicationId to indicate that this report comes from the general UE usage and not a specific app?

[rjb1000]

I had to go back to TS 23.288 (written by SA2) to understand the underlying stage-2 requirement here. There are references to "communication performance" peppered through that specification, but it is only when you search the clauses about data analytics (the operation of the NWDAF) do you find a possible answer to the question:

6.7.3 UE Communication Analysis

6.7.3.1 General

...
An NWDAF supporting UE Communication Analytics collects per-application communication description from AFs. If consumer NF provides an Application ID, the NWDAF only considers the data from AF, SMF and UPF that corresponds to this application ID. NWDAF may also collect data from AMF.

This implies that downstream consumers of analytics information from the NWDAF can filter on Application ID. This implies that when Application Functions (such as the Data Collection AF) expose events to the NWDAF, they should include this parameter.

My initial impact assessment is that the Data Collection AF needs to include the Application ID in the event corresponding to communication performance that it exposes to the NWDAF. Further analysis is needed to determine whether this extends to all "generic" events exposed by the Data Collection AF to the NWDAF, as well as 5G Media Streaming events defined in TS 26.512. There may be an argument for adding the Application ID as a property of the generic BaseRecord type if it is not included in the event-specific data types defined below it.

A similar analysis should also be conducted for other filters specified in clause 6.7.3.1 of TS 23.288 (and other similar clauses specifying analytics consumption parameters for other in-scope event types).

• Slice ID (S-NSSAI)
• Data Network Name (DNN).
• Area of Interest.

These filters are included in the event records exposed by the 5GMS AF instantiation of the Data Collection AF in the common BaseEventRecord specified in TS 26.512, but there could be an argument for promoting them to the TS 26.532 common BaseRecord data type depending on the above analysis.

[rjb1000]

The above analysis is going to take quite some time to complete, so I think it best to deal with this in a separate set of Change Requests, perhaps in a later SA4 meeting.

I think there is some justification in fixing this for Rel-17 as well as Rel-18 given that it impacts the reference point between the Data Collection AF and the NWDAF.

[rjb1000]

In terms of populating a hypothetical new Application ID property in 5GMS events exposed by the Data Collection AF instantiated inside the 5GMS AF, this would be a simple reverse look-up from the media delivery session identifier to the Provisioning Session ID to the Application ID.

[rjb1000]

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

• TS 26.247
  • Rel-14: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-15: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-16: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-17: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-18: CR0185 "[EVEX, TEI18] Additional QM10 reporting schema fields for alignment" in S4aI240053.
• TS 26.510
  • Rel-18: pCR "[EVEX, TEI18] Add missing implicit data reporting parameters" in S4aI240049.
• TS 26.512
  • Rel-16: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-17: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-18: CR0070 "[EVEX, TEI18] Add missing explicit data reporting and event exposure parameters" in S4aI240050.
• TS 26.532
  • Rel-17: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-18 as a starting point.
  • Rel-18: CR0011 "[EVEX] Essential corrections" in S4aI240051.

[rjb1000]

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

• TS 26.247
  • Rel-18: CR0185 "[EVEX, TEI18] Additional QM10 reporting schema fields for alignment" in S4aI240053.
    • Endorsed and will be resubmitted to SA4#128 for agreement.
• TS 26.510
  • Rel-18: pCR "[EVEX, TEI18] Add missing implicit data reporting parameters" in S4aI240049.
    • Agreed for incorporation into the Editor's draft V1.2.1.
    • Additional proposal to move the locationReporting flag from ConsumptionReportingConfiguration resource to ProvisioningSession so that it also controls the reporting of location for Dynamic Policies and Network Assistance Sessions.
• TS 26.512
  • Rel-18: CR0070 "[EVEX, TEI18] Add missing explicit data reporting and event exposure parameters" in S4aI240050.
    • Endorsed and will be resubmitted to SA4#128 for agreement.
• TS 26.532
  • Rel-18: CR0011 "[EVEX] Essential corrections" in S4aI240051.
    • Endorsed and a revision will be resubmitted to SA4#128 for agreement.
      • Need to add "TEI18" Work Item code.
    • Still need to check whether the same delimiter can be used multiple times to extend a schema type.
    • Still need to expand representation of location in XML Schema.