Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.122  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4.4…   4.4.3…   4.4.5…   4.4.7   4.4.8…   4.4.12…   5…   5.6…   5.8…   5.10…   5.12…   6…

 

4.4.7  Procedures for Group Message DeliveryWord‑p. 37

4.4.7.1  General

This procedure is used by an SCS/AS to deliver a payload to a group of UEs. Two methods of Group Message Delivery via the T8 are specified:
  • Group Message Delivery via MBMS which is intended to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used. This method further includes two varieties:
    • the MB2 interface (see stage 2 in TS 23.468 and stage 3 in TS 29.468) is used as southbound interface;
    • the xMB interface (see stage 2 in TS 26.348 and stage 3 in TS 29.116) is used as southbound interface.
  • Group Message Delivery via unicast MT NIDD for UEs which are part of the same External Group Identifier.
Error handling for the procedures in the subsequent subclauses shall be handled based on subclause 5.2.6.
Up

4.4.7.2  Group Message Delivery via MBMS

4.4.7.2.1  General
This procedure is used by an SCS/AS to deliver a payload to a group of UEs via the T8 interface. The SCEF use the Group Message Delivery via MBMS to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used.
The procedure of Group message Delivery via MBMS and MB2 used as southbound interface is described in subcaluse 4.4.7.2.2 and the procedure of Group message Delivery via MBMS and xMB used as southbound interface is described in subcaluse 4.4.7.2.3.
Up
4.4.7.2.2  Group Message Delivery via MBMS by MB2
4.4.7.2.2.1  TMGI Allocation
If the SCS/AS acts as a GCS AS in the application level and if there is no assigned TMGI for an External Group Identifier, the SCS/AS shall send an HTTP message to the SCEF to the resource "TMGI Allocation". The body of the HTTP POST request message shall include the External Group Identifier. The SCS/AS may also include the location information in the body.
Upon receipt of the HTTP POST request from the SCS/AS to allocate a TMGI, the SCEF shall check whether the SCS/AS is authorized to request TMGI allocation. If authorization is successful, the SCEF shall initiate TMGI allocation by the BM-SC as defined in subclause 5.2.1 of TS 29.468. Upon successful allocation of a TMGI, the SCEF shall create the resource which represents the TMGI allocation, addressed by a URI that contains the SCS identity and TMGI, and shall respond to the SCS/AS with a 201 Created message including the TMGI and the TMGI expiration time.
In order to renew the TMGI expiration time, the SCS/AS shall send an HTTP PUT or PATCH message to the SCEF to the resource "Individual TMGI Allocation". Upon receipt of the HTTP PUT or PATCH request from the SCS/AS to renew TMGI expiration time, the SCEF shall initiate TMGI expiration time renewal to the BM-SC as defined in subclause 5.2.1 of TS 29.468. Upon successful result, the SCEF shall update the resource and respond to the SCS/AS by sending an HTTP response with 200 OK including the new TMGI expiration time.
If the SCEF receives the response with an error code from the BM-SC for the allocation of TMGI or renewal of expiration time for the existing TMGI, the SCEF shall not create or update the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
Upon the TMGI expiration, the SCEF may delete the resource of the TMGI locally.
Upon receipt of the notification of TMGI expiration by the BM-SC as defined in subclause 5.2.3 of TS 29.468, the SCEF shall delete the resource if not yet deleted.
Up
4.4.7.2.2.2  TMGI DeallocationWord‑p. 38
In order to deallocate the TMGI, the SCS/AS shall send an HTTP DELETE message to the SCEF to the resource "Individual TMGI Allocation". Upon receipt of the HTTP DELETE request from the SCS/AS to deallocate the TMGI, the SCEF shall initiate TMGI deallocation by the BM-SC as defined in subclause 5.2.2 of TS 29.468. Upon successful deallocation of a TMGI, the SCEF shall delete the resource "Individual TMGI Allocation" together with all sub-resouces "GMD via MBMS by MB2" if available,and shall respond to the SCS/AS by sending an HTTP response with 204 No Content.
Up
4.4.7.2.2.3  Creation of group message delivery
If the SCS/AS acts as a GCS AS in the application level and if the SCS/AS has an assigned TMGI for the External Group Identifier, in order to perform the group message delivery, the SCS/AS shall sends an HTTP POST request message to the SCEF to the resource "GMD via MBMS by MB2". The body of the HTTP POST request message shall include the External Group Identifier and notification destination URI identifying the recipient of notification within the "notificationDestination" attribute. The SCS/AS may also include the Group Message Payload, the location information and a Message Delivery Start Time in the body.
The SCS/AS may also send an HTTP POST message to the SCEF directly to the resource "TMGI Allocation" without previously requesting TMGI allocation as defined in subclause 4.4.7.2.2. The SCEF shall create the resource "Individual TMGI Allocation" and perform the procedure as define in subclause 4.4.7.2.2, and shall also create resource "GMD via MBMS by MB2" and perform the procedure as mentioned in this subcaluse for MBMS bearer creation.
Upon receipt of the HTTP POST request from the SCS/AS to deliver the group message, the SCEF shall check whether the SCS/AS is authorized to send a group message request. It also checks to see if the Message Delivery Start Time does not start after the TMGI expiration. If authorization is successful, the SCEF shall initiate the Active MBMS Bearer procedure as defined in subclause 5.3.2 of TS 29.468 with the difference that the SCEF acts as a GCS AS. The SCEF shall include the location information based on the local configuration if the location information is not provided in the HTTP POST request message.
Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by MB2", addressed by a URI that contains Transaction Id allocated by the SCEF and respond to the SCS/AS by sending an HTTP response with a 201 Created status code, including a Location header field containing the URI for the created resource. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this active MBMS bearer. If the Group Message Payload was not include in the HTTP POST above, the HTTP response sent from the SCEF shall also include the SCEF message delivery Ipv4 address or Ipv6 address and port number.
If the SCEF receives the response with an error code from the BM-SC for the activation of MBMS bearer, the SCEF shall not create the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in TS 29.468 at Message Delivery Start Time.
If the Group Message Payload was not include in the HTTP POST above, the SCEF shall transfer the contents received from the SCS/AS to the BM-CS at or after the requested Group Message Start Time, but before the TMGI Expiration time. In this case, when the SCEF detects the group message delivery was triggered successful, the SCEF shall send an HTTP POST request message to the SCS/AS.
Up
4.4.7.2.2.4  Modification of previous submitted group message deliveryWord‑p. 39
If the SCS/AS determines that modification of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP PATCH or HTTP PUT request message to the SCEF to the resource "Individual GMD via MBMS by MB2". The body of the HTTP PATCH request message shall include the Message Delivery Start Time. The SCS/AS may also include the External Group Identifier, the Group Message Payload and the location information in the body. The body of the HTTP PUT request message shall include the information as the information provided in the HTTP POST in subclause 4.4.7.2.2.2.3. The body of the HTTP PATCH request message shall include the information defined in the data type of GMDViaMBMSByMb2Patch as defined in subclause 5.8.2.1.1.6.
Upon receipt of the HTTP PATCH or HTTP PUT request from the SCS/AS to modify the previous group message delivery subscription, the SCEF shall check whether the SCS/AS is authenticated and authorized to modify the submitted group message delivery. If the authorization is successful, the SCEF shall initiate the Modify MBMS Bearer procedure as defined in subclause 5.3.4 of TS 29.468 with the difference that the SCEF acts as a GCS AS. The SCEF shall include the location information based on the local configuration if the location information is not provided in the HTTP PATCH or HTTP PUT request message.
Upon successful modification of MBMS bearer, the SCEF shall update the resource and respond to the SCS/AS with a 200 OK success message indicating that previous group message delivery subscription is successfully updated.
If the SCEF receives the response with an error code from the BM-SC for the modification of MBMS bearer, the SCEF shall not update the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
Up
4.4.7.2.2.5  Cancellation of previous submitted group message delivery
If the SCS/AS determines that deletion of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP DELETE request message to the SCEF.
Upon receipt of the HTTP DELETE request from the SCS/AS to delete the previous group message delivery, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete an existing group message delivery subscription. If the authorization is successful, the SCEF shall initiate the Delete MBMS Bearer procedure as defined in subclause 5.3.3 of TS 29.468 with the difference that the SCEF acts as a GCS AS.
Upon successful deletion of MBMS bearer, the SCEF shall respond to the SCS/AS with a 204 No Content message indicating that submitted group message delivery is successfully deleted.
Up
4.4.7.2.3  Group message Delivery via MBMS by xMB
4.4.7.2.3.1  Service Creation
If the SCS/AS acts as a content provider in the application level and if there is no assigned Service ID for an External Group Identifier, the SCS/AS shall send an HTTP POST message to the SCEF to the resource "xMB Services". The body of the HTTP POST request message shall include the External Group Identifier.
Upon receipt of the HTTP POST request from the SCS/AS to create a service, the SCEF shall check whether the SCS/AS is authorized to request service creation. If authorization is successful, the SCEF shall initiate service creation by the BM-SC as defined in subclause 5.2.1.2.2 of TS 29.116. Upon successful service creation, the SCEF shall create the resource which represents the service creation, addressed by a URI that contains the SCS identity and Service Id, and shall respond to the SCS/AS with a 201 Created message which may include the service announcement information.
If the SCEF receives the response with an error status code from the BM-SC for the service creation, the SCEF shall not create or update the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
Up
4.4.7.2.3.2  Service DeletionWord‑p. 40
In order to delete the service, the SCS/AS shall send an HTTP DELETE message to the SCEF to the resource "Individual xMB Service". Upon receipt of the HTTP DELETE request from the SCS/AS to delete the service, the SCEF shall initiate service deletion by the BM-SC as defined in subclause 5.2.1.2.4 of TS 29.116. Upon successful deletion of a service, the SCEF shall delete the resource "Individual xMB Service" together with all sub-resouces "GMD via MBMS by xMB" if available, and shall respond to the SCS/AS by sending an HTTP response with 204 No Content.
Up
4.4.7.2.3.3  Creation of group message delivery
If the SCS/AS acts as a content provider in the application level, the SCS/AS may sends an HTTP POST request message to the SCEF to the resource "GMD via MBMS by xMB". The body of the HTTP POST request message shall include the External Group Identifier and notification destination URI identifying the recipient of notification within the "notificationDestination" attribute. The SCS/AS may also include the Group Message Payload, the location information, a Message Delivery Start Time and Message Delivery Stop Time in the body.
Upon receipt of the HTTP POST request from the SCS/AS to deliver the group message, the SCEF shall check whether the SCS/AS is authorized to send a group message request. It also checks to see if the Message Delivery Start Time doesn't start after the Message Delivery Stop Time. If authorization is successful, the SCEF shall initiate the Create Session procedure as defined in subclause 4.4.5.2 of TS 29.116 and the Update Session procedure as defined in subclause 4.4.5.3 of TS 29.116 with the difference that the SCEF acts as a Content Provider, Session Start is set accordiong to the Message Delivery Start Time and the Session Stop is set according to the Message Delivery Stop Time. The SCEF shall include the location information based on the local configuration if the location information is not provided and include the session type set to "Files" in the HTTP POST request message.
Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by xMB ", addressed by a URI that contains Transaction Id allocated by the SCEF and respond to the SCS/AS by sending an HTTP response with a 201 Created status code, including a Location header field containing the URI for the created resource. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this active MBMS bearer. If the Group Message Payload was not included in the HTTP POST above, the HTTP response sent from the SCEF shall also include the SCEF message delivery Ipv4 address or Ipv6 address and port number.
If the SCEF receives the response with an error code from the BM-SC for the activation of MBMS bearer, the SCEF shall not create the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in TS 29.468 at Message Delivery Start Time.
If the Group Message Payload was not included in the HTTP POST above, the SCEF shall transfer the contents received from the SCS/AS to the BM-CS at or after the requested Message Delivery Start Time, but before the Message Delivery Stop Time. In this case, when the SCEF detects the group message delivery was triggered successful, the SCEF shall send an HTTP POST request message to the SCS/AS.
Up
4.4.7.2.3.4  Modification of previous submitted group message delivery
If the SCS/AS determines that modification of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP PATCH or HTTP PUT request message to the SCEF to the resource "Individual GMD via MBMS by xMB ". The body of the HTTP PATCH request message shall include the Message Delivery Start Time and Message Delivery Stop Time. The SCS/AS may also include the External Group Identifier, the Group Message Payload and the location information in the body. The body of the HTTP PUT request message shall include the information as the information provided in the HTTP POST in subclause 4.4.7.2.3.3. The body of the HTTP PATCH request message shall include the information defined in the data type of GMDViaMBMSByxMBPatch as defined in subclause 5.8.3.1.1.4.
Upon receipt of the HTTP PATCH or HTTP PUT request from the SCS/AS to modify the previous group message delivery subscription, the SCEF shall check whether the SCS/AS is authenticated and authorized to modify the submitted group message delivery. If the authorization is successful, the SCEF shall initiate the Update Session procedure as defined in subclause 4.4.5.3 of TS 29.116 with the difference that the SCEF acts as a Content Provider, Session Start is set accordiong to the Message Delivery Start Time and the Session Stop is set according to the Message Delivery Stop Time. The SCEF shall include the location information based on the local configuration if the location information is not provided in the HTTP PATCH or HTTP PUT request message.
Upon successful modification of MBMS bearer, the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that previous group message delivery subscription is successfully updated.
If the SCEF receives the response with an error code from the BM-SC for the modification of MBMS bearer, the SCEF shall not update the resource and shall respond to the SCS/AS with a corresponding failure code as described in subclause 5.2.6.
Up
4.4.7.2.3.5  Cancellation of previous submitted group message deliveryWord‑p. 41
If the SCS/AS determines that deletion of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP DELETE request message to the SCEF.
Upon receipt of the HTTP DELETE request from the SCS/AS to delete the previous group message delivery, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete an existing group message delivery subscription. If the authorization is successful, the SCEF shall initiate the Delete Session procedure as defined in subclause 4.4.5.4 of TS 29.116 with the difference that the SCEF acts as a Content Provider.
Upon successful deletion of MBMS bearer, the SCEF shall respond to the SCS/AS with a 204 No Content message indicating that submitted group message delivery is successfully deleted.
Up


Up   Top   ToC