5 Functional Description and Information Flow

23.4683GPPGroup Communication System Enablers for LTE (GCSE_LTE)Release 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 MB2: Interface between GCS AS and BM-SC

5.1.1 General

MB2 offers access to the MBMS bearer service from a GCS AS. MB2 carries control plane signalling (MB2-C) and user plane (MB2-U) between GCS AS and BM-SC. MB2 has the following properties:

– MB2 is used by the GCS AS to interact with the BM-SC for MBMS bearer management.

– The GCS AS may use the MBMS service from multiple BM-SCs, each with a separate MB2 interface.

– The BM-SC shall provide service to multiple GCS ASs via a separate MB2 interface.

– Within one PLMN, an MBMS session is supported by exactly one BM-SC and provided for only one GCS AS.

– The data transferred via MBMS bearer(s) by the GCS AS is transparent to the BM-SC. A GCS AS may transfer data from one or multiple GCS groups via a single MBMS bearer.

– MB2 is a standardized secured interface to an AS.

– The GCS AS needs to be configured with the IP addresses or a FQDN of the contact points of MB2-C. The MB2-C contact points need to be configured per PLMN ID.

– The user plane transport information (e.g. IP address/UDP port) for delivering group communication data flow from the GCS AS to the BM-SC over MB2-U shall be exchanged over MB2-C.

NOTE 1: The GCS AS is not associated to any specific PLMN from an ownership standpoint.

NOTE 2: It is up to stage 3 to define the protocol stack and security requirements for MB2-C/U, and any additional parameters that may be needed by the MBMS procedure as defined in TS 23.246 [3].

5.1.2 MB2 Procedures

5.1.2.1 General

The MB2 interface provides the ability for the application to use the functionality of the MBMS system to deliver data to group members over MBMS. The procedures supported include:

– allocation of a set of TMGIs (TS 23.246 [3]) by the BM-SC at the request of the GCS AS, (see clause 5.1.2.2.2),

– deallocation of a set of TMGIs by the BM-SC at the request of the GCS AS, (see clause 5.1.2.2.3),

– activating an MBMS bearer, (see clause 5.1.2.3.2):

– this may include request related to BM-SC applying FEC or RoHC or both to a set of media.

– deactivating an active MBMS bearer, (see clause 5.1.2.3.3),

– modifying characteristics of an active MBMS bearer, (see clause 5.1.2.4), and

– reporting of MBMS delivery status from the BM-SC to the GCS AS, (see clause 5.1.2.5).

The MB2 interface between the GCS AS and the BM-SC is established before any MB2 messages are sent between these two entities, and carries all MB2 messages between the two entities for all MBMS bearers used by the GCS AS. The TMGI/FlowID (see TS 23.246 [3]) is the unique identifier used by the GCS AS and BM-SC to refer to the MBMS bearer.

5.1.2.2 TMGI Management

5.1.2.2.1 General

TMGIs are managed between the GCS AS and the BM-SC using the following explicit allocation and deallocation procedures upon request from the GCS AS.

TMGIs may also be allocated automatically by the BM-SC at bearer activation as described in clause 5.1.2.3.2.

Each TMGI is allocated by the BM-SC for a given period of time determined by the BM-SC. If the GCS AS wants to retain access to a TMGI for an extended period of time the GCS AS needs to request extension of the allocation period. The GCS AS may request an extension of the allocation period at any time prior to expiry of the time period. The actions consequent upon expiry of a TMGI allocation period are described in clause 5.1.2.2.4.

5.1.2.2.2 TMGI Allocation Procedure

The TMGI Allocation procedure is used by the GCS AS to request a set of TMGIs. This procedure may also be used to renew the expiration time for already allocated TMGIs.

Figure 5.1.2.2.1-1 provides the procedure used between the GCS AS and the BM-SC to allocate a set of TMGIs to the GCS AS.

Figure 5.1.2.2.1-1: TMGI Allocation Procedure

1. When the GCS AS wishes to have the BM-SC allocate one or more TMGIs to it, the GCS AS sends an Allocate TMGI Request message to the BM-SC, including the number of requested TMGIs. The GCS AS may include a list of TMGIs that are already allocated to the GCS AS, and for which the GCS AS wishes to obtain a later expiration time. The number of TMGIs requested may be zero, if this procedure is used only to renew the expiration time for already allocated TMGIs.

2. The BM-SC shall determine whether the GCS AS is authorized to receive the TMGIs and allocates a set of TMGIs. The BM-SC determines an expiration time for the TMGIs. If a list of TMGIs has been received in the Allocate TMGI Request message, the BM-SC also determines whether the TMGIs are allocated to the requesting GCS AS and if yes, whether the expiration time for those TMGIs can be set to the new expiration time.

3. The BM-SC shall send an Allocate TMGI Response message to the GCS AS indicating the list of allocated TMGIs, and an expiration time for those TMGIs.

5.1.2.2.3 TMGI Deallocation Procedure

The TMGI Deallocation procedure is used by the GCS AS to immediately release a set of TMGIs, irrespective of their expiration times.

Figure 5.1.2.2.2-1 provides the procedure used between the GCS AS and the BM-SC to deallocate TMGIs.

Figure 5.1.2.2.2-1: TMGI Deallocation Procedure

1. When the GCS AS decides that it no longer needs one or more TMGIs that are allocated to it, the GCS AS shall send a Deallocate TMGI Request message to the BM-SC with the list of TMGIs to be deallocated. Absence of the list of TMGIs implies that all TMGIs currently allocated by the BM-SC to the GCS AS are to be deallocated.

2. The BM-SC shall determine that the GCS AS is authorized to deallocate the indicated TMGIs, and shall then deallocate the TMGIs. If MBMS resources are in use for any of the deallocated TMGIs, those resources are released using the Session Stop procedure defined in TS 23.246 [3] and the BM-SC shall release any corresponding MB2 resources.

3. The BM-SC sends a Deallocate TMGI Response message to the GCS AS.

5.1.2.2.4 TMGI allocation period expiry

When the allocation period for a TMGI expires the TMGI and its associated Flow ID are no longer available for use by the GCS AS.

If, at the time of expiry, the TMGI is associated with a previously activated MBMS bearer (clause 5.1.2.3.2) the BM-SC shall autonomously take whatever actions are needed to stop broadcast of the MBMS bearer to the agreed MBMS service area, and shall release the MBMS resources used for the MBMS bearer using the Session Stop procedure defined in TS 23.246 [3]. The BM-SC shall send an MBMS Delivery Status Indication message to the GCS AS and shall release any corresponding MB2 resources.

At any time prior to expiry, the allocation period for a TMGI(s) may be extended as described in clause 5.1.2.2.2. A GCS AS wanting to ensure that it retains access to a TMGI should request extension of the allocation period at an adequate time before expiry, e.g. halfway through the allocation period.

5.1.2.3 Activating and Deactivating an MBMS bearer

5.1.2.3.1 General

Activating and deactivating an MBMS bearer involves the allocation/deallocation of MBMS resources, based on the MBMS bearer configuration provided by the GCS AS, using the following explicit activation and deactivation procedures upon request from the GCS AS.

MBMS bearer resources may also be deallocated autonomously by the BM-SC, upon expiry of the allocation period of the TMGI associated with the MBMS bearer, as described in clause 5.1.2.2.4.

5.1.2.3.2 Activate MBMS Bearer Procedure

The Activate MBMS Bearer procedure is used by the GCS AS to cause allocation of resources for an MBMS bearer. In addition, the GCS AS acting in the role of the Mission Critical service server as specified in TS 23.280 [12] can request the BM-SC to apply FEC and/or RoHC to a set of medias, transported by that MBMS bearer,

Figure 5.1.2.3.2-1 provides the procedure used between the GCS AS and the BM-SC to activate an MBMS bearer.

Figure 5.1.2.3.2-1: Activate MBMS Bearer Procedure

1. In order to activate an MBMS bearer over MB2, the GCS AS sends an Activate MBMS Bearer Request message to the BM-SC, including the TMGI which represents the MBMS bearer to be started, QoS, MBMS broadcast area, and start time. The TMGI is optional. The QoS shall be mapped into appropriate QoS parameters of the MBMS bearer. The MBMS broadcast area parameter shall include a list of MBMS Service Area Identities, or a list of cell IDs, or both.

NOTE 1: If the MBMS broadcast area parameter includes a list of MBMS Service Area Identities, the list of MBMS Service Area Identities is determined from information that may come from the UEs (e.g. list of cell IDs) or some other knowledge of where to establish the service (e.g. configuration).

The GCS AS may request that FEC is applied for media streams within the MBMS bearer by including for each media stream the following information elements: the SDP media descriptions (transport protocols, destination IP address and port), the identification of the FEC repair packet flow (destination IP address and port), an upper bound to the additional latency resulting to FEC application.

The GCS AS may request that RoHC is applied for IP flows within the MBMS bearer by including the following information elements: the RoHC configuration, the list of RTP and UDP flows to be header compressed, characterized by their destination IP addresses and port numbers. For each of these flows, the request may indicate a target periodicity for the full header packets.

2. If the TMGI was included, the BM-SC shall determine whether the GCS AS is authorized to use the TMGI. The BM-SC shall reject the request if the TMGI is not authorized. If the TMGI was not included in the request, the BM-SC shall assign an unused value for the TMGI. The BM-SC allocates a FlowID value corresponding to this TMGI and MBMS broadcast area. If the MBMS broadcast area parameter includes a list of cell IDs, the BM-SC may map the cell IDs into MBMS Service Area Identities subject to operator policy. The BM-SC shall then include a list of MBMS Service Area Identities and, if available, the list of cell IDs in the MBMS Session Start message. If another MBMS bearer with the same TMGI is already activated, the BM-SC shall accept the request only if the MBMS broadcast area in the new request is not partly or completely overlapping with any existing MBMS bearer(s) using the same TMGI as according to TS 23.246 [3] and shall allocate a unique FlowID for the newly requested MBMS bearer. The BM-SC shall allocate MBMS resources to support content delivery of the MBMS bearer to the requested MBMS broadcast area using the Session Start procedure defined in TS 23.246 [3]. If the GCS AS requested that FEC and/or RoHC are applied, the BM-SC shall allocate resources to apply FEC and/or RoHC as requested.

3. The BM-SC shall send an Activate MBMS Bearer Response message to the GCS AS, including the TMGI, the allocated FlowID, service description, BM-SC IP address and port number for the user-plane, and an expiration time. The service description contains MBMS bearer related configuration information as defined in TS 26.346 [7] (e.g. radio frequency and MBMS Service Area Identities). If the BM-SC mapped the cell IDs into the MBMS Service Area Identities in Step 2, then the service description shall contain the MBMS Service Area Identities that the BM-SC included in the MBMS Session Start message. The expiration time is included only if the BM-SC has allocated a TMGI as a result of this procedure.

4. The BM-SC receives an MBMS session response message from the MBMS‑GW and is notified that the MBMS bearer is activated in RAN. See TS 23.246 [3] clause 8.3.2.

5. The BM-SC may send a MBMS Delivery Status Indication message to the GCS AS, including the TMGI and optionally the allocated FlowID and radio resource allocation condition.

NOTE 2: The GCS AS can use the service description to provide information to the UE to access the MBMS bearer.

NOTE 3: Since the MBMS bearer is not necessarily established in all cells belonging to the MBMS SAIs in the Activate MBMS Bearer Response message, the list of MBMS SAIs provided by the BM-SC to the GCS AS does not guarantee that the MBMS bearer is available in all cells of the service area identified by the MBMS SAIs.

If the GCS AS requested that FEC is applied, the BM-SC shall include an indication of success or failure for each media stream where FEC was requested to be applied.

If the GCS AS requested that RoHC is applied, the BM-SC shall include an indication of success or failure for each IP flow where RoHC was requested to be applied.

5.1.2.3.3 Deactivate MBMS Bearer Procedure

The Deactivate MBMS Bearer procedure is used by the GCS AS to cause deallocation of resources for an MBMS bearer.

Figure 5.1.2.3.2-1: Deactivate MBMS Bearer Procedure

1. The MBMS bearer is being broadcast over the MBMS system.

2. When the GCS AS determines that the MBMS bearer is no longer needed, it shall send a Deactivate MBMS Bearer Request message to the BM-SC, including the TMGI and FlowID representing the MBMS bearer to be deactivated.

3. The BM-SC shall determine whether the GCS AS is authorized to use the TMGI and shall take whatever actions are needed to stop broadcast of the MBMS bearer to the agreed MBMS service area, and to deallocate MBMS resources used for the MBMS bearer using the Session Stop procedure defined in TS 23.246 [3].

4. The BM-SC shall send a Deactivate MBMS Bearer Response message to the application, including the TMGI, the FlowID, and a result.

5.1.2.4 Modify MBMS Bearer Procedure

The Modify MBMS Bearer procedure is used by the GCS AS to cause modification of the priority and preemption values for an MBMS bearer, the MBMS broadcast area, or both. In addition, the GCS AS acting in the role of the Mission Critical service server as specified in TS 23.280 [12] can request the BM-SC to apply FEC and/or RoHC to a set of medias, transported by that MBMS bearer.

Figure 5.1.2.4-1 provides a description of the procedure used between the GCS AS and the BM-SC to modify an activated MBMS bearer.

Figure 5.1.2.4-1: Modify MBMS Bearer Procedure

1. When the GCS AS determines that an activated MBMS bearer needs to be modified, it shall send a Modify MBMS Bearer Request message to the BM-SC, including the TMGI, FlowID, any new priority and preemption characteristics to be used, and the MBMS broadcast area. The priority and preemption characteristics and the MBMS broadcast area are optional parameters but one of them needs to be included in the Modify MBMS Bearer request. The MBMS broadcast area parameter shall include a list of MBMS Service Area Identities, or a list of cell IDs, or both.

The GCS AS may request that RoHC is applied for IP flows within the MBMS bearer by including the following information elements: The RoHC configuration, the list of RTP and UDP flows to be header compressed, characterized by their destination IP address and port numbers. For each of these flows, the request may indicate a target periodicity for the full header packets.

2. If the MBMS broadcast area is being modified, the BM-SC shall accept the request only if the new MBMS broadcast area is not partly or completely overlapping with the MBMS broadcast area of any other existing MBMS bearer(s) with the same TMGI, in accordance with TS 23.246 [3]. The BM-SC shall modify the characteristics of the MBMS bearer using the Session Update procedure defined in TS 23.246 [3]. If the MBMS broadcast area parameter is present and includes a list of cell IDs, the BM-SC may map the cell IDs into MBMS Service Area Identities subject to operator policy. The BM-SC shall then include a list of MBMS Service Area Identities and, if available, the list of cell IDs in the MBMS Session Update message.

3. The BM-SC shall send a Modify MBMS Bearer Response message to the GCS AS, including the TMGI, FlowID, and the result. If the BM-SC mapped the cell IDs into the MBMS Service Area Identities in Step 2, then the service description shall contain the MBMS Service Area Identities that the BM-SC included in the MBMS Session Update message.

NOTE 2: Since the MBMS bearer is not necessarily established in all cells belonging to the MBMS SAIs in the Modify MBMS Bearer Response message, the list of MBMS SAIs provided by the BM-SC to the GCS AS does not guarantee that the MBMS bearer is available in all cells of the service area identified by the MBMS SAIs.

4. The BM-SC receives an MBMS Session Update Response message from the MBMS‑GW and is notified that the MBMS bearer is modified in RAN. See TS 23.246 [3] clause 8.8.4.

5. The BM-SC may send a MBMS Delivery Status Indication message to the GCS AS, including the TMGI and optionally the allocated FlowID and radio resource allocation condition.

If the GCS AS requested that FEC is applied, the BM-SC shall include an indication of success or failure for each media stream where FEC was requested to be applied.

If the GCS AS requested that RoHC is applied, the BM-SC shall include an indication of success or failure for each IP flow where RoHC was requested to be applied.

5.1.2.5 MBMS Delivery Status Indication Procedure

The MB2 interface allows the BM-SC to notify the GCS AS of conditions affecting the delivery of services that use MBMS Delivery. The occurrence of the indicated condition may have been detected at the BM-SC or may have been reported to the BM-SC by other entities involved in the MBMS delivery.

The BM-SC sends the MBMS Delivery Status Indication message which includes an identification of the condition whose occurrence triggered the sending of the message and may include other information.

Figure 5.1.2.5-1 illustrates the MBMS Delivery Status Indication procedure.

Figure 5.1.2.5-1: MBMS Delivery Status Indication procedure

5.2 Specific Usage of EPS Bearers for GCS

Each UE participating in the Group Communication Service uses one or multiple EPS bearers for exchanging application signalling and data with the GCS AS. The EPS bearer services are specified in TS 23.401 [5] and TS 23.203 [6].

In order to enable GCS, a PDN connection needs to be established that can be used for GC1 signalling exchange. When the PDN connection gets established the PCC functionality determines a QCI and an ARP for the default bearer, which may be used for GC1 signalling . Alternatively, during PDN connection establishment a dedicated bearer may be established for GC1 signalling by configuring PCC rules accordingly.

A GCS UE may join multiple GCS groups, which are served by one or more EPS bearers. The GCS AS determines the service characteristics of a specific Group Communication Service, e.g. media or flow description and priority, which is used by the PCRF to determine the EPS bearer configuration appropriate for GCS. The GCS AS updates the PCRF with service characteristics to initiate any required update of the EPS bearer configuration, e.g. when the UE joins or leaves a GCS group or when a GCS data exchange starts or stops.

Whenever the UE’s bearer configuration needs to be updated, the GCS AS provides the updated or new service characteristics to the PCRF. From service characteristics PCRF determines the required bearer configuration, including QCI and ARP, and requests the PCEF amendment of the UE’s EPS bearers accordingly. If the priority of the application Group Communication session changes, the GCS AS provides an update of the service characteristics towards the PCRF via the Rx interface. The PCRF translates the service characteristics to PCC policies and forwards its policy decision to the PCEF. The PCEF determines, based on policies provided by the PCRF, whether the PCEF modifies already established bearers or whether the PCEF establishes dedicated bearer(s) with the determined bearer characteristics.

The PCRF is not aware of the GCS group(s).

To obtain the responsiveness desired for GCS the GCS UE shall signal the Idle Mode DRX value to the MME, using the procedures described in TS 23.401 [5]. The E-UTRAN derives from the QCI the configuration for delivering an equivalent responsiveness in Connected Mode. When performing the S1 interface paging procedure for a DownlinkData Notification for a bearer associated with either QCI 65 or QCI 69 (e.g. Mission Critical Push To Talk), the Paging Priority IE needs to be set to a value such that the E-UTRAN can correctly prioritize the contents of its radio interface paging messages to enable low latency for the first downlink packet on that bearer. To enable the MME to send this Paging Priority IE on the S1 interface, the bearer(s) associated with QCI 65 and QCI 69 should have appropriate ARP(s).

5.3 Service Continuity

5.3.1 General

This clause provides flows & procedures for switching from Unicast Delivery to MBMS Delivery and vice-versa. In the flows, the need for service continuity is determined and executed by the UE. In the make-before-break flows, the UE may simultaneously receive the same DL data on both Unicast and MBMS bearers. In such scenarios, it is up to the application to manage duplicate detection.

5.3.2 Switching from Unicast Delivery to MBMS Delivery

Figure 5.3.2-1 shows the procedures for service continuity when a UE which is receiving DL data over unicast moves into MBMS coverage. During the switching process, the UE simultaneously receives data from both unicast and MBMS, so there is no service interruption.

Figure 5.3.2-1: Switching from Unicast Delivery to MBMS Delivery

1. The UE has an on going group communication and the GCS AS informs the UE, over GC1, of the availability of MBMS delivery and of the corresponding TMGI of the MBMS bearer service.

2. The UE is receiving downlink data by Unicast Delivery.

3. The UE detects it has entered MBMS coverage and starts receiving MBMS Scheduling Information over MCH and the data from the MBMS bearer corresponding to the TMGI over MTCH.

4. The UE receives DL data by MBMS Delivery.

5. The UE simultaneously receives data by Unicast Delivery and MBMS Delivery.

6. The UE notifies the GCS AS via GC1 that it is in MBMS coverage and receiving the MBMS bearer service corresponding to the TMGI. The GCS AS stops sending the data over by Unicast Delivery to this UE. The UE now receives the content only by MBMS Delivery.

5.3.3 Switching from MBMS Delivery to Unicast Delivery

5.3.3.1 General

This clause defines the following two procedures for service continuity for switching from MBMS Delivery to Unicast Delivery:

– MBMS Delivery to Unicast Delivery (make-before-break).

– MBMS Delivery to Unicast Delivery (break-before-make).

5.3.3.2 MBMS Delivery to Unicast Delivery (make-before-break)

Figure 5.3.3.2-1 shows the procedure for service continuity when a UE is about to move out of MBMS coverage. In this procedure, the UE detects that is about to move out of MBMS coverage and elects to receive data over unicast while still within MBMS coverage. During the switching process, the UE simultaneously receives data from both unicast and MBMS, so there is no service interruption.

Figure 5.3.3.2-1: Switching from MBMS Delivery to Unicast Delivery (make-before-break)

1. The UE has an ongoing group communication.

2. The UE is receiving downlink data by MBMS Delivery.

3. The UE detects that it is about to move out from MBMS coverage, for the corresponding MBMS bearer service, through implementation-specific methods. For example, the UE can determine it is about to move out of MBMS coverage by detecting poor MBSFN signal quality.

4. The UE notifies the GCS AS that it may move out of MBMS coverage via GC1 and the GCS AS sets up a unicast flow.

5. The GCS AS now sends the downlink data by Unicast Delivery to this UE.

6. The UE simultaneously receives DL data by Unicast Delivery and by MBMS Delivery.

7. The UE ceases to receive the downlink data by MBMS Delivery but continues receiving data by Unicast Delivery.

8. The UE monitors the SIBs in order to detect the TMGI on MCCH and thus determine it is back in MBMS coverage for the MBMS bearer service.

5.3.3.3 MBMS Delivery to Unicast Delivery (break-before-make)

Figure 5.3.3.3-1 shows the procedure for service continuity when a UE has moved out of MBMS coverage. Here the UE starts receiving DL data over unicast after it has stopped receiving data over MBMS, so there may be some service interruption.

This procedure is used by the UE to handle loss of MBMS Delivery due to MBMS resource congestion in E-UTRAN resulting in pre-emption of the MBMS bearer service as described in clause 5.4.

Figure 5.3.3.3-1: Switching from MBMS Delivery to Unicast Delivery (break-before-make)

1. The UE has an ongoing group communication.

2. The UE is receiving downlink data by MBMS Delivery for an MBMS bearer service is identified by a TMGI.

3. The UE detects it is out of MBMS coverage for that TMGI and, therefore, is unable to receive any data by MBMS Delivery for the corresponding MBMS bearer service.

4. The UE notifies the GCS AS via GC1 that it has moved out of MBMS coverage for the MBMS bearer service corresponding to the TMGI and the GCS AS sets up a unicast flow.

5. The GCS AS sends the downlink data by Unicast Delivery.

6. The UE monitors the SIBs in order to detect the TMGI on MCCH and thus determine that it is back in MBMS coverage for the MBMS bearer service.

5.4 Priority and Pre-emption for Group Communication

A Group Communication Session that requires to be prioritized over other Group Communication Sessions or non-Group Communication Sessions includes both the priority level and the GCS identifier in a service authorization request to the PCRF and to the BM-SC.

The priority level and the GCS identifier are defined at the application layer for priority and pre-emption purposes. The GCS AS provides the priority level and the GCS identifier to the PCRF and the BM-SC. It is mapped by the PCRF and the BM-SC to the ARP priority level, pre-emption capability and pre-emption vulnerability indication under the consideration of the respective EPS network.

In the case of Unicast Delivery, the PCRF translates the service characteristics to PCC policies and forwards its policy decision to the PCEF. The PCEF determines, based on policies provided by the PCRF, whether the PCEF modifies already established bearers or whether the PCEF establishes dedicated bearer(s) with the determined bearer characteristics. If the priority of a particular application Group Communication session changes, the GCS AS provides an update of the service characteristics towards the PCRF via the Rx interface. The PCRF updates the PCC policies and forwards them to the PCEF. The PCEF modifies already established bearers or establishes dedicated bearer(s) accordingly.

The PCRF shall, at the reception of service authorization from the GCS AS including an indication that is a prioritized GC Session and priority level, ensure that the ARP priority level of the default bearer is assigned a prioritized value which is at least as high as the highest priority of all Group Communication Sessions within the same IP-CAN session. The PCRF shall also ensure that the ARP pre-emption capability and pre-emption vulnerability indication of the default bearer satisfies the strongest requirements of all Group Communication Sessions within the same IP-CAN session.

When the PCRF detects that all prioritized Group Communication Sessions within the same IP-CAN session are released, the PCRF shall assign the ARP of the default bearer as appropriate.

In the case of MBMS Delivery, if the priority of an MBMS bearer needs to be changed, based upon a GCS AS decision to change the priority level, the GCS AS performs either:

– The Modify MBMS Bearer procedure in clause 5.1.2.4; or

– A new Activate MBMS Bearer procedure and a Deactivate MBMS Bearer procedure replacing the old MBMS bearer service with a new one.

In certain network conditions such as congestion, the bearer used for group communication service may be pre-empted.

– In the case of Unicast Delivery, the GCS AS is notified by the PCRF of unicast bearer release.

– In the case of MBMS Delivery, the related MBMS bearer may be ‘suspended’ by E-UTRAN and the UE becomes aware in either of the following ways:

– packets are dropped at the eNB. In this case the UE can detect that MBMS delivery is no longer available when the related TMGI is removed from MCCH.

– The UE receives an explicit indication broadcast from the eNB in the MBMS Scheduling Information (see TS 36.300 [9] and TS 36.321 [10]), where it is informed that transmission for the MBMS bearer is going to be, or has been, suspended.

The procedure used by the UE in these scenarios is depicted in figure 5.4-1.

Figure 5.4-1: Switching from MBMS Delivery to Unicast Delivery following bearer suspension (and subsequent resumption of MBMS delivery)

1. The UE has an ongoing group communication.

2. The UE is receiving downlink data by MBMS Delivery.

3. E-UTRAN (e.g. after detecting MBMS congestion) decides to suspend one or more MBMS bearer(s) within MBSFN area(s) (based on e.g. the ARP and/or on the counting results for the corresponding MBMS service(s)), and trigger the migration of impacted UEs to receive DL data via unicast, by either:

a) explicitly informing those UEs that the MBMS bearer has been, or is going to be, suspended by broadcasting an indication within MAC MBMS Scheduling Information (and removing the TMGI from the MCCH), or

b) removing the TMGI of the MBMS bearer that has been suspended from the MCCH.

4. The UE detects the suspension of the corresponding MBMS bearer service, but continues to monitor for MBMS Delivery (i.e. because while it is establishing unicast there may still be DL data sent on the MBMS bearer).

5. Over GC1, the UE notifies the GCS AS of the MBMS service suspension.

6. The GCS AS decides whether to set up the Unicast Delivery path for the downlink data to this UE.

7. The UE receives DL data by Unicast Delivery and continues to monitor MBMS channels for resumption of the MBMS bearer.

NOTE: Between step 2 and step 11 data associated with the suspended MBMS bearer continues to be delivered by the GCS AS on the corresponding multicast transport infrastructure towards the E-UTRAN (e.g. because it is still delivered via eMBMS in non-congested MBSFN areas). This also allows a quicker resumption of the MBMS service when congestion is over.

8. At some point, the RAN determines that it can resume the MBMS bearer within the MBSFN area(s), e.g. when the congestion is over. The decision which of the suspended MBMS bearers to resume may be based on e.g. the ARP and/or on the counting results for the corresponding MBMS service(s).

9. The MCCH indicates that the TMGI is available.

10. The UE detects the TMGI on the MCCH and prepares to receive it.

11. The UE is again receiving downlink data by MBMS Delivery.

12. The UE notifies the GCS AS that it is receiving the group content via MBMS.

13. GCS AS stops the delivery via unicast.

5.5 Charging

For MBMS Delivery, the architecture requirement for charging defined for MBMS broadcast service for E-UTRAN in TS 23.246 [3] shall apply.

For Unicast Delivery, the architecture requirement for charging defined for EPS bearer services in TS 23.401 [5] shall apply.

5.6 Security

Security requirements for supporting the MB2 reference point for GCS are defined in TS 33.246 [8].

No additional security requirement is defined for supporting GCS with Unicast Delivery.

Annex A (Informative):
Utilisation of the Group Communication Service