TS 26.512 Policy Template state reasons

[davidjwbbc]

Description

TS 26.512 Clause 4.3.7.1 shows a model where Policy Templates in a Provisioning Session transition through various states.

Some of these state changes will happen for a specific reason ("invalid" and "suspended" states). In order for the AP to address issues with a PolicyTemplate, it needs to know this reason. There is no way, in the v17.4.0 version of TS 26.512, of conveying this reason to the Application Provider with the PolicyTemplate resource (TS 26.512 Clause 7.9.3.1).

Suggested solution

Add a conditional stateReason field, of type String, to the PolicyTemplate resource in Table 7.9.3-1 which will hold a human readable reason for the latest state change. This new field must be present if the state field is "invalid" or "suspended". This can then be populated with a reason for the rejection of a PolicyTemplate when it is transitioned to the "invalid" state by a System operator, or can hold a description of the policy violation which led to the PolicyTemplate entering the "suspended" state (e.g. paid for data limits reached or too many clients using the policy).

[rjb1000]

Adding a human-readable string in the Policy Template sounds sensible from an operational point of view.

This could be called something as simple as message or comment or stateDetails.

[tlohmar]

General question on

This new field must be present if the state field is "invalid" or "suspended"."

TS 29.501 points to RFC 7807 (JSON ProblemDetails) for more detailed error information. What about inserting a object of type ProblemDetails (TS 29.571)?

[rjb1000]

TS 29.501 points to RFC 7807 (JSON ProblemDetails) for more detailed error information. What about inserting a object of type ProblemDetails (TS 29.571)?

Good idea. I like this suggestion to reuse an existing type.

[rjb1000]

Once we have a candidate solution more fleshed out, we should check whether this needs to be backported to Rel-17 and/or Rel-16.

[rjb1000]

I checked the YAML specification for ProblemDetails in TS 26.571:

    ProblemDetails:
      description: Provides additional information in an error response.
      type: object
      properties:
        type:
          $ref: '#/components/schemas/Uri'
        title:
          type: string
        status:
          type: integer
        detail:
          type: string
          description: A human-readable explanation specific to this occurrence of the problem.
        instance:
          $ref: '#/components/schemas/Uri'

        cause:
          type: string
          description: >
            A machine-readable application error cause specific to this occurrence of the problem. 
            This IE should be present and provide application-related error information, if
            available.

        invalidParams:
          type: array
          items:
            $ref: '#/components/schemas/InvalidParam'
          minItems: 1
        supportedFeatures:
          $ref: '#/components/schemas/SupportedFeatures'
        accessTokenError:
          $ref: 'TS29510_Nnrf_AccessToken.yaml#/components/schemas/AccessTokenErr'
        accessTokenRequest:
          $ref: 'TS29510_Nnrf_AccessToken.yaml#/components/schemas/AccessTokenReq'
        nrfId:
          $ref: '#/components/schemas/Fqdn'

Basically, there are a lot of fields that wouldn't be relevant in the context of a simple error response because it is intended to be used to convey errors in reponse to RESTful service operations, which is different from the use case we are trying to satisfy here.

On the other hand, all the properties of the data type are optional, so this isn't such a worry. We could profile it down for use in this context.

[rjb1000]

OK. I propose adding a new mandatory property in Rel-17 below state called stateReason of type ProblemDetails with the following profiling in its definition:

Additional details about the current state of this Policy Template exposed to the 5GMS Application Provider by the 5GMS AF.

The instance property shall be present and shall indicate the URL of this Policy Template resource.

The title property shall be present and shall indicate a human-readable representation of the state property specified above, e.g. "Policy Template ready for use" or "Policy Template invalid".

The detail property shall be present except in the case of READY state and shall indicate a human-readable error message.

All other properties shall be omitted.

[rjb1000]

CR contributed to SA4#124 (Berlin):

• TS 26.512 CR0033r3 "[5GMS3] Rel-17 corrections" in S4-230771

[rjb1000]

CRs agreed during SA4#124 (Berlin):

• TS 26.512 CR0033r5 "[5GMS3, TEI17] Rel-17 corrections" in S4-230968
• TS 26.512 CR0035 "[5GMS3] Rel-16 corrections" in S4-230976

[rjb1000]

CRs agreed during SA4#124 (Berlin):

• TS 26.512 CR0033r5 "[5GMS3, TEI17] Rel-17 corrections" in S4-230968
• TS 26.512 CR0035 "[5GMS3] Rel-16 corrections" in S4-230976

[rjb1000]

CR Pack SP-230546 including TS 26.512 CR0033r5 (Rel-17) and CR0035 (Rel-16) approved at SA#100 (Taipei).

[rjb1000]

📣 3GPP TS 26.512 V16.10.0 and V17.5.0 are now published:

• https://www.3gpp.org/ftp/Specs/archive/26_series/26.512/26512-ga0.zip
• https://www.3gpp.org/ftp/Specs/archive/26_series/26.512/26512-h50.zip

[rjb1000]

Updated APIs now published:

• https://forge.3gpp.org/rep/all/5G_APIs/-/tree/TSG100-Rel16
• https://forge.3gpp.org/rep/all/5G_APIs/-/tree/TSG100-Rel17