TS 26.512: M5 Dynamic Policies API and Network Assistance API - Potential inconsistency in the resource structure

[dsilhavy]

Description

TS 26.512 17.70 defines the M5 Dynamic Policies API and the M5 Network Assistance API and their corresponding resource structures:

• {apiRoot}/3gpp-m5/{apiVersion}/dynamic-policies/
• {apiRoot}/3gpp-m5/{apiVersion}/network-assistance/

The DynamicPolicy resource that is sent as a payload in the POST request is defined in Section 11.5.3.1 and contains a provisioningSessionId. The same is true for the provisioning of a new network assistance session, as can be seen in the defintion of the NetworkAssistanceSession resource in Section 11.6.3.

Compared to other API endpoints such as the one for consumption reporting and metrics reporting the provisioningSessionId is not part of the resource structure. As an example:

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

Discussion

I was wondering what the reason was to place the provisioningSessionId in the POST body for dynamic policies and network assistance. This seems to be inconsistent to what was done for metrics reporting and consumption reporting.

As an example, can we add the provisioningSessionId as a sub-resource path to the POST request of the Dynamic Policies API? From my understanding the provisioningSessionId is not needed for the GET, PUT, PATCH and DELETE operations as we are using a unique dynamicPolicyId. Consequently, we can not add the provisioningSessionId to the base URL path.

[rjb1000]

Thinking about this one...

[rjb1000]

After discussing with @davidjwbbc, I decided to try and make the case for this change in TS 26.510 Rel-18 first and will present a pCR to SA4#127 for possible agreement.

For consistency of approach across reference point M5 (except for Service Access Information retrieval, which is being changed differently in Rel-18), we both agreed that a uniform base path that includes the Provisioning Session ID at the start for all the other API endpoints would be beneficial:

• /provisioning-sessions/{provisioningSessionId}/dynamic-policies/
• /provisioning-sessions/{provisioningSessionId}/network-assistance-sessions/
• /provisioning-sessions/{provisioningSessionId}/metrics-reporting/{metricsReportingConfigurationId}
• /provisioning-sessions/{provisioningSessionId}/consumption-reporting

Here is my prototype implementation on a feature branch of 3GPP Forge:

• https://forge.3gpp.org/swagger/editor-versions/v3.18.0/?url=https://forge.3gpp.org/rep/sa4/5gms_pro_ph2/raw/m5-refactoring/TS26512_Maf_SessionHandling.yaml

[rjb1000]

As an adjunct of this design, {provisioningSessionId} needs to become a read-only property of the DynamicPolicy and NetworkAssistanceSession resources that are created by the Media AF on request from the Media Session Handler.

[rjb1000]

Decided not to pursue this in Rel-16 or Rel-17 because it would break backwards compatibility of the APIs.