Content for  TS 23.682  Word version:  19.0.0

If there is no assigned TMGI for an External Group Id, the SCS/AS sends the Allocate TMGI Request (External Group ID, SCS Identifier, (optional) location information, Accuracy) message to the SCEF. The SCS/AS may determine the IP address(es)/port(s) of the SCEF by performing a DNS query using the External Group Identifier or using a locally configured SCEF identifier/address. The location information restricts the distribution of the group message. It takes the format indicated in Accuracy parameter which can be either a list of cell IDs, or a list of MBMS Service Areas, or civic addresses, or a geographic area, or a combination of any of the above. Using the location information, the SCEF checks whether the SCS/AS is authorized to request TMGI allocation. If the expiration time for a previously allocated TMGI is to be extended, in addition to External Group ID, SCS Identifier and location/area information, the previously allocated TMGI is included in the Allocate TMGI Request message.

The SCEF determines whether the SCS/AS is authorized to request TMGI allocation.

The SCEF initiates TMGI allocation by the BM-SC (see TMGI Allocation Procedure specified in TS 23.468). In this procedure, if the TMGI is not included in step 1, the SCEF requests allocation of only one TMGI. If a TMGI is included in step 1, the SCEF requests to extend the TMGI expiration time for that TMGI. The SCEF stores TMGI and TMGI expiration received in this step.

The SCEF sends Allocate TMGI Response (Cause, TMGI, TMGI expiration) message to the SCS/AS. Cause value indicates success or failure of the requested procedure. In the case of failure, the reason for the failure condition is also included. The TMGI allocated by the BM-SC to which the SCS/AS is expected to send the group message, and TMGI expiration indicating the expiration time for the TMGI are also included. Steps 5 to 14 are skipped if the SCS/AS only wants to extend the expiration time of the TMGI (MB2 only).

Application level interactions may be applied for the UEs of specific group to retrieve the related MBMS service information, e.g. TMGI, start time, etc. in the case of MB2. Application level interactions between the UE and the SCS/AS are out of scope of this specification.

The SCS/AS sends the Group Message Request (External Group Identifier, SCS Identifier, TMGI (MB2 only), Message Delivery Stop Time (xMB only), optional (Group Message Payload, location information, Accuracy, Message Delivery Start Time) message to the SCEF. In the case of xMB, the SCEF creates a service using xMB for the group message and associates the external Group Identifier with the HTTP REST resource identifier of the service provided by the BM-SC upon service creation. The then SCEF forwards either only the ServiceID (see Table 5.4-1 in TS 26.348) to the SCS/AS or all service announcement. After the service is created, the SCS/AS triggers session creation towards the SCEF. The SCEF assigns a TLTRI that identifies this group message delivery request. The location information is included to identify the location over which group message is to be sent. It takes the format indicated in Accuracy parameter which can be either a list of cell IDs, or a list of MBMS Service Areas, or civic addresses, or a geographic area, or a combination of any of the above. The Message Delivery Start Time indicates the time at which the group message is to be sent by the network on the MBMS bearer(s). If not included, the group message is expected to be sent immediately. The Message Delivery Stop Time indicates the time at which the group message delivery is expected to be completed. When included, Group Message Payload indicates the payload the SCS/AS intends to deliver to UEs. Absence of Group Message Payload is indicative of the SCS/AS using delivery of group message in step 13a. In the case of xMB, if the application in the UE receives a ServiceId through application level interaction, the application can activate reception using MBMS APIs (see TS 26.347).

The SCEF checks that the SCS/AS is authorised to send a group message request. It also checks to see if Message Delivery Start Time doesn't start after the TMGI expiration (MB2 only). In the case of xMB, the SCEF ensures that the xMB session stop time is not before the Message Delivery Start Time. If either of the checks fail, then the SCEF executes step 11 with a cause value indicating the reason for the failure condition and the flow stops at this step. In this case, the SCS/AS may subsequently release the TMGI allocated at step 3 by requesting an explicit de-allocation, or may rely on the expiration timer.

If MB2 is used, the Activate MBMS Bearer Procedure (see clause 5.1.2.3.2 of TS 23.468) is executed with the following changes:

• In step 1 of this procedure, the SCEF, acting as GCS AS, may include location information from step 6. If no location information is provided in step 6 of this procedure, then the SCEF, based on local configuration, uses either a list of MBMS Service Area Identities, or a list of cell IDs, or both as the MBMS broadcast area.
• In step 2 of this procedure, the BM-SC may map the civic address(es) (if provided) and/or geographic area(s) (if provided) of location information into MBMS Service Area Identities subject to operator policies.

If xMB is used, the Create Session procedure (see clause 5.4.2 of TS 26.348), Get Session Properties (see clause 5.4.3 of TS 26.348) and the Update Session Procedure (see clause 5.4.4 of TS 26.348) is executed with the following changes and clarification:

• SCEF acts as a Content Provider.
• After completion of the Get Session Properties procedure, the Session Type value is set to "Files" by the SCEF irrespective of the received value for this parameter.
• In step 1 of Update Session procedure, the SCEF may include location information from step 6, session start and session stop. If no location information is provided in step 6 of this procedure, then the SCEF, based on local configuration, uses either a list of MBMS Service Area Identities, or a list of cell IDs, or both as the MBMS broadcast area. The SCEF shall derive the session start based on the Message Delivery Start Time if provided in step 6 and the session stop based on the Message Delivery Stop Time if provided in step 6. Session Resource ID as defined in TS 26.348 Create Session response sent by the BM-SC to SCEF uniquely identifies an MBMS session during which MBMS service data is sent. Given that an MBMS session can target a certain MBMS Service Area via a TMGI and an MBMS Service Area description, it can be mapped to a specific group (i.e., MBMS UEs belonging to that group and which have received MBMS service announcement information containing the TMGI of the MBMS bearer service associated with this MBMS session can activate reception for that session).
• In step 2 of Update Session procedure, the BM-SC may map the civic address(es) (if provided) and/or geographic area(s) (if provided) of location information into MBMS Service Area Identities subject to operator policies.

In the case of xMB, depending on the service created, the BM-SC may send the service announcement information to the UE as specified in TS 26.348. The service announcement information is referenced by the ServiceId which was provided by the BM-SC to the SCEF and then forwarded to the SCS/AS for service identification.

Void.

Void.

The SCEF sends a Group Message Response (TLTRI, TMGI (MB2 only), Acceptance Status, (optional) SCEF Message Delivery IP address/port) message to the SCS/AS to indicate whether the Request has been accepted for delivery to the group. The SCEF sends Acceptance Status of TMGI to indicate whether activation of MBMS bearer corresponding to the TMGI was accepted or rejected. If Group Message Payload was not included in step 6, then the SCEF also sends SCEF Message Delivery IP address and port number to the SCS/AS.

Application level interactions may be applied for the UEs of specific group to retrieve the related MBMS service information, e.g. TMGI, start time. Application level interactions between the UE and the SCS/AS are out of scope of this specification. When using xMB, the application may receive the appropriate information through MBMS APIs from the MBMS Client (see TS 26.347).

If Group Message Payload was included in step 6, then at Message Delivery Start Time, the SCEF delivers to BM-SC the Group Message Payload(s) to corresponding to the MB2-U or the xMB-U IP address and port number associated with respective TMGI. If Group Message Payload was not included in step 6, then at or after the requested Group Message Start Time, but before the TMGI Expiration time (if MB2 is used) or Message Delivery Stop Time (if xMB is used), the SCS/AS transfers the content to be delivered to the group to the SCEF using the SCEF Message Delivery IP address and port number received at step 11, and then the SCEF delivers the content to the BM-SC. The BM-SC transfers the corresponding content to UEs. The SCS/AS may repeat Step 13a unless the Message Delivery Stop Time is reached. To avoid that potential responses to the broadcast message by high numbers of UEs are sent at almost the same time, it is recommended that the SCS/AS provide the UEs with a response time window if it expects the UEs to respond to the delivered content.

Upon execution of 13a, the SCEF sends a Group Message Delivery (TLTRI, TMGI, Delivery Trigger Status) message to the SCS/AS to indicate whether group message delivery was triggered successful. TLTRI refers to the transaction identified by TLTRI in step 6. For the TMGI, the SCEF sends Delivery Trigger Status to indicate whether delivery of Group Message Payload corresponding to the TMGI was successful or not.

When a UE receives the Group Message Payload it may initiate immediate or later communication with the SCS/AS.

The pre-condition for this flow is the successful completion of step 11 from clause 5.5.1.

Application level interactions may be applied for the UEs of specific group to retrieve the related MBMS service information, e.g. TMGI, start time, etc. in the case of MB2 or ServiceId in the case of xMB. When the application receives a ServiceId through application level interaction, the application can activate reception using MBMS APIs (see TS 26.347). Application level interactions between the UE and the SCS/AS are out of scope of this specification.

The SCS/AS determines that modification of previously accepted Group Message Delivery Request is required. The SCS/AS sends the Modify Group Message Request (TLTRI, Requested Action, Message Delivery Start Time, Message Delivery Stop Time (xMB only), optional (External Group Identifier, SCS Identifier, TMGI (MB2 only), Group Message Payload, location information, Accuracy) message to the SCEF. In the case of xMB, the SCEF identifies the associated MBMS Service using the external Group Identifier. Requested Action is either set to "Modify", or "Cancel". "Modify" indicates the request is to modify the transaction identified by TLTRI. "Cancel" indicates the request is to cancel the transaction identified by TLTRI. When set to "Modify", then the remainder parameters, except Message Delivery Start Time, are optional, and included only if different to that of step 6 from clause 5.5.1. When set to "Cancel", no other parameters are included.

The SCEF uses TLTRI to locate the context of previously accepted Group Message Delivery Request executed in clause 5.5.1. If no associated transaction is found, or if a transaction if found but step 13a from clause 5.5.1 was completed, then step 4 is executed with appropriate Cause value, and the flow stops at this step. Otherwise, the flow proceeds.

If Requested Action was set to "Cancel", then if MB2 is used the mechanisms defined in clause 5.1.2.3.3 of TS 23.468 and if xMB is used the mechanisms defined in clause 5.4.5 of TS 26.348 are executed by the SCEF to release the associated MBMS resources. If Requested Action was set to "Modify", then if MB2 is used the mechanisms defined in clause 5.1.2.4 of TS 23.468 are used by the SCEF to modify the associated MBMS resources, whereas if xMB is used the mechanisms defined in clause 5.4.4 of TS 26.348 with the following changes:

• In step 1 of this procedure, the SCEF, acting as GCS AS (if MB2 is used) or Content provider (if xMB is used), may include location information from step 2. If no location information is provided in step 2 of this procedure, then the SCEF, based on local configuration, uses either a list of MBMS Service Area Identities, or a list of cell IDs, or both as the MBMS broadcast area.
• In step 2 of this procedure, the BM-SC may map the civic address(es) (if provided) and/or geographic area(s) (if provided) of location information into MBMS Service Area Identities subject to operator policies.

If Requested Action was set to "Cancel", then the SCEF sends a Modify Group Message Response (Cause) message to the SCS/AS with appropriate Cause value depending on whether the cancellation was accepted, and the flow stops at this step. If Requested Action was set to "Modify", then the SCEF sends a Modify Group Message Response (Cause, TMGI, Acceptance Status) message to the SCS/AS to indicate whether the requested modifications were accepted. The usage of parameters is similar to step 11 of clause 5.5.1.

Steps 12-14 of clause 5.5.1 are executed.

If SCS/AS has downlink non-IP data to send to a group of UEs, the SCS/AS sends a Group MT NIDD Submit Request (SCS/AS Identifier, External Group Identifier, TLTRI, non-IP data, Reliable Data Service Configuration, Maximum Latency, PDN Connection Establishment Option) message to the SCEF. The SCS/AS may determine the IP address(es)/port(s) of the SCEF by performing a DNS query using the External Group Identifier or using a locally configured SCEF identifier/address. When non-IP data is sent to an External Group Identifier, the Reliable Data Service Configuration shall indicate that no reliable data service acknowledgment is requested. The Maximum Latency Parameter provided by the SCS/AS in this procedure is only used by the SCEF to determine the maximum acceptable delay for associated non-IP data and is not propagated further by the SCEF.

Based on the preceding NIDD Configuration of the UE Group (see clause 5.13.2) and the SCEF stored list of authorized External Identifiers associated to the External Group Identifier, the SCEF sends a single Group MT NIDD Submit Response (Cause) message to the SCS/AS to acknowledge acceptance of the Group MT NIDD Submit Request. The Cause may indicate that the non-IP packet size is larger than the Maximum Packet Size determined in the preceding NIDD configuration of the UE Group.

The SCEF performs this step for each External Identifier that belongs to the External Group Identifier. The SCEF stored the list of authorized External Identifiers associated to the External Group Identifier during the preceding NIDD Configuration of the UE Group (see clause 5.13.2). The SCEF determines the EPS Bearer Context based on the NIDD Configuration TLTRI that is associated with the SCS/AS Identifier and the External Identifier. If an SCEF EPS bearer context corresponding to the External Identifier and SCS/AS Identifier is found, then the SCEF checks whether the SCS/AS is authorised to send NIDD requests and that the SCS/AS has not exceeded its rate control quota or rate of data submission to the SCEF EPS bearer. If this check fails, the SCEF does nothing in this step for this UE and the Cause value that is associated with this UE and provided to the SCS/AS in step 4 will indicate the reason for the failure condition for each failed UE. For each UE that passes these checks, the SCEF continues with the flow by executing steps 2-9 (except steps 2b and 5) of the Mobile Terminated NIDD Procedure of clause 5.13.3.

After executing step 3 for all UEs, the SCEF sends an aggregated response message Group MT NIDD Submit Indication (TLTRI associated with the Request of step 1, Hop-by-Hop Acknowledgment Indication(s), Re-Transmission time(s), Trigger Indication(s), Cause(s)). The Re-Transmission time(s) report, for UEs that have power saving function and did not receive the MT NIDD message, how long time it will take before they are reachable. Re-Transmission time(s) are not sent for UEs where transmission was successful. The SCEF does not buffer the non-IP data further (if applicable) and provides a Hop-by-Hop Acknowledgment Indication, and a Cause value for each UE in the response to the SCS/AS. See clause 5.13.3 for a description of the Hop-by-Hop Acknowledgment Indication and when it is included. The Trigger Indication(s) is used to indicate UE(s) for which a trigger was sent in order to establish a PDN connection.