5 Functional requirements
22.4683GPPGroup Communication System Enablers (GCSE)Release 17TS
5.1 Overall requirements
5.1.1 High level requirements
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.
Note 1: As GCSE Groups can be composed of users from different agencies in different territories using GCSE clients provided by different manufacturers it is essential that multi-vendor interworking is facilitated.
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.
Note 2: This requirement accommodates the need to support a console-type dispatching device, which is most often a wired device used in Group Communications by Public Safety.
5.1.2 Performance
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.
Note: The 300 ms indicated in the preceding requirements is based on requirements from ETSI ETR 086 [8] for legacy TETRA mission critical voice systems. It is understood that these requirements are particularly important for half duplex voice communication and other data that is delay sensitive. These requirements may not be met in some cases where the data is delay insensitive e.g., a large document and/or where the type of Group Communication requires acknowledgement(s) from Receiver Group Members before it is allowed to proceed.
- 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
When UEs are moving among cells during Group Communication, service continuity shall be supported.
5.1.4 Resource efficiency
The system shall provide a mechanism to efficiently distribute data for Group Communication.
5.1.5 Scalability
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.
Note: This includes both multiple Group Communications within the same GCSE Group, and multiple Group Communications associated with multiple GCSE Groups. The actual number of such Group Communications achievable and desirable will depend on the type of media.
5.1.6 Security requirements for Group Communication
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
The system shall support the collection of resource and service usage information for Group Communication.
5.1.8 Roaming and network interworking requirements
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
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
5.2.1 Creation, modification, and deletion of GCSE Groups
5.2.1.1 General
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
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
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
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
5.3.1 Group Communication setup requirements
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
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
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
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
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.
Note: During the lifetime of a Group Communication the Receiver Group Members of the Group Communication may change. In the case where there are no Receiver Group Members, Transmitter Group Members would need to know that there are no other Receiver Group Members, and when another Receiver Group Member returns to the Group Communication.
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
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.