5 Services offered by the MB-SMF

29.5323GPP5G Multicast-Broadcast Session Management Services5G SystemRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

Table 5.1-1 summarizes the SBI services produced by an MB-SMF.

Table 5.1-1: NF Services provided by MB-SMF

Service Name

Description

Example Consumers

Nmbsmf_TMGI

This service enables to request the allocation or release of TMGI(s). Applicable to both Broadcast and Multicast services.

NEF, MBSF, AF

Nmbsmf_MBSSession

This service enables:

– to create, modify, activate, deactivate and release a multicast MBS session

– create, modify and release a broadcast MBS session

– request the start or termination of MBS data reception for a multicast MBS session

– query information (e.g. QoS information) about a multicast MBS session and subscribe and unsubscribe to notifications of events about the multicast MBS session context and notify corresponding events to the subscribed NFs

– subscribe and unsubscribe to notifications of events about status change of a broadcast or multicast MBS session and notify corresponding events to the subscribed NFs

NEF, MBSF, AF

SMF, AMF

SMF

NEF, MBSF, AF

Table 5.1-2 summarizes the corresponding MB-SMF APIs defined in this specification (see Annex A).

Table 5.1-2: MB-SMF API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Nmbsmf_TMGI	5.2	MB-SMF TMGI Service	TS29532_ Nmbsmf_TMGI.yaml	nmbsmf_tmgi	A.2
Nmbsmf_MBSSession	5.3	MB-SMF MBSSession Service	TS29532_ Nmbsmf_MBSSession.yaml	nmbsmf_mbssession	A.3

5.2 Nmbsmf_TMGI Service

5.2.1 Service Description

The Nmbsmf_TMGI service operates on TMGI resources. It is applicable to both Broadcast and Multicast services. The service operations exposed by this service allow other NFs to request the allocation and release of TMGIs. The following are the key functionalities of this NF service, as specified in clause 9.1.2 of 3GPP TS23.247 [14]:

– Requesting the allocation of one or more TMGI values, or requesting to refresh the expiration time of the previous allocated TMGI(s);

– Requesting the deallocation of one or more TMGI values.

Table 5.2.1-1 lists the service operations that are supported by the Nmbsmf_TMGI service.

Table 5.2.1-1: Service operations supported by the Nmbsmf_TMGI service

Service Operations

Description

Operation

Semantics

Example Consumers

Allocate

Request the allocation of one or more TMGI values, or refresh the expiration time of the previously allocated TMGI(s).

Request / Response

NEF, MBSF, AF

Deallocate

Request the deallocation of one or more TMGI values.

Request / Response

NEF, MBSF, AF

5.2.2 Service Operations

5.2.2.1 Introduction

See Table 5.2.1-1 for an overview of the service operations supported by the Nmbsmf_TMGI service.

5.2.2.2 TMGI Allocate service operation

5.2.2.2.1 General

The TMGI Allocate service operation (Nmbsmf_TMGI_Allocate) shall be used by NF Service Consumers to request the allocation of TMGI(s). The TMGI Allocate service operation shall also be used to refresh the expiration time of the previously allocated TMGI(s).

It is used in the following procedures:

– MBS Session Creation with and without PCC (see clauses 7.1.1.2 and 7.1.1.3 in 3GPP TS 23.247 [14]).

The NF Service Consumer (e.g. NEF, MBSF and AF) shall trigger the allocation of one or more TMGIs by using the HTTP POST method on the TMGI collection resource (/tmgi), as shown in Figure 5.2.2.2.1-1.

Figure 5.2.2.2.1-1: TMGI allocation and TMGI refresh operations

1. The NF Service Consumer shall send a POST request to the resource representing the TMGI collection resource (/tmgi) of the MB-SMF. The payload body (TmgiAllocate data structure) of the POST request shall contain:

– the number of TMGIs to be allocated, if TMGI allocation is requested;

– one or more TMGIs, if the expiration time of the previously allocated TMGI(s) needs to be refreshed.

2a. On success, the MB-SMF shall return a 200 OK response with a payload body (TmgiAllocated data structure), which contains the allocated TMGI(s) and their expiration time, i.e. one expiration time for all TMGIs.

2b. On failure, or redirection, one of the HTTP status codes listed in Table 6.1.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails data structure with ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3.

5.2.2.3 TMGI Deallocate service operation

5.2.2.3.1 General

The TMGI Deallocate service operation (Nmbsmf_TMGI_Deallocate) shall be used by NF Service Consumers to request the deallocation of one or more TMGI(s).

It is used in the following procedures:

– MBS Session Deletion with and without PCC (see clauses 7.1.1.4 and 7.1.1.5 in 3GPP TS 23.247 [14]);

– MBS Session Release for Broadcast (see clause 7.3.2 in 3GPP TS 23.247 [14]).

The NF Service Consumer (e.g. NEF, MBSF and AF) shall trigger the deallocation of one or more TMGIs by using the HTTP DELETE method on the TMGI collection resource (/tmgi), as shown in Figure 5.2.2.3.1-1.

Figure 5.2.2.3.1-1: TMGI deallocation

1. The NF Service Consumer shall send a DELETE request to the resource representing the TMGIs collection. Query parameters shall be used to indicate the TMGI(s) to be deallocated. The NF Service Consumer may request to deallocate all previously allocated TMGIs, or one or more specific TMGIs previously allocated.

2a. On success, "204 No Content" shall be returned with empty message body.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.1.3.2.3.2-3.

5.3 Nmbsmf_MBSSession Service

5.3.1 Service Description

The Nmbsmf_MBSSession service operates on MBS Sessions. It is applicable to both Broadcast and Multicast services. The service operations exposed by this service allow other NFs to create, update and release MBS sessions. The following are the key functionalities of this NF service, as specified in clause 9.1.3 of 3GPP TS23.247 [14]:

– Creation, modification and release of MBS contexts for MBS Sessions;

– Requesting the start or termination of MBS data reception for a multicast MBS session;

– Subscribing to or unsubscribing from notifications of status change of multicast MBS session context;

– Subscribing to or unsubscribing from notifications of status change of a broadcast or multicast MBS session.

Table 5.3.1-1 lists the service operations that are supported by Nmbsmf_MBSSession service.

Table 5.3.1-1: Service operations supported by the Nmbsmf_MBSSession service

Service Operations	Description	Operation Semantics	Example Consumers
Create	Create a multicast or broadcast MBS session	Request / Response	NEF, MBSF, AF
Update	Update a multicast or broadcast MBS session	Request / Response	NEF, MBSF, AF
Delete	Delete a multicast or broadcast MBS session	Request / Response	NEF, MBSF, AF
ContextUpdate	Request the start or termination of MBS data reception for a multicast MBS session	Request / Response	AMF, SMF
ContextStatusSubscribe	Request information (e.g. QoS information) about a multicast MBS session and subscribe to notification of events about the multicast MBS session context	Subscribe/ Notify	SMF
ContextStatusUnsubscribe	Unsubscribe to notification of events about the multicast MBS session context		SMF
ContextStatusNotify	Notify events about the multicast MBS session context		SMF
StatusSubscribe	Subscribe to notifications of status change of a broadcast or multicast MBS session	Subscribe/ Notify	NEF, MBSF, AF
StatusUnsubscribe	Unsubscribe to notifications of status change of a broadcast or multicast MBS session		NEF, MBSF, AF
StatusNotify	Notify status changes of a multicast or broadcast or multicast MBS session		NEF, MBSF, AF

5.3.2 Service Operations

5.3.2.1 Introduction

See Table 5.3.1-1 for an overview of the service operations supported by the Nmbsmf_MBSSession service.

5.3.2.2 Create

5.3.2.2.1 General

The Create service operation shall be used to create a multicast or a broadcast MBS session, or for a location dependent MBS session, the part of an MBS Session within an MBS service area.

NOTE: For a location dependent MBS service, the Create service operation is performed per MBS service area of the MBS session.

It is used in the following procedures:

– MBS Session Creation with or without PCC (see clauses 7.1.1.2 and 7.1.1.3 of 3GPP TS 23.247 [14]); and

– MBS Session Start for Broadcast (see clause 7.3.1 of 3GPP TS 23.247 [14]).

For a location dependent MBS service, TMGI shall be used to identify the MBS Session within 5GS. Different MBS Service Areas shall use different SSM (source specific IP multicast) addresses if multicast transport is used over N6mb.

The NF Service Consumer (e.g. NEF, MBSF or AF) shall create an MBS session, or for a location dependent MBS session, the part of an MBS Session within an MBS service area, by using the HTTP POST method as shown in Figure 5.3.2.2.1-1.

Figure 5.3.2.2.1-1: MBS session creation

1. The NF Service Consumer shall send a POST request (CreateReqData structure) targeting the MBS Sessions collection resource of the MB-SMF. The payload body of the POST request shall contain the following information:

– MBS Session ID (source specific IP multicast address or TMGI) and/or TMGI allocation request indication;

– MBS service type (either multicast or broadcast service);

– the locationDependent IE set to true, for a location dependent MBS service;

– MBS Service Area, for a location dependent MBS service or for a Local MBS service.

The payload body of the POST request may further contain the following parameters:

– for a multicast or a broadcast MBS session:

– ingress transport address request indication, if the allocation of an ingress transport address is requested;

– DNN;

– S-NSSAI;

– MBS start time;

– MBS termination time;

– MBS service information;

– an MBS session status subscription request, including the list of MBS session events requested to be subscribed, a Notify Correlation ID, the Notification URI where to receive MBS session status notifications and the NF instance ID of the subscribing NF, for subscribing to notifications of events about the MBS session.

– for a multicast MBS session:

– session activity status (active/inactive);

– indication that any UE may join the MBS session, for a multicast MBS session;

– if security protection is applied, the multicast session security context containing MBS Service Key (MSK), MBS Traffic Key (MTK) and the corresponding key IDs.

– for a broadcast MBS session:

– list of MBS FSA IDs.

2a. On success, the MB-SMF shall reserve ingress resources for the MBS session and shall return a "201 Created" response. The "Location" header shall be present and shall contain the URI of the created resource. The payload body of the POST response (CreateRspData structure) shall contain a representation of the created MBS session, including the following parameters:

– the TMGI allocated to the MBS session and its expiration time, if the request included a TMGI allocation request;

– the Area Session ID allocated by the MB-SMF for the MBS session and MBS service area, for a location-dependent MBS session;

– MB-UPF tunnel information used between MB-UPF and MBSTF over Nmb9, or between MB-UPF and AF/AS if unicast transport is used over N6mb;

– list of MBS FSA IDs, if any, for a broadcast MBS session; and

– a representation of the created MBS session status subscription, including the list of MBS session events successfully subscribed, the URI of the created subscription and the expiry time after which the subscription becomes invalid, if the Create request includes the subscription to events about the MBS session and the subscription was created successfully.

The POST response may also contain:

– a list of event reports, if corresponding information is available.

For a location dependent MBS service, the MB-SMF shall allocate a unique Area Session ID within the MBS session for the MBS Service Area.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.2.3.1-3.

5.3.2.3 Update

5.3.2.3.1 General

The Update service operation shall be used to update a multicast or a broadcast MBS session, or for a location dependent MBS session, the part of an MBS Session within an MBS service area.

NOTE: For a location dependent MBS service, the Update service operation is performed per MBS service area of the MBS session.

It is used in the following procedures:

– MBS Session Update with or without PCC (see clauses 7.1.1.6 and 7.1.1.7 of 3GPP TS 23.247 [14]); and

– MBS Session Update for Broadcast (see clause 7.3.3 of 3GPP TS 23.247 [14]).

The NF Service Consumer (e.g. NEF, MBSF or AF) shall update an MBS session by using the HTTP PATCH method with the URI of the individual MBS session as shown in Figure 5.3.2.3.1-1.

Figure 5.3.2.3.1-1: MBS session update

1. The NF Service Consumer shall send a PATCH request (PatchData) to update the MBS session. The following parameters may be modified:

– for a multicast or a broadcast MBS session:

– MBS Service Area and/or;

– MBS service information.

– for a multicast MBS session:

– session activity status (active/inactive) to activate or deactivate an MBS session; and/or

– if security protection is applied, the multicast session security context containing MBS Service Key (MSK), MBS Traffic Key (MTK) and the corresponding key IDs.

– for a broadcast MBS session:

– list of MBS FSA IDs.

If the "indication that the PCF has to be contacted" shall be conveyed in the update request as defined in 3GPP TS 23.247 [14], the NF service consumer shall include the corresponding "contactPcfInd" attribute within the set of requested modifications.

2a. On success, the MB-SMF shall return a "204 No Content" response.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.3.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.3.3.1-3.

5.3.2.4 Release

5.3.2.4.1 General

The Release service operation shall be used to delete a multicast or broadcast MBS session, or for a location dependent MBS session, the part of an MBS Session within an MBS service area.

NOTE: For a location dependent MBS service, the Release service operation is performed per MBS service area of the MBS session.

It is used in the following procedures:

– MBS Session Deletion with or without PCC (see clauses 7.1.1.4 and 7.1.1.5 of 3GPP TS 23.247 [14]); and

– MBS Session Release for Broadcast (see clause 7.3.2 of 3GPP TS 23.247 [14]).

The NF Service Consumer (e.g. NEF, MBSF or AF) shall release an MBS session by using the HTTP DELETE method with the URI of the individual MBS session as shown in Figure 5.3.2.4.1-1.

Figure 5.3.2.4.1-1: MBS session release

1. The NF Service Consumer shall send a DELETE request (mbsSessionRef) to release the MBS session.

2a. On success, the MB-SMF shall release ingress resource for the MBS session and return a "204 No Content" response.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.3.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.3.3.2-3.

5.3.2.5 ContextUpdate

5.3.2.5.1 General

The ContextUpdate service operation shall be used to start or terminate MBS data reception of a multicast MBS session, or for a location dependent multicast MBS session, for the part of an MBS session within an MBS service area.

NOTE: For a location dependent multicast MBS service, the ContextUpdate service operation is performed per MBS service area of the MBS session.

It is used in the following procedures:

– to start MBS data reception:

– Multicast session join and session establishment procedure (see clause 7.2.1.3 of 3GPP TS 23.247 [14])

– Establishment of shared delivery toward RAN node (see clause 7.2.1.4 of 3GPP TS 23.247 [14])

– Xn based handover from MBS supporting NG-RAN node (see clause 7.2.3.2 of 3GPP TS 23.247 [14])

– N2 based handover from MBS supporting NG-RAN node (see clause 7.2.3.3 of 3GPP TS 23.247 [14])

– MBS session activation procedure (see clause 7.2.5.2 of 3GPP TS 23.247 [14])

– to terminate MBS data reception:

– MBS session Leave (see clause 7.2.2.2 of 3GPP TS 23.247 [14])

– SMF removing joined UEs from MBS session (see clause 7.2.2.3 of 3GPP TS 23.247 [14])

– Release of shared delivery toward RAN node (see clause 7.2.2.4 of 3GPP TS 23.247 [14])

– MBS session deactivation procedure (see clause 7.2.5.3 of 3GPP TS 23.247 [14])

The NF Service Consumer (e.g. AMF or SMF) shall update the MBS session context to start or terminate the MBS data reception of an MBS session by using the HTTP POST method as shown in Figure 5.3.2.5.1-1.

Figure 5.3.2.5.1-1: Multicast MBS session Context Update

1. The NF Service Consumer shall send a POST request targeting the /mbs-sessions/contexts/update resource. The payload body of the POST request (ContextUpdateReqData structure) shall contain the following information:

– NF Instance ID of the NF Service Consumer;

– MBS Session ID;

– Area Session ID, for a location dependent MBS session;

– if the NF Service Consumer is the SMF:

– requested action (i.e. Start or terminate MBS data reception);

– the (UPF) DL GTP-U F-TEID, to be used for starting or terminating MBS data reception, if unicast transport is used over N19mb.

– if the NF Service Consumer is the AMF:

– RAN Node ID;

– N2 MBS Session Management Container (see MBS Distribution Setup Request Transfer IE and MBS Distribution Release Request Transfer IE specified in clauses 9.3.5.7 and 9.3.5.10 of 3GPP TS 38.413 [20]), if an N2 MBS Session Management Container has been received from the NG-RAN;

– a Leave Indication, if it is the last NG-RAN controlled by the AMF serving the multicast MBS session.

2a. On success, a "200 OK" response shall be returned, if additional information needs to be returned in the response. The payload body of the POST response (ContextUpdateRspData structure) may contain the following parameters:

– if the NF Service Consumer is the SMF and it was requested to start MBS data reception:

– the GTP-U Common TEID (C-TEID, see 3GPP TS 29.281 [17]) and the related IP multicast source address of the MB-UPF, for data reception over N19mb using multicast transport, if no DL GTP-U F-TEID was received in the request for unicast transport;

– if the NF Service Consumer is the AMF:

– N2 MBS Session Management Container (see MBS Distribution Setup Response Transfer IE or MBS Distribution Setup Unsuccessful Transfer IE specified in clauses 9.3.5.8 and 9.3.5.9 of 3GPP TS 38.413 [20], if an N2 MBS Session Management Container needs to be sent to the NG-RAN.

If the MB-SMF supports a deployment where NG-U termination can be shared by multiple NG-RAN nodes, the MB-SMF shall check the information (e.g. NG-RAN Node ID, NG-U DL F-TEID, etc.) carried in the N2 MBS Session Management Container in step 1, and accordingly determine whether to maintain the existing shared NG-U tunnel or request the MB-UPF to establish new shared NG-U tunnel or release the existing shared NG-U tunnel, as specified in clause 7.2.1.4 and clause 7.2.2.4 of 3GPP TS 23.247 [14].

If the Leave indication was received in the request, the MB-SMF shall remove the information of the AMF from the context of the multicast MBS session.

NOTE: The user plane from the MB-UPF to NG-RAN (for 5GC Shared MBS traffic delivery) and the user plane from MB-UPF to UPFs (5GC Individual MBS traffic delivery) may use multicast transport via a common GTP-U tunnel per MBS session or use unicast transport via separate GTP-U tunnels at NG-RAN or at UPF per MBS session.

2b. Otherwise, the MB-SMF shall return a "204 No Content" response if no additional information needs to be returned in the response

2c. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.2.4.2.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.2.4.2.2-2.

5.3.2.6 StatusSubscribe service operation

5.3.2.6.1 General

The StatusSubscribe service operation shall be used by an NF Service Consumer (e.g. NEF, MBSF or AF) to create or to update a subscription to the MB-SMF notifications related to the status of an MBS session or, for a location dependent MBS session, the part of an MBS session within an MBS service area.

NOTE: For a location dependent MBS service, one StatusSubscribe service operation is performed per MBS Service Area of the MBS session.

5.3.2.6.2 Subscription creation

When the StatusSubscribe service operation is used for creating a subscription, the NF Service Consumer (e.g. NEF, MBSF or AF) shall subscribe to MB-SMF service notifications by using the HTTP POST method as shown in Figure 5.3.2.6.2-1.

Figure 5.3.2.6.2-1: Subscribing to MB-SMF notifications

1. The NF Service Consumer shall send a POST request to the resource URI representing the "/subscriptions" collection resource in the MB-SMF (/mbs-sessions/subscriptions). The request body shall include the data indicating the type of notifications that the NF Service Consumer is interested in receiving. The payload body of the POST request (StatusSubscribeReqData data structure, see clause 6.2.6.2.7) shall contain:

– the MBS Session ID (source specific IP multicast address or TMGI);

– Area Session ID, for a location dependent MBS session;

– the list of MBS session events requested to be subscribed.

– the Notification URI, indicating the address where the MB-SMF shall send the MBS session status notifications; and

– the NF instance ID of the subscribing NF, if available.

The request body may also contain:

– an expiry time suggested by the NF Service Consumer, representing the time span during which the subscription is desired to be kept active; and

– a Notification Correlation ID indicating the correlation identity to be carried in event notifications generated by the subscription.

2a. On success, the MB-SMF shall return a "201 Created" response. The "Location" header shall be present and shall contain the URI of the created resource. The payload body of the POST response shall include a representation of the created subscription (StatusSubscribeRspData data structure, see clause 6.2.6.2.8), with the following parameters:

– MBS Session ID (source specific IP multicast address or TMGI);

– Area Session ID, for a location dependent MBS session;

– the list of MBS session events successfully subscribed; and

– the expiry time after which the subscription becomes invalid.

The POST response may also contain:

– a list of event reports, if corresponding information is available.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.4.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in the same Table 6.2.3.4.3.1-3).

5.3.2.6.3 Subscription update

When the StatusSubscribe service operation is used for updating a subscription, the NF Service Consumer (e.g. NEF, MBSF or AF) shall update its subscription to MB-SMF notifications by using the HTTP PATCH method as shown in Figure 5.3.2.6.3-1.

Figure 5.3.2.6.2-1: Updating a subscription to MB-SMF notifications

1. The NF Service Consumer shall send a PATCH request to update the individual subscription resource at the MB-SMF (/mbs-sessions/subscriptions/{subscriptionId}). The message body contains an array(PatchItem), where each PatchItem type indicates a requested change to the MbsSessionSubscriptiondata (see clause 5.2.4.3 in 3GPP TS 29.571 [18]). The following information may be requested to be modified with array(PatchItem) structure (see Table 6.2.3.5.3.1-2):

– Notification URI (callback URI), indicating the address where the MB-SMF shall send the notifications;

– Notification Correlation ID, indicating the correlation identity to be carried in event notifications generated by the subscription;

– New expiration time; and/or

– List of MBS Session events.

2a. On success, the MB-SMF shall return a "200 Ok" response with a representation of the modified subscription (MbsSessionSubscription data structure, see clause 5.2.4.3 in 3GPP TS 29.571 [18]).

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.5.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in the same Table 6.2.3.5.3.1-3.

5.3.2.7 StatusUnsubscribe

5.3.2.7.1 General

The StatusUnsubscribe service operation shall be used by an NF Service Consumer (e.g. NEF, MBSF or AF) to unsubscribe from the MB-SMF notifications related to the status of the MBS session, or for a location dependent MBS session, of the part of an MBS session within an MBS service area.

NOTE: For a location dependent multicast MBS service, the StatusUnsubscribe service operation is performed per MBS service area of the MBS session.

The NF Service Consumer (e.g. NEF, MBSF or AF) shall unsubscribe from MB-SMF service notifications by using the HTTP DELETE method as shown in Figure 5.3.2.7.1-1.

Figure 5.3.2.7.1-1: Unsubscribing from MB-SMF notifications

1. The NF Service Consumer shall send a DELETE request to the resource URI representing the individual subscription document resource in the MB-SMF (/subscriptions/{subscriptionID}).

2. On success, the MB-SMF shall return a "204 No Content" response.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.5.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in the same Table 6.2.3.5.3.2-3.

5.3.2.8 StatusNotify

5.3.2.8.1 General

The StatusNotify service operation shall be used by the MB-SMF to notify a subscribed NF Service Consumer (e.g. NEF, MBSF or AF) about the change in the status of the MBS session, or for a location dependent MBS session, of the part of an MBS session within an MBS service area.

NOTE: For a location dependent multicast MBS service, the StatusNotify service operation is performed per MBS service area of the MBS session.

The MB-SMF shall notify the NF Service Consumer (e.g. NEF, MBSF or AF) by using the HTTP POST method to the callback URI received earlier in the subscription as shown in Figure 5.3.2.8.1-1.

Figure 5.3.2.8.1-1: MB-SMF notifications

1. The MB-SMF shall send a POST request to the callback URI ({notifUri}) of the subscribed NF Service Consumer. The payload body of the POST request (StatusNotifyReqData data structure) shall contain:

– Notification Correlation ID, if this information is available in the MBS session status subscription;

– the list of MBS session events to be reported;

– When reporting a BROADCAST_DELIVERY_STATUS event:

– the new broadcast delivery status (e.g. the MBS session has been ACTIVATED or TERMINATED);

– When reporting a INGRESS_TUNNEL_ADD_CHANGE event:

– new ingress tunnel address used over the N6mb/Nmb9 reference point.

2a. On success, the MB-SMF shall return a "204 No Content" response.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.5.2.3.1-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in the same Table 6.2.5.2.3.1-2).

5.3.2.9 ContextStatusSubscribe

5.3.2.9.1 General

The ContextStatusSubscribe service operation enables to create and modify a subscription to notifications of events about a multicast MBS session context.

NOTE: For a location dependent MBS service, the ContextStatusSubscribe service operation is performed per MBS session.

5.3.2.9.2 Creation of a subscription

The ContextStatusSubscribe service operation shall be used to request information (e.g. QoS information) about a multicast MBS session and subscribe to notifications of events about the multicast MBS session context.

It is used in the following procedures:

– Multicast session join and session establishment procedure (see clause 7.2.1.3 of 3GPP TS 23.247 [14]).

The NF Service Consumer may subscribe to multiple events in a subscription. A subscription shall be specific to a multicast MBS session context.

The NF Service Consumer (e.g. SMF) shall request information (e.g. QoS information) about a multicast MBS session and create a subscription to notification of events about the multicast MBS session context by using the HTTP POST method with the URI of the Subscriptions collection for MBS contexts resource as shown in Figure 5.3.2.9.2-1.

Figure 5.3.2.9.2-1: Creation of a subscription for a multicast MBS session context

1. The NF Service Consumer shall send a POST request. The payload body of the POST request (ContextStatusSubscribeReqData structure) shall contain the description of the subscription requested to be created:

– NF Instance ID of the NF Service Consumer creating the subscription;

– MBS Session ID (i.e. TMGI or source specific multicast address) being the target of the subscription;

– Event ID(s) of the events to which the NF service consumer requests to subscribe; and

– Notification URI, indicating the address where to send the events notifications generated by the subscription;

The payload body of the POST request may further contain the following parameters:

– Notification Correlation ID, indicating the correlation identitity to be carried in event notifications generated by the subscription.

– For each subscribed event:

– Immediate Report Indication, to request to receive an immediate report in the response with the current event status;

– Reporting Mode, to indicate how event shall be reported (One-time Reporting or Continuous);

– Expiry time, indicating the time up to which the subscription is desired to be kept active and after which the subscribed events shall stop generating notifications.

In this release of the specification, the SMF shall subscribe to the "QOS_INFO", "STATUS_INFO", "SERVICE_AREA_INFO", "SESSION_RELEASE", "SECURITY_INFO" and "MULT_TRANS_ADD_CHANGE" events, with the Reporting Mode set to "Continuous event reporting".

2a. On success, the MB-SMF shall return a "201 Created" response, with an HTTP Location header providing the URI of the newly created resource.

The payload body of the POST response (ContextStatusSubscribeRspData structure) shall include a representation of the created subscription. If the NF Service Consumer has included more than one event in the subscription creation request and some of the events cannot be subscribed, the MB-SMF shall accept the request and indicate the successfully subscribed event(s) in the response.

If the NF Service Consumer has requested an Immediate Report, the MB-SMF shall include the current status of the events subscribed in the response, if available:

– list of MBS QoS flows to set up (in the qosFlowsAddModRequestList IE) for the multicast MBS session;

– multicast MBS session’s status (activated/deactivated);

– multicast MBS session service area for local multicast service; and

– if security protection is applied, the multicast session security context containing MBS Service Key (MSK), MBS Traffic Key (MTK) and the corresponding key IDs.

NOTE: No immediate report is generated for the MULT_TRANS_ADD_CHANGE event type.

If the NF Service Consumer has requested One-time Reporting and if the MB-SMF has included the current status of the events subscribed in the response, then the MB-SMF shall not do any subsequent event notification for the subscribed events.

The payload body of the POST response shall also contain the following parameters:

– the MBS Service Areas and their respective Area Session IDs, for a location dependent MBS session; or

– the MBS Service Area, for a local MBS session.

The payload body of the POST response may also contain the following parameters:

– start time of the multicast MBS session;

– the GTP-U Common TEID (C-TEID, see 3GPP TS 29.281 [17]) and the related IP multicast source address of the MB-UPF, for data reception over N19mb using multicast transport, if IP multicast transport may apply over N19mb;

– MBS session authorization information (i.e. indication whether the multicast MBS session allows any UE to join);

– Expiry time after which the subscription becomes invalid, determined based on operator policies and taking into account the expiry time included in the request if any. If an expiry time was included in the request, then the expiry time returned in the response should be less than or equal to that value. The NF Service Consumer may update the subscription before the Expiry time to extend the subscription lifetime. Once the subscription expires, if the NF Service Consumer wants to keep receiving notifications, it shall create a new subscription in the MB-SMF. If the expiry time is not included in the response, the NF Service Consumer shall consider the subscription to be valid without an expiry time.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.6.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.6.3.1-3.

5.3.2.9.3 Modification of a Subscription

The ContextStatusSubscribe service operation shall be used to modify an existing subscription or extends the lifetime of an existing subscription to notifications of events about a multicast MBS session context.

The NF Service Consumer shall modify the subscription by using HTTP method PATCH with the URI of the individual subscription resource to be modified as shown in Figure 5.3.2.9.3-1.

Figure 5.3.2.9.3-1: Modification of a subscription for a multicast MBS session context

1. The NF Service Consumer shall send a PATCH request (PatchData) targeting the URI of the individual subscription resource to be modified. The payload body of the PATCH request shall contain the description of the modifications to apply to the subscription. The following information may be requested to be modified:

– NF Instance ID of the NF Service Consumer;

– Notification URI, indicating the address where to send the events notifications generated by the subscription;

– Event ID(s) of the events to which the NF service consumer requests to subscribe;

– Notification Correlation ID, indicating the correlation identity to be carried in event notifications generated by the subscription.

– Expiry time, indicating the time up to which the subscription is desired to be kept active and after which the subscribed events shall stop generating notifications.

NOTE: A subscription can be modified e.g. when it is taken over by another SMF in the same SMF set, or before the Expiry time expires.

2a. On success, the MB-SMF shall return a "200 OK" response, with the payload body (ContextStatusSubscription) containing a representation of the modified subscription.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.7.3.1-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.7.3.1-3.

5.3.2.10 ContextStatusUnSubscribe

5.3.2.10.1 General

The ContextStatusUnSubscribe service operation shall be used to unsubscribe to notifications of events about a multicast MBS session context.

NOTE: For a location dependent MBS service, the ContextStatusUnSubscribe service operation is performed per MBS session.

The NF Service Consumer (e.g. SMF) shall unsubscribe to notification of events about a multicast MBS session context by using the HTTP DELETE method as shown in Figure 5.3.2.10.1-1.

Figure 5.3.2.10.1-1: Deletion of a subscription for a multicast MBS session context

1. The NF Service Consumer shall send a DELETE request (subscriptionId) targeting the subscription resource to be deleted.

2a. On success, the MB-SMF shall return a "204 No Content" response.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.3.7.3.2-3 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.7.3.2-3.

5.3.2.11 ContextStatusNotify

5.3.2.11.1 General

The ContextStatusNotify service operation shall be invoked by the MB-SMF to send a notification about event(s), when events about the multicast MBS session context included in the subscription occur.

NOTE: For a location dependent MBS service, the ContextStatusNotify service operation is performed per MBS session.

It is used in the following procedures:

– Multicast session leave requested by the network or MBS session release (see clause 7.2.2.3 of 3GPP TS 23.247 [14]);

– MBS session activation procedure (see clause 7.2.5.2 of 3GPP TS 23.247 [14]);

– MBS session deactivation procedure (see clause 7.2.5.3 of 3GPP TS 23.247 [14]); and

– Multicast session update procedure (see clause 7.2.6 of 3GPP TS 23.247 [14]).

The MB-SMF shall notify event(s) about the multicast MBS session context by using the HTTP POST method targeting the notification URI received in the subscription as shown in Figure 5.3.2.11.1-1.

Figure 5.3.2.11.1-1: Notification of a multicast MBS session context event

1. The MB-SMF shall send a POST request targeting the notification URI. The notification, i.e. the payload body of the POST request (ContextStatusNotifyReqData structure) shall contain the following information:

– Notification Correlation ID, if available in the subscription;

– List of event(s) which occurred;

– When reporting a MULT_TRANS_ADD_CHANGE event:

– new multicast transport address (Low Layer SSM and C-TEID) used over the N19mb reference point;

– area session Id of the part of the location dependent MBS session for which the new multicast transport address is provided, for a location dependent MBS session;

– When reporting a QOS_INFO event:

– list of MBS QoS flows to add, modify and/or release (in the qosFlowsAddModRequestList IE and/or qosFlowsRelRequestList) for the multicast MBS session.

– When reporting a SECURITY_INFO event:

– if security protection is applied, the multicast session security context containing MBS Service Key (MSK), MBS Traffic Key (MTK) and the corresponding key IDs.

2a. On success, a "204 No Content" response shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.2.5.3.3.1-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.5.3.3.1-2.