3GPP TR 23 - 一般社団法人電波産業会 · PDF file3GPP TR 23.768 V12.1.0 ... 6.1.4 Solution evaluation ... Group communications with pre-established MBMS broadcast Bearers

3GPP TR 23.768 V12.1.0 (2014-06) Technical Report

3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;

Study on architecture enhancements to support Group Communication System Enablers for LTE (GCSE_LTE)

(Release 12)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Report is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 2 Release 122T

Keywords 3GPP, Architecture, Group communication, LTE

3GPP

Postal address

3GPP support office address 650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.

© 2014, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).

All rights reserved. UMTS™ is a Trade Mark of ETSI registered for the benefit of its members 3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM® and the GSM logo are registered and owned by the GSM Association

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 3 Release 122T

Contents Foreword ...................................................................................................................................................... 6

1 Scope .................................................................................................................................................. 7

2 References .......................................................................................................................................... 7

3 Definitions and abbreviations .............................................................................................................. 8 3.1 Definitions ................................................................................................................................................... 8 3.3 Abbreviations............................................................................................................................................... 8

4 Assumptions and architectural requirements ........................................................................................ 8 4.1 General ........................................................................................................................................................ 8 4.2 High-level reference diagram ....................................................................................................................... 9 4.3 Reference points ........................................................................................................................................ 10 4.4 Assumptions .............................................................................................................................................. 10 4.5 Architectural requirements ......................................................................................................................... 10

5 Key Issues ........................................................................................................................................ 10 5.1 Key Issue #1: Decision point for using PtP and/or PtM ............................................................................... 10 5.1.1 General description ............................................................................................................................... 10 5.1.2 Group Privacy considerations for PtP/PtM decision ............................................................................... 10 5.2 Key Issue #2: GCSE_LTE interaction with ProSe UE-to-Network Relays ................................................... 11 5.2.1 General description ............................................................................................................................... 11 5.3 Key Issue #3: Group Communication with geographical scope ................................................................... 11 5.3.1 General description ............................................................................................................................... 11 5.4 Key Issue #4: MuSe with additional media handling ................................................................................... 12 5.4.1 General description ............................................................................................................................... 12 5.5 Key Issue #5: Service continuity................................................................................................................. 12 5.5.1 General description ............................................................................................................................... 12 5.6 Key Issue #6: Roaming support .................................................................................................................. 12 5.6.1 General description ............................................................................................................................... 12 5.7 Key Issue #7: Interworking ........................................................................................................................ 12 5.7.1 General description ............................................................................................................................... 12 5.8 Key Issue #8: Priority and Pre-emption on Group Communication .............................................................. 13 5.8.1 General description ............................................................................................................................... 13

6 Solutions ........................................................................................................................................... 13 6.1 Solution 1 - Group Communications using pre-established eMBMS bearers ................................................ 13 6.1.1 Functional description ........................................................................................................................... 13 6.1.1.1 Solution description ......................................................................................................................... 13 6.1.1.2 Architecture reference model ........................................................................................................... 14 6.1.2 Procedures ............................................................................................................................................ 15 6.1.2.1 Group Communication Setup using pre-established eMBMS bearers ................................................ 15 6.1.2.2 Service continuity during unicast and MBMS switching ................................................................... 16 6.1.2.2.1 General ...................................................................................................................................... 16 6.1.2.2.2 Switching from MBMS to unicast - make-before-break .............................................................. 16 6.1.2.2.3 Switching from MBMS to unicast - Non make-before-break ....................................................... 18 6.1.2.2.4 Switching from unicast to MBMS .............................................................................................. 19 6.1.3 Impact on existing entities and interfaces .............................................................................................. 20 6.1.4 Solution evaluation ............................................................................................................................... 20 6.2 Solution 2 - GCSE AS counting of UEs per group per cell .......................................................................... 20 6.2.1 Functional description ........................................................................................................................... 20 6.2.2 Procedures ............................................................................................................................................ 20 6.2.3 Impact on existing entities and interfaces .............................................................................................. 21 6.2.4 Solution evaluation ............................................................................................................................... 22 6.3 Solution 3 - Group Communications with MuSe (eNB centric) ................................................................... 22 6.3.0 Overview .............................................................................................................................................. 22 6.3.1 Functional description ........................................................................................................................... 23 6.3.2 Procedures ............................................................................................................................................ 24

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 4 Release 122T

6.3.2.1 Multicast Delivery Setup ................................................................................................................. 24 6.3.2.2 MuSe and Mobility handling ........................................................................................................... 25 6.3.2.3 MuSe with voice and video media handling ..................................................................................... 26 6.3.3 Impact on existing entities and interfaces .............................................................................................. 28 6.3.4 Solution evaluation ............................................................................................................................... 28 6.4 Solution 4 - GCSE architecture using IMS and eMBMS ............................................................................. 28 6.4.1 Functional description ........................................................................................................................... 28 6.4.1.1 Solution description ......................................................................................................................... 28 6.4.1.2 Architecture reference model ........................................................................................................... 29 6.4.2 Procedures ............................................................................................................................................ 29 6.4.2.1 General ........................................................................................................................................... 29 6.4.2.2 GCSE group communication procedures .......................................................................................... 29 6.4.2.2.1 Switching from unicast to eMBMS delivery for an ongoing GCSE group communication

session ....................................................................................................................................... 29 6.4.2.3 GCSE Group membership procedures .............................................................................................. 31 6.4.2.3.1 Subscribing to a GCSE group ..................................................................................................... 31 6.4.2.3.2 UE joining Group Communication ............................................................................................. 31 6.4.3 Impact on existing entities and interfaces .............................................................................................. 31 6.4.4 Solution evaluation ............................................................................................................................... 31 6.5 Solution 5 - Group communications with pre-established MBMS broadcast Bearers and

multicast/unicast switching ......................................................................................................................... 31 6.5.1 Functional description ........................................................................................................................... 31 6.5.2 Procedures ............................................................................................................................................ 33 6.5.3 Impact on existing entities and interfaces .............................................................................................. 36 6.5.4 Solution evaluation ............................................................................................................................... 36 6.6 Solution 6: MuSe with configurable geographic scope ................................................................................ 36 6.6.1 General description ............................................................................................................................... 36 6.6.2 Procedures ............................................................................................................................................ 36 6.6.2.1 Group Communication within configured Geographic Service Area ................................................. 36 6.6.2.2 Group Communication with geographic service area override and filtering ....................................... 38 6.6.3 Impact on existing entities and interfaces .............................................................................................. 40 6.6.4 Solution evaluation ............................................................................................................................... 40 6.7 Solution 7: Assign and Re-assign Priority and Pre-emption capability for the GC ........................................ 40 6.7.1 Solution description .............................................................................................................................. 40 6.7.1.1 General ........................................................................................................................................... 40 6.7.1.2 Session Setup Procedure .................................................................................................................. 40 6.7.1.3 Session update Procedure ................................................................................................................ 41 6.7.1.4 Session Release Procedure ............................................................................................................... 41 6.7.2 Impact on existing entities and interfaces .............................................................................................. 41 6.7.3 Solution evaluation ............................................................................................................................... 42 6.8 Solution 8: Service continuity from unicast to multicast delivery ................................................................. 42 6.8.1 Functional Description .......................................................................................................................... 42 6.8.2 Procedures ............................................................................................................................................ 42 6.8.3 Impact on existing entities and interfaces .............................................................................................. 44 6.8.4 Solution evaluation ............................................................................................................................... 44 6.9 Solution 9: Group Management and associated user interaction................................................................... 44 6.9.1 UE and GCSE AS roles and requirements ............................................................................................. 44 6.9.2 Group management not at BM-SC level ................................................................................................ 44 6.9.3 Solution evaluation ............................................................................................................................... 45 6.10 Solution 10: Using pre-established eMBMS bearers as generic multicast delivery bearer ............................. 45 6.10.1 Solution evaluation ............................................................................................................................... 46 6.11 Solution 11: Scalability above the SGi reference ......................................................................................... 46 6.11.1 Functional Description .......................................................................................................................... 46 6.11.2 Impact on existing entities and interfaces .............................................................................................. 46 6.11.3 Solution evaluation ............................................................................................................................... 47

7 Evaluation ........................................................................................................................................ 47 7.1 Common approach ..................................................................................................................................... 47 7.1.1 GC2 ..................................................................................................................................................... 48 7.1.1.1 Information exchanged between GCSE AS and BM-SC ................................................................... 48 7.1.1.2 GC2 procedure ................................................................................................................................ 48 7.1.1.3 Control plane and User plane of GC2 ............................................................................................... 49

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 5 Release 122T

7.1.2 Roaming Architecture ........................................................................................................................... 49 7.1.3 Call flows and procedures ..................................................................................................................... 51 7.1.3.1 Downlink Media path setup for multipoint service ........................................................................... 51 7.1.3.1.1 General ...................................................................................................................................... 51 7.1.3.1.2 Pre-established eMBMS bearers ................................................................................................. 51 7.1.3.1.3 Dynamic eMBMS bearers .......................................................................................................... 51 7.1.3.2 Media Traffic using unicast and eMBMS on DL .............................................................................. 52 7.1.3.3 Service continuity procedures between unicast and multipoint service .............................................. 52 7.1.3.3.1 Unicast to eMBMS .................................................................................................................... 52 7.1.3.3.2 eMBMS to Unicast .................................................................................................................... 52 7.2 GCSE_LTE common solution approach with respect to Group Management considerations ........................ 53 7.2.1 Analysis of GCSE related contexts ........................................................................................................ 53 7.2.2 Key considerations................................................................................................................................ 53

8 Conclusions ...................................................................................................................................... 55 8.1 General ...................................................................................................................................................... 55 8.2 Priority and Pre-emption on Group Communication .................................................................................... 56

Annex A: QoS and bearer parameters for Group Communications .............................................. 58

A.1 General ............................................................................................................................................. 58

A.2 Overview .......................................................................................................................................... 58

A.3 Draft Changes to TS 23.203 v12.3.0 .................................................................................................. 58

Annex B: Change history ................................................................................................................. 63

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 6 Release 122T

Foreword This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 7 Release 122T

1 Scope The present document captures the results of the study and evaluation of possible solutions for architectural enhancements to support Group Communication System Enablers for LTE (GCSE_LTE). The Stage 1 requirements for GCSE_LTE are defined in TS 22.468 [3].

Specifically, GCSE_LTE covers the following aspects:

- Group Communication (GC) among entitled group members via E-UTRAN;

- Group Communication (GC) among entitled group members using E-UTRAN and members of the same group using ProSe communication paths via a ProSe UE-to-Network Relay;

- The relationship between ProSe and GCSE for GCs.

The functional descriptions of "ProSe communication paths via ProSe UE-to-Network Relay" and "ProSe GCs" have been defined in TR 23.703 [4].

2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".

[3] 3GPP TS 22.468: "Group Communication System Enablers for LTE (GCSE_LTE)".

[4] 3GPP TR 23.703: "Study on architecture enhancements to support Proximity Services (ProSe)".

[5] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".

[6] Open Mobile Alliance: "OMA PoC System Description" v2.1.

[7] IETF RFC 4582 (November 2006): "The Binary Floor Control Protocol (BFCP)".

[8] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description".

[9] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".

[10] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification".

[11] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".

[12] 3GPP TS 33.246: "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)".

[13] 3GPP TS 23.003: "Numbering, addressing and identification".

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 8 Release 122T

[14] 3GPP TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode".

3 Definitions and abbreviations

3.1 Definitions For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].

GCSE Group: A set of members that are entitled to participate in a GC service.

Group Communication service ID: A Group communication service identifier identifies the communication service among the group members.

Multipoint Service: A service, which is offered to the GCSE AS and used to distribute the same Group Communication data to the UEs of a GCSE Group in a resource efficient way.

Multicast Delivery: A delivery mode where the Group Communication data is delivered via shared network resources to multiple group members.

NOTE: RAN might study a "Multicast Delivery" consisting of PtP or PtM radio bearers.

Unicast Delivery: A delivery mode where the Group Communication data is delivered to a particular group member via resources dedicated to a group member.

3.3 Abbreviations For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1].

BM-SC Broadcast Multicast - Service Centre DL Down Link EMBMS Evolved Packet System MBMS GC Group Communication GCSE_LTE Group Communication Service Enabler over LTE GCSE AS Group Communication Service Enabler Application Server MBMS Multimedia Broadcast/Multicast Service MBSFN MBMS over a Single Frequency Network MOCN Multi-Operator Core Network MuSe Multipoint Service MTCH Multicast Traffic Channel ProSe Proximity Services PCRF Policy and Charging Rules Function PtP Point to Point PtM Point to Multipoint TMGI Temporary Mobile Group Identity

4 Assumptions and architectural requirements

4.1 General Editor's note: Placeholder for any general aspect of this study.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 9 Release 122T

4.2 High-level reference diagram Figure 4.2-1 shows the high level view of the GCSE architecture.

UE eNB MBMS GW BM-SC

GCSEApplication

server

MME P-GW

Uu GC3

S1-aaE

SG-imb

SGi

SG-mb

GC2

S-GW

GC4 S11 S5

S1-U

GCSE

Application

UEGCSE

Application

troSe Communication

UEGC1GCSE

Application

MuSe

GC5aedia

NOTE 1: It is for FFS on whether the unicast service is provided via GC5 or SGi. NOTE 2: It is FFS on how this architecture will be further decomposed (based on solution proposal). NOTE 3: Multiple PLMNs (i.e., members for the same group are served by different PLMNs concurrently) and

roaming architecture is FFS.

Figure 4.2-1: Overall of high level architecture view for GCSE_LTE

This high-level architecture diagram consists of Application layer and 3GPP EPS layer. The Application layer consists of GCSE AS. The 3GPP EPS layer consists of a MuSe function. The MuSe function interworks with the 3GPP EPS entities (defined by TS 23.401 [5]) to provide the Multipoint Service (MuSe) functionality.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 10 Release 122T

4.3 Reference points GC1: It is the reference point between the GCSE application in the UE and in the application server. It is used

to define application level signalling requirement to enable Multipoint functionality for GCSE_LTE, and possibly for session establishment and floor control usages, etc.

GC2: It is the reference point between the GCSE AS and the MuSe function. It is used to define the interaction between GCSE AS and MuSe functionality provided by the 3GPP EPS layer.

GC3: It is the reference point between the E-UTRAN and MuSe function. It is used to define the interaction between E-UTRAN and MuSe function in order to achieve Multipoint functionality provided by the 3GPP EPS layer.

GC4: It is the reference point between the MME and MuSe function It is used to define the interaction between MME and MuSe function in order to achieve Multipoint functionality provided by the 3GPP EPS layer.

GC5: It is the reference point between the P-GW and MuSe function. It is used to provide DL unicast service by MuSe .

Editor's note: The use of the above new reference points for normative work will need to be justified.

4.4 Assumptions Editor's note: This clause will define the underlying assumptions of this study.

4.5 Architectural requirements Editor's note: This clause will define the architectural requirements for this study.

The architecture shall allow as an option for the GCSE AS to determine whether to deliver the group call data using Unicast delivery or Multicast delivery or both.

5 Key Issues Editor's note: For each key issue identified, the clause will capture the "General description and assumptions" (sub-

clause 1). Different architecture solutions to address the key issues will be documented in clause 6.

5.1 Key Issue #1: Decision point for using PtP and/or PtM

5.1.1 General description Should the decision to use PtP and/or PtM distribution be done at the application layer or within the 3GPP EPS layer? Proposed solutions should explain why the proposed method should be used and how this may be achieved.

5.1.2 Group Privacy considerations for PtP/PtM decision The use of PtM by a cell is communicated in broadcast information and typically most cells might not use PtM.

Editor's note: It is FFS whether Groups are treated independently or whether several Groups share a single PtM identifier at the RAN or EPS level.

Hence the activation (or modification) of PtM resources in a cell may serve as a warning to criminals of the nearby presence of public safety personnel.

Some entity in the network needs to take account of the Group's privacy settings before deciding to use PtM, e.g.

- Whether to NEVER establish PtM for that group;

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 11 Release 122T

- Whether to perform a "fast" PtM activation over a single DRX period thereby risking some mobiles not discovering the broadcast but minimising the time that PtM can be detected;

- Whether there are no restrictions on PtM for that group.

Privacy considerations such as these should be taken into account when making the decision on 'application layer' vs. '3GPP EPS' control of PtM/PtP bearer usage.

5.2 Key Issue #2: GCSE_LTE interaction with ProSe UE-to-Network Relays

5.2.1 General description A public safety ProSe-enabled UE not served by E-UTRAN can take part in a GC of one or more GCSE Groups for which it is authorised via a ProSe UE-to-Network Relay.

The details of the Prose UE-to-Network Relay procedures and interaction with the network at the "transport layer" will be studied in Proximity Services Study Report TR 23.703 [4].

Aspects specific to the interaction between GCSE_LTE and the ProSe UE-to-Network Relay need to be considered in potential solutions.

5.3 Key Issue #3: Group Communication with geographical scope

5.3.1 General description Based on the requirements defined in TS 22.468 [3] on "Geographical scope of GCSE Groups", the group members may be restricted to receive and/or transmit only within those cells corresponding to the area defined by the geographical scope of the GCSE group. This geographical scope of the GCSE group is typically agreed between customer and GCSE application service provider as part of the subscription for the GCSE Group.

When requested, a notification shall be sent to a requesting entity when the group member ceases to participate in the communications from the GCSE Group, i.e. in case of a group with restricted geographic scope when the group member leaves the Group's Service Area.

NOTE 1: This notification requirement is not just related to geographical scope.

Proposed solutions should explain how GCSE is accomplished for groups with a geographic scope as per TS 22.468 [3] and how any required notifications are provided when a group member ceases to participate in the communications from its GCSE group due to leaving the Group's Service Area.

Per instance of group communication the geographic area in which the group communication is delivered can be further restricted within the geographic scope of the GCSE group.

Some scenarios may require overriding the geographic scope of the GCSE group. An operator may want to charge for this.

NOTE 2: The geographic area concept is independent of whether the Group Communication data is delivered over unicast or multicast.

Editor's note: It's FFS where this functionality is most optimally implemented (e.g. in MuSe or at application level).

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 12 Release 122T

5.4 Key Issue #4: MuSe with additional media handling

5.4.1 General description In GCSE, a Group Communication may consist of different media (e.g. voice+video or voice only, IP packet for data communications, etc). A Transmitter Group Member may choose to send IP packet for data communication or particular media type (e.g. voice) initially and later adds data/media component(s) (e.g. video) to this group session based on the situation and then removes the additional data/media when it is no longer needed.

Receiver group members may choose to receive only the data/media type that are in its interest to receive (e.g. only voice media and not video).

Proposed solutions should explain how the addition and removal of additional data/media component(s) (e.g. video) is performed within the current Group Communication session and how the Receiver group members can decide which type of data/media to receive if only certain media/data is wanted.

5.5 Key Issue #5: Service continuity

5.5.1 General description It is assumed that continuity of service will be provided when a UE moves between cells in the same PLMN providing a GC via Multipoint Service (MuSe) exists in both cells.

The SA WG2 study phase needs to consider at least:

- will the 3GPP EPS provide service continuity for a GCSE Group Communication between delivery over a unicast EPS bearer and delivery over a Multipoint Service (MuSe) ?

- If so, what EPS procedures will be required ?

- If not, what interface support, in order to minimize service disruption, will the EPS provide to Third Party applications to manage the switch to/from unicast EPS bearers and a Multipoint Service (MuSe) ?

- what EPS procedures will be required to provide service continuity when UE numbers in a cell / MuSe service area rise and fall across the threshold indicating that multicast/broadcast delivery should or should not be provided ?

- what are the interfaces between the RAN and EPC- In collaboration with RAN WGs ? Determine the split of responsibilities between RAN and CN for service continuity.

5.6 Key Issue #6: Roaming support

5.6.1 General description The SA WG2 study phase needs to consider at least:

- what EPS procedures will be required so that GCSE_LTE Group Communication support may be provided by the HPLMN when the UE is roaming (attached to a VPLMN) ?

5.7 Key Issue #7: Interworking

5.7.1 General description The SA WG2 study phase needs to consider at least:

- what EPS procedures, entities and interfaces will be required to provide GCSE-based GC interworking between UEs which are connected to a common RAN but are attached to different PLMNs (support for MOCN with all

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 13 Release 122T

UEs attached to their HPLMN). More than one PLMN may provide access to a GCSE Application Server. The GCSE Application Server(s) may be within the operator domain or outside the operator domain;

- the architecture, including interfaces and location of any interworking function (i.e. inside or outside the EPS), that would enable interworking between:

- UEs which are connected to different EPS networks where each network provides GCSE-based GC services;

- UEs connected to a 3GPP network offering GCSE-based GC and terminals connected to a non-3GPP network which also offers group communication services for Public Safety (e.g. legacy systems such as TETRA and P25).

In each of the above cases it is assumed that suitable interworking agreements are in place between the different operators.

5.8 Key Issue #8: Priority and Pre-emption on Group Communication

5.8.1 General description One Group Communication may include different transport paths, i.e. unicast/ multicast delivery. For one Group Communication the priority and pre-emption capability for a particular media within a PLMN should be same no matter which transport path is selected.

One Group Communication can include different media, e.g. voice and picture. For one GCSE group different user may have different priority. During the exceptional situation of resource limitations, the system may decide to release resources allocated for Group Communications based on the priority level and pre-emption capability of the different communication groups.

The SA WG2 study phase needs to consider at least:

- In the 3GPP network, how to assign the priority level and pre-emption capability to the traffic of the Group Communication ?

6 Solutions Editor's note: This clause is intended to document architecture solutions. Each solution should clearly describe

which of the key issues it covers and how.

6.1 Solution 1 - Group Communications using pre-established eMBMS bearers

6.1.1 Functional description

6.1.1.1 Solution description

These are the salient features of the solution:

1. Solution leverages eMBMS on downlink for GCs.

2. The solution uses pre-established eMBMS bearers for fast GC setup.

It implies the followings:

- TMGI(s) associated with the group call is pre-assigned by the BM-SC and the MBMS bearers for this group call (one MBMS bearer per QoS class) are pre-established in advance.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 14 Release 122T

- The network establishes MBMS session in preconfigured MBSFN areas.

NOTE: Different groups can have different preconfigured MBSFN areas.

Editor's note: The size of MBSFN area is FFS.

- The UE may need to receive data for multiple TMGIs in the same scheduling period (which for low latency services such as speech is anticipated to be set to 80 ms). The network needs to take the UEs' Radio Access Capabilities into account if these TMGIs are used on different carrier frequencies.

NOTE: While clause 5.8.1.1 of Release 11 TS 36.331 [10] specifies this behaviour to be 'implementation specific', TSG RAN indicated in their LS in S2-140050 (= RP-132109) that:

"If multiple MBMS services or multiple MBSFN areas, in which the current serving cell is participating, are transmitted on the same carrier, then it should be straightforward to receive them simultaneously. There is no big impact on the UE processing requirements. It is worth noting that the capability of UE would be constrained by the UE category given in TS 36.306.".

Hence it seems reasonable for SA WG2 to assume that a more stringent, multi-TMGI, requirement can be placed on UEs for Public Safety users in 3GPP Release 12.

- The network sends the corresponding TMGI(s) and session information over MCCH.

- If not all MBMS subframes allocated in MCCH are needed for transmission of existing MBMS services, the left over MBMS subframes can be used for unicast. However (from LS response to question 1a in TD R1-134985), it is not possible to multiplex MBMS and unicast transmissions in the same subframe.

- (As a consequence of answer 3c in LS response in TD R2-133728) Because the minimum MCCH modification period is 5.12 seconds, and initial talk spurts need much lower latency, once the MBMS session start for that talk group has been received, the eNB continually sends the TMGI(s) on the MCCH. To avoid excessive end to end speech delay, MCH Scheduling Information (MSI) is sent every 80 ms to indicate whether or not data for an individual TMGI is sent on the MBMS subframes.

3. Unicast bearers are used for uplink communication. In certain cases (e.g. eMBMS is not supported) unicast is also used for DL.

4. The solution uses PCRF as interface between GCSE As and BM-SC for exchange of eMBMS related control information.

Editor's note: The use of PCRF for exchanging eMBMS control information is FFS.

6.1.1.2 Architecture reference model

UE eNB MBMS GW BM-SC

GCSEApplication

server

MCE MME P-GW

Uu a1

a2

a3

SG-imb

SGi

SG-mb

PCRFRx

Gxn

S-GW

Sm S11 S5

S1-U

GCSE

Application

UEGCSE

Application

troSe Communication

Figure 6.1.1.2-1: Architecture for 3GPP GCSE service

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 15 Release 122T

6.1.2 Procedures

6.1.2.1 Group Communication Setup using pre-established eMBMS bearers

The interaction between the UE and GCSE AS is shown as an example.

Figure 6.1.2.1-1

1-4. GC Server requests the TMGI(s) for the GCSE group(s) from the BM-SC through the PCRF.

5. GC Server maintains a mapping of the TMGI to the GCSE Group ID.

6-10. Pre-established bearers are set up for the group(s). The corresponding MBSFN area is based on the eNBs that were pre-selected for this GCSE GC as provided to the BM-SC. Triggered by step 8, the E-UTRAN sends MBMS related system information and MCCH configuration information over the air.

The UE periodically monitors MCH scheduling information (MSI) to detect if the TMGI associated with MTCH has been scheduled.

11. The GCSE Application on UE registers with GCSE Application Server.

The register message may include all the group identifiers the UE is in interested.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 16 Release 122T

12. The TMGI(s) of the GCSE group(s), if available, are returned to the UE.

The UE maintains a mapping of the TMGI to the GCSE group identifier.

13. The UE monitors the network to determine the availability of the eMBMS transmission corresponding to the TMGI(s) of the interested GCSE group(s). The UE initiates a Group Communication set up for a particular GCSE group using Unicast UL bearers. The UE also indicates the availability of the eMBMS transmission corresponding to the TMGI of the GCSE group in the group setup signalling.

14. The GCSE AS decides whether to use the pre-established eMBMS bearers for downlink.

When the E-UTRAN detects the data is coming from the network, the E-UTRAN modifies the MSI to indicate the schedule to the UE. The UE receives the MSI and tunes to the MTCH.

6.1.2.2 Service continuity during unicast and MBMS switching

6.1.2.2.1 General

The clause provides flows for switching from MBMS to unicast and vice-versa.

6.1.2.2.2 Switching from MBMS to unicast - make-before-break

Figure 6.1.2.2.2-1 shows the procedures for service continuity when the UE is about to move from a cell (eNB1) transmitting (e)MBMS bearer service to a cell (eNB2) which does not transmit the same (e)MBMS service, i.e. when the UE is about to move out of MBSFN area.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 17 Release 122T

GCSE AS UEMME/

MCEP-GW/SGWMBMS-GWBM-SC

6. Media

eNB1(MBSFN)

1. Receiving aSI and Contents from TaGI

over aTCH

6. Media

1. Group Call is On Going

3. UE enters connected state if UE is in idle state

1. Media1. Media

2. UE detects a.aS coverage is weak by

measuring the a.SCN signal

eNB2

4. UE indicates to the GCSE AS that it is moved out from the a.aS coverage

5. Ack

9. Stop monitoring aTCH and continues receiving

SI.

7. The UE is handoff from eN.1 to eN.2

8. Media8. Media

Figure 6.1.2.2.2-1: Service continuity when moving out from eMBMS coverage (Make-Before-Break)

The following steps are performed:

- In Step 1 the group call is on going. The UE receives the GC service data/media from the content provider (GCSE-AS) via an eMBMS bearer service.

- In Step 2, for make-before-break switching procedures, the UE detects that it is about to move out from the eMBMS coverage through the following implementation-specific methods (but not limited to):

- The UE detects that MBSFN signal strength becomes weak;

- The UE detects that packet data loss rate is increased.

Editor's note: It is FFS whether UE can reliably detect that it is moving out of MBSFN coverage by measuring MBSFN signal strength or packet error rate.

- In Step 3, If the UE is in idle state, the UE enters connected state by performs RRC connection procedures with eNB1.

- In Step 4, the UE indicates the GCSE-AS that it is moved out from the eMBMS coverage through application signalling.

- In Step 5, the GSCE-AS sends ack to the UE through application signalling.

- In Step 6, the UE receives the GC service data/media from the content provider (GCSE-AS) via the unicast bearer through eNB1.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 18 Release 122T

- In Step 8, the UE is handoff from eNB1 to eNB2.

- In Step 9, the UE receives the GC service data/media from the content provider (GCSE-AS) via the unicast bearer through eNB2.

- In Step 10, the UE stops receiving current MTCH and continues receiving SIBs.

6.1.2.2.3 Switching from MBMS to unicast - Non make-before-break

Figure 6.1.2.2.3-1 shows the procedures for service continuity when the UE moves from a cell (eNB1) transmitting (e)MBMS bearer service to a cell (eNB2) which does not transmit the same (e)MBMS service, i.e. when the UE moves out of MBSFN area.

Editor's note: It is FFS if the non make-before-break can satify the service continuity requirements.

GCSE AS UEMME/


6. Media

eNB1(MBSFN)

1. Receiving aSI and Contents from TaGI

over aTCH

6. Media

1. Group Call is On Going

3. UE enters connected state if the UE is in idle state

1. Media1. Media

2. UE detects it is moved from eN.1 to eN.2

which doesn’t support a.aS (for example,

SI.13, SI.15, or aCCH)

eNB2

4. UE indicates to the GCSE AS that it is moved out from the a.aS coverage

5. Ack

7. Continues receiving SI.

Figure 6.1.2.2.3-1: Service continuity when moving out from eMBMS coverage (non make-before-break)


- In Step 1 the group call is on going. The UE receives the GC service data/media from the content provider (GCSE-AS) via an eMBMS bearer service.

- In Step 2, the UE detects that it is already moved from eNB1 to eNB2 which doesn't support GC service data/media over the MBMS session by monitoring SIB (SIB2/SIB13/SIB15 etc.) messages or MCCH.

- In Step 3, the UE enters Connected State if the UE is in Idle State.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 19 Release 122T

- In Step 4, the UE indicates the GCSE-AS that it is moved out from the eMBMS coverage through application signalling.

- In Step 5, the GSCE-AS sends Ack to the UE through application signalling.

- In Step 6, the UE receives the GC service data/media from the content provider (GCSE-AS) via an EPC unicast bearer through eNB2.

- In Step 7, the UE continues receiving the SIB messages.

6.1.2.2.4 Switching from unicast to MBMS

Figure 6.1.2.2.4-1 shows the procedures for service continuity when the UE moves into MBMS coverage.

GCSE AS UEMME/


1. Media

eNB2

1. Media

1. Group Call is On Going (The UE is in connected state and GCSE service is over unicast bearer through eN.2)

10. Media10. Media

eNB1 (MBSFN)

7. UE indicates to the GCSE AS that it is within the a.aS coverage

8. Ack

3. UE detects it moves into a.aS coverage (for

example, it receives SI.13, SI.15, or aCCH)

6. Receiving aSI and Contents from TaGI over

aTCH

4. UE receives USD

5. a.aS user service registration and obtains aSK if needed

9. GCSE AS stops sending media through unicast channel and unicast bearer is released

2. The UE is handoff from eN. 2 to eN.1

2. Media1. Media

Figure 6.1.2.2.4-1: Service continuity when moving into eMBMS coverage


- In Step 1 the group call is on going. The UE is in connected state and receives the GC service data/media via an unicast bearer through eNB2 which doesn't support MBMS.

- In Step 2, the UE is handoff from eNB2 to eNB1 which supports MBMS and the UE continues to receive the GC service data/media via the unicast bearer through eNB1.

- In Step 3, the UE detects that it is moving into the eMBMS coverage by monitoring SIB (SIB2/SIB13/SIB15 etc.) messages or MCCH.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 20 Release 122T

- In Step 4, the UE performs service discovery procedures if needed. The UE receives USD from eMBMS channel or from unicast channel.

- In Step 5, the UE performs MBMS service registration procedures and receive MBMS service key if needed.

- In Step 6, the UE receives the GC service data/media from the content provider (GCSE-AS) via an eMBMS bearer service.

- In Step 7, the UE indicates the GCSE-AS that it is moved into the eMBMS coverage through application signalling.

- In Step 8, the GSCE-AS sends an Ack to the UE through application signalling.

- In Steps 9, the GCSE- AS stops sending the GC service data/media via an EPC unicast bearer.

The unicast bearer can be released.

- In Step 10, the UE continues to receive the GC service data/media from the content provider (GCSE-AS) via an eMBMS bearer service.

6.1.3 Impact on existing entities and interfaces Editor's note: Impacts on existing nodes or functionality will be added.

6.1.4 Solution evaluation Editor's note: The fulfilment of requirements in clause 4.2 needs will be evaluated.

a) Without knowledge about whether mobiles from the talk/media group are within the cell, data for that talk/media group has to be broadcast in every cell in the pre-established MBMS area. From the description of the number of mobiles per groups per TETRA cell in TD S2-131607, and the fact that commercial cellular networks deploy more cells per unit area than the UK TETRA network, it can be seen there will be frequently zero users from a group in a cell. (Table 1 shows that Site 4, cell A has 27 groups, but site 4 cell C has only 2 groups, i.e. with solution 1, site 4 cell C would broadcast data for at least 25 groups unnecessarily!)

b) For low latency services such as speech, the UE needs to receive the Multicast Scheduling Information at least once every 80 ms.

6.2 Solution 2 - GCSE AS counting of UEs per group per cell

6.2.1 Functional description This solution builds on the eMBMS service description provided in Solution 1. The intention is to use unicast bearers to distribute the downlink media unless there are a significant number of users in the same group in the same cell (in which case eMBMS usage in that cell is triggered).

While this solution normally keeps the public safety UEs "Permanently RRC Connected", there are variants that allow the device to move to RRC-Idle. However, it is anticipated that modern work management/asset tracking/employee safety systems will ensure frequent location and status updates from all 'group call' devices. The frequency of these updates is likely to be of the order of every 30 seconds and hence the RAN is anyhow likely to want to keep them in connected state. In addition, the need to rapidly playout a speech command to users means that if they were allowed to go to RRC idle, then they would need to use the shortest DRX setting, i.e. 320 ms.

6.2.2 Procedures a) At the start of the Public Safety User's shift, the user "clocks on" and IMS-style signalling is used to register the

user/device, AND to inform the device of TMGI(s) and decryption keys that may be used if eMBMS is encountered.

NOTE 1: The term "IMS-style signalling" indicates, for example, the use of SIP messages, and/or, IMS authentication and/or the use of QCI 5 as a bearer for SIP signalling, etc.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 21 Release 122T

b) The MME instructs the EUTRAN to keep this UE in RRC connected state. Either the subscription record from the HLR, a dedicated APN for GC, or an indication from the GCSE AS (e.g. via Rx/Gx/S5-S8/S11 messages), can give instruction to the MME so as to inform the RAN to keep the UE in RRC connected state.

c1) RFSP/SPID functionality is used to group Emergency Service Users on the same frequency/RAT (typically the LTE frequency that forms the network's "coverage layer").

c2) the cells on the network's LTE coverage layer have eMBMS subframes configured but the MCCH does not normally signal any TMGIs.

NOTE 2: This configuration is believed to consume very little radio resource provided that there is a significant proportion of Rel-10 or newer mobiles in the cell. When their TMGI is not signalled, the battery impact on the UE is low (reception of the MCCH is required only every 5.12 seconds).

d) The PDN GW activates ULI report procedure with Cell based granularity. This activation may be based on the APN, or, could be controlled across interface(s) between the PDN GW and the GCSE AS via Rx/Gx.

The latter option may permit relaxed location reporting (e.g. TA based) to be used for devices that are in a TA-list/PLMN that is excluded from the Group Call area.

NOTE 3: An alternative to the network based ULI report, is that the UE detects the cell change and sends a user data packet to the GCSE AS to inform it that the UE is in a new cell. Reporting of cell change from the RRC layer to "upper layers" is a feature that is supported by USIM Application Tool kit and most modern device operating systems/engineering functions. However, the RAN signalling load caused by the transition from Connected-DRX mode to data transfer mode at every cell change is probably slightly greater than the load caused by the ULI reports sent at intra-eNB movement, and by using ULI reporting there is less data transmission from the device and hence a somewhat improved battery life. If using this alternative, the need for the network to keep the mobile in RRC Connected state can be relaxed provided that the UE uses an idle mode DRX (e.g. 320 ms) that meets the service's latency requirements.

e) With each User Location Information report, the 'GCSE AS' increments and decrements counters on how many users are in each group in each cell.

f) dependent upon the number of users in a group in a cell (and the cell's RAT), the 'GCSE AS' decides whether to distribute future media/data in that cell via:

- the existing established point to point bearer, and/or,

- an eMBMS broadcast bearer (at this point step 6 clause 6.1.2.1 of in solution 1 occurs and the cell starts to broadcast the TMGI of that group on the MCCH even if no media is present). Single cell MBSFN areas are used because the number of users per group per cell can vary greatly even within the cells of a single eNodeB.

It is anticipated to be normal that the Group spans many cells and when media is sent out to that Group some cells use point to point bearers; some cells use an eMBMS bearer; and, at least in transient mobility cases, some cells will have both point to point bearers and an eMBMS bearer.

g) even when eMBMS is in use, the UEs can use unicast uplink transmissions to the GCSE AS to ack/nack the downlink transmissions. If the eMBMS link quality is insufficient for a specific UE, then the GCSE AS may use the point to point downlink bearer to send the media to that UE.

As an additional complementary component to the above procedure, if the service used within that group has a fast response time requirement (e.g. 300 ms), then (at step b), the subscription record from the HLR informs the MME [and SGSN] to instruct the RAN to keep this UE in RRC connected state with "a short connected mode DRX".

6.2.3 Impact on existing entities and interfaces Interfaces. There is a need to:

- define an appropriate RFSP/SPID value; and

- for the HSS to be able to control the RAN's use of "short connected mode DRX" for fast response time services;

- GC2 interface to be able to describe the MBMS area in terms of cell identities.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 22 Release 122T

Network entities are likely to be somewhat more loaded by the cell change reports, however, the proportion of Public Safety users in a commercial network should be relatively low (e.g. < 5%), and, in a dedicated Public Safety network, resilience requirements will probably result in the over-dimensioning of the core network.

6.2.4 Solution evaluation a) By tracking which users are in which cell and using single-cell MBSFN areas, there are never any MBMS (or

unicast) transmissions in cells with no recipients of the data. This is a significant radio efficiency advantage over solution 1.

b) The pros and cons of tracking devices using network based ULI reporting vs UE based application cell-change reports are finely balanced. "Speed to market" and core network signalling load considerations indicate that the UE based solutions are likely to win, at least initially. A UE based solution may result in slightly more data transmission with the network.

c) The Carrier Aggregation work within RAN WGs shows that many layers of cells can be present in the same geographic location. In order to benefit from the efficiencies of MBMS when large numbers of users from the same group are in the same location, a mechanism such as RFSP/SPID is needed to group the PS users on to the same cell layer (at least if UE based application cell change reports are used).

d) By using a per-UE connected mode (or possibly even an idle mode) DRX of 320 ms, decent PTT delays can be achieved while also achieving reasonable battery life. (It is assumed that a Public Safety device will have a larger than normal battery, e.g. sufficient battery power to keep GPS positioning running for at least a 12 hour shift).

e) By only using MBMS when there are significant numbers of members of a group in a cell, and single cell MBSFN areas, the number of groups using MBMS in a cell will normally be low. Hence the allocation of different TMGIs to different talk groups is likely to be a workable solution, e.g. the chance of one device needing to receive on >> 1 TMGI in an 80 ms period is low.

NOTE In S2-140050 (=RP-132109), TSG-RAN stated that "If multiple MBMS services or multiple MBSFN areas, in which the current serving cell is participating, are transmitted on the same carrier, then it should be straightforward to receive them simultaneously. There is no big impact on the UE processing requirements. It is worth noting that the capability of UE would be constrained by the UE category given in TS 36.306".

f) For the simultaneous reception of voice and video by the same "work group", the ability to receive 2 TMGIs simultaneously enables the existing eMBMS QoS model (see clause 6.3.2 of TS 23.246 [8]) to be retained.

g) the use of single cell MBSFN areas avoids the need for tight inter-site time synchronisation. This may be particularly useful for major incidents where temporary cell sites are deployed as these temporary cells may be difficult to connect to the MCE which serves the permanent cells in that area (clause 15.1.1 of TS 36.300 [2] indicates that all cells in the MBSFN area need to use a common MCE).

h) Keeping UEs in RRC connected state adds some load to the eNB. Having different inactivity timers/connected mode DRX settings in the eNB for Public Safety and non-Public Safety users requires eNB implementation effort.

6.3 Solution 3 - Group Communications with MuSe (eNB centric)

6.3.0 Overview For Multicast Delivery, this solution reuses the eMBMS architecture as defined in TS 23.246 [8] for media distribution in the core network level toward the associated eNB(s). At the eNB level, this solution expects that the eNB to make a decision to determine whether the radio delivery mechanism toward a particular UE should be using PtP or PtM transmission and the type of radio transmission being used by eNB is transparent toward the core network.

For Unicast Delivery, this solution does not alter the current EPS procedure as defined in TS 23.401 [5] for handing GBR/non-GBR.

In high level, the following steps describe how this Multicast Delivery works in the system level.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 23 Release 122T

1. For a particular GC session, eNB receives the media/TMGI from MBMS-GW. eNB broadcasts the TMGI over the air. Media is not transmitted over the radio.

2. UE detects this TMGI from the serving eNB and indicates to eNB (become RRC Connected if not already) that it wants to join to the Mulitcast Delivery session pointed by this TMGI.

3. eNB then maintains a group-call context (e.g. remember UE-TMGI relationship).

4. eNB starts sending the media over the radio and indicate to UE the corresponding radio related parameter so the UE can start listening in to the DL media using Multicast Delivery.

5. For mobility handling, source eNB indicates to target eNB the TMGI(s) associated with the UE so target eNB can prepare the radio resource during the HO process.

Editor's note: This procedure requires new eMBMS RAN radio transmission scheme and procedures and is therefore subject to future study by RAN WGs.

6.3.1 Functional description Figure 6.3.1-1 shows a high level interaction between the UE, Application layer, and MuSe function, and the RAN nodes for invoking multipoint service for GC.

UE#1 GCSE AS MuSe

A1. Group registration (user ID, Group ID (s),..)A2. Group member validation

A3. Response to UE

B1. Decision to start MuSe?B2. Send MuSe Request

B3. MuSe Setup in EPSB4. Response to GCSE AS

C1. Update UE with MuSe related parameterC2. UE receiving media with MuSe

eNodeB

D1. Express interest for MuSe deliveryD2. eNodeB caches UE context and adjusts radio parameters

Figure 6.3.1-1: high-level interaction for GCSE functions

At high level, the interaction can break into 4 areas:

A1 to A3: UE expresses its interest for joining to certain GC(s) to become Receiver group member. GCSE AS needs to validate the user request and response to the request accordingly. This is communicated over GC1.

B1 to B4: GCSE AS made a decision to use Multicast Delivery offered by the EPS for GC so it sends a request to MuSe. MuSe coordinates the setup within the EPS and response to GCSE AS accordingly. This is communicated over GC2.

C1 to C2: UE needs to be updated with certain Multicast related parameter (e.g MBMS service announcement information) in order to use the multipoint service offered by the EPS. This is communicated over GC1.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 24 Release 122T

D1 to D2: UE expresses its interest for MuSe Delivery (i.e. provide TMGI) to eNodeB. The eNodeB caches UE context (e.g. mapping between UE and TMGI), and adjusts the radio parameters to keep the UE in long connected state. The eNodeB determines whether to use PtP/PtM to send DL group traffic media, based on the knowledge of cached UE context and RAN node situation.

6.3.2 Procedures

6.3.2.1 Multicast Delivery Setup

Prior to Multicast Delivery setup, UE is participating to a GC using a Unicast Delivery. At some point, GCSE AS decided to involve Multicast Delivery for media distribution so it invokes the MuSe function via GC2.

UE eNB MME MBMS GW BMSC

2. MuSe Request (QoS, Geo Scope, Group Comm. ID)

GCSE AS

1. UE established Unicast Delivery for group communication

3. MuSe session setup

4. MuSe Request Resp(status, media address, service announ.., ...)

6. forwarding Media

5. update MuSe parameter (service announcement info, ..)

7. UE receiving DL media using Multipoint Delivery

8. UE release Unicast Delivery for group communication and indicate to GCSE AS that Multipoint Delivery is used.

Figure 6.3.2.1-1: MuSe Setup

1. UE has expressed its interest to participate into a GC and GCSE AS has granted the access. The media is received via a dedicated EPS bearer toward the group server (i.e. Unicast Delivery).

2. GCSE AS determines that Multicast Delivery is needed and sends a request to BMSC. It includes the QoS information for the DL media, and GC ID that points to this GC. QoS indicates information similar to ARP and QCI in order to define the characteristic of the media. It may also include a Geographical Scope to define the area where the DL media distribution is confined.

3. MuSe setup to corresponding eNb using the procedure defined for eMBMS in TS 23.246 [8] clause 8.3.2 - MBMS Session Start Procedure for E-UTRAN step 1 to 6.

4. BMSC responds to GCSE AS with the address where the DL media is sent, service announcement /Service ID information for joining the MBMS service (see TS 26.346 [11]). UE expresses interest for a certain service identified by its service ID. BMSC authenticates the UE and provides the TMGI, MSK, codec, etc.

Status is used to indicate to GCSE AS if this request is accepted or not. BMSC also keeps internally the allocated TMGI with the GC ID received from step 2.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 25 Release 122T

5. GCSE update the Receiver group members with service announcement information.

6. Based on the DL media reception address received from step 5, GCSE AS forwards the media related to this GC.

NOTE 1: Step 5 and 6 can be performed in parallel.

7. UE monitors the system broadcast for the interested TMGI. When detected, UE expresses its interest to eNb to receive the DL media. The eNB adjusts radio parameters to keep the UE in long connected state, and sends the DL media to UE. RAN can determine the best transmission scheme to forward the media to UE (i.e. PtP/PtM).

NOTE 2: Currently, eNB does not determine PtP/PtM transmission for eMBMS bearer. Only PtM is supported.

8. When UE can receive the DL media using Multicast Delivery, it releases the Unicast Delivery session to the group server and indicates to GCSE AS that GC media is now using Multicast Delivery.

After Multicast Delivery Setup has been performed (i.e., GCSE AS has received service announcement information from BMSC), then GCSE AS can return the service announcement information to the subsequent UE(s) who wanted to participate to this GC without further interaction with MuSe function.

6.3.2.2 MuSe and Mobility handling

This solution requires the eNB to keep track of the UE Group Communication context (e.g. like TMGI and UE relationship) in order to start the Multicast Delivery at the target cell.

When a Multipoint Service (MuSe) is setup with Geographic Scope requirement, it is expected only those cell(s) which belongs to the geographical restricted area can perform the Multicast Delivery. When UE moves around those cells within the geographical restricted area, it is expected the multicast delivery session is not disrupted. As Geographic Scope is optional and may not be required for this MuSe then the Multicast Delivery session is maintain across the whole PLMN. When the UE moves outside the geographical restricted area, it will no longer receive the multicast delivery from the serving cell, and the UE may request the GCSE AS directly via GC1 to rejoin the GC if needed. If UE was using Unicast Delivery and moved into the serving cell where Multicast Delivery is possible (based on the UE detecting the TMGI is being broadcasted by the serving cell), the UE then informs the eNB of the TMGI(s) that it wishes to receive in order for the eNB to create the UE Group Communication context, and eNB then starts the DL delivery toward that UE using Multicast Delivery. When UE can receive the DL media using Multicast Delivery, it releases the Unicast Delivery to the group server and indicates to GCSE AS that GC media is now using Multicast Delivery.

The following are the high level steps for the mobility procedure:

1. During the Multicast Delivery setup procedure as defined in clause 6.3.2.1, the MBMS Session Start Message is sent only toward those eNBs that are within the geographical restricted area.

Those eNBs receive the TMGI and IP multicast address for this multicast delivery session.

2. UE which is participating in a multicast delivery session is always RRC connected. When a UE expresses its interest for Multicast Delivery, the eNB adjusts the radio parameters to keep the UE in long connected state.

3. Intra RAT PS HO is used for mobility procedure. Source eNB indicates the multicast delivery session(s) (i.e, TMGI(s)) that the UE is currently participating to the target eNB.

4. If target eNB has received the MBMS Session Start during the MuSe Setup procedure (step 1) then the received TMGI is known and can allocate the corresponding radio level parameter in the HO CMD for PtP/PtM reception at this target cell. Otherwise, the HO CMD will not contain any radio parameter for any of the TMGI and multicast delivery session will not be continued when UE is moved to this target eNB.

Figure 6.3.2.2-1 shows the above principles.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 26 Release 122T

eNB

( Source ) MME BMSC / MBMS GW

MBMS Session Start procedure

Media

UE eNB ( Target )

MBMS session Start Procedure a

b . Meas . Rpt

c . Intra E - UTRAN HO

d . HO CMD

HO to target eNb

Media

Media Media

Figure 6.3.2.2-1: Mobility Signalling flow within Group Communication area

a. During the MuSe setup procedure, the eNBs that are serving the GC are given the IP multicast address to receive the media from BMSC GW for DL distribution. Active GCSE UE is receiving the media from source eNB.

b-c. At some point, source eNB needs to invoke the intra E-UTRAN handover procedure based on e.g. Meas. Report, and with the following additions:

- Source eNB includes the TMGI(s) of the MBMS Services that the UE is currently receiving to target eNB in eNB to eNB transparent container.

- Target eNB, based on the received TMGI, responds back with the corresponding radio parameters for each TMGI in HO CMD for PtP/PtM reception at the target cell.

d. HO CMD is sent to UE and UE uses the radio parameters for each TMGI(s) to continue the receiving of the DL media from target cell for each GC.

6.3.2.3 MuSe with voice and video media handling

When a Multipoint Service requires different media type (e.g. voice and video) for the same Group Communication, a different Multicast Delivery session is allocated for each media type. Each of the Multicast Delivery session can have different QoS and bit rate requirements. However, they are linked to the same MuSe and can be independently removed at any time by the GCSE AS. The UE which has registered to this Group Communication will be given all the TMGI(s) and their corresponding media type via GC1; hence the UE can determine if certain Multicast Delivery session can be ignored.

The following are the high level steps for this procedure:

1. GCSE AS determines that a MuSe for a particular Group Communication will consist of more than one Multicast Delivery sessions in order to carry different media type.

2. GCSE AS setup a Multipoint Service with MuSe. It gives the QoS/bit-rate requirements for each Multicast Delivery session separately based on the requirement of the media type to be carried in each Multicast Delivery session.

3. MuSe creates the number of Multicast Delivery sessions as requested by GCSE AS.

Each Multicast Delivery session has its own TMGI which will be indicated to GCSE AS.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 27 Release 122T

4. When UE registers to GCSE AS for this Group Communication, the GCSE AS informs the UE of all the related TMGIs and their associated component type. For Multicast Delivery, UE can then decide which TMGIs to monitor from the serving cell. It means that the UE can choose which Multicast Delivery sessions it wants to be a part of within the Group Communication.

5. If a particular Multicast Delivery session for a GC is no longer needed, GCSE AS requests the MuSe to remove this Multicast Delivery session from this GC. GCSE AS can make that decision based on e.g. input from the group member and/or administrator who oversees this GC.

The above procedure can introduce delay toward the receiving group member who is using Multicast Delivery because the UE relies upon acquiring the information about the newly added media component from the MCCH. The MCCH can only be modified once every 5 or 10 seconds dependent upon the MBMS configuration (the rate of MCCH repetition is configurable between 320 ms and 2560 ms (see TS 36.331 [10])). This means that reception of the newly added component (e.g. video toward an existing voice group session) will be delayed until UE is able to decode the MCCH and acquires its radio configuration. The following new procedure allows the eNB to directly inform the current participating UEs of the Multicast Delivery radio configuration necessary to receive the newly added media; thus, eliminating any delays that are due to the UE relying upon changes to the MCCH and the constraints of the MCCH modification period.

UE eNB MME MBMS GW BMSC

2b. Secondary Session Start Response()

2a. Secondary Session Start Request(TMGI, linked TMGI, QoS)

1b. BMSC receives a request from GCSE AS for adding additional media toward an

ongoing group communication.

3. Secondary Session Start Request(TMGI, linked TMGI, QoS, IP multicast address)

4. Notification of a new session andSession Scheduling Info / Radio

Resource Re-configuration

Secondary media

GCSE AS

1a. MuSe Request (start additional media, Group ID, QoS,..)

2c. MuSe Request Resp (status)

New updated info (MCCH)

OLD info (MCCH)

MC

CH

modification period

Join to multicast session

Figure 6.3.2.3-1: adding an additional media toward an on-going Multicast Delivery session

1a-b. BM-SC receives a request from an GCSE AS for adding a media (e.g. video) on the existing GC session. BM-SC creates secondary MBMS session with the MBMS-GW. It allocates a new TMGI for the new session and also identifies the current active MBMS session by its TMGI which is referred to as "linked TMGI".

2a-c. BMSC creates a secondary MBMS session toward the MBMS-GW.

3. The MBMS-GW sends a secondary session request (TMGI, linked TMGI, QoS, IP multicast address for the new secondary MBMS session,) to the eNB that is serving the current active MBMS session. eNB joins the multicast session for secondary MBMS session and starts receiving the new media.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 28 Release 122T

4. In this solution, UEs which are participating in a GC via Multicast Delivery is always in RRC connected state. When eNB is aware of the secondary session due to step 3, eNB notifies each of those UEs via RRC signalling with the new radio related configuration of the secondary MBMS session (i.e., for the new media) such that UE can immediately start receiving the additional media via Multicast Delivery mechanism. eNB identifies the relevant UEs based on its internal stored context from the ongoing active session (i.e., UE and TMGI correlation).

NOTE: MCCH modification period is shown in the figure for completeness only. It has no bearing with the above proposal.



6.4 Solution 4 - GCSE architecture using IMS and eMBMS

6.4.1 Functional description

6.4.1.1 Solution description

The following are the salient features of this solution:

1. GCSE AS is an Application Server in the IMS.

2. SIP signalling is used for establishment, modification and release of GCSE GC sessions.

It is also used for joining and leaving pre-established GCSE GC sessions.

3. eMBMS is an optional feature for the RAN. If available, eMBMS is used for MuSe delivery on the downlink. The BM-SC function is may be stand-alone or collocated with the GCSE AS.

4. The solution allows for switching between unicast and eMBMS delivery for an ongoing GCSE group communication session.

5. Unicast bearers are used for uplink communication. In cells where eMBMS channel is not available, unicast is also used for the downlink.

6. In the context of this solution "GCSE group communication" is synonymous with a SIP session that is associated with GCSE Group ID i.e. a globally unique GCSE Group-specific SIP URI (e.g. [email protected] or a conference factory URI). The SIP session can be either pre-established or set up on the fly.

7. In one alternative of this architecture the GCSE AS is used as an IMS conference server as specified in TS 24.147 [9]. The "GCSE group communication" is synonymous with an IMS conferencing session.

8. The GCSE Application Server exchanges eMBMS-related control information with the BM-SC either via new reference point (GC2-C) or via the PCRF.

Editor's note: The use of PCRF and the functions provided by PCRF for interfacing between GCSE AS and BM-SC is FFS.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 29 Release 122T

6.4.1.2 Architecture reference model

Ut

UE A UE A UE

Gm

eN. SGW tGW

S1 - MME S11

S1 - U Uu

GCSE App

ISC

S5 SGi

aaE

M1 .aSC a.aS - GW

GCSE AS aRCt aRCC

tCRC

t/S - CSCC

GC2 - U

Gxsc

Rxsc GC2 - C SGmb

SGi - mb

IMS

New or enhanced reference points: Gm: This is an enhanced Gm. It relies on SIP signalling for establishment, modification and release of GCSE

group communication sessions, or for joining and leaving pre-established GCSE group communication sessions. Floor control is performed using BPCF [7] as specified in [z] or RTCP messages (e.g. like those defined in [6]).

GC2-U: This is the user plane reference point between GCSE AS and BM-SC for eMBMS delivery. GC2-C: This reference point may be used for exchange of control plane information between GCSE AS and BM-

SC for eMBMS delivery. Rxsc/Gxsc: This reference point may be used for exchange of control plane information between GCSE AS and

BM-SC for eMBMS delivery. Ut: In the IMS conferencing architecture alternative Ut is used to update group related information in the

GCSE AS e.g. group membership.

Figure 6.4.1.2-1: GCSE architecture based on IMS and eMBMS

6.4.2 Procedures

6.4.2.1 General

The procedures in the present clause are provided as examples only. The detailed call flows depend on the architecture alternative.

6.4.2.2 GCSE group communication procedures

6.4.2.2.1 Switching from unicast to eMBMS delivery for an ongoing GCSE group communication session

Outlined in Figure 6.4.2.2.2-1 is the control plane procedure for switching between unicast and eMBMS delivery for an on-going GCSE group communication session. It is up to Stage 3 to decide which IMS procedures to use.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 30 Release 122T

Figure 6.4.2.2.1-1: Switching from unicast to eMBMS delivery for an ongoing GCSE group communication session

1a.-1d. UE joins a GCSE group communication session. It is assumed that at this point there is no eMBMS channel for this GCSE Group in the cell where the UE resides. GCSE AS uses unicast delivery in the downlink (e.g. via the same EPS bearer that UE uses for the uplink or via a different EPS bearer).

2a.-2f. At some point GCSE AS decides to establish an eMBMS channel for this GCSE Group in this cell. In the user plane a specific GC is identified by the TMGI (if each GCSE Group is assigned a unique TMGI) or the combination of a TMGI and a UDP port number (in case GCs from several GCSE Groups are multiplexed on the same TMGI). As soon as the eMBMS channel is established, the GCSE AS starts sending data using eMBMS delivery. In parallel GCSE AS keeps unicast delivery to the UE over the EPS bearer as long as the UE has not switched to eMBMS.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 31 Release 122T

3a.-3d. GCSE AS uses SIP INFO to inform the UE about the availability of eMBMS delivery in the cell. The SIP INFO contains media description for delivery via the eMBMS channel i.e. a TMGI and possibly a UDP port number.

3e.-3i. UE acquires the eMBMS channel and acknowledges the channel acquisition to GCSE AS using SIP UPDATE. At this point GCSE AS may stop the parallel unicast delivery for this UE.

4a.-4j. At some point after step 3 GCSE AS may decide that there are not enough users in the cell anymore to justify eMBMS delivery. GCSE AS re-starts unicast delivery to the UE and informs the UE to switch to unicast delivery providing media description for unicast delivery over the EPS bearer.

Editor's note: In steps 2a and 4a, the decision function in the GCSE-AS whether to use establish or release eMBMS bearer and the correspondingly needed information are FFS.

6.4.2.3 GCSE Group membership procedures

6.4.2.3.1 Subscribing to a GCSE group

Subscribing to a group membership can be done through a SUBSCRIBE / NOTIFY mechanism. GCSE group identifier is a SIP URI identifier. UE's that are part of the group can SUBSCRIBE to that group.

Editor's note: Other mechanisms are FFS.

6.4.2.3.2 UE joining Group Communication

A UE device may join a pre-established GCSE group either by direct request or at the invitation of the GCSE AS.

Editor's note: The method through which the join is done is FFS.

6.4.3 Impact on existing entities and interfaces Editor's note: To be completed.


6.5 Solution 5 - Group communications with pre-established MBMS broadcast Bearers and multicast/unicast switching

6.5.1 Functional description These are the functional principles of this solution

- It is assumed the Public Safety device uses LTE only within the scope of this solution (the device may have other radio interfaces but these are out of the scope of this clause).

- Handling of GCs and group management at the application layer.

- Mapping of group of users to IP multicast addresses performed based on application layer criteria as a result of BMSC and application interaction.

- Distribution of traffic for multicast IP addresses via eMBMS broadcast to specific areas based on application layer criteria.

- As defined in TS 23.246 [8], UE's are not expected to use IGMP to receive multicast data on the eMBMS bearer.

- UEs can participate in application layer GCs either by receiving IP multicast packets by listening to the eMBMS broadcast associated to a TMGI the application notifies to the group members, or by receiving IP unicast packets.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 32 Release 122T

- The UE may directly notify the application when the TMGI-related channel is available in a cell or not and therefore cause the application to deactivate or activate unicast transmission to the UE, respectively.

- It is assumed that the broadcast groups are long term or could be created on demand. The UE can receive notification of groups available to it on the Unicast channel (using dedicated signalling with the applications) or by listening on a dedicated broadcast channel available over the whole PS network (e.g. a channel associated to a well known TMGI devoted to advertising the available communications groups in a particular area and related TMGI's).

- The system remains application neutral, except it may provide some PS optimizations for eMBMS.

- The support of inter-operator roaming is built into the solution as the PS applications are a third party to every operator the PS agency needs to have access to.

- Different PS applications may be available via the same PDN connection or different PDN connections.

- Optional optimization: UEs could be provisioned with Cell ID's constituting the boundary of the group distribution via application layer interaction (FFS) so that when the UE arrives at a cell where the switch between unicast and multicast is possible, the application may assist the UE to decide to switch the UE to/from BROADCAST from/to UNICAST reception, depending on criticality of not missing any communication or based on any exceptional cell load reported to the applications by the operator. This provisioning avoids the need of the UE to always report the cell where it is to the application and to report just when it enters or exist boundary cells. Alternately, ULI reporting may be active for the device and the location information reported to the application via Rx, however this assumes the UE is in RRC connected state for as long as this is needed to make this optimization work.

- Application layer signalling between the UE and the GC application is out of the scope of GCSE-LTE work item and shall be part of the definition of the applications using GCSE-LTE capabilities. However GCSE-LTE work item can provide application developers with guidance on how applications shall be designed, e.g. by means of informational flows.

In order to implement a solution with these attributes the following system architecture for GCSE-LTE is proposed.

UE eNB MBMS GW BM-SC GC

Application

MCE MME P-GW

Uu a1

a2

a3

SG-imb

SG-mb

PCRF

Sgc-U

Gx

S-GW

Sm S11 S5

S1-U

GC Application

Client/troxy

UE

troSe Communication

SGiRx

Sgc-C

GC Atplication

Client

Figure 6.5.1-1

When the UE uses unicast communications for DL traffic, the path is via the PGW SGi and the PCRF is providing the application with means to interact with the infrastructure via Rx interface.

When the UE uses multicast for DL traffic, then the BMSC is providing the application with means to interact with the infrastructure on the C-plane interface identified by Sgc-C., and the user plane is in the DL via the BMSC over the Sgc-U interface.

The uplink user traffic and both DL and UL application signalling with the UE is via the SGi. Optionally, available group advertisement can also take place on the broadcast channel.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 33 Release 122T

The application may establish dedicated unicast bearers to deliver content in unicast mode via the PCRF.

6.5.2 Procedures These flows are examples of UE-network interaction for this solution.

UEUE

5. Establish ea.aS bearers

1. Request TaGI+provide GC service area

2. TaGI Reserved+GC service area boundary cells

6. Establish ea.aS .earer

4.ea.aS Request bearer

7. .earer Response

11. Return TaGI for GC group(s) to UE+ opt. boundary cells list

10. UE Registers with GC Application and triggers unicast distribution

14.UE detects TaGI is supported in Cell and

uses .CAST DL

3. GC group to TaGI mapping acquired and service area boundary cell ID’s

known

8.Group Communication aulticast Traffic using ea.aS

Group Communication App. uses ea.aS bearers for DL

Group Communication App. uses ea.aS bearers for DL

tCRC .aSC GCApplicationEtS

9. UE turns GC application on

12. DL/UL bearer Establishment via tCRC

13.DL Group Communication UNICAST Traffic via tGW

15. UE requests GC app. To remove unicast leg for its It address

16. DL bearer Revocation via tCRC

14.DL Group Communication aulticast Traffic via .aSC

Figure 6.5.2-1: The UE initiates an application and eventually uses MBMS

In this Figure 6.5.2.1, the application is shown to set up the broadcast transmission path for the GC distribution, by interacting with the BMSC. The BMSC provides the Application with a TMGI, used over the radio to identify the broadcast transmission for the Group communication, and optionally a list of Cell ID's at the boundary of the service area of the broadcast communications. At this point the application has:

1) The mapping of the multicast IP address used for GC and the TMGI.

2) A list of cells at the boundary of the broadcast service area.

With this, the application can start sending DL data to the EPS via the BMSC over the Sgc-U interface. This interface is simply a user plane interface and the only way the GC application interacts with the BMSC is by providing the Multicast address in the IP packets it sends. So, it is really a purely user plane interface.

In step 9 the UE is powered on and it registers on the user plane with the application server for the GC, using protocols and procedures outside 3GPP scope. As part of these procedures, at step 11 the UE obtains the TMGI of the used for

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 34 Release 122T

broadcast communications, and optionally a list of the cells it is required to report to the application upon entering and exiting.

For sake of argument we suppose the UE was not in coverage area where the Broadcast communication was available, so the application server was triggered to send DL packets using a DL bearer it can establish via the PCRF (if a dedicated bearer was required, otherwise the UE shall receive the DL traffic on the default bearer already available).

Upon mobility, the UE enters a cell where broadcast transmission of the TMGI provided to it by the GC application is available. So at that stage the UE decides to join the broadcast distribution and asks the network to release distribution via its unicast IP address.

Using similar approaches, the flow in the figure 6.5.2.2 here below describes the switching between broadcast and unicast mode, based solely on TMGI detection in the cell.

UEUE

3. UE triggers unicast distribution

6.UE detects TaGI is supported in Cell and

uses .CAST DL

2.DL Group Communication aulticast Traffic using ea.aS


0. UE already registerd witha GC application and has the related TaGI and

boundary cell ID’s






1.DL Group Communication aulticast Traffic Using ea.aS

2. UE detects loss of TaGI

Figure 6.5.2-2: The UE switches from broadcast to unicast and vice-versa

The detection of loss of TMGI is an event that can potentially cause disruption of communication. Unlike in the case where the UE is using unicast traffic and then it switched to eMBMS, there is potentially a time interval (up to 5-10 second in the worst case) where the UE may lose the DL data. This may not be too critical in certain application, but in some others it could be critical. Therefore a potential optimization is based on the UE detecting the boundary of a service area beyond which the TMGI is not offered. This is via a cell ID list provisioned on the UE or provided at registration time (or downloaded in the UE upon registration triggering it). This list may also be updated dynamically or also broadcasted on the MBMS channel specific to an application.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 35 Release 122T

If the UE was using MBMS and arrives at a cell in the boundary list, as it triggers the application to assist it in whether it should switch to unicast or not, it may take decisions to proactively switch to unicast. Also, the UE notifies the application when it leaves the cell and whether it moves to a cell with TMGI support or not. The application, based on consideration related to load from this cell (maybe also based on counting the number of UE's that triggered the assistance and have not yet updated the application they have left the boundary cell, but also maybe based on cell congestion feedback from the PCRF - if any was available after the UPCON work is complete), criticality of not losing data in DL, and other possible criteria related to the specific application, could decide to hint or request the UE to switch to unicast while it is still receiving the broadcast data. Here is an example flow in figure 6.5.2.3:

UEUE

3. UE triggersGC application assistance

6.UE exits cell and detects TaGI is not

supported in Cell



0. UE already registered with a GC application and has the related TaGI and boundary

cell ID’s






1.DL Group Communication aulticast Traffic Using ea.aS

2. UE detects it has entered a boundary cell

4. GC application triggers switch to unicast

5. UE triggers unicast distribution

7. UE updates it is no longer in boundary cell and it is using no ea.Sa

8. UE detects it has entered a boundary cell

With TaGI support 9. UE triggersGC application assistance 10. GC application triggers switch to broadcast

Figure 6.5.2-3: The UE switches from Broadcast to Unicast and vice-versa using application assistance

The amount of messages required when the applications provide more intelligence in switching is greater, however the advantage is that the decision to switch to unicast/broadcast is controlled by the application. If the application server is also shared by many applications, it allows coordinated decisions for multiple applications. It should also be noted the UE may take unilateral decisions in the direction unicast- broadcast if network control was not necessary in this direction, but still the need to update the GC application on this decision would be relevant to keep accounting of the number of users in a cell.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 36 Release 122T

6.5.3 Impact on existing entities and interfaces This solution has minimal impact on the existing system:

The only impact identified is that the interface between the BMSC and GC applications needs to be standardised


6.6 Solution 6: MuSe with configurable geographic scope

6.6.1 General description This solution addresses the requirements relating to the geographical scope of GCSE Group Communications as specified in clause 5.2.2, TS 22.468 [3]. In addition, the following requirement relating to the Key Issue #3: MuSe with Geographical Scope, is also addressed by this solution:

- When requested, a notification shall be sent to a requesting entity when the group member ceases to participate in the communications from the GCSE group, i.e. in case of a group with restricted geographic scope when the group member leaves the Group's Service Area.

This solution builds over the "GCs using pre-established eMBMS bearers" solution described in clause 6.1.

The solution in clause 6.1 proposes the use of PCRF as the interface between the GCSE AS and the BM-SC for the exchange of MBMS control information. This solution does not have such restrictions on the placement of the PCRF. The methods for the implementation of the C-Plane and U-Plane components of the GC2 reference point is FFS.

Editor's note: Implementation of GC2 reference point is FFS.

The signalling procedures between the UE and the GCSE AS (over GC1 reference point) can be based on IMS-style signalling as described in the solution in clause 6.4.

6.6.2 Procedures

6.6.2.1 Group Communication within configured Geographic Service Area

This solution provides the following capabilities in addition to the capabilities provided by the solution in clause 6.1:

1. By default, each GCSE Group is of system wide scope. This solution provides the capability (e.g. to the Users) to configure Geographic Service Areas for each GCSE Group within which GC services are to be provided.

2. It is also possible for the Users to reconfigure the Geo Service Areas for the GCSE Group(s).

3. This solution assumes that the Users (such as Public Safety, Dispatch Services) have a relationship with the 3GPP system operator whereby Geo Service Areas have a predefined mapping with the corresponding EPS MBMS Service Areas, such as in terms of the lists of MBMS Service Areas. For example, a Geo Service Area may comprise of sub-Areas A, B, C, ..., each of which is pre-mapped to a corresponding List A, List B, List C of MBMS Service Area Identities (MBMS SAIs).

Editor's note: How Geo Service Areas are mapped to MBMS Service Areas is FFS.

4. Such mapping of Geo Service Areas to EPS specific MBMS Service Areas is done by appropriate configurations within the EPS. Such configurations ensure that MBMS Service Areas are not larger than the corresponding Geo Service Areas.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 37 Release 122T

GCSE ASauSeEtSUE 2UE 1

4. UE1 Resisters (Group ID, Location=A, It Address ..)

1. Request TaGI(s) (GCSC Gt ID(s), Geo Service Area(s))

2. TaGI(s) Reserved (TaGIs, a.aS SAIs ..)

9. Cloor Request and Cloor Grant (Group ID ..)

16. GCSE Service (Group ID, a.aS SAIs, ..)

5. Return TaGI (TaGI, a.aS SAIs ..)

10. Unicast .earer Established

11. UL Communication via Unicast delivery

7. GCSE Notification (Group ID, TaGI, within a.aS Service Area Inidication ..)

8. UE2 at Location . Attaches. Turns on Gt-1 Application.Registers with GCSE AS (Group ID, Location=., It Address ..)

Return TaGI (TaGI, a.aS SAIs ..)GCSE Notification (Group ID, TaGI, within a.aS Serving Area Indication ..)

25. Unicast .earer Established: UE1 at Location=C

26. DL Communication with UE1 at Location=C via Unicast delivery

3. UE1 at location A Attaches. Turns on Gt-1 App.

17. DL Group Communication (Gt ID ..)

19. DL Group Communication using auSe .earer

20. UE1 detects TaGI for Gt-1. Acquires auSe bearer

21. Remove unicast bearer for UE1

23. UE1 Notifies GCSC AS about loss of auSe (Group ID, Loc=C, outside a.aS Service Area indication ..)

24. Loc C within Geo Service Area. GCSE AS decides to provide DL communication to UE1 using Unicast bearer

6. UE1 detects a.aS SAI at current location within

a.aS SAI list

18. Establish auSe bearers

13. Unicast .earer Established: UE1 at Location=A

14. DL Communication with UE1 at Location=A via Unicast delivery

22. UE1 moves to Location C, outside the a.aS SAI list, and/or No TaGI for Gt-1 detected

12. GCSE AS may decide to provide Unicst bearer, based on application requirements while auSe bearer is being established..

15. .ased on notification at Step 7, GCSE AS decides to provide DL Group Communication using auSe

Figure 6.6.2.1-1: Geographic Service Area configured for a GCSE Group

Some salient enhancements of this solution over the solution described in clause 6.1 are as follows:

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 38 Release 122T

1. (Steps 1-2): When requesting the TMGIs for GCSE Group(s) from the MuSe function, the GCSE AS includes the Geo Service Area(s) for the respective GCSE Group (s) also in the request message. The mapping of Geo Service Area(s) to the corresponding MBMS Service Area(s) and associated TMGI(s) are made available to the GCSC AS. The GCSE AS maintains such mapping of the GCSE Group IDs with their associated TMGIs and MBMS Service Areas(s) e.g. in the terms of the lists of MBMS SAIs.

2. (Step 3-4): After a UE attaches to the EPS, turns on a GCSE application and registers with the GCSE AS; in addition to sending the GCSE Group ID to the GCSE AS, the UE includes its location information also in the registration message.

NOTE 1: The location information passed by the UE to the GCSE AS can be in terms of Geo Area A, Area B etc. that is understood by the GCSE AS.

NOTE 2: It is assumed that the GCSE Group ID(s) corresponding to the GCSE Application(s) is preconfigured at the UE. The details of such configuration procedures is FFS.

3. (Step 5): The GCSE validates that the requesting UE is located within the allowed Geo Service Area before returning the TMGIs for the GCSE Group(s) and the associated MBMS Service Area information to the UE. In addition to saving the TMGIs for the GCSE Group(s), the UE saves the associated MBMS Service Area information also. This way, the UE can know when it moves out of the configured MBMS Service Area.

NOTE 3: Validation of the location of the registering UE ensures that the Transmitting and the Receiving Members are within the configured Geo Service Area.

4. If the Geo Service Area(s) of a GCSE Group(s) is/are reconfigured, the GCSE AS updates its cached mapping of the new Geo Service Area(s) to the respective new MMBS Service Area(s) by performing the TMGI request procedure again with the MuSe function. The GCSE AS pushes such new/updated MBMS Service Area(s) information to all registered GCSE Group Members using the procedure such as those described in Step 5.

5. (Steps 6-7): UE reads the TMGI Information and determines that it is currently located within the MBMS Service Area for the GCSE Group of interest. UE notifies GCSE AS accordingly, including the within MBMS Service Area indication and the TMGI.

6. (Step 12-14): The solution in clause 6.1 proposes the pre-establishment of the MBMS bearers over the MBMS Service Area(s). As a difference, this solution does not propose such pre-established MBMS bearers. The GCSE AS can provide DL communications to the UEs via unicast bearers till such time that MBMS bearers are established and acquired by the respective UEs.

NOTE 4: The time taken for the setting up the MBMS bearers, the nature of the applications, latency requirements, number of receiving members etc. can be the factors for consideration by the GCSE AS for making the decision about when to set up the MBMS bearers.

7. (Steps 16-18): Once the GCSE AS decides to provide DL GCs via MuSe; the GCSE AS passes MBMS Service Area information (e.g. list of MBMS Service Area Identities) where MBMS based services are to be provided to the MuSe function via. GC2 reference point. The MBMS Service Area information ensures that DL MBMS based GC is restricted to a geographic area of interest.

8. (Steps 22-23) When a UE moves to a new location and determines that it is out of the MBMS Service Area, the UE notifies the GCSE AS of its new location and the loss of MBMS transmission indication for the GCSE Group of interest. On verifying that the UE at the new location is still within its configured Geo Service Area or that the UE is authorized to continue in this GC from the new location, the GCSE AS can decide to provide DL GC using unicast bearer(s).

9. If the GCSE AS determines that UE at the new location has moved outside the Geo Service Area; such information can be used by the GCSE AS for generating Notification to the requesting entities, informing that the UE (group member) has left group's Service Area. This addresses the requirement related to sending notification to the requesting entity, as has specified for Key issue #3.

6.6.2.2 Group Communication with geographic service area override and filtering

This solution provides the following capabilities in addition to the capabilities provided by the solution in clause 6.1:

1. It is possible for the system to override geographic area restrictions for a GCSE Group for a particular GC transmission for its Receiving Members. A Transmitting Member initiates modify Geo Area Request that

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 39 Release 122T

includes parameters such as "override location:abc", to the GCSE AS. Alternatively, such "override" request can be initiated by the "dispatcher" entity at the GCSE AS.

2. The system also provides a mechanism to restrict a particular GC to a sub-geo area within the geographical scope of that group. In this case only the Receiving Members that are within the sub-geo area receive the GC. Such restriction for Receiving within a sub-geo-area can be initiated by the "dispatcher" entity at the GCSE AS also.

13. DL Group Communication: Selected aedia in Areas . and C using auSe .earer

9. aodify Geo Area Request/Response (Group ID, opt Cilter Areas ., C, opt filter aedia Type ..)

11. aodify GCSE Service Area (Group ID, a.aS SAIs for Geo Areas ., C , aedia Type ..)

12. aodify auSe bearers



GCSE ASauSeEtSUE 2UE 1

Steps 1-8 same as illustrated in Cigure 6.6.2.1-1

10. GCSE AS modifies the DL Group Communication area to be limited to Areas . and C based on filter criterion from UE1. Such filtering of Group Communications can also be initiated by the GCSC AS autonomously, such as for Dispatch Services.

Figure 6.6.2.2-1: GC with Geographic Service Area filter

Some salient enhancements of this solution over the solution described in clause 6.1 are as follows.

1. (Steps 9-11): In the Modify Geo Area Request signalling to the GCSE AS, the UE includes parameters such as "Filter Areas: B, C" asking for the following instances of GC transmissions to be limited to Geo Areas B and C only. The request may include filter-Media Type(s) information also indicating the types of the media that need to be delivered in the limited Geo Area(s). On validating that the UE is authorized to make such a request, and that Geo Areas B and C are a subset of the Geo Service Area for this Group, the request is granted.

2. For the case of overriding the geographic area restrictions, the UE includes parameters such as "Override location:abc" in the Modify Geo Area Request signalling to the GCSE AS. On validating that the UE is authorized to make such an override request at the location identified by "location:abc:", the request is granted. Such "override" procedure is not detailed in this illustration.

3. (Step 12): The GCSE AS decides to provide DL GC within the filtered-Geo Service Area (Geo Areas B and C) based on filter criterion received from the UE. Alternatively, the GCSE AS may apply geographic filtering on specific instances of GC based on local policy. Such DL GC within "filtered Geo areas" can also be initiated by the GCSE AS autonomously, such as for Dispatch Services. Knowing that certain UEs are registered within the filtered Geo Area, and other factors such as number of registered users etc., the GCSE AS decides to provide DL GC via MuSe.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 40 Release 122T

4. (Step 13): The GCSE AS passes MBMS Service Area information for Geo Areas B and C (e.g. list of MBMS Service Area Identities for Geo Areas B and C) where MBMS based services are to be provided and the desired Media Type information, to the MuSe function via. GC2 reference point.

Editor's note: Describes the high-level operation, procedures and information flows for the solution.



6.7 Solution 7: Assign and Re-assign Priority and Pre-emption capability for the GC

6.7.1 Solution description

6.7.1.1 General

This solution addresses key issue 8 and clarifies how to assign/re-assign Priority and Pre-emption for GC.

The priority level defined on the application level is for priority and pre-emption purpose. In the EPS QoS model the ARP parameter is used for the same purpose and contains information about the priority level, pre-emption capability and pre-emption vulnerability. So the application level priority is mapped to the ARP parameter under the consideration of the specific GC. The concrete mapping is specific to the respective EPS network and operator.

The priority level mapping between application priority and EPS QoS parameter is performed in the EPS network based on policy information preconfigured in the BM-SC, PCRF or a group related subscription. All can provide the linkage between the priority level(s) of the GC and the associated EPS QoS (ARP) parameter(s).

Group Members within a GCSE Group are permitted to have different priorities. It is required that the uplink traffic, i.e. the traffic from UE to GCSE AS, can reflect the user priority in the GC. In that case, the GCSE AS informs the EPS about group member related priorities, the EPS shall take this into account when mapping to the ARP parameters for the uplink traffic. For the downlink traffic only the GC priority needs to be reflected.

GC may have different media, e.g. voice/image. In such case, the media belonging to the same GC may have different priorities. If the GCSE AS informs the EPS about media related priorities, the EPS shall take this into account when mapping to the EPS QoS (ARP) parameters. For a particular downlink media within a PLMN the priority level should however be the same no matter which transport path (i.e. unicast or multicast) is selected.

6.7.1.2 Session Setup Procedure

UE may send GC1 signalling over default EPS bearer, or bearer carrying IMS signalling (if IMS is used for GCSE). To avoid Group Communication failure in case network resources are limited, the ARP of the bearer used for GC1 signalling needs to be upgraded. The GCSE AS requests the PCRF to upgrade the ARP of the EPS bearer used for GC1 signalling, when GC1 registration is performed, if needed (e.g. in case that the GCSE Group is configured with higher priority).

For the unicast delivery the GCSE AS sends the Media Component information, Priority, user's priority to the PCRF via the Rx interface. Based on those parameters PCRF maps the received application layer priority to the EPS level ARP parameter and sends to the PGW.

For the muliticast delivery, the GCSE AS need to send the Media Component information, Priority, the group communication service ID, to the BM-SC via the GC2 interface. Based on those parameters the BM-SC maps the received GC priority parameter into the EPS level QoS (ARP) parameter. When the eMBMS bearer is to be setup, the mapped ARP parameter is included.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 41 Release 122T

6.7.1.3 Session update Procedure

For the priority change it can be categorized into two types:

1. Per UE granularity update triggered by the GCSE AS .The typical use case is that the user's group member priority has been changed. The updated user's priority information is received by the PCRF. Based on that information the EPS QoS parameter is updated

2. Per Group granularity update. It is required that the Group Communication priority level can be reassigned.

To update the ARP parameter of a unicast bearer, the procedure defined in the clause 5.4.2.1 of TS 23.401 [5] is used. If one group priority is changed and the unicast bearer is to be updated, the GCSE AS triggers the session modification per UE via the Rx/Gx interface.

For the MBMS bearer the QoS parameter is not supported to be updated per TS 23.246 [8]. To update the ARP parameter, two procedures are possible.

- Enhance the existing MBMS Session Update procedure defined in the clause 8.8.4 of TS 23.246 [8]. The BM-SC sends the Session update Request message to the MBMS-GW including the updated ARP parameter. If the distributed MCE architecture is deployed, it also needs to ensure the update is synchronized among the different eNBs in the same MBSFN area.

- New TMGI replace the old TMGI. The BM-SC establishes a new MBMS bearer service with the updated ARP parameter. After the new MBMS bearer has been established successfully, the BM-SC notifies the new TMGI to the GCSE AS. By that the GCSE AS can notify the interested UE to replace the old TMGI with the new TMGI via GC1 interface. The old MBMS bearer can be kept for a configured time to assure all the interested UEs have been notified.

6.7.1.4 Session Release Procedure

One UE can join multiple GCs simultaneously. All the signalling traffic from UE to the GCSE AS may share the same connection, i.e. EPS bearer. It is required that the bearer used for the signalling traffic always reflects the priority of the highest uplink GC traffic. When a GC bearer is released, the PCRF needs to check the priority of the IP flow of the signalling traffic and update the corresponding PCC rule if the highest uplink GC traffic has been changed.

In the congestion case the bearer used for GC service may be released.

- For the unicast delivery if the GC bearer is released the GCSE AS can get the release notification. It depends on GCSE AS logic on how to handle this case.

- For the multicast delivery the MBMS bearer is 'suspended', i.e. packets are dropped in eNB without any message sent from eNB to BM-SC. The interested UE can detect the related TMGI is removed from MCCH. The UE shall treat this scenario in a manner the same as an MBMS to unicast switch (non make-before-break) as described in clause 6.1.2.2.3. It depends on GCSE AS logic how to handle this case.

NOTE 1: MBMS bearer service resumption, if and when pre-emption is no longer necessary, can be treated in the same manner as the currently agreed procedure for switching from unicast to MBMS (clause 6.1.2.2.4).

NOTE 2: The MBMS service area may consist of more than one MBSFN area (i.e,. controlled by multiple MCEs). Hence, this solution only indicates that a MBSFN area where the UE is currently residing is not transmitting, and does not necessarily mean the whole MBMS service area is affected.

6.7.2 Impact on existing entities and interfaces There are no impacts on the PGW. The additional functionalities on the PCRF/BM-SC are listed as below,

PCRF

- Assure the priority of the GC signalling IP flow always reflects the highest priority of the uplink GC communication UE involved.

BM-SC

- Support the priority change of the MBMS bearer.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 42 Release 122T

For Rx interface the following parameters need be sent from GCSE AS to PCRF:

- Media Component information (e.g. media type, bandwidth).

- Priority.

- User's group member priority.

For GC2 interface the following parameters need be sent from GCSE AS to BM-SC:

- Media Component information (e.g. media type, bandwidth).

- Priority.

- Group Communication service ID.

6.7.3 Solution evaluation This solution addresses the key issue#8 'Priority and Pre-emption on Group Communication'. It has the following advantages:

- Reuse the existing EPS ARP parameter.

- The mapping between the application level priority and EPS layer priority is performed in the EPS network and under the operator's control.

- UE can join multiple Groups sharing the same EPS bearer for Group Communication signalling.

- Group members within a single GCSE group can have different priorities, which is also reflected on the EPS network.

- Support the priority change on the MBMS bearer.

6.8 Solution 8: Service continuity from unicast to multicast delivery

This solution is related to Key issue #5 "Service Continuity".

6.8.1 Functional Description This solution for service continuity from unicast to MBMS delivery proposes a 3GPP network-oriented approach to inform the UE about the established MBMS bearer service related to the GC received currently over unicast delivery.

The following are the main principles of this solution:

- The MME maintains UE context containing the GC service ID (GC-ID).

- The MME maintains MBMS bearer context containing GC service ID (GC-ID).

- Upon a handover of a UE into a cell which supports MBMS delivery for the GC service currently received over unicast, the MME indicates to the UE the TMGI of the GC service, so that the UE can join the MBMS delivery.

6.8.2 Procedures Figure 6.8.2-1 shows the procedures for service continuity when the UE is connected to a cell which provides multicast delivery (i.e. eMBMS bearer service) of the GC service which is currently received via unicast delivery. It is proposed that the MME maintains a UE's context including the GC service identifier (GC-ID or APN). Upon handover, the MME determines that the GC service currently received over unicast bearer is distributed over eMBMS bearer in the target cell.

The thick arrows in Figure 6.8.2-1 show the data flow and the thin arrows show the signalling flow between the functional entities.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 43 Release 122T

UE

eN.2 (target) (a.aS)

eN.1 (source)

(non - a.aS) aaE .a - SC /

a.aS GW GC - AS

(3) UE performs HO from eN.1 to eN.2

(6.2) GC - AS terminates unicast delivery

(5) UE scans for ea.aS

service

(6.1) Informs GC - AS about multicast reception

(4) aaE indicates TaGI to UE

(5.1) UE joins ea.aS bearer service

GC with unicast delivery to UE (via eN.1)

(1) UE indicates GC - ID (e.g. AtN) to aaE during GC service setup

(2) aaE stores GC - ID in a.aS bearer

context

a.aS bearer establishment (via eN.2)

GC with unicast delivery to UE (via eN.2)

broadcasting

receiving GC service over aR.

Figure 6.8.2-1: Service continuity when UE moves into eMBMS service area


- In step (1) the UE establishes GC service over eNB1. The UE learns the GC service ID form the GC-AS and informs the MME with GC-ID over NAS exchange. As eNB1 is not part of the eMBMS bearer service (or no eMBMS bearer service has been established yet), the GC service delivery is via unicast bearer. The MME stores in the UE's context the GC service identifier (GC-ID, e.g. APN, session ID). Optionally the UE may indicate a GC-ID for the specific GC service. From the UE's point of view, the eMBMS bearer service can be seen as pre-established prior to the handover procedure.

- In step (2), the MME stores in the MBMS context the Group service identifier (GC-ID). The MME is able to map the relation of the GC-ID of the unicast bearers with the multicast MBMS bearer identifier.

Editor's note: It is FFS how the MME is provided with the GC-ID in the MBMS bearer context.

- In step (3) the UE performs an inter-eNB handover from eNB1 to eNB2 according to TS 23.401 [5]. After the handover procedure the UE receives the GC service data over unicast delivery via eNB2.

- In step (4), the MME determines that the GC service, which the UE receives over unicast EPS bearer, is provided by the eMBMS bearer in this cell. The MME indicates to the UE that the GC service can be obtained via eMBMS bearer service, e.g. MME indicates the TMGI of the eMBMS bearer service.

- In step (5) the UE starts scanning the broadcasted cell system information (SIB) to discover the radio resources for the eMBMS bearer service.

In step (5.1) The UE initiates procedures to join the eMBMS bearer service as described in TS 23.246 [8]. After steps (5) and (5.1) the UE is able to receive the GC service via eMBMS bearer service.

- In steps (6.1) the UE uses application-level signalling to inform the GC-AS about the ability to receive GC service data over multicast delivery. In step (6.2) the GC-AS can acknowledge the reception of the message in step (6.1) and to terminate the transmission of GC service data over unicast delivery.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 44 Release 122T

The procedures described in Figure 6.8.2-1 are also applicable to the case where the eMBMS bearer service is established after or during the UE receives the GC service data over unicast delivery. After the eMBMS bearer service is set up, similar to step (4) in Fig. 10, the MME determines that the unicast EPS bearer established for GC service over eNB1 is used for the same service as the newly established eMBMS bearer service in eNB1's cell. The MME indicates to the UE that the GC service can be obtained via eMBMS bearer service, and more specifically the MME indicates the TMGI of the eMBMS bearer service.

6.8.3 Impact on existing entities and interfaces Impacts to UE:

- Support transfer of MBMS-related information (TMGI) over NAS protocol.

Impacts to MME:

- Support transfer of MBMS-related information (TMGI) over NAS protocol to UE.

- Supports the reception and storing of Group session ID in the MBMS bearer context.

Impacts to BM-SC / MBMS-GW:

- Support the forwarding of Group session ID to the MME over SGmb and Sm interfaces.

6.8.4 Solution evaluation Editor's note: The fulfilment of requirements in clause 4 needs will be evaluated.

6.9 Solution 9: Group Management and associated user interaction

Group Management and associated user interaction for GCSE_LTE involve functionality and performance solution considerations at the application level and the EPS level.

Editor's note: Group management contexts for the EPS level are FFS.

6.9.1 UE and GCSE AS roles and requirements Specific Group Management functionality and associated user interaction can be handled at the application layer. The corresponding procedure and procedure between the UE and GCSE AS via GC1 is out of scope for Rel-12.

The specific group Management functionality considered in this solution is:

- group creation and group membership control and associated user interaction (adding/removing member), encryption key refreshment.

- notifications when group communications start, ability of user to accept/reject/ignore (and for the system to require a user to accept) a group communication.

6.9.2 Group management not at BM-SC level In order to avoid membership management control at the BM-SC level (i.e., aware of who is being added or removed for a particular GCSE group), the eMBMS security procedure (TS 33.246 [12]) is not used for this purpose. The GCSE media encryption (if required) is provided at the application layer by the GCSE AS, and GCSE AS is responsible to ensure the removed member will not be able to listen in to the media provided by Mulitcast Delivery (e.g. based on application specific methods). There is no requirement toward GC2 with this approach.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 45 Release 122T

GCSE ASUEGC1

BM-SC

GC2

No additional encryption provided by BM-SC for the media received via GC2 (i.e, eMBMS security is not used)

Media is encrypted based on application specific method

Figure 6.9.2-1: GCSE media encryption may be provided by the Application layer

NOTE: eMBMS security in addition to the encrypted GCSE media from GCSE AS should be possible.

6.9.3 Solution evaluation - Any group management happening over the GC1 between the UE and GCSE AS is out of scope of this study,

includes group creation and group membership control and associated user interaction, notifications when group communications start, ability of user to accept/reject/ignore (and for the system to require a user to accept) a group communication, membership control (delete or adding member).

Editor's note: How Group Management at the application level could affect the EPS level (e.g. does MME/eNB/PGW/PCRF needs to be GCSE group aware and for what purpose) is FFS!

- GCSE media encryption (if needed) may be provided by the Application layer. The encryption requirement (and key refresh, etc) becomes an application level requirement.

NOTE: This proposal avoids BM-SC to have GCSE group membership awareness; hence, no impacts toward GC2 for group management purpose. The overall security aspect will be subjected to SA WG3 analysis.

6.10 Solution 10: Using pre-established eMBMS bearers as generic multicast delivery bearer

When the eMBMS bearer is pre-established for the purpose of serving multiple GCSE groups, the following procedures are used:

- terminals interested in different group communication and waiting for possible broadcast session to start would all monitor this same generic pre-established eMBMS bearer. The identity for this bearer (e.g. TMGI) and identification of the relevant group communication (e.g. UDP port#) and associated decryption keys are done based on the application layer signalling between GCSE AS and UE.

- once a session for a given service starts:

- its data is broadcast for some time on the generic bearer (and hence received by all terminals monitoring this bearer); the precise identity of the service in question is signalled in-band as part of the scheduled data. It is assumed that the terminals not authorized to receive the service content will not have the keys to decipher the content.

- eventually, for the service with session starting a separate broadcast bearer of its own is established, identified with its own identifiers, at which point the broadcasting of the data moves from the generic bearer to the service-

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 46 Release 122T

specific bearer. (The receiving terminals will notice this from the appearance of the service in question on the MCCH channel). This is to stop draining the batteries of terminals not addressed by the service in question.

- This way, only one such generic bearer per MCH channel (characterized by the same set of cells, same set of reserved subframes, and same modulation and coding used in transmission) needs to be kept pre-established and group-specific broadcast bearers can still be set up only on need basis.

6.10.1 Solution evaluation Editor's Note: The fulfilment of requirements in clause 4.2 needs will be evaluated.

Same as solution 6.1 with the following additions:

a) the pre-established eMBMS bearer may be required to be in a much bigger area in order to account for multiple GCSE groups with different geo-graphic requirements.

b) GCSE AS needs to send data to both multicast delivery sessions (pre-established and dedicated eMBMS bearers) for transitioning period (i.e., allow UE to switch the DL reception with the dedicated TMGI).

c) UE needs to monitor the availability of the dedicated eMBMS bearer in order to switch the DL reception from the dedicated eMBMS bearer when available.

d) more UE battery consumption when the pre-established eMBMS bearer is deployed with GCSE groups being multiplexing into single TMGI.

6.11 Solution 11: Scalability above the SGi reference

6.11.1 Functional Description Having just one Group Call Application Server that serves all users of all groups and all Public Safety services across a whole country is likely to be impractical and/or undesirable.

For the purposes of 3GPP Release 12, it is assumed that:

a) A GCSE-AS may (or need not) be shared by multiple Public Safety bodies.

b) One GCSE Group is only handled by one GCSE-AS.

c) In the context of one MBMS session (one TMGI), one GCSE AS can only be connected to one BMSC, and vice versa. For networks (e.g. with large geographic scopes) that use multiple BM-SCs and have GCSE Groups that need to span the BM-SC boundaries, the GCSE AS can establish a separate (duplicate) multicast session with each BM-SC and the group members can monitor the separate TMGIs allocated by each BM-SC.

d) Multiple GCSE-ASs may be connected to the BM-SC and PCRF, while respecting the restriction in bullet c) above.

e) Typically the UE registers to just one GCSE-AS for all its GCSE Groups, but, in some circumstances (e.g. the user is a member of a national security agency group and is joining a local/county police group), the UE may need to register with more than one GCSEAS.

In the future, beyond 3GPP Release 12, it is envisaged that:

i) A GCSE-AS to GCSE-AS interface is specified that allows groups hosted on different GCSE-ASs to be joined together (e.g. a group of firemen hosted by one GCSE-AS are - on a per task/incident basis - linked to the appropriate group of policeman; or groups in adjacent European countries are temporarily linked to handle an incident on their border).

6.11.2 Impact on existing entities and interfaces The consequences of a network having multiple BM-SCs needs to be verified.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 47 Release 122T

6.11.3 Solution evaluation - from c) in clause 6.11.1, one MBMS session is supported by one BM-SC and one GCSE-AS.

- from c) in clause 6.11.1, to handle networks with multiple BM-SCs (and GCSE Groups that span their boundary) the GC2 interface will need to be able to connect multiple BM-SCs to one GCSE-AS.

- from d) in clause 6.11.1, to handle large numbers of MBMS sessions the GC2 interfaces will need to be able to connect multiple GCSE-ASs to one BM-SC.

- from e) in clause 6.11.1, the UE may need to connect to more than one GCSE-AS simultaneously. It is assumed that this can be supported by the UE on a single default bearer, and, is supported by existing IMS functionality.

7 Evaluation Editor's note: this clause contains the overall evaluation of various solutions.

7.1 Common approach The following architecture diagram shows a composite view of different solutions from clauses 6.1 to 6.5.

UE GCSE ASGC1

BM-SC

GC2

E-UTRANM1

SGi

S/P-GW

MBMS-GWSgi-mbSGmb

MME

SmM3

HSS S6a

S11

Uu

PCRF Rx

Gx

Figure 7.1-1: Composite view of different solutions on GCSE

When analyzing the different solutions from the present document (clauses 6.1 to 6.5), the following principles were common among those and shall be used to form the base-line solution.

1. Use of BM-SC and MBMS-GW in the core network for Multipoint Service.

2. GC2 is used to request the setup of the Multipoint Service. GC2 consists on both user plane and control plane components.

3. GC1 is used by the UE for GCSE group registration and to relay eMBMS related info, and for signalling to the GCSE AS for the purpose of service continuity . No protocol work is expected on GC1. It is shown for completeness only.

4. GCSE AS determines if DL media for a particular GCSE group communication (or UE/Receiving group member) is using Unicast Delivery or Multicast Delivery.

5. UL traffic is always done via unicast.

6. Multipoint Service is to be realized using eMBMS (TS 23.246 [8]).

7. Reusing the existing EPS QoS parameters.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 48 Release 122T

7.1.1 GC2

7.1.1.1 Information exchanged between GCSE AS and BM-SC

The following information needs to be exchanged between the GCSE AS and BM-SC on the GC2 control plane interface:

From BM-SC to GCSE AS:

- User Service Description (USD) of the MBMS User Service established by the BM-SC (which contains information about the media including serviceId, TMGI, multicast address/port of media, etc.)

- Information regarding the bearer establishment state.

- Information needed to route media packets from GCSE AS to the BM-SC (e.g. IP address(es), port(s)).

From GCSE AS to BM-SC:

- Area where the group call is targeted (identified by MBMS SAI(s) defined in TS 23.003 [13] or ECGI(s) defined in TS 23.003 [13]).

- Session information (e.g. Media Component information (e.g. media type, bandwidth), Group Priority, Group Communication service ID, etc.).

NOTE: The impacts to GC2 related to eMBMS security will be studied by SA WG3.

7.1.1.2 GC2 procedure

The following call flows show a high level procedure on GC2 for multicast delivery service.

NOTE 1: More flows are expected during normative phase.

BM-SC GCSE AS

1. MuSe Setup Request (..)

2. MuSe Setup Response (..)

3. Internal logic to begin the multicast

delivery

4. MuSe Start(..)

5. MuSe Update(..)

6. MuSe Stop(..)

Ack

Ack

Ack

eMBMS session start procedure

eMBMS session update procedure

eMBMS session stop procedure

Figure 7.1.1.2-1: GC2 Interface procedure

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 49 Release 122T

NOTE 2: parameters listed below are example. Any parameter to be carried over GC2 needs further discussion during normative phase of the work.

1. GCSE AS sends a MuSe Setup Request message to BM-SC to indicate the attributes of a group communication (e.g. MBMS Service Area, Media component information, Group Priority, and Group Communication Service ID).

2. BM-SC responds with MuSe Setup Response message with information for GCSE AS for multicast delivery. This includes e.g. USD and media packet routing address (IP address/port).

3. GCSE AS delivers the USD to the interested UE. GCSE AS may start the multicast delivery immediately (e.g. pre-established scenario (solution 1)) by invoking step4. For dynamic usage scenario (solution 2), GCSE AS may only start the multicast delivery when there are sufficient users within a cell.

4. GCSE AS sends a MuSe Start message to start the multicast delivery. It includes the Group Communication Service ID to identify the session. GCSE AS sends the media toward the routing address given from step 2.

This triggers the eMBMS session start procedure as defined in TS 23.246 [8] clause 4.4.3.2.

NOTE 3: For the pre-established scenario, it should be possible to combine step 1 to 4 above as one operation.

5. At any time after step 2, GCSE AS may use MuSe Update (e.g. for new priority setting) .

This triggers the eMBMS session update procedure similar to TS 23.246 [8] clause 4.4.3.6.

6. At any time after step 2, GCSE AS may send MuSe Stop message (e.g. Group Communication Service ID) to remove a multicast delivery from BM-SC.

This triggers the eMBMS session stop procedure as defined in TS 23.246 [8] clause 4.4.3.5.

NOTE 4: TS 36.300 [2] has Suspend/Resume procedure defined for eMBMS bearer. Allowing GC2 to trigger Suspend/Resume procedure directly needs FFS.

7.1.1.3 Control plane and User plane of GC2

GC2 is an IP interface. The protocol stack for control/user plane is FFS.

7.1.2 Roaming Architecture The model which is assumed is that the GCSE AS is not associated to any PLMN (regardless of the wireless access subscription of the UEs that use it) and it is merely perceived as a third party application server by each Serving PLMN users are in. In addition:

- When the group communication service is provided using unicast bearers, there is no additional requirement to the support of GCSE in roaming than enabling plain EPS roaming and ability of the GCSE AS to access QoS control capabilities via a Rx interface supported in the HPLMN (Home routed and Local breakout via S9 interface) . The HPLMN is defined as the PLMN where the wireless subscription of the UE is (as the GCSE AS is not associated to any PLMN).

- When the service is offered via eMBMS bearers in particular regions of the serving PLMN, the GCSE AS is required to use eMBMS bearers of the serving PLMN according to GCSE framework, to have access to a GC2 interface offered by the serving PLMN. In fact there is no way to use the Mz interface to offer eMBMS Roaming support in Rel-12.

Since the GCSE AS is a third party application server, the GCSE AS can access the required network resources to deliver the GCSE service, whether the serving PLMN is the Home PLMN or a different VPLMN. From application layer standpoint this is possible as long as agreements are in place between the owner of the GCSE AS and the serving PLMN to use the serving PLMN resources (mediated by the HPLMN, in the case of the PCC interface).

It is assumed the PLMN selection proceeds using current methods. When a PLMN is selected the UE registers or re-registers with the GCSE AS and reports to it the PLMN ID of the current serving network as well as its own HPLMN ID. The GCSE AS can then, based on this, determine it if has a GC2 connection agreement for the serving PLMN and if so report to the UE the eMBMS related service data required to use the service via eMBMS delivery in the PLMN. Also,

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 50 Release 122T

the HPLMN ID is needed to identify the contact point for the Rx interface as it is assumed the Rx interface is supported by the HPLMN.

If no GC2 connection agreement with the GCSE AS is available in the serving PLMN, then the GCSE AS may provide the service using unicast, if so was acceptable.

If availability of eMBMS service in the serving PLMN is requirement by the GCSE AS, a possibility to make sure that automatic network selection yields networks that are providing GC2 to the AS is that the UE (the USIM) is provisioned by the HPLMN with a set of preferred PLMNs the Public Safety agency knows to support GC2 agreement. Also the HPLMN may forbid access to any other PLMN even in manual selection mode if so was desired, by rejecting attempts to use PLMNs other than those with which the GCSE AS has a GC2 connection.

As a summary: the GC2 interface is always supported in the VPLMN, and the Rx always in the home network. As unicast bearers can be supported in Home routed mode, or in Local breakout (using PCC roaming interface S9 and a Rx provided by the home network), the following figure 7.1.2 -1 and figure 7.1.2 -2 hold respectively:

UE

GCSE AS

BM-SCE-UTRANM1

S-GW

MBMS-GW

SGmb

SGimb

MME

HSS

S6a

Uu

PCRF

Gx

GC1

S1-u

S1-MMe

S-11

M3S1-m

SGi

GC2

Applicationdomain

Rx

P-GW

S8

H-PLMN

V-PLMN

Figure 7.1.2-1: Home routed unicast case

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 51 Release 122T

UE

GCSE AS

BM-SCE-UTRANM1

S-GW/PGW

MBMS-GW

SGmb

SGimb

MME

HSS

S6a

Uu

H-PCRF

GC1

S1-u

S1-MMe

S-11

M3S1-m

S-Gi

GC2

Applicationdomain

Rx

H-PLMN

V-PLMNV-PCRF

S9

Gx

Figure 7.1.2-2: LBO unicast case

Which one of the approaches should be selected by an operator or a public safety agency operating a GCSE AS is not in scope of this Technical Report.

7.1.3 Call flows and procedures

7.1.3.1 Downlink Media path setup for multipoint service

7.1.3.1.1 General

The clause describes two procedures for multipoint bearer setup on the downlink.

- using pre-established eMBMS bearers.

- using dynamic eMBMS bearers.

7.1.3.1.2 Pre-established eMBMS bearers

In this scenario, the GCSE AS pre-establishes eMBMS session in certain pre-configured areas before the start of the group communication. When a UE originates a request for group communication from one of these areas, the pre-established eMBMS session is used for the DL traffic.

See clauses 6.1.2.1, 6.10, and 6.5.2 for example flows using pre-established eMBMS bearers.

7.1.3.1.3 Dynamic eMBMS bearers

In this scenario, the GCSE AS establishes unicast communication with the UE for the DL traffic at the start of the group communication session. When the GCSE AS decides to use multipoint service, the GCSE AS establishes an eMBMS session with the BM-SC. The GCSE AS provides the necessary eMBMS service information to the UE so that the UE can switch to eMBMS for the DL traffic in areas where it is available.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 52 Release 122T

NOTE: The above procedures assume there are no eMBMS bearers at the time of session set up. If eMBMS bearers have already been established for the group (e.g. dynamic eMBMS bearer setup for another UE belonging to the same group), the GCSE AS can provide the eMBMS service information to the new UE without the need to set up a unicast session.

See clauses 6.2.2, 6.3.2.1 and 6.4.2.2.1 for example flows using dynamic eMBMS bearers.

7.1.3.2 Media Traffic using unicast and eMBMS on DL

The following diagram shows an example of a scenario where a combination of unicast and eMBMS traffic is used by the GCSE AS on the DL to different UEs. Here, UE-1 and UE-2 receive DL traffic over unicast whereas UE-3 to UE-5 receive DL traffic over eMBMS.

Figure 7.1.3.2-1 Media traffic with unicast and eMBMS on DL

7.1.3.3 Service continuity procedures between unicast and multipoint service

The clause provides flows & procedures for switching from eMBMS to unicast and vice-versa. In the flows, the need for service continuity is determined and executed by the UE, which has been agreed as the way forward. The UE also may for some time receive the same DL data on both Unicast and eMBMS bearers. In such scenarios, it is upto the application implementation to manage duplicate detection.

7.1.3.3.1 Unicast to eMBMS

See clause 6.1.2.2.4 for examples flows for switching from unicast to eMBMS.

7.1.3.3.2 eMBMS to Unicast

Clauses 6.1.2.2.2 and 6.1.2.2.3 describe two mechanisms for switching from eMBMS to unicast - make-before-break and non-make-before-break. It is agreed to go forward with the make-before-break and non make-before-break approach. The non make-before-break is primary used to handle scenarios such as MBMS service is suspended by the MCE due to resource shortage, MBMS node failure, etc.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 53 Release 122T

In both the procedures, the UE determines that it needs to switch from eMBMS to unicast. In the make-before-break flows, the UE switches to unicast when it is still in the eMBMS coverage whereas in the other scenario, the UE switches to unicast after it moves out of the eMBMS coverage area.

NOTE: The configuration of MBMS radio measurements and possible MBMS signal threshold for service continuity in the UE by the E-UTRAN is studied in the RAN WGs. SA WG2 will update its conclusions depending on the RAN study outcome.

7.2 GCSE_LTE common solution approach with respect to Group Management considerations

Public Safety needs to understand what the common solution approach will provide with respect to Group Management in Rel-12, as to have future public safety deployments there needs to be a clear understanding of what is provided in Rel-12 and the work required in Rel-13 to augment this. The purpose of this clause is to build a common understanding of what will be delivered in Rel-12 and what is still required.

When considering this it is important to consider the following points:

(a) for a given GCSE_LTE group its members may be arbitrarily located (e.g. in the same or different sectors, cells, E-UTRANs, PLMNs) for a particular GCSE_LTE group communication;

(b) a GCSE_LTE group communication can involve one or more media types;

(c) GCSE_LTE Group Management is media-type independent; and

(d) Group Management is an overarching concept for managing GCSE_LTE service functionality specified in the GCSE_LTE service requirements but is not explicitly defined in the GCSE_LTE service requirements.

7.2.1 Analysis of GCSE related contexts - IDLE mode DRX is expected to be based on upper layer configuration in the UE (e.g,. GCSE application) and

existing mechanism in TS 23.401 [5] / TS 36.304 [14].

- As GCSE has certain delay requirements for unicast delivery, it is desirable for eNB to be made aware of these at the radio bearer establishment/modification. This allows the eNB to apply per-UE connected mode DRX of e.g. 320 ms as described in Solution 2 (clause 6.2) with the intention of achieving decent PTT delays while also achieving reasonable battery life. How eNB can be made aware of this requirement and what information is needed is FFS.

NOTE: It is FFS for RAN to determine if such information can also be used for optimizing its call admission control.

- Within EPS, the priority level of a unicast and multicast session is represented with ARP.

- The EPS level does not have to be aware of group creation and group membership control and associated user interaction (adding/removing members), user notification when group communications start, ability of the user to accept/reject/ignore (and for the system to require a user to accept) a group communication.

7.2.2 Key considerations The common approach specified in Rel-12 GCSE_LTE should be evaluated with respect to Group Management for GCSE_LTE with the purpose of identifying the key assumptions being made about how the Group Management is being handled in Rel-12. The key considerations are as follows:

1. Consideration of GCSE_LTE group member types (e.g. UE, application, human user, machine user).

2. Consideration of Group Management functionality most appropriately provided by Multipoint Service (MuSe) at the EPC level and by GCSE_LTE Application Servers in support of GCSE_LTE-based applications (e.g. PTT, video, multimedia).

3. Consideration of how the function of invoking efficient (e.g. unicast or multicast) GCSE_LTE communication paths used for GCSE_LTE group communication takes into account that Group Management is media-type

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 54 Release 122T

independent and a particular group communication may consist of multiple media types and a very large number of group members.

4. Consideration of the administration of GCSE_LTE groups and group members (e.g. "GCSE_LTE group handling"), including their identification (e.g. GCSE_LTE group creation, deletion, and modification and the manipulation of GCSE_LTE communication paths based on applications using functionality provided by the Group Communication System Enablers for LTE).

5. Consideration of (i) establishing and reporting reachability of GCSE_LTE group members for a particular GCSE_LTE group communication and (ii) monitoring the participation status of GCSE_LTE group members.

6. Consideration of the relationship between Group Management and GCSE_LTE User Interaction.

7. Consideration of the function of prioritization and pre-emption and QoS of GCSE_LTE communication groups and group members for a GCSE_LTE group communication.

8. Consideration of the overall architecture of the Group Communication System Enablers for LTE needed to support Group Management functionality.

9. Consideration of EPS (E-UTRAN and EPC) and application layer functions and entities (e.g. Application Server, devices (e.g. UEs), applications, human users, machine users).

10. Consideration of what Group Management functions are required to be provided by the EPS.

11. Consideration of security and charging as part of architectural solutions supporting GCSE_LTE.

12. Consideration of relationships to ProSe Group Management.

13. Consideration of the term "Group Management" with respect to existing or potential use of the same or similar terms by other groups (e.g. RAN1, RAN2).

NOTE: The criteria identified in clause 7.2.2 are FFS.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 55 Release 122T

Table 7.2.1-1: Analysis of common solution approach with respect to GCSE_LTE Group Management key considerations

Key Consideration EPS Level Application Level

1 Not aware of member types Implementation, to be based on UE-GCSE AS interaction via GC1

2 FFS GCSE AS level for group management

3 Start the eMBMS service for broadcast delivery based on instruction from GCSE AS via GC2.

Determines when/where to start the broadcast delivery. UE uses broadcast or unicast based on

availability of broadcast in its serving area.

4 Administration of GCSE groups and members is not done at the EPS level

Administration of GCSE groups and members is done at the application level.

5 N/A Service continuity is to be based on UE – GCSE AS interaction via GC1.

6 N/A Roaming support, in addition to normal roaming

support for attachment to a visited PLMN, is to be based on UE – GCSE AS interaction via GC1.

7 Interworking is based on the EPS's ARP parameter

(mapped by BM-SC and PCRF using the priority level assigned from GCSE AS).

Priority level is assigned by GCSE AS.

8 FFS FFS 9 FFS FFS 10 FFS FFS

11 GCSE specific security is to be determined by SA3, GCSE specific charging is to be determined by SA5.

GCSE specific security is to be determined by SA3, GCSE specific charging is to be determined by SA5.

12 Administration of ProSe group management is not done at EPS level

To ensure ProSe Group communication is linked with a GCSE group, the GCSE AS provides the related

ProSe configuration parameters to UE (see TR 23.703 [4] clause 7.3.1.1).

13 FFS FFS

8 Conclusions Editor's note: The clause will capture agreed conclusions from the Key issues and Architecture Solutions clauses.

8.1 General - The GCSE_LTE applications will use a mix of Unicast and eMBMS bearers. Any evolution of eMBMS or

unicast bearers in Rel-12 is assumed to be mostly impacting RAN layers only.

- For low latency services such as speech, when using eMBMS, the UE can be expected to receive at least once every 80 ms, and, when using unicast bearers the UE can be expected to receive at least once every 320 ms. While it is assumed that consumer devices normally operate with an idle mode DRX of either 1.28 or 2.56 s, it is also assumed that Public Safety users are prepared to use devices with larger capacity batteries.

- In Rel-12 no UE-to-GCSE_LTE application-specific interface will be standardized by 3GPP (SP-130506).

3GPP still need to decide how TMGIs and associated security credentials are allocated. As no specification impact is expected, in Rel-12 some application developer guideline will be provided to document the kind of information applications and UE's need to exchange to use the unicast and the eMBMS bearers correctly.

- GCSE_LTE applications interact with the BMSC to enable for specific GCSE_LTE groups the establishment of eMBMS bearers for specific distribution areas, and with specific QoS level for specific IP flows.

The BMSC provides the applications with the eMBMS service information for the various GCSE_LTE groups using eMBMS. As such, in Rel-12 it is expected the GC2 interface shall be standardized.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 56 Release 122T

- Downlink traffic from multiple media flows belonging to the same or different GCSE Groups may be multiplexed on the same eMBMS bearer.

- The media distribution in DL for unicast is on SGi (no GC5 required).

- GC3 shall be the M1 interface.

- The functionality required to support the MUSE function is assumed to be split between the BMSC and the MBMS-GW. Due to GCSE there are no (or only limited if any) expected change on the MBMS-GW and on SGmb.

- GC4 is the Sm interface.

- It is up to the application layer to deal with packet loss / duplication / not in sequence delivery of packets (e.g. related with switching between point-to-point and eMBMS delivery).

- It is assumed that the GCSE AS is not associated to any specific PLMN from an ownership standpoint, and it can access PLMN resources via SGi+Rx (When using unicast bearers) and GC2(when using Multicast bearers).

- The SGi interface can be offered in LBO mode or home routed mode.

- The Rx is supported in the HPLMN (whether SGi is in Home routed or LBO mode).

- The GC2 is offered only by the serving PLMN in this release of the specifications.

- One MBMS session is supported by exactly one BM-SC and one GCSE-AS.

- The GC2 interfaces will need to be able to connect multiple BM-SCs to one GCSE-AS.

- The GC2 interfaces will need to be able to connect multiple GCSE-ASs to one BM-SC.

- The PLMN ID of the serving PLMN and the HPLMN ID needs to be provided to the GCSE AS when serving PLMN ID changes so the GCSE-AS can select the right Rx and GC2 connections. This happens via a GCSE registration or re-registration procedure.

- The GCSE AS needs to be configured with the IP addresses or a FQDN of the contact points for Rx and GC2. The GC2 contact points need to be configured per PLMN ID, while the Rx is a single value per user, associated to the HPLMN ID.

- If for a PLMN ID there is no GC2 contact point configured, the GCSE AS can only offer unicast-based group services for the related PLMN.

- PLMN selection procedures are not affected by GCSE. The list of preferred PLMNs in the USIM and the forbidden PLMNs by the HPLMN may however be customized if the GCSE application requires to only access to eMBMS capable PLMNs with which an agreement to use eMBMS is in place (i.e. PLMN's for which there is a GC2 contact point).

- The eMBMS service information (i.e, USD) is sent to the UE via a unicast bearer (on the GC1 interface) or via a multicast (i.e. eMBMS) bearer. GCSE AS determines which path to deliver the USD over (GC1 or via eMBMS bearer). Transfer of the USD from the BM-SC to the GCSE AS is done over the GC2 interface.

NOTE: Additional methods of providing eMBMS service information (e.g. via configuration) are possible.

- Normative solution to be specified is based on the proposals defined in sub-clause "Common Approach" under sub-clause 7.1 and 7.2, to allow deployment of GCSE over LTE with "Group Communications using pre-established eMBMS bearers" in section 6.1 and/or "GCSE AS counting of UEs per group per cell" in section 6.2.

8.2 Priority and Pre-emption on Group Communication For key issue#8 'Priority and Pre-emption on Group Communication', it is agreed to adopt elements of the solution 7 in the base line solution. Specifically, it is agreed:

- For updating the priority for multicast bearer service, MBMS Session Update procedure needs to be enhanced. Other alternative, e.g. replacing old eMBMS bearer with new eMBMS bearer with updated ARP, is dependent on the GCSE AS decision.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 57 Release 122T

- For updating priority for unicast bearer service, the GCSE AS selects individual UE(s) that are using unicast bearers, and updates individual Rx sessions

- The GCSE AS sets and updates the priority of the IP flows based on the application level priorities, events and the specifics of the application.

NOTE: In the eNB the resources reserved for multicast and unicast are separate and cannot be used interchangeably, with one exception. If the radio subframes allocated for MBMS services is not fully occupied, the unused radio subframes can be scheduled for unicast transmission. However for those radio subframes the eNB always give the priority to the multicast traffic over the unicast traffic.

- Support reassignment of Group Communication priority level.

- UE can join multiple Groups sharing the same EPS bearer for Group Communication signalling.

- Group members within a single GCSE group can have different priorities which are also reflected on the EPS network.

- The priorities of the MBMS bearers can be changed.

- MBMS bearer suspension due to pre-emption is treated in the same manner as an MBMS to unicast switch (non make-before-break) as described in clause 6.1.2.2.3.

- MBMS bearer service resumption, if and when pre-emption is no longer necessary, is treated in the same manner as the procedure for switching from unicast to MBMS (clause 6.1.2.2.4).

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 58 Release 122T

Annex A: QoS and bearer parameters for Group Communications

A.1 General The intention of this annex is to capture the status of discussions that lead to a CR to TS 23.203 to detail the QoS and related bearer parameters (e.g. connected mode DRX control) needed for GCSE.

A.2 Overview The following aspects were considered in the generation of the draft changes:

a) The data rate for Push to Talk speech is known in advance, so the network can indicate the likely bandwidth requirement to the RAN. This suggests using a GBR bearer rather than a non-GBR bearer (that is just part of overall the AMBR).

b) The 'statistics' of the Push to Talk voice activity are different to that of normal telephony, e.g. long silent periods between exchanges of talk spurts, and, more downlink speech than uplink speech.

c) Push to Talk signalling (e.g. floor control and talker ID) is sometimes multiplexed in with the media. However, a media bearer's Packet Error Loss Rate of 10-2 may be more than expected for Push to Talk signalling. Hence it is suggested to aim the Push To Talk Signalling to QCI 5 (IMS). When the exact requirements for Push To Talk signalling are known in Rel-13, it may be necessary to (re)consider this.

d) The UE should not be controlling whether it is in RRC IDLE or RRC CONNECTED state, yet the UE will be expecting similar QoS characteristics in RRC IDLE and RRC CONNECTED states. In RRC IDLE the lowest DRX setting is 320 ms, and the UE can demand this from the network. This gives a service latency expectation adequate for Push To Talk. That latency should not be worsened when in RRC CONNECTED state. Similarly the battery consumption of the device, when not transferring media, should not be greatly different in RRC CONNECTED compared to RRC IDLE. This implies that for the first packet(s) in a talk burst in RRC CONNECTED state, the PDB can be relaxed, but to not beyond 320 ms.

e) While the high priority of the IMS QCI is needed to make sure that any needed release of IMS transactions succeeds, the IMS QCI can also be heavily loaded by much less urgent IMS signalling, e.g. Presence updates, leading to latencies. Hence it is suggested that the Mission Critical Push to Talk is given a higher Priority Level than that of QCI 5. Non-Mission-Critical Push to Talk traffic should however have a lower priority than QCI 5.

f) GBR bearers are not released at normal RRC CONNECTED to RRC IDLE transitions.

g) It is assumed that these bearers should not be candidates for SRVCC.

h) In a congested network (e.g. during a major public safety incident) the speech PDB of 100 ms may cause the end to end delay requirements for Push to Talk to be exceeded. Hence a lower PDB is proposed. It is also likely that the PCEF will be closer to the base station than when global roaming is in use and hence an allowance of 10 ms for the network delays may be more appropriate.

i) It is assumed that these new QCIs can also be used for eMBMS. (Note that TS 23.246 [8] clause 6.3.2 specifies that for EPS only GBR MBMS is specified, and this is an extra hint that the new QCIs should be GBR ones).

j) For group communications with other media, it is currently assumed that the existing QCIs 1-9 are adequate.

A.3 Draft Changes to TS 23.203 v12.3.0 This clause is work in progress and needs to be validated by SA WG2 and other working groups.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 59 Release 122T

6.1.7 Standardized QoS characteristics

6.1.7.1 General

The service level (i.e., per SDF or per SDF aggregate) QoS parameters are QCI, ARP, GBR, and MBR.

Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI). For the same IP-CAN session multiple SDFs with the same QCI and ARP can be treated as a single traffic aggregate which is referred to as an SDF aggregate. An SDF is a special case of an SDF aggregate. The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.) and that have been pre-configured by the operator owning the node (e.g. eNodeB).

6.1.7.2 Standardized QCI characteristics

This clause specifies standardized characteristics associated with standardized QCI values. The characteristics describe the packet forwarding treatment that an SDF aggregate receives edge-to-edge between the UE and the PCEF (see figure 6.1.7-1) in terms of the following performance characteristics:

1 Resource Type (GBR or Non-GBR);

2 Priority;

3 Packet Delay Budget;

4 Packet Error Loss Rate.

Access Network (B side)

IP Application / Service Level

Send/ Rcv

Access Network (A side)

Send/ Rcv

UE PDN GW

Scope of the standardized QCI characteristics UE PDN

GW Scope of the standardized

QCI characteristics Backbone


Send/ Rcv


Send/ Rcv

UE PDN GW

Scope of the standardized QCI characteristics Server Backbone



Send/ Rcv


Send/ Rcv

UE PDN GW

Scope of the standardized QCI characteristics UE PDN


QCI characteristics Backbone



Send/ Rcv


Send/ Rcv

UE PDN GW

Scope of the standardized QCI characteristics UE PCEF Scope of the standardized QCI characteristics UE PDN


QCI characteristics UE PCEF Scope of the standardized QCI characteristics Backbone


Send/ Rcv


Send/ Rcv

UE PDN GW

Scope of the standardized QCI characteristics Server Backbone


Send/ Rcv


Send/ Rcv

UE PDN Scope of the standardized QCI characteristics UE PCEF Scope of the standardized QCI characteristics Server Backbone

Figure 6.1.7-1: Scope of the Standardized QCI characteristics for client/server (upper figure) and peer/peer (lower figure) communication

The standardized characteristics are not signalled on any interface. They should be understood as guidelines for the pre-configuration of node specific parameters for each QCI. The goal of standardizing a QCI with corresponding characteristics is to ensure that applications / services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and in case of roaming. A standardized QCI and corresponding characteristics is independent of the UE's current access (3GPP or Non-3GPP).

The one-to-one mapping of standardized QCI values to standardized characteristics is captured in table 6.1.7.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 60 Release 122T

Table 6.1.7: Standardized QCI characteristics

QCI Resource Type

Priority Packet Delay

Budget (NOTE 1)

Packet Error Loss

Rate (NOTE 2)

Example Services

1 (NOTE 3)

2 100 ms 10-2 Conversational Voice

2 (NOTE 3)

GBR

4 150 ms 10-3 Conversational Video (Live Streaming)

3 (NOTE 3)

3 50 ms 10-3 Real Time Gaming

4 (NOTE 3)

5 300 ms 10-6 Non-Conversational Video (Buffered Streaming)

65 (NOTE 7, NOTE 8, NOTE 9)

A [0.7]

75 ms 10-2 Mission Critical user plane PTT voice (e.g. MCPTT)

66 (NOTE 8)

B [3.5]

100 ms 10-2 Non-Mission-Critical user plane PTT voice

5 (NOTE 3)

1 100 ms 10-6 IMS Signalling

6 (NOTE 4)

6

300 ms

10-6

Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

7 (NOTE 3)

Non-GBR 7

100 ms

10-3

Voice, Video (Live Streaming) Interactive Gaming

8 (NOTE 5)

8

300 ms

10-6

Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file

9 (NOTE 6)

9 sharing, progressive video, etc.)

69 (NOTE 9)

C [0.5] 60 ms 10-6 Mission Critical delay sensitive signalling (e.g. MC-PTT signalling)

70 D [2.8 or 5.5] 200 ms 10-6 Public Safety default bearer NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given

PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.

NOTE 2: The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.

NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.

NOTE 4: If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers.

NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers".

NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.

NOTE 7: For Mission Critical Push to Talk, it may be assumed that the PCEF is located "close" to the radio base station (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence delay of 10 ms for the delay between a PCEF and a radio base station should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface.

NOTE 8: In order to permit reasonable battery saving (DRX) techniques in both RRC Idle and RRC Connected mode, for the first packet(s) in a downlink talk or signalling burst, the PDB requirement is relaxed but not to greater

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 61 Release 122T

than 320 ms. NOTE 9: It is expected that QCI-65 and QCI-69 are used together to provide Mission Critical Push to Talk service (e.g.

QCI-5 is not used for signalling bearer that utilizes QCI-65 as user plane bearer). It is expected that the amount of traffic will be similar or less compared to the IMS signalling.

The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control. A Non GBR SDF aggregate may be pre-authorized through static policy and charging control.

The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points). The PDB shall be interpreted as a maximum delay with a confidence level of 98 percent.

NOTE 1: The PDB denotes a "soft upper bound" in the sense that an "expired" packet, e.g. a link layer SDU that has exceeded the PDB, does not need to be discarded (e.g. by RLC in E-UTRAN). The discarding (dropping) of packets is expected to be controlled by a queue management function, e.g. based on pre-configured dropping thresholds.

The support for SRVCC requires QCI=1 only be used for IMS speech sessions in accordance to TS 23.216 [28].

NOTE 2: Triggering SRVCC will cause service interruption and/or inconsistent service experience when using QCI=1 for non-IMS services.

Services using a Non-GBR QCI should be prepared to experience congestion related packet drops, and 98 percent of the packets that have not been dropped due to congestion should not experience a delay exceeding the QCI's PDB. This may for example occur during traffic load peaks or when the UE becomes coverage limited. See Annex J for details. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below).

Services using a GBR QCI and sending at a rate smaller than or equal to GBR can in general assume that congestion related packet drops will not occur, and 98 percent of the packets shall not experience a delay exceeding the QCI's PDB. Exceptions (e.g. transient link outages) can always occur in a radio access system which may then lead to congestion related packet drops even for services using a GBR QCI and sending at a rate smaller than or equal to GBR. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below).

Every QCI (GBR and Non-GBR) is associated with a Priority level. The lowest Priority level corresponds to the highest Priority. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then Priority shall be used as follows: in this case a scheduler shall meet the PDB of an SDF aggregate on Priority level N in preference to meeting the PDB of SDF aggregates on next Priority level immediately greater than N, until the priority N SDF aggregate's GBR (in case of a GBR SDF aggregate) has been satisfied. Other aspects related to the treatment of traffic exceeding an SDF aggregate's GBR are out of scope of this specification.

NOTE 3: The definition (or quantification) of "sufficient radio channel quality" is out of the scope of 3GPP specifications.

NOTE 4: In case of E-UTRAN a QCI's Priority level may be used as the basis for assigning the uplink priority per Radio Bearer (see TS 36.300 [19] for details).

The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E-UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E-UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E-UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.

NOTE 5: The characteristics PDB and PELR are specified only based on application / service level requirements, i.e., those characteristics should be regarded as being access agnostic, independent from the roaming scenario (roaming or non-roaming), and independent from operator policies.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 62 Release 122T

6.1.7.3 Allocation and Retention Priority characteristics

The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The priority level defines the relative importance of a resource request. This allows deciding whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). It can also be used to decide which existing bearers to pre-empt during resource limitations.

The range of the ARP priority level is 1 to 15 with 1 as the highest level of priority. The pre-emption capability information defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. The pre-emption vulnerability information defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The pre-emption capability and the pre-emption vulnerability can be either set to 'yes' or 'no'.

The ARP priority levels 1-8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the serving network). The ARP priority levels 9-15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming.

NOTE: This ensures that future releases may use ARP priority level 1-8 to indicate e.g. emergency and other priority services within an operator domain in a backward compatible manner. This does not prevent the use of ARP priority level 1-8 in roaming situation in case appropriate roaming agreements exist that ensure a compatible use of these priority levels.

3GPP

3GPP TR 23.768 V12.1.0 (2014-06) 63 Release 122T

Annex B: Change history

Change history Date TSG # TSG Doc. CR Rev Cat Subject/Comment Old New

2013-12 SP#62 SP-130545 - - - MCC Editorial update for presentation to TSG SA for information

0.5.0 1.0.0

2014-02 SP#63 SP-140117 - - - MCC Editorial update for presentation to TSG SA for Approval

1.2.0 2.0.0

2014-03 SP#63 - - - - MCC Editorial update for publication after TSG SA approval 2.0.0 12.0.0 2014-03 SP#64 SP-140259 0002 - F QCI values for Public Safety services 12.0.0 12.1.0

Documents

3GPP TR 23 - 一般社団法人 電波産業会 · PDF file3GPP TR 23.768 V12.1.0 ... 6.1.4 Solution evaluation ... Group communications with pre-established MBMS broadcast Bearers

3GPP TR 23 - 一般社団法人電波産業会 · PDF file3GPP TR 23.768 V12.1.0 ... 6.1.4 Solution evaluation ... Group communications with pre-established MBMS broadcast Bearers