7.7 Group message delivery using MBMS

7.7.1 Overview

The Group Management (GMG) CSF is responsible for handling group related requests. The requests are sent to manage a group and its membership as well as to perform fanout operations to group member resources. When the same content is sent to the members of a group that are located in a particular geographical area, 3GPP provides MBMS capabilities that may be used to efficiently distribute the message to the group members using multicasting.

7.7.2 Resource Structure

Refer to the clause 9.6.44 Resource Type <localMulticastGroup> of oneM2M TS-0001[1].

7.7.3 Procedures

7.7.3.1 Create MBMS Group

Figure 7.7.3.1-1: Service Flow of MBMS Group Creating

Pre-conditions:

1. The MBMS service area information provided by the MNO is configured in the oneM2M System;
2. External Group Identifiers for the devices have been pre-provisioned in the oneM2M System.

Step 1: The IN-AE sends a <group> create request to the Group Hosting CSE.

Step 2: The Group Hosting CSE checks if the multicastCapability attribute of the <remoteCSE> resource for more than two member Hosting CSEs are configured with a value of MBMS and have the same externalGroupID. If so, the Group Hosting CSE then creates the <group> as specified in clause 10.2.7.2 of oneM2M TS-0001[1] and the multicastType attribute of the Multicast Group Information is set to 3GPP_MBMS_group as specified in clause 10.2.7.13 of oneM2M TS-0001[1].

Step 3: The Group Hosting CSE sends the response to the IN-AE/CSE.

Step 4: The Group Hosting CSE sends the Allocate TMGI Request to the SCEF. The request shall contain the following information as specified in 3GPP TS 29.122 [4].

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-group-message-delivery-mb2 /v1/{scsAsId}/ tmgi-allocation. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a TMGIAllocation data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • externalGroupId shall be set to the externalGroupID of Member Hosting CSEs.
  • mbmsLocArea may be set to location information of Member Hosting CSEs per the accuracy policy.
  • supportedFeatures shall be set to a string value of "0" indicating no support for notifications over Websockets or notification test events.

General Exceptions:

The SCEF is not reachable when Hosting CSE (i.e. IN-CSE) tries to send Allocate TMGI Request request. In this case the IN-CSE will not be able to get an allocated TMGI from the underlying 3GPP network. Hence the IN-CSE will not be able to use multicast functionality for this group. The IN-CSE may service requests for the group using unicast functionality if applicable.

Step 5: The Allocate TMGI Request is processed by the underlying 3GPP network based on the procedure defined in 3GPP TS 23.682 [2].

Step 6: The SCEF sends the Allocate TMGI Response to the Group Hosting CSE. The response will contain the following information as specified in 3GPP TS 29.122 [4].

• A response code of 201 CREATED
• The URI of the Communication Patterns Configuration subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation/{tmgi}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {tmgi} segment is configured by the SCEF.
• The response payload will include a TMGIAllocation data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
  • self is configured with a link to the {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation/{tmgi} resource created by the SCEF for the request
  • tmgi is configured with the identity of a particular MBMS bearer service
  • tmgiExpiration is configured with absolute time at which the TMGI is considered to expire.

See clause 8.3 for a list of possible error scenarios and error handling options for the IN-CSE.

Step 7: The Group Hosting CSE stores the tmgi and tmgiExpiration in the local Multicast Group Information and sends <localMulticastGroup> creation requests to the Member Hosting CSEs via unicast which contain mandatory attributes specified in clause 9.6.44 of oneM2M TS-0001[1]. If the multicastType is 3GPP_MBMS_group, the request contains the tmgi and responseTimeWindow.

Steps 8 and 9: These steps are specified in clause 10.2.7.14 of oneM2M TS-0001 [1].

7.7.3.2 Group message delivery using MBMS

Figure 7.7.3.2-1: Service Flow of MBMS Group Message Delivery

Step 1: Before the tmgiExpiration of the multicast group, the Group Hosting CSE may send an Allocate TMGI Request to renew the expiration time for already allocated TMGIs. The request shall contain the following information as specified in 3GPP TS 29.122 [4].

• An HTTP PUT method shall be used
• URI shall be set to {apiRoot}/3gpp-group-message-delivery-mb2 /v1/{scsAsId}/tmgi-allocation/{tmgi}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {tmgi} segment is configured by the SCEF in the response to the initial TMGI Allocation request.
• The request payload shall include a TMGIAllocation data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • externalGroupId shall be set to the externalGroupID of Member Hosting CSEs.
  • mbmsLocArea may be set to location information of Member Hosting CSEs per the accuracy policy.
  • supportedFeatures shall be set to a string value of "0" indicating no support for notifications over Websockets or notification test events.

General Exceptions:

The SCEF is not reachable when Hosting CSE (i.e. IN-CSE) tries to send Allocate TMGI Request. In this case the IN-CSE will not be able to renew the TMGI with the underlying 3GPP network. Hence the IN-CSE will not be able to use multicast functionality for this group. The IN-CSE may service requests for the group using unicast functionality if applicable.

Step 2 and 3: The Allocate TMGI is processed by the underlying 3GPP network based on the procedure defined in 3GPP TS 23.682 [2].

Step 4: The SCEF sends the Allocate TMGI Response to the Group Hosting CSE. The response will contain the following information as specified in 3GPP TS 29.122 [4].

• A response code of 200 OK
• The response payload will include an updated TMGIAllocation data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
  • self is configured with a link to the {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation/{tmgi} resource created by the SCEF for the request
  • tmgi is configured with the identity of a particular MBMS bearer service
  • tmgiExpiration is configured with absolute time at which the TMGI is considered to expire.

The Group Hosting CSE shall replace the new tmgiExpiration in the Multicast Group Information locally.

Note, Step1-Step4 are optional (e.g. if the tmgiExpiration is not going to expire any time soon).

See clause 8.3 for a list of possible error scenarios and error handling options for the IN-CSE.

Step 5: The IN-AE/CSE sends a request carrying the group resource identifier for accessing member resources to the Group Hosting CSE.

Step 6: If the multicastType is 3GPP_MBMS_group, the Group Hosting CSE checks the existing <schedule> child resources for all the Member Hosting CSE <node> resources. If there is no time intersection of the existing <schedule>s, then the Group Hosting CSE returns an error response to the IN-AE/CSE after which the procedure is terminated. If there is a time intersection, the Group Hosting CSE shall check if the Operation Execution Time and Request Expiration Timestamp are in the scope of the intersection when Operation Execution Time or Request Expiration Timestamp is included in the request. If not, the Group Hosting CSE shall return an error to the IN-AE/CSE after which the procedure is terminated.

Note

3GPP supports the SCS/AS to set the Message Delivery Start Time for the UEs of a group which can impact the power saving mode of the UE, but oneM2M does not support it in release 3.

Then the group Hosting CSE shall send the Group Message Delivery Request to the SCEF to activate the MBMS bearer to provide MBMS communication network resources for MBMS members from the next start time of the time intersection. The request shall contain the following information as specified in 3GPP TS 29.122 [4].

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation/{tmgi}/delivery-via-mbms. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {tmgi} segment is configured by the SCEF in the response to the initial TMGI Allocation request.
• The request payload shall include a GMDViaMBMSByMb2 data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • externalGroupId shall be set to the same value as the externalGroupID of Member Hosting CSEs.
  • groupMessagePayload shall be set to the value specified in the request of access member resources from the IN-AE/CSE.
  • mbmsLocArea shall be set to location information of Member Hosting CSEs per the accuracy policy.
  • messageDeliveryStartTime shall be set to the next start time of the time intersection.
  • notificationDestination shall be configured with a URI that the SCEF can target Group Message Delivery notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • requestTestNotification and websockNotifConfig are not supported by the present document and shall not be included.

General Exceptions:

The SCEF is not reachable when Hosting CSE (i.e. IN-CSE) tries to send Group Message Delivery Request. In this case the IN-CSE will not be able to use multicast functionality to send the request to the group members. The IN-CSE may send the request to the group members using unicast functionality if applicable.

Step 7 and 8: The Activate MBMS Bearer Procedure is processed by the underlying 3GPP network based on the procedure defined in 3GPP TS 23.682 [2].

Step 9: The SCEF sends the Group Message Response to the Group Hosting CSE. The response shall contain the following information as specified in 3GPP TS 29.122 [4].

• A response code of 201 CREATED
• The URI of the Group Message Delivery resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation{tmgi}/delivery-via-mbms/{transactionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {tmgi} and {transactionId} segments are configured by the SCEF.
• The response payload will include an updated GMDViaMBMSByMb2 data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
  • self is configured with a link to the {apiRoot}/3gpp-group-message-delivery-mb2/v1/{scsAsId}/tmgi-allocation/{tmgi}/delivery-via-mbms/{transactionId} resource created by the SCEF for the request
  • acceptanceStatus indicating whether the activation of MBMS bearer corresponding to the TMGI was accepted or rejected
  • scefMessageDeliveryIPv4 indicates the Ipv4 address where the SCEF supports receiving group message payloads separate from the Group Message Delivery Request. In the present document, the IN-CSE includes the group message payload in the Group Message Delivery Request and hence the IN-CSE ignores this information in the response.
  • scefMessageDeliveryIPv6 indicates the Ipv6 address where the SCEF supports receiving group message payloads separate from the Group Message Delivery Request. In the present document, the IN-CSE includes the group message payload in the Group Message Delivery Request and hence the IN-CSE ignores this information in the response.
  • scefMessageDeliveryPort indicates the port number where the SCEF supports receiving group message payloads separate from the Group Message Delivery Request. In the present document, the IN-CSE includes the group message payload in the Group Message Delivery Request and hence the IN-CSE ignores this information in the response.

See clause 8.3 for a list of possible error scenarios and error handling options for the IN-CSE.

Step 10: The Group Message Delivery by MBMS Procedure is processed by the underlying 3GPP network based on the procedure defined in 3GPP TS 23.682 [2].

Step 11: The SCEF sends a Group Message Delivery Notification to the Group Hosting CSE.

The notification message contains the following information as specified in 3GPP TS 29.122 [4].

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Group Message Delivery Request.
• The request payload will include a GMDByMb2Notification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • transaction configured with a URI to the transaction resource for which this notification corresponds to
  • tmgi identifies the TMGI that this notification is applicable to
  • deliveryTriggerStatus indicates whether the delivery of the group message payload was successful or not and will have the value of TRUE or FALSE.

Step 12: After receiving a Group Message Delivery Notification, the Group Hosting CSE (i.e. IN-CSE) returns a response having a response code of 204 NO CONTENT.

Step 13: The Member Hosting CSE shall send the response message within the scope of responseTimeWindow. Details are specified in clause 10.2.7.13.2 of oneM2M TS-0001[1].

Step 14: The Group Hosting CSE shall receive the response messages from Member Hosting CSEs until responseTimeWindow expires and return the aggregated group member responses to the IN-AE/CSE.

General Exceptions:

If the SCEF sends a Group Message Delivery Notification to the Group Hosting CSE with a deliveryTriggStatus set to FALSE indicating that the delivery of the group message payload was not successful, then the Group Hosting CSE may choose to return a GROUP_MEMBERS_NOT_RESPONDED error response to the IN-AE/CSE before the responseTimeWindow expires.