Content for TS 24.542 Word version: 18.1.0

1… 6… A…

6.1 General 6.2 On-network procedures 6.3 Off-network procedures

6 Notification management procedures p. 9

6.2 On-network procedures p. 9

Upon receiving an HTTP request, the SNM-S shall authenticate the identity of the sender of the HTTP request as specified in TS 24.547, and if authentication is successful, the SNM-S shall use the identity of the sender of the HTTP request as an authenticated identity.

6.2.1.2 Boot up procedure p. 9

Upon device boot up, the SNM-C in the UE shall create the notification channel with the notification management server as specified in clause 6.2.2.1.

6.2.2 Notification channel creation procedure p. 9

6.2.2.1 SNM client procedures p. 9

Upon receiving a request from VAL service to receive notifications via the notification channel; the SNM-C may create a notification channel by sending an HTTP POST request to the SNM-S. In the HTTP POST request the SNM-C:

shall set the Request-URI to the URI of the SNM-S;
shall include the Host header with public user identity of the SNM-S;
shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in RFC 6750;
shall include a Content-Type header field set to "application/vnd.3gpp.seal-create-notification-channel-request";
shall generate the create notification channel request message as specified in clause A.1.2 and:
1. shall set the requestor identity to the notification management client identity;
2. shall set the channel type to PULL or PUSH based on the VAL Application requesting the use of notification channel;
3. may set the PUSH channel details parameter with the PUSH callback-URL if the channel type is PUSH;
4. shall set the validity duration of the notification channel;
5. may set the pull notification message trigger parameter to "true", if in case the SNM-C support application trigger to initiate pull notification message procedure; and
  
  NOTE:
  Application trigger enables the SNM-C to pull notification messages from the SNM-S only when the outstanding notifications are available at the SNM-S.
6. shall set the VAL id cluster list parameter with list of VAL identities corresponding to each VAL service requesting to receive notifications via the notification channel; and
include the parameters specified in clause A.1.2 serialized into a javascript object notation (JSON) structure as specified in RFC 8259.

Upon receiving an HTTP 200 (OK), the SNM-C shall notify the VAL services about the successful creation of notification channel and shall listen on the PUSH callback-URL for receiving the PUSH notification messages from the SNM-S.

6.2.2.2 SNM server procedures p. 10

Upon reception of an HTTP POST request from SNM-C where the Request-URI of the HTTP POST request contains the URI of the SNM-S, the SNM-S:

shall determine the requestor identity of the received HTTP POST request as specified in clause 6.2.1.1, and:
1. if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;
shall process the create notification channel request and if the channel type is:
1. PUSH, the SNM-S shall process:
  1. the PUSH channel details parameter as specified in clause A.1.2 to fetch the PUSH callback-URL of the SNM-C:
    1. if the PUSH callback-URL is not provided the SNM-S shall respond with an HTTP 406 (Not Acceptable) response to the HTTP POST request and skip rest of the steps; and
    2. the SNM-S shall store this PUSH callback-URL for future usages, when the notification messages are to be pushed to SNM-C; and
  2. the VAL id cluster list parameter, which is a list of VAL identities corresponding to each VAL services requesting to receive notifications messages via the notification channel; and
2. PULL, the SNM-S:
  1. may process the pull notification message trigger attribute if provided. If the SNM-S supports sending the application trigger to the SNM-C to initiate pulling notification message procedure, then the SNM-S may share this indication in the create notification channel response and store this for future usage to send triggers to the SNM-C for outstanding notification messages received from the VAL server; and
    
    NOTE 1:
    The SNM-S can utilize the application triggering services (or Device Triggering) provided by the 3GPP core network via the NEF or the SCEF.
  2. shall wait for the SNM-C to pull the notification messages; and
Editor's note:
In case of multiple notification accumulated at the SNM-S from same VAL Server towards the SNM-C. How the SNM-S decides to share all the notifications or latest notifications is FFS.
shall process the validity duration share by the SNM-C.

Upon successful creation of notification channel; the SNM-S:

shall create a notification channel response message with below attributes as specified in clause A.1.3 and;
1. shall generate unique channel identifier;
2. shall generate the callback URL, which shall be used by VAL clients in UE for sharing it to the VAL server as part of their respective services;
3. may generate the validity duration of the notification channel; and
4. may generate a notification URL that shall be used by the SNM-C to pull the notifications from the SNM-S in case of PULL channel type; and
shall include a Content-Type header field set to "application/vnd.3gpp.seal-create-notification-channel-response"; and
shall send an HTTP 200 (OK) response including message generated above.

6.2.3 Notification Message delivery p. 11

6.2.3.1 PUSH notification messages procedure p. 11

6.2.3.1.1 SNM client procedure p. 11

Upon receiving the HTTP POST request over a call back URI which was given to SNM-S at the time of notification channel creation, the SNM-C:

shall match identifier received in the channel identifier parameter of the HTTP POST request with the locally stored channel identifier. If channel identifier is not matching, then:
1. send an HTTP 406 (Not Acceptable) response to SNM-S and skip rest of the steps;
shall send an HTTP 200 (OK) response to SNM-S; and
shall process the VAL notification message list parameter received in HTTP request entity-body as specified in clause A.2.2 and deliver each received notification message to the appropriate VAL client on UE that matches the VAL id cluster info parameter received with each message.

6.2.3.1.2 SNM server procedure p. 11

To send the PUSH notification messages received from the VAL server to the SNM-C, the SNM-S:

shall check whether an PUSH notification channel exists with the SNM-C to receive the notification messages matching to the VAL identities (VAL UE or VAL user ID, VAL service ID, VAL application ID) shared by VAL server; if there is no channel created then skip rest of the steps;
shall generate an HTTP POST message to send notification messages received from the VAL server. In the HTTP POST message:
shall set request URI to the call back URI received at the time of creating channel;
shall set Content-Type header to "application/vnd.3gpp.seal-notification-payload/json";
shall generate the notification message payload as specified in clause A.2.2:
shall set the channel identifier associated with the SNM-C; and
shall generate the notification message list for the messaged received from VAL servers as specified in Table A.2.2-2; and
shall include an HTTP request entity-body with the parameters specified in clause A.2.2 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259; and
shall send the HTTP POST request towards SNM-C.

6.2.3.2 PULL notification messages procedure p. 11

6.2.3.2.1 SNM client procedure p. 11

To retrieve the latest notification messages available at the SNM-S as received from VAL servers, the SNM-C shall send an HTTP GET request to the SNM-S. In the HTTP GET request the SNM-C:

shall set the Request-URI with the "notification URL" received in create notification channel response message as specified in clause A.1.3;
shall include the Host header with public user identity of SNM-S;
shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in RFC 6750;
shall include a Content-Type header field set to "application/vnd.3gpp.seal-pull-notification-message-request/json";
shall generate the pull notifications request message as specified in clause A.2.3:
1. shall set the requestor identity to the notification management client identity; and
2. shall set the channel identifier to the identity of the corresponding notification channel with SNM-S from which the messages has to be pulled.
3. include the parameters specified in clause A.2.3 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259.

Upon receiving an HTTP 200 (OK), the SNM-C shall parse the notification messages received from SNM-S as specified in Table A.2.2-1 and notify the VAL services. The SNM-C shall immediately send HTTP GET towards the SNM-S to retrieve the next set of latest notification messages and await for response from SNM-S.

6.2.3.2.2 SNM server procedure p. 12

Upon reception of an HTTP GET request from SNM-C where the Request-URI of the HTTP POST request is set to the notification URL of the SNM-S, the SNM-S:

shall determine the requestor identity of the received HTTP GET request as specified in clause 6.2.1.1, and:
1. if the identity of the sender of the received HTTP GET request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP GET request and skip rest of the steps;
shall determine whether notification URL corresponding to the one issued by SNM-S as part of create notification channel response or not; and:
1. if notification URL is not valid, shall respond with an HTTP 404 (Not Found) response to the HTTP GET request and skip rest of the steps;
shall determine whether notification channel corresponding to the channel identifier and exists or not; and:
1. if notification channel does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP GET request and skip rest of the steps;
shall generate the pull notification message response to send notification messages received from the VAL servers:
1. shall include a Content-Type header field set to "application/vnd.3gpp.seal-notification-payload/json";
2. shall generate the notification message payload as specified in clause A.2.2:
  1. shall set the channel identifier associated with the SNM-C; and
  2. shall generate the notification message list for the messaged received from VAL servers as specified in Table A.2.2-2; and
3. shall include an HTTP entity-body with the parameters specified in clause A.2.2 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259; and
shall send an HTTP 200 (OK) response towards SNM-C.

6.2.4 Notification channel deletion procedures p. 13

6.2.4.1 SNM client procedures p. 13

Upon receiving a request from VAL service to stop receiving notifications via the notification channel; the SNM-C shall delete a notification channel by sending an HTTP DELETE request to the SNM-S. In the HTTP DELETE request the SNM-C:

shall set the Request-URI to the URI of the SNM-S;
shall include the Host header with public user identity of SNM-S;
shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in RFC 6750;
shall include a Content-Type header field set to "application/vnd.3gpp.seal-delete-notification-channel-request";
shall generate the delete notification channel request message as specified in clause A.3.2:
1. shall set the requestor identity to the notification management client identity; and
2. shall set the channel identifier to the identity of the corresponding notification channel with SNM-S to be deleted. If the other VAL services use the same notification channel in the UE, then SNM-C:
  1. may set the VAL identity cluster info parameter with VAL identities corresponding to the VAL service requesting to stop receiving notifications, which indicates SNM-C prefers to deregister the notification channel for these identities rather than deletion of the notification channel; and
include the parameters specified in clause A.3.2 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259.

6.2.4.2 SNM server procedures p. 13

Upon reception of an HTTP DELETE request from SNM-C where the Request-URI of the HTTP DELETE request contains the URI of the SNM-S, the SNM-S:

shall determine the requestor identity of the received HTTP DELETE request as specified in clause 6.2.1.1, and:
1. if the identity of the sender of the received HTTP DELETE request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP DELETE request and skip rest of the steps;
shall determine whether notification channel corresponding to the channel identifier exists or not; and:
1. if notification channel does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP DELETE request and skip rest of the steps;
shall delete the notification channel if the VAL identity cluster info parameter is not provided else proceed to only deregister the notification channel for these identities shared in VAL identity cluster info parameter corresponding to VAL service; and
shall send an HTTP 200 (OK) response to the SNM-C.

6.2.5 Notification channel update procedure p. 13

6.2.5.1 SNM client procedures p. 13

Upon detecting the expiry period of the active notification channel approaching; the SNM-C shall request for update of the notification channel expiry period by sending an HTTP PUT request to the SNM-S. In the HTTP PUT request the SNM-C:

shall set the Request-URI to the URI of the SNM-S;
shall include the Host header with public user identity of SNM-S;
shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in RFC 6750;
shall include a Content-Type header field set to "application/vnd.3gpp.seal-update-notification-channel-request";
shall generate the update notification channel request message as specified in clause A.4.2:
1. shall set the requestor identity to the notification management client identity;
2. shall set the channel identifier to the identity of the corresponding notification channel with SNM-S to be updated; and
3. may set the expiry time of the notification channel; and
include the parameters specified in clause A.4.2 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259.

Upon receiving an HTTP 200 (OK), the SNM-C shall store the expiry time received in the response for performing the future update procedure.

6.2.5.2 SNM server procedures p. 14

Upon reception of an HTTP PUT request from SNM-C where the Request-URI of the HTTP PUT request contains the URI of the SNM-S, the SNM-S:

shall determine the requestor identity of the received HTTP PUT request as specified in clause 6.2.1.1, and:
1. if the identity of the sender of the received HTTP PUT request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;
shall determine whether notification channel corresponding to the channel identifier exists or not; and:
1. if notification channel does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP PUT request and skip rest of the steps;
shall generate a notification channel update response message with below attributes as specified in clause A.4.3;
1. shall check whether the new proposed expiry time from SNM-C is valid or generate the new validity duration of the notification channel; and
include the parameters specified in clause A.4.3 serialized into a JavaScript Object Notation (JSON) structure as specified in RFC 8259;
shall include a Content-Type header field set to "application/vnd.3gpp.seal-update-notification-channel-response"; and
shall send an HTTP 200 (OK) response to the SNM-C.

6.3 Off-network procedures p. 14

The off-network procedures are out of scope of the present document in this release of the specification.