TS 26.512 Policy Template state change events

[davidjwbbc]

Description

TS 26.512 (v17.4.0) Clause 4.3.7.1 discusses a Policy Template life cycle where the Policy Template starts in a "pending" state and asynchronously transitions between states during its lifetime.

In order for the Application Provider to know when a Policy Template has entered a different state it must poll the AF using the PolicyTemplatesProvisioning APIs on the interface at reference point M1. The polling period can be determined by the AF setting Cache-Control or Expires headers in its responses to API requests, but several requests may be made before the Policy Template transitions to a new state.

An event subscription/notification mechanism would cut down on unnecessary API communications and improve AP response times to Policy Template state changes.

Suggested solution

Introduce a state change event subscription and notification to the PolicyTemplateProvisioning APIs so that an AP can subscribe to state change event notifications for Policy Templates in its Provisioning Sessions.

[rjb1000]

Good idea to add a notification mechanism.

Because this is effectively an additional feature of the Policy Templates Provisioning API, it will need to be Rel-18.

[tlohmar]

Sounds like a good idea to introduce a notification mechanism. Yes, it would be a new feature. Questions:

• Does the notification delivered using webhook (callback) or a WebSocket or both (see TS 29.122)?
• Since this is a new feature, what about the feature negotiation mechanism, as defined in TS 29.500 Cl. 6.6.2?

[rjb1000]

Does the notification delivered using webhook (callback) or a WebSocket or both (see TS 29.122)?

This could open up a real can of worms. Other APIs offering northbound exposure (e.g. _NafEventExposure, _NmbsfMBSUserService, _NmbsfMBSUserDataIngestSession) tend to use a simple subscribe/publish message exchange pattern. Should _M1PolicyTemplates align with that? (I note that it's not exposed at all by the NEF yet, despite what TS 26.501 says.)

Since this is a new feature, what about the feature negotiation mechanism, as defined in TS 29.500 Cl. 6.6.2?

Need to look into this.

[tlohmar]

I think, Naf_EventExposure, Nmbsf_MBSUserService, Nmbsf_MBSUserDataIngestSession only support WebHooks, i.e. the API invoker registers an URL with a subscription procedure, which is used for sending a POST for publishing the event. Maybe good enought.

Yep. That's what I was thinking. Let's stay aligned with the service-based architecture as much as possible.

(The lack of NEF exposure for the M1 APIs remains a major concern for me. Not sure how to address this.)

[rjb1000]

@davidjwbbc: There is an opportunity to draft a pCR to TS 26.510 in the next meeting cycle (or possibly the one after that) in relation to this issue.