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: Clarification on reportFormat URIs for reports defined in the spec #111

Closed davidjwbbc closed 2 months ago

davidjwbbc commented 7 months ago

TS 26.532 v18.1.0 Table 5.4.2.2-1 shows that a DataReportingRule has a mandatory reportingFormat property which contains a URI describing the report format to use.

I cannot seem to find the reportingFormat URIs to use for the base data report types defined in TS 26.532. Table 7.3.2.3-1 defines the actual report structure, and Annex A defines the record types, but the reportFormat URIs are not stated in either location. Are these reportingFormat URIs defined anywhere?

rjb1000 commented 7 months ago

My assessment is that the reporting format for any given data domain is pre-determined by the JSON data types defined in TS 26.532 table 7.3.2.3-1. (This view is further supported by the text in clause 5.3.2.3.)

I believe this stems from a misinterpretation of the stage-2 requirement in TS 26.531 clauses 4.6.x which refer to the high-level concept of reporting format in the context of data reporting rules. Because this requirement is implicitly satisfied by the JSON syntax in TS 26.532 table 7.3.2.3-1, it was a mistake to express this as an explicit property of DataReportingRule in table 5.4.2.2-1.

In light of this, the reportingFormat property appears to be redundant and I recommend removing it altogether from table 5.4.2.2-1 (and from the OpenAPI), taking care to remove all other references to reporting format in other rows of this table.

rjb1000 commented 7 months ago

Given that this issue affects the provisioning and reporting of UE data to the standalone Data Collection AF (i.e. for exposure of the basic SA2 events to NWDAF), I think changes to both Rel-17 and Rel-18 are justified, even though 5G-MAG Reference Tools is only implementing Rel-18.

The Rel-17 fix could potentially be folded in to TS 26.532 CR0007 that is already addressing #114.

rjb1000 commented 7 months ago

For reasons of backwards compatibility, we could simply mark the property as optional in Rel-17.

It could be marked as deprecated in Rel-18.

rjb1000 commented 6 months ago

Change Requests contributed to SA4#127-bis-e for agreement:

rjb1000 commented 5 months ago

Change Requests agreed without revision at SA4#127-bis-e:

These will go to SA#104 for approval in June.

rjb1000 commented 2 months ago

New specification versions published following approval of CRs at SA#104: