Content for TS 23.247 Word version: 18.7.0
1…
4…
4.2…
4.3
5…
6…
6.6…
7…
7.1.1.2
7.1.1.3
7.1.1.4…
7.1.1.6…
7.1.2…
7.2…
7.2.2…
7.2.3…
7.2.4…
7.2.4.3…
7.2.5…
7.2.6…
7.3…
7.3.5…
7.5…
8…
9…
9.2…
9.3…
9.4…
A…
7.5 MBS procedures for Group Message Delivery
7.5.1 Group Message Delivery via MBS Broadcast
7.5.2 Modification of previously submitted Group message
7.5.3 Cancellation of previously submitted Group message
...
...
7.5 MBS procedures for Group Message Delivery |R18| p. 110
7.5.1 Group Message Delivery via MBS Broadcast p. 110
Step 1.
The AF sends Nnef_MBSGroupMsgDelivery_Create Request to the NEF. The Request message contains the Group Message Payload, MBS service area, Group Message Delivery Start Time, Stop Time and External Group Identifier, Target UE Classes (as defined in TS 26.502).
Step 2.
The NEF checks authorization of the AF. If geographical area information or civic address information was provided by the AF as MBS service area, the NEF translates the MBS service area to Cell ID list or TAI list. The NEF may further check the MBS capability within the MBS service area.
Step 3.
The NEF transforms the group message payload into a file, and determines the meta data information of the file (e.g. File URL, etc.). The NEF assigns a Group Message Correlation ID that identifies this group message delivery request.
If Application Service Provisioning specified in TS 26.502 has not been performed, step 4 to step 8 are executed. Otherwise, they can be skipped.
Step 4.
The NEF performs Application Service Provisioning by invoking Nmbsf_MBSUserService_Create and Nmbsf_MBSUserDataIngestSession_Create towards the MBSF using Object Distribution Method as specified in TS 26.502.
Step 5.
The MBSF performs MBS Session Creation as specified in clause 7.1.1.2 or clause 7.1.1.3.
Step 6.
The MBSF performs Distribution Session Provisioning as specified in TS 26.502. The MBSF invokes Nmbstf_MBSDistributionSession_Create on the MBSTF, passing the parameters of the MBS Distribution Session received in step 4 to the MBSTF.
Step 7.
The MB-SMF initiates the MBS Session Start for Broadcast procedure as specified in step 2 to step 9 in clause 7.3.1.
Step 8.
If the MBSF performs the service announcement, it initiates the MBS User Service Announcement as specified in TS 26.502. The application may receive the appropriate information through the MBS-6 API from the MBS Client (see TS 26.502). The NEF may receive the service announcement information via Nmbsf_MBSUserDataIngestSession_StatusNotify callback service operation (see TS 26.502).
Step 9.
The NEF sends Nnef_MBSGroupMsgDelivery_Create Response (Group Message Correlation ID, Acceptance Status, Cause) to the AF. The Acceptance Status indicates whether the group message delivery request is accepted or not. If not, the Cause is included indicating the appropriate failure reason. If the AF performs the service announcement, the NEF includes in the Group Message Response the service announcement information which contains information such as Session Description parameters (e.g. TMGI) and the object meta data as specified in TS 26.502. The NEF may further include the area where MBS is not supported within the MBS service area in the Nnef_MBSGroupMsgDelivery_Create response to the AF.
If the AF knows the UEs that are located in the area where MBS is not supported, AF may use unicast to send the group message to those UEs.
Step 10.
If the AF needs to perform the Service Announcement, the AF sends the application service announcement to the UE as specified in TS 26.502.
Step 11.
The NEF performs the User Data Ingestion towards the MBSTF as specified in TS 26.502. The NEF may push the file to the MBSTF or let MBSTF pull the file from the NEF.
Step 12.
The MBSTF performs packetization and optionally FEC encoding as specified in TS 26.502.
Step 13.
The MBSTF delivers the packets to the MB-UPF to NG-RAN, and NG-RAN broadcast to the UE as specified in step 13 to step 15 in clause 7.3.1.
Step 14.
Based on the service announcement information received in step 8 or step 10, when the UE receives the packets, the MBS client performs FEC decoding to restore the file and gets the group message from the file, as specified in TS 26.502. The MBS Client can expose the file towards the application in the UE using the MBS-7 API (see TS 26.502).
Step 15.
The MBSTF notifies the MBSF of User Data distribution status, and the MBSF then notifies the MBSF of the User Data ingestion status as specific in TS 26.502.
Step 16.
The NEF sends Nnef_MBSGroupMsgDelivery_StatusNotify to the AF, containing Group Message Correlation ID, Delivery Status. The Delivery Status indicates whether delivery of Group Message Payload is successful or not. The delivery status information is received by the NEF via Nmbsf_MBSUserDataIngestSession_StatusNotify service operation (see TS 26.502).
7.5.2 Modification of previously submitted Group message p. 112
Step 1.
For Group Message Payload update, steps 3 to 6 are executed:
The AF sends Nnef_MBSGroupMsgDelivery_Update Request to the NEF. The Request message contains the Group Message Correlation ID, Group Message Payload, MBS service area, Group Message Delivery Start Time, Stop Time and External Group Identifier, Target UE Classes (as defined in TS 26.502). The NEF identifies the associated MBS Service by the external Group Identifier. The Group Message Correlation ID indicates the transaction to be modified.
Step 2.
The NEF checks authorization of AF. If geographical area information or civic address information was provided by the AF as MBS service area, the NEF translates the MBS service area to Cell ID list or TAI list. The NEF may further check the MBS capability within the MBS service area.
Step 3.
For MBS service area update, step 7 and step 8 are executed:
The NEF transforms the group message payload into a file, and use the determined file meta data (e.g. File URL, etc.) in clause 7.5.1.
Step 4.
If the NEF pushes the updated file to the MBSTF, step 4 to step 5 can be skipped. If the MBSTF pulls the updated file from the NEF, the NEF updates MBS User Data Ingest Session on the MBSF as specified in TS 26.502. The update service operation needs to indicate an update of the file containing the updated group message.
Step 5.
The MBSF updates MBS Distribution Session on the MBSTF as specified in TS 26.502. The update service operation needs to indicate an update of the file containing the updated group message.
Step 6.
The NEF pushes the update file to the MBSTF or the MBSTF pulls the updated file from the NEF. And the MBSTF delivers the updated file towards the MB-UPF in 5GC as specified in clause 4.3.3.2 of TS 26.502.
Step 7.
If Requested Action is "Cancel", step 9 to step 14 are executed: step 9 to step 11 are needed when the group message delivery has started and MBSF needs to inform the MBS Client about the cancel of the file delivery. Otherwise, they can be skipped.
The NEF updates MBS User Service on the MBSF as specified in TS 26.502. The update service operation indicates MBS service area update.
Step 8.
The MBSF performs MBS Session Update as specified in clause 7.1.1.6 or clause 7.1.1.7 to update MBS service area, which triggers MBS Session Update for Broadcast as specified in clause 7.3.3.
Step 9.
After the modified group message is delivered, the NEF sends Nnef_
The NEF sends Nnef_MBSGroupMsgDelivery_Update Response (Acceptance Status, Cause) to the AF. The Acceptance Status indicates whether the group message update request is accepted or not. If not, the Cause is included indicating the appropriate failure reason. The NEF may further include the area where MBS is not supported in the Nnef_MBSGroupMsgDelivery_Update response to the AF.
7.5.3 Cancellation of previously submitted Group message p. 113
Step 1.
The AF sends Nnef_MBSGroupMsgDelivery_Delete Request (Group Message Correlation ID, External Group Identifier) to the NEF. The NEF identifies the associated MBS Service by the External Group Identifier. The Group Message Correlation ID indicates the transaction to be cancelled.
Step 2.
The NEF checks authorization of the AF.
Steps 3 to step 5 are executed if the group message delivery has started and MBSF needs to inform the MBS Client about the cancellation of the file delivery. Otherwise, they can be skipped.
Step 3.
The NEF updates MBS User Data Ingest Session on the MBSF as specified in TS 26.502 indicating the cancellation of the file delivery.
Step 4.
If the MBSTF pulled the file from the NEF previously, the MBSF updates MBS Distribution Session on the MBSTF as specified in TS 26.502 indicating cancellation of the file delivery and the MBSTF stops the file delivery.
Step 5.
If the NEF pushed the file previously to the MBSTF, the NEF may send HTTP DELETE to the MBSTF to cancel the file delivery. The MBSTF stops the file delivery.
Step 6.
The NEF destroys MBS User Data Ingest Session on the MBSF as specified in TS 26.502.
Step 7.
The MBSF destroys MBS Distribution Session on the MBSTF as specified in TS 26.502.
Step 8.
The MBSF performs MBS Session Deletion as specified in clause 7.1.1.4 or clause 7.1.1.5, which includes MBS Session Release for Broadcast as specified in clause 7.3.2.
Step 9.
The NEF sends Nnef_MBSGroupMsgDelivery_Delete Response (Acceptance Status, Cause) to the AF. The Acceptance Status indicates whether the Nnef_MBSGroupMsgDelivery_Delete Request is accepted or not. Cause is included when the Nnef_MBSGroupMsgDelivery_Delete Request is not accepted.
