search

5G-MAG / Standards

Specifications related to 5G-MAG's areas of work. Tracking comments, bug-fixing, request for new features, etc.
https://www.5g-mag.com/standards
12 stars 4 forks source link

TS 26.532: Need for a configuration context in data reporting sessions #133

Open davidjwbbc opened 3 months ago

davidjwbbc commented 3 months ago

Problem

During work implementing the Data Collection Application Function it has become apparent that there are problems arising from a disconnection between:

  1. Provisioned configurations (each containing a set of sampling rules, reporting rules, reporting conditions and access profiles).
  2. How the rules and conditions contained within these configurations are presented to the data collection client by the Data Collection AF in data reporting sessions.
  3. How the data collection client subsequently submit reports to the Data Collection AF.

Problematic observations:

  1. The provisioned rules and conditions are flattened from multiple configurations in the current set of provisioning sessions into simple lists provided to the data collection client in response to it setting up a data reporting session. In the flattening process, the information about which sampling rules are paired with which data reporting rules and data reporting conditions is lost. This could result in sampled data being reported at times or when conditions are met that were intended for other sampling rules.
  2. The DataReport submitted by the data collection client contains no information about which sampling rule or rules stimulated collection of the UE data. It is therefore impossible for the Data Collection AF report recipient to know which set of DataAccessProfiles are applicable to those records.

Suggested solution

It is proposed that an array of context identifiers, each one identifying a DataReportingConfiguration in the AF, is added to certain data types used in the Ndcaf_DataReporting service:

Multiple data reporting configurations provisioned by the same or different Application Service Providers may use the same sampling rules or reporting rules or reporting conditions. These can be collapsed in the DataReportingSession into a single entry in the proposed new array of context identifiers. Since one sample record may be the consequence of multiple contexts, because multiple context identifiers may be associated with a DataSamplingRule, then reporting the list of context identifiers from the DataSamplingRule allows the AF to process that record against each set of DataAccessProfiles that apply to it.

The suggestion is to add a read-only contextIds property, of type array(ResourceId), to each of:

This new field is filled in by the Data Collection AF, containing an identifier that will allow it to identify specific DataReportingConfigurations, for each DataSamplingRule, DataReportingRule and DataReportingCondition passed to the data collection client when it creates a new DataReportingSession. The data collection client then sample the data according to the DataSamplingRules, making a note of which sampling rule was used to generate that record.

Further, it is proposed to add contextIds, of type array(ResourceId) to BaseRecord, as a read/write or write-only property. All reported UE data records will thus provide the context identifier used to generate it.

The DataReportingRules and DataReportingConditions trigger the submission of data reports from the data collection client to the Data Collection AF. These will only contain data records where the associated DataSamplingRule.contextIds intersect with the DataReportingRule and/or DataReportingCondition.contextIds (this ensures reports are only sent as intended by the provisioned configuration). The value of DataSamplingRule.contextIds is conveyed in the BaseRecord.contextId of the data record in the DataReport.

While processing received DataReport records into AfEventNotifications, the Data Collection AF can thus use the context identifier in each reported record to identify the DataReportingConfigurations that the record was triggered by, and it can therefore select set of DataAccessProfiles that should be applied for each AfEventNotification.

rjb1000 commented 3 months ago

I note that DataSamplingRule, DataReportingCondition and DataReportingRule are all data types shared between the provisioning and reporting APIs (they are specified in clause 5.4 of TS 26.532).

If we are adding a read-only contextId property to each of them, are we happy that the value assigned by the Data Collection AF is also exposed to the Application Service Provider via reference point R1, @davidjwbbc?

davidjwbbc commented 3 months ago

I note that DataSamplingRule, DataReportingCondition and DataReportingRule are all data types shared between the provisioning and reporting APIs (they are specified in clause 5.4 of TS 26.532).

If we are adding a read-only contextId property to each of them, are we happy that the value assigned by the Data Collection AF is also exposed to the Application Service Provider via reference point R1, @davidjwbbc?

The set of contextIds would be specific to the reporting application and may even be specific to a particular UE or group of UEs, so although the property would be a read-only property I would only propose that the AF fill it in as part of the various rules and conditions provided in the DataReportingSession. There would be no reason to return a value for this property via R1 unless you wanted an alternative method of providing these reporting contexts to the UE app (e.g. via M8 for 5GMS).

rjb1000 commented 3 months ago

@davidjwbbc wrote:

The set of contextIds would be specific to the reporting application and may even be specific to a particular UE or group of UEs, so although the property would be a read-only property I would only propose that the AF fill it in as part of the various rules and conditions provided in the DataReportingSession. There would be no reason to return a value for this property via R1 unless you wanted an alternative method of providing these reporting contexts to the UE app (e.g. via M8 for 5GMS).

I agree that contextId is only significant for the Data Reporting reference points, and hence there is no reason to expose this externally at reference point R1. I simply point out that the DataSamplingRule, DataReportingCondition and DataReportingRule data types are all shared with the provisioning reference point, so visibility of this new contextId property is unavoidable with the current data type design.

I assume we would declare this new property as required as well as readOnly in the three abovementioned data types.

davidjwbbc commented 2 months ago
  • But what about when the Application Service Provider interrogates the Provisioning Session at reference point R1? Is there a way to suppress the population of a required read-only property?

This property would not be populated in the AF until the structure is about to be sent, so either:

  1. Have the contextIds property a 1..* array that is read-only but also not required. That way the AF can put it in for R2-R4 but omit the property for R1.
  2. Have the contextIds property a 0..* array that is read-only and required. But this array will be left empty for R1 and only populated for R2-R4.
  3. Have the contextIds property a 1..* array that is read-only, required and nullable. That way the AF can put an array in for R2-R4 but mark the property as null for R1.
davidjwbbc commented 2 months ago

After discussion with @rjb1000 we've reached the conclusion that exposing the contextIds at R1 is actually a good thing to support configuration and indirect data reporting via R8. We can conclude it is therefore fine to add a contextIds property to each of the shared data types which is a required, read-only 1..* array.

rjb1000 commented 1 month ago

Change Requests contributed to SA4#129-e:

rjb1000 commented 1 month ago

Change Requests agreed at SA4#129-e:

Up for approval at SA#105.