TS 22.468
Group Communication System Enablers for LTE

3GPP‑Page ETSI‑search CONTENT_↓

V18.0.1 (PDF) 2024/03 … p.

V17.0.1 2020/06 25 p.

V16.0.0 2019/12 24 p.

V15.0.0 2018/06 23 p.

V14.0.0 2017/03 24 p.

V13.0.0 2014/12 23 p.

V12.1.0 2014/09 22 p.

Rapporteur:: Mr. Merkel, Jürgen
Nokia Germany

Content for TS 22.468 Word version: 18.0.1

5.1 Overall requirements 5.2 Group handling 5.3 Group Communication A.1 Speech Group Call use case A.2 "See what I see" use case A.3 Harmonized multi-agency use case

0 Introduction p. 5

To position 3GPP radio as technology for critical communications such as public safety, Group Communication is needed.

Group Communication function complements its sibling communication feature of proximity-based services (ProSe).

1 Scope p. 6

The present document collects the requirements as relevant to improve the 3GPP system to support Group Communication for Public Safety and Critical Communication and other services.

For Public Safety and Critical Communication Services, US requirements as specified in NPSTC (Mission Critical Voice Requirements) [2], [3], [4], the TETRA + Critical Communications Association (TCCA) [8] and ITU [6], [7] inputs are taken as starting point.

Other regional requirements may also be reflected in the work. The requirements are worded in a way to easily accommodate future requirements from other regions or stakeholders.

Other services have corresponding regulatory and service justification.

2 References p. 6

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]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

Recommended Minimum Technical Requirements to Ensure Nationwide Interoperability for the Nationwide Public Safety Broadband Network, Final Report: NPSTC BBWG, May 22, 2012.

[3]

Mission Critical Voice Communications Requirements for Public Safety: NPSTC BBWG, August 30, 2011.

[4]

Public Safety Broadband High-Level Statement of Requirements for FirstNet Consideration: NPSTC Report Rev B, June 13, 2012.

[5]

TS 22.101: "Service aspects; Service principles".

[6]

ITU-T Recommendation G.114: One-Way Transmission Time, May 2003.

[7]

ITU-T Recommendation Y.1541: Network Performance Objectives for IP-Based Services, December 2011

[8]

ETSI ETR 086: "Trans European Trunked Radio (TETRA) System; Technical Requirements Specification Part 1: Voice plus Data (V+D) systems", January 1994.

[9] TS 22.278: "Service requirements for the Evolved Packet System (EPS)".

3 Definitions and abbreviations p. 6

3.1 Definitions p. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 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.

Group Member:

A user assigned to a GCSE Group.

GCSE Group:

A set of Group Members.

Receiver Group Member:

A Group Member of a GCSE Group that has interest expressed in receiving ongoing or future Group Communications of that GCSE Group.

Transmitter Group Member:

A Group Member of a GCSE Group that is authorized to transmit an ongoing or future Group Communications for that GCSE Group.

Group Communication:

Communication from Transmitter Group Members to Receiver Group Members.

Group Communication System Enabler (GCSE):

A 3GPP feature enabling an application layer functionality to provide Group Communication.

Multipoint Service:

A service used to distribute the same content to many UEs in a resource efficient way.

3.2 Abbreviations p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 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.

Core Network

GCSE

Group Communication System Enabler

LMR

Land Mobile Radio

ProSe

Proximity Services

PTT

Push to Talk

RAN

Radio Access Network

TETRA

TErrestrial Trunked Radio

TCCA

TETRA + Critical Communications Association

4 Overview (informative) p. 7

4.1 Service description of a Group Communication service p. 7

A Group Communication Service is intended to provide a fast and efficient mechanism to distribute the same content to multiple users in a controlled manner as an enabler for a variety of services.

As an example, the concept of group communications is used extensively in the operation of classical Land Mobile Radio (LMR) systems used for, but not limited to, Public Safety organizations. At the moment, the primary use of a Group Communication Service in LMR is to provide "Push to Talk" (PTT) functionality, so a Group Communication Service based on the 3GPP system should enable PTT voice communications with comparable performance.

Another example is network controlled interactive services. 5G UEs will include new forms of devices, e.g. VR/AR devices, robots, game consoles, etc. These will be used in diverse environments including public spaces, in educational institutions and in the work place. These supported scenarios entail efficient support of 5G UEs executing group communication applications, specifically gaming and interactive data exchange applications with delay sensitivity and demanding throughput.

The service should allow flexible modes of operation as the users and the environment they are operating in evolves. For example, the capabilities of the 3GPP system allow for broadband communication, so Group Communication Service is expected to support, voice, video or, more general, data communication. Also the 3GPP system can allow users to communicate to several groups at the same time in parallel e.g. voice to one group, different streams of video or data to several other groups.

The users of Group Communication Service are organised into groups; a user can be member of more than one group.

4.2 Relation to Group Communication System Enablers p. 8

The requirements listed in the present document shall serve as requirements to develop enablers; i.e. modular functions and open interfaces (e.g. a resource efficient distribution mechanism) that can be used to design Group Communication Services. This is to flexibly accommodate the different operational requirements on Group Communication Services that are expected to be different for various types of user groups (e.g. police or fire brigade), or from country to country.

5 Functional requirements p. 8

5.1 Overall requirements p. 8

5.1.1 High level requirements p. 8

The ability to make use of the Group Communication System Enabler provided by the 3GPP system shall be enabled on a Group Member basis.

The system shall provide a mechanism to indicate network support of Group Communication System Enabler to the UE.

The UE shall have the ability to indicate the network support of Group Communication System Enabler to the user.

Group Communication System Enabler shall support various media such as conversational type communication (e.g. voice, video) or streaming (e.g. video) or data (e.g. messaging) or a combination of them.

The system shall be able to uniquely identify a GCSE group. The system shall be able to uniquely identify a Group Member within a GCSE group

The system shall provide a mechanism to send a Group Communication to all Receiver Group Members.

Only Receiver Group Members of the GCSE Group shall be able to receive from that GCSE Group via Group Communication.

The system shall be able to authorise a Group Member to become a Transmitter Group Member.

A Transmitter Group Member shall be able to transmit to a GCSE Group that it is a member of, with or without being a Receiver Group Member of that GCSE Group.

The interface between the GCSE client on the UE and the network shall be an open interface.

The network shall provide a third party interface for Group Communication. This implies that the interface supports e.g. charging and authentication/authorisation.

The system shall provide a mechanism for a Group Member that is not connected via a 3GPP network, to communicate in a Group Communication for a GCSE Group that it is a member of.

5.1.2 Performance p. 8

The system shall be optimized to minimize the time intervals related to the use of Group Communication.

The recommended time intervals specified below are for consideration in the development of detailed RAN/CN requirements, and the evaluation of architecture solutions.

The system should provide a mechanism to support a Group Communication end-to-end setup time less than or equal to 300ms. It is assumed that this value is for an uncontended network, where there is no presence checking and no acknowledgements requested from Receiver Group Member(s). The end-to-end setup time is defined as the time between when a Group Member initiates a Group Communication request on a UE and the point when this Group Member can start sending start sending a voice or data communication.

The time from when a UE requests to join an ongoing Group Communication to the time that it receives the Group Communication should be less than or equal to 300ms.

The end to end delay for media transport for Group Communications should be less than or equal to 150 ms [6], [7].

5.1.3 Service continuity p. 9

When UEs are moving among cells during Group Communication, service continuity shall be supported.

5.1.4 Resource efficiency p. 9

The system shall provide a mechanism to efficiently distribute data for Group Communication.

5.1.5 Scalability p. 9

The number of Receiver Group Members in any area may be unlimited

The system shall support multiple distinct Group Communications in parallel to any one UE that is capable of supporting that number of distinct Group Communications in parallel. The mechanisms defined shall allow future extension of the number of distinct Group Communications supported in parallel.

5.1.6 Security requirements for Group Communication p. 9

The system shall support at least the same security level for Group Communication (e.g. for Authentication, Integrity, Confidentiality and Privacy) as a 3GPP LTE packet data bearer.

5.1.7 Charging requirements for Group Communication p. 9

The system shall support the collection of resource and service usage information for Group Communication.

5.1.8 Roaming and network interworking requirements p. 9

The system shall support the transmitting and/or receiving of Group Communication by Group Members that are roaming.

Subject to operator agreement, the system shall be able to support Group Communications where Group Members are attached to different PLMNs.

An interface shall be provided to enable Group Communication interworking between a network offering GCSE-based Group Communication Services with either or both of:

another 3GPP network offering GCSE-based Group Communication Services,
a non-3GPP network offering group communication services.

5.1.9 High availability of Group Communication p. 10

The system shall be capable of achieving high levels of availability for Group Communications utilising GCSE, e.g. by seeking to avoid single points of failure in the GCSE architecture and/or by including recovery procedures from network failures.

5.2 Group handling p. 10

5.2.1 Creation, modification, and deletion of GCSE Groups |R13| p. 10

5.2.1.1 General |R17| p. 10

There are two mutually exclusive ways that the 3GPP System supports GCSE Group management creation, modification and deletion functions, by authorized users and by third parties.

General requirements that apply to both are listed below.

The system shall provide a mechanism for the dynamic creation, modification, and deletion of GCSE Groups.

Information additional to the set of Group Members shall be associated with a GCSE Group, to be used by the system to identify the GCSE Group and to specify attributes that determine how it is changed and used. This may be used to, e.g. define which Group Members are authorized for administrative functions, and whether the GCSE Group can be relayed via ProSe.

The system shall provide notification of the creation or deletion of a GCSE Group to its Group Members.

The system shall provide a mechanism to remotely configure a UE with any GCSE related information.

5.2.1.2 GCSE Group Management by Users |R17| p. 10

If authorised, a user shall be able to request and receive a list of all the GCSE Groups for which it is a Group Member.

A mechanism shall be provided such that, if authorized, a user may modify information associated with a GCSE Group, add or remove Group Members of a GCSE Group, or create/delete a GCSE Group.

If authorized, a user shall be able to request and receive a list of Group Members of a particular GCSE Group.

If authorized, a user shall be able to request a notification for when specific or any Group Member(s) is added to or removed from a particular GCSE Group.

5.2.1.3 GCSE Group Management by 3rd parties |R17| p. 10

The 3GPP system shall allow a 3rd party (e.g., a gaming server) to provide information to be used for group communication (e.g. group ID and group member list).

5.2.2 Geographical scope of GCSE Groups |R13| p. 10

GCSE Groups shall by definition be of system wide scope. Optionally, GCSE Groups may be geographically restricted.

The system shall provide a mechanism to restrict all Group Communications for a given GCSE Group to a defined geographic area. In this case Group Members shall be able to receive and/or transmit only within this geographic area.

The system shall provide a mechanism to redefine the geographic area for a GCSE Group that has a defined geographic area.

The system shall provide a mechanism to override geographic area restrictions for a GCSE Group for a particular Group Communication transmission.

The system shall provide a mechanism to restrict a particular Group Communication transmission to a defined geographic area within the geographical scope of that group. In this case only Receiver Group Members within the geographic area shall receive the Group Communication.

5.3 Group Communication p. 11

5.3.1 Group Communication setup requirements p. 11

A Transmitter Group Member shall be able to transmit a Group Communication for a GCSE Group without knowledge of the identities of other GCSE Group Members.

A Group Member shall be able to request to join or leave an established Group Communication.

The system shall provide a mechanism to setup, release, and modify a multipoint service with applicable parameters e.g. QoS, priority.

The system shall validate the parameters received in the request to setup or modify a Group Communication based on the policy specified by the group's subscription information, e.g. checks for QoS, priority.

The system shall provide the means to notify the requesting entity of any updates in the status of an on-going Group Communication.

The system shall provide notification to the requesting entity of the outcome of a request to setup, release, or modify a multipoint service.

5.3.2 Services to the Group Member |R13| p. 11

The system shall provide a mechanism to permit a Group Member to request notification when a Group Communication is initiated using that GCSE group.

The system shall provide notification of a Group Communication to Group Members that have requested notification for the GSCE Group.

5.3.3 Group Member requests of the system |R13| p. 11

A Group Member shall be able to express interest to receive Group Communications when the GCSE Group is used for Group Communications.

The system shall provide a mechanism for a Receiver Group Member receiving a Group Communication to be able to accept, reject, or ignore the Group Communication.

The system shall provide a mechanism for a Receiver Group Member receiving a Group Communication to be required to accept the Group Communication.

5.3.4 Priority and pre-emption of GCSE communication p. 11

The following requirements apply to the allocation and retention of system resources:

The system shall provide a mechanism to support at least n priority levels for Group Communication.

The system shall provide a mechanism to support reassignment of Group Communication priority level.

The network operator shall be able to configure each Group Communication priority level with the ability to pre-empt lower priority Group Communications and non-Group Communications traffic.

The system shall provide a mechanism to allow pre-emption of lower priority for Group Communications and non-Group Communications traffic.

Group Members within a GCSE Group shall be able to have different priorities from each other.

5.3.5 Services provided during an on-going Group Communication |R13| p. 12

An entity shall be able to request a notification when a specific Group Member ceases to be a Receiver Group Member.

A Receiver Group Member ceases to be a Receiver Group Member of a certain group by:

user decision
third party decision
after a service dependent amount of time
after a system configurable amount of time of unavailability.

A notification shall be provided to the requesting entity when a specific Group Member ceases to be a Receiver Group Member.

A Transmitter Group Member ceases to be a Transmitter Group Member of a certain group by:

user decision
third party decision
after a service dependent amount of time
after a system configurable amount of time of unavailability.

5.3.6 User perception of Group Communication p. 12

All Receiver Group Members in a given area shall receive the Group Communication at the same time according to user perception.

All changes to the GCSE Group (e.g., adding or removing group members) shall take effect as soon as possible.

All changes to the set of Receiver Group Members shall take effect in the Group Communication as soon as possible.

6 Interaction with other services and functions p. 12

6.1 Emergency calling p. 12

The ability for a UE to make an emergency call (TS 22.101) shall be unaffected by being in a Group Communication.

6.2 Interaction with ProSe p. 12

If the 3GPP system supports ProSe, the 3GPP system shall be able to make use of ProSe Group Communication and the public safety ProSe UE-to-Network Relay for Group Communication, subject to operator policies and UE capabilities or settings.

A public safety ProSe-enabled UE not served by a public safety enabled 3GPP system shall be able to support Group Communication based on ProSe Communication paths. A public safety ProSe-enabled UE shall be able to dynamically express its interest in receiving, via a public safety ProSe UE-to-Network Relay, the Group Communications of one or more GCSE Groups for which it is authorized.

A public safety ProSe UE-to-Network Relay shall be able to relay Group Communication to/from ProSe Communication paths, if the following conditions apply:

the GCSE Group is allowed to be relayed; and
the public safety ProSe UE-to-Network Relay is allowed to relay Group Communication.

A public safety ProSe UE-to-Network Relay shall be able to restrict the relayed Group Communication on a per group basis.

The system shall support groups whose membership shall be the same irrespective of whether a Group Communication is made using ProSe Group Communication or GCSE Group Communication.

GCSE Group Members shall be able to access Group Communication services using ProSe Communication paths [9] and/or by network path (TS 22.278).

A Use cases p. 14

A.1 Speech Group Call use case p. 14

A.1.1 Description p. 14

This use case describes communications in a speech group call.

A.1.2 Pre-conditions p. 14

A "traffic" group is enabled on the system, where "system" refers to the combination of group call application and underlying 3GPP network.

The list of UEs permitted to join the group is defined on the system.

The operating area of the group is defined on the system (e.g. by lists of radio sites which are allowed to support the group).

UEs are configured with lists of groups that they may join.

Mick is a dispatcher in control of "traffic" group.

Traffic group officers are members of "traffic" group and include Ned, Oscar, Peter and Roger.

Simon is another officer who is not authorised to use "traffic" group.

A.1.3 Service flows p. 14

A.1.3.1 Service Flow 1 - Joining a group p. 14

Traffic group officers including Ned, Roger and Peter (but not Oscar), who are within the defined operating area of the traffic group, select the group on their UE devices in order to join the group and communicate in the group. The group is also selected on Mick's dispatcher terminal.

The UE indicates to the user if joining the group was successful.

Oscar is located outside the defined area of the traffic group. His UE indicates that he is out of area for this group.

Simon is within the defined area of the "traffic" group, but he is not authorised to use the group.

A.1.3.2 Service Flow 2 - Joining and leaving a group based on group operating area p. 14

Oscar has not changed the group setting on his UE. He moves into the group's operating area. His UE automatically joins the group, and he receives an indication on the UE that he is now within the operating area of the group.

Ned moves to an area outside the operating area of the group. The system automatically removes his UE from the group. The UE indicates to Ned that he is now outside the operating area of the group.

A.1.3.3 Service Flow 3 - Call start p. 14

Ned moves back to an area within the defined operating area of the group. His UE automatically joins the group, and he receives an indication that he is now within the operating area of the group.

The group is not carrying traffic.

Oscar initiates a call to the group on his UE. The system sets the call up. Oscar receives an indication that the call is set up, and he may talk, within 300 ms of initiating the call setup. Other group members, irrespective of their location relative to Oscar and irrespective of the number of users who have joined the group, receive an indication that a call is starting within 300 ms of Oscar initiating the call setup.

The system efficiently allocates resources on all cells, and cells that provide service to many group members use the same resources for all members to receive the call.

Oscar speaks, and all group members including the dispatcher Mick hear the audio that he has spoken within minimal delay (within a few hundred milliseconds). The audio is a one way transmission, i.e. receiving parties hear Oscar's spoken audio, but no-one hears audio from any of the receiving parties.

All receiving parties including the dispatcher, Mick, can see Oscar's identity as the talking party on their UEs up to the time Oscar disconnects his call to the group.

Differences in audio delay are not noticeable to officers standing near each other who are receiving service from the same cell as each other; i.e. they do not hear an "echo" effect from different UEs.

Any UEs which are permitted to be members of the group, but which have not joined the group do not take part in the call.

A.1.3.4 Service Flow 4 - Call interruption p. 15

While Oscar is still speaking, Ned attempts to speak (i.e. he makes a PTT request).

If the system is configured such that the transmitting party cannot be interrupted, then Ned's PTT request is rejected. He receives an indication on his UE of the rejection. Oscar continues to speak and to be heard by all receiving parties in the group.
If the system is configured (such that interruption is possible, or is possible based on relative priorities of Oscar and Ned, and Ned has a higher priority rating), then the system sends a message to Oscar's UE withdrawing transmit permission. The UE indicates this to Oscar, and Oscar's UE no longer transmits. The system grants transmit permission to Ned's UE, which indicates that his request is successful. Ned now speaks, and his speech is heard by the group from this point onwards. All receiving parties now see Ned's identity as the talking party on their UEs.

If priorities are used, at least four priorities are needed for normal user, supervisory user, dispatcher and supervisory dispatcher.

A.1.3.5 Service Flow 5 - Talking party changeover p. 15

When the current talking party (Oscar in 4.1, Ned in 4.2) has finished speaking, an indication is sent to the UEs of all group members.

Peter then initiates speech transmission to the group. The group call goes on with Peter as the talking party.

A.1.3.6 Service Flow 6 - Late Entry and mobility p. 15

Roger has not previously selected the "traffic" group, and therefore has not been listening to audio. Whilst Peter is transmitting, Roger selects the "traffic" group on his UE. The UE signals to the system that it wants to join the group, and system grants the request. The UE joins the call, and Roger hears the audio being spoken by Peter, and Roger's UE displays Peter's identity as the talking party.

The system allocates resources efficiently to include Roger. If Roger is receiving service from a radio site which is also serving several other users, Roger's UE uses the same resources that are being used for the other users.

Ned is receiving the call on one cell, but moves to another cell whilst Peter is transmitting. The system hands over Ned's call to the new cell. If the new cell is serving several other users, Ned's UE uses the same resources that are being used for the other users. Ned experiences minimal interruption to his received audio due to the cell change.

Whilst transmitting, Peter moves to another cell. The system hands over Peter's call to the new cell and allows him to continue transmission with minimal interruption.

A.1.3.7 Service Flow 7 - Call release p. 16

Peter finishes transmitting and ends the call on his UE. The UE signals to the system that the transmission is ceased, and the system in turn signals this to all receiving parties in the call. Peter's audio is no longer heard, and his identity is no longer displayed as the talking party.

After a short period of time, the system releases resources which had been assigned to the call.

The Group Call is cleared by the system after a short time after the last speaker and no one has spoken in the meantime (and the system may be configured with a timer to determine this time).

A.1.3.8 Service Flow 8 - Blocking of resources p. 16

Oscar initiates a new call. Traffic group members are spread across several cells.

Calling Party cell busy:

Oscar's cell does not have enough resources to support the new call.
Oscar receives an indication that the call cannot be established, and will be queued.
The system places the call in a queue until enough resources are available at least on Oscar's cell.
Once enough resources are available, the call is started, and Oscar receives an indication that he can start to transmit.

Receiving Party cell busy:

Oscar's cell has enough resources to support the call, but on one or more cells where group members are receiving service, the system does not have enough resources to support the new call. Two alternatives may follow:
- Queued configuration: If the system is configured to queue calls, the call is queued until the system has enough resources to support all the users of the group. Oscar receives an indication that the call has been queued. Once enough resources become available, Oscar receives an indication that he can start to transmit.
- Immediate call start configuration: If the system is configured to start providing that the talking party's cell has sufficient resources, the call will be started and audio received by receiving parties in the call on cells where the system has enough resources to receive the call. If cells that did not have enough resources at the start of the call subsequently have the enough resources available e.g. due to a reduction in load, users on those cells are connected into the call as soon as is possible.

A.1.4 Post-conditions p. 16

Whilst idle, the group is not consuming system resources.

A.2 "See what I see" use case p. 16

A.2.1 Description p. 16

This use case illustrates a situation where a policeman shares multimedia content (video and/or picture) with all the members of a pre-defined group (including the dispatcher and group members in the field). According to the operational rules of the users, the sharing of multimedia content within a group might be authorized by a dispatcher or not. This use case describes the case where the sharing is authorized by the dispatcher.

A.2.2 Actors p. 16

A group of police officers is affected to a mission of protecting a touristic and shopping area from pickpockets and delinquency acts.

Officer Graham is the dispatcher in the control room.

Officer Smith and Johnson are two members of the team on the field.

Officer Smith is assigned to the surveillance of the main square of the touristic and shopping area. Officer Johnson is another member of the group assigned to the surveillance of a set of streets adjacent to the main square of the area.

A.2.3 Pre-conditions p. 17

A group "Area Protection Team" is created to provide multimedia communications between the officers in the field and the incident management officer in the control room.

All officers (including Officers Graham, Smith and Johnson) have their equipment configured to the "Area Protection Team" group.

Officer Smith is equipped with a wearable camera connected to his UE. Officer Smith's terminal is also capable of multimedia communications (video, voice group calls, text and data). All members of the group in the field have the same equipment set-up.

Default communication mode is Push to Talk (PTT) voice [refer to A.1 "Speech Group Call Use Case and requirement proposal"].

A.2.4 Service flows p. 17

Officer Smith is supervising the main square of the touristic and shopping area. He is in voice group call communications with all members of the team on the "Area Protection Team" group.

Suddenly, a pick-pocket steals a camera from a tourist in the vicinity of the Officer Smith. Officer Smith informs the team (including the dispatcher) using PTT voice communication that an incident is occurring in the main square.

Officer Smith identifies the suspect in the crowd. He activates the transmission of his wearable live video camera. A live video communication is created between Officer Smith's UE and the control room. Officer Graham can also see the suspect on the live video. Optionally, Officer Smith receives an indication that Officer Graham is actually receiving the live video flow.

3bis)

Optionally, Officer Graham remotely triggers a modification of the quality of the live video to a higher quality.

Officer Graham dispatches the video to the other members of the team so that all of them can identify how the suspect looks like (note, suspect identification can be augmented by means of voice description using the PTT communications on the "Area Protection Team" and/or by highlighting and tracking the image of the suspect on the live video). A video group communication is then created from the network to all team members. All team members can now see what Officer Smith is seeing and can also identify the suspect in the crowd.

From the live video that Officer Johnson receives on his terminals, he realises that the suspect is running into his direction. He gets ready to arrest the suspect.

Officer Johnson arrests the suspect.

A.2.5 Post-condition p. 17

After the suspect has been arrested, Officer Graham suspends the sharing of the video with all group members.

Officer Smith stops transmitting live video images.

Communications between all members of the team reverts to nominal PTT voice communication.

A.3 Harmonized multi-agency use case p. 18

A.3.1 Description p. 18

This use case illustrates a situation where a GCSE group of personnel from one local agency (e.g. fire fighters) will need to be joined with other GCSE groups of personnel from other agencies representing the same locality (e.g. police, ambulance), or with other GCSE groups from national, international or adjacent localities (e.g. police from an adjacent force, national authorities, or authorities from an adjacent country). In all cases the various groups which form the composite group must be able to join/leave the composite group and be identified as members of it. The individual personnel must also be able to fully participate in multimedia sessions within the composite group (i.e. take the floor, receive broadcast communications, etc.).

A.3.2 Actors p. 18

A group of local fire fighters, called to an explosion and gas leak from a chemical facility close to a national border.

The local fire service dispatcher.

A group of local ambulance personnel, called to attend to casualties at the site.

A group of local police officers, called to evacuate residents downwind of the leak in the same country.

A group of police officers in the adjacent country, called to prepare for possible evacuation of residents downwind of the leak in their territory.

A.3.3 Pre-conditions p. 18

The local fire fighters are members of GCSE Group A.

The local ambulance personnel are members of GCSE Group B.

The local police officers are members of GCSE Group C.

The group of police officers in the adjacent country are members of GCSE Group Z.

The GCSE applications on the UEs in all four groups are compatible, and are able to interwork with one another and with any of the four individual GCSE servers which may eventually control them.

A.3.4 Service flows p. 18

The local fire fighters are called to the scene and use GCSE Group A. They notice casualties. The local ambulance personnel attend to the casualties and use GCSE Group B.

A second chemical storage tank is seen to be in imminent danger of rupture so the Fire Service Dispatcher adds GCSE Group B to Group A to form a composite group, in order to keep Ambulance personnel appraised of the situation. Members of both groups are able to use the composite group to communicate amongst each other using all the common capabilities of the GCSE clients resident on their UEs.

The local police officers are called to the surrounding area in order to evacuate nearby residents and prevent others from entering. They use GCSE Group C. The Fire Service Dispatcher adds GCSE Group C to the composite group in order to keep them appraised. Members of all three groups are able to use the composite group to communicate amongst each other using all the common capabilities of the GCSE clients resident on their UEs.

The prevailing wind carries the gas cloud from the initial leak towards the national border so the Police Authority in the adjacent country mobilises their local force to prepare residents for evacuation. They use GCSE Group Z.

The Fire Service Dispatcher adds GCSE Group Z to the composite group to keep the police force in the adjacent country appraised. Members of all four groups are able to use the composite group to communicate amongst each other using all the common capabilities of the GCSE clients resident on their UEs.

The second chemical storage tank is successfully damped down by the local fire service, made safe, and further danger is averted. The initial gas cloud dissipates to a safe level.

The local fire fighters inform the Fire Service Dispatcher that all is safe. The Fire Service Dispatcher is able to inform all members of the composite group that the incident is over.

A.3.5 Post-condition p. 19

Having informed the composite group members that all is safe the Fire Service Dispatcher dissolves the composite group.

Communications between members of the four individual GCSE groups continue within the separate groups A, B, C, and Z.

B Group communication concept(s) p. 20

From the 3GPP network perspective the concept of a group communication appears to be a foreign concept. The concept of group communication has been the underpinnings of public safety communications currently and in the past, not point to point communications. A group communication is the ability for a set of devices to be considered as a whole. In these public safety systems the method for identifying a group communication has evolved from a particular radio frequency to an abstraction (i.e., a logical group identifier). The logical Venn diagram shown in Figure B.1 shows the concept of a group communication considering three characteristics: a member of a group (A), the device is reachable (R), and the device wants to participate (P).

Figure B.1: Group characteristics

The truth table shown in Table B.1 provides the expected actions that the 3GPP network must provide to the device based on these three characteristics.

Table B.1: Expected actions

representative device	member of group	reachable	wants to participate	actions
x8	T	T	T	receives notice, receives call, participates in communication
x7	T	T	F	receives notice, receives call, does not participate
x6	T	F	T	does not receive notice, does not receive call, does not participate
x5	T	F	F	does not receive notice, does not receive call, does not participate
x4	F	T	T	does not receive notice, does not receive call, does not participate
x3	F	T	F	does not receive notice, does not receive call, does not participate
x2	F	F	T	does not receive notice, does not receive call, does not participate
x1	F	F	F	does not receive notice, does not receive call, does not participate

Using these characteristics the 3GPP network needs to know the devices that make up the group communication so that it can make the appropriate inquiries and make the correct decisions to determine reachability, membership, and participation. The condition (or indication) to participate may be at the device level or may be a decision made by the user of the device. The 3GPP network is the only entity that knows whether a device is reachable. The application layer can indirectly obtain the reachability information from the 3GPP network (e.g., be using it to deliver an application "ping" message). As one can see from Table B.1 the actual devices that will compose the group communication may not be all of the devices that are listed as members of a group.

C Description of usage of GCSE for public safety p. 22

Based on real life scenarios, at least 36 simultaneous voice group communications involving a total of at least 2000 participating users in an area , with up to 500 users being able to participate in the same group could be expected.