Content for  TS 29.122  Word version:  18.4.0

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 clause 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 clause 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 or 204 No Content if the required TMGI expiration time renewal is successful with no content in the HTTP PUT or PATCH response message body. 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 clause 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 clause 5.2.3 of TS 29.468, the SCEF shall delete the resource if not yet deleted.

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 clause 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.

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 clause 4.4.7.2.2. The SCEF shall create the resource "Individual TMGI Allocation" and perform the procedure as define in clause 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 clause 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 clause 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.

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 clause 4.4.7.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 clause 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 clause 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, or 204 No Content if the updates or replacement is successful with no content in the HTTP PATCH or HTTP PUT response message body. 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 clause 5.2.6.

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 clause 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.

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 clause 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 clause 5.2.6.

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 clause 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.

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 clause 4.4.5.2 of TS 29.116 and the Update Session procedure as defined in clause 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 clause 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.

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 clause 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 clause 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 clause 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 or with a 204 No Content success message if no content in the HTTP PUT or PATCH response message body. 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 clause 5.2.6.

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 clause 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.