The provision of a group communication service is achieved through the introduction of two complementary functionalities, one called the group communication system enablers (GCSE) and the other the mission critical push to talk (MCPTT).
The separation of two features has been chosen to flexibly accommodate the operational needs of group communication services that should be different for different types of user groups.
The GCSE function allows mobile devices to participate in group communication for multiple groups in parallel, which can be one or more voice, video or data communications. This feature resides in the mobile and in a GCS application server that determines how these communications will be handled.
The MCPTT function manages group interactions such as floor control, which decides which of the mobiles that have issued a communication request is allowed to communicate, or mechanisms to join or leave a group communication in course, or creating, editing and deleting groups.
The MCPTT function operates on mobiles with radio coverage provided by the evolved universal terrestrial radio access network (E-UTRAN), and also on mobiles using a proximity service (ProSe) sidelink, without impact on the evolved packet system (EPS) or on mobiles running as ProSe relays.
The GCS application server supports the following functions (Figure 9.1):
For multicast transmission, the GCS application server uses the MB2-C interface to indicate the QCI (QoS Class Identifier) priority level applied to the flow (Table 9.1).
For unicast transmission, the GCS application server uses the Rx interface to indicate the QCI priority level applied to the flow (Table 9.1).
Table 9.1. QoS class identifier
QCI |
Resource type |
Priority |
Delay |
Error rate |
Services |
65 |
GBR |
0.7 |
75 ms |
10-2 |
Voice service Critical mission |
66 |
2 |
100 ms |
10-2 |
Voice service Non-critical mission | |
69 |
Non-GBR |
0.5 |
60 ms |
10-6 |
Telephone signaling Critical mission |
70 |
5.5 |
200 ms |
10-6 |
Data Critical mission |
The GC1 interface is defined as part of the MCPTT function.
The MB2 interface provides access to the eMBMS service support from a GCS application server.
It carries the control plane signaling (MB2-C) and the traffic plane flow (MB2-U) between the GCS server and the BM-SC entity.
The MB2 interface has the following properties:
The MB2-C interface is the reference point between the BM-SC entity and the GCS application server. This interface supports the DIAMETER protocol.
The message DIAMETER GAR (GCS-Action-Request) allows the GCS application server to request an allocation of a temporary mobile group identity (TMGI) or an activation of the multicast bearer.
The message DIAMETER GAA (GCS-Action-Answer) is the response of the BM-SC entity to the GAR message.
The message DIAMETER GNR (GCS-Notification-Request) allows the BM-SC entity to send a status notification of the TMGI or the multicast bearer.
The message DIAMETER GNA (GCS-Notification-Answer) is the response of the GCS application server to the GNR message.
The MCPTT function uses the multimedia service provided by the IP multimedia sub-system (IMS), the proximity service, the group communication service provided by the eMBMS and the data transfer provided by the EPS.
The MCPTT function is composed of two parts providing, respectively, the application services and the management services.
The application services are related to the mobile registration, the session establishment, the media negotiation, the distribution and the media mixer, as well as the floor control.
The management services are related to the group management, the configuration, the identity and the keys.
Application services are provided by the MCPTT server, which is also an instantiation of the GCS application server, in order to control multicast and unicast transmissions for group communications (Figure 9.2).
Assuming the role of a GCS application server, the MCPTT server is responsible for the following functions:
The MCPTT server acting as control is responsible for the following functions:
The MCPTT server acting as participant is responsible for the following functions:
The mobile receives an initial configuration via a boot procedure that provides the various clients (MCPTT client, group management client, configuration management client, identity management client, key management client) with the necessary information when connecting to the MCPTT function. This includes PDN connection information and identity information for all servers with which the mobile must interact.
The configuration management provides the following information: user data, user profile data, service configuration data and group configuration data (Figure 9.3).
The user data sets the maximum number of simultaneous group calls and private calls when the mobile is under the coverage of the 4G network or out of coverage.
The user profile data is stored in the MCPTT database. The configuration management server is used to configure user profile data in MCPTT mobiles. The MCPTT server obtains the user profile data from the MCPTT database (Figure 9.3).
The user profile data sets authorizations to initiate and/or receive private calls and group calls.
The service configuration data is stored on the MCPTT server. The configuration management server is used to configure MCPTT mobiles (Figure 9.3).
The service configuration data defines the parameters (timers) associated with the different types of calls (group call, private call) and the floor control.
The group configuration data is stored in the group management server that configures the MCPTT mobile and the MCPTT server (Figure 9.3).
The group configuration data is for the rules to be used for media mixing and for the group call when the mobile is under coverage of the 4G network or out of coverage.
The group management allows the group to be created by the administrator and the user group by an authorized user or by the dispatcher. Group grouping allows dispatchers or authorized users to temporarily combine different groups (Figure 9.3).
The MCPTT mobile requires a token that allows access to different servers. The identity management client must be authenticated by the identity management server that provides the authorization token (Figure 9.3).
When an MCPTT client is granted access to the MCPTT domain, it can obtain the key associated with the user’s identity using the authorization token.
The identity keys are required to support key distribution for SIP signaling, floor control and data. The key management server provides the identity keys to the key management client, the group management server and the MCPTT server (Figure 9.3).
The key distribution for signaling and floor control is performed by the MCPTT client that sends the key to the MCPTT server.
The group key distribution is performed by the group management server that sends the group key to the different MCPTT clients. The group management server may distribute the group key to the MCPTT server to enable use of the media mixer function.
In the case of a private call, the key distribution is performed by the mobile that initializes the call.
Since the MCPTT server assumes the functions of the GCS AS server, the MCPTT-1 interface corresponds to the GC1 reference point.
The MCPTT-1 interface is the reference point between the MCPTT client and the MCPTT server. The MCPTT-1 interface supports signaling for establishing a session.
The MCPTT-1 interface uses SIP-1 and SIP-2 reference points for the transport and the routing of the session initiation protocol (SIP). The MCPTT-1 interface can use the HTTP-1 and HTTP-2 reference points (Figure 9.4).
The MCPTT-1 interface may provide the MCPTT server with location information (E-UTRAN cell global identifier (ECGI)), in order to verify the availability of multicast service for the MCPTT client.
The MCPTT-1 interface also allows the provision of the TMGI to the mobile.
The messages supported on this interface may also include information describing the mapping of transport resources to specific group calls.
The MCPTT-2 interface is the reference point between the MCPTT server and the MCPTT database, via the DIAMETER protocol, to retrieve information about a specific user.
The MCPTT-3 interface is the reference point between MCPTT servers. The MCPTT-3 interface uses the SIP-2 reference point or SIP-2 and SIP-3 reference points for the transport and the routing of SIP signaling (Figure 9.5).
The MCPTT-4 interface is the reference point between the floor control server and the floor control client, for the signaling transmitted on unicast support. The MCPTT-4 interface uses the SGi reference point.
Since the MCPTT server assumes the functions of the GCS AS server, the MCPTT-5 interface corresponds to the Rx reference point.
The MCPTT-5 interface is the reference point between the media distribution function and the PCRF entity, in order to obtain the QoS parameters of the bearer.
Since the MCPTT server assumes the functions of the GCS AS server, the MCPTT-6 interface corresponds to the MB2-C reference point.
The MCPTT-6 interface is the reference point between the MCPTT server and the BM-SC entity for the activation of the multicast bearer.
The MCPTT-7 interface is the reference point between the media distribution function and the media mixer, for unicast media exchange. The MCPTT-7 interface uses the SGi reference point.
The MCPTT-8 interface is the reference point between the media distribution function and the media mixer, for multicast media transfer. The MCPTT-8 interface uses the MB2-U reference point.
The MCPTT-9 interface is the reference point between the floor control server and the floor control client, for the signaling transmitted on the multicast support. The MCPTT-9 interface uses the MB2-U reference point.
The CSC-1 interface is the reference point between the server and the client performing the identity management.
The CSC-2 interface is the reference point between the server and the client performing the group management.
This interface uses SIP-1 and SIP-2 reference points for the transport and the routing of subscription-related signaling, and HTTP-1 and HTTP-2 reference points for the transport and the routing of signaling not related to the subscription.
The CSC-3 interface is the reference point between the server performing the group management and the MCPTT server.
This interface uses the SIP-2 reference point for the transport and the routing of subscription-related signaling, and the HTTP-1 and HTTP-2 reference points for the transport and the routing of signaling not related to the subscription.
The CSC-4 interface is the reference point between the server and the client performing the configuration management.
This interface uses SIP-1 and SIP-2 reference points for the transport and the routing of subscription-related signaling, and HTTP-1 and HTTP-2 reference points for the transport and the routing of signaling not related to the subscription.
The CSC-5 interface is the reference point between the server performing the configuration management and the MCPTT server.
This interface uses the SIP-2 reference point for the transport and the routing of subscription-related signaling, and the HTTP-1 and HTTP-2 reference points for the transport and the routing of signaling not related to the subscription.
The CSC-7 interface is the reference point between the servers performing the group management.
This interface uses SIP-2 and SIP-3 reference points for the transport and the routing of subscription-related signaling, and HTTP-1, HTTP-2 and HTTP-3 reference points for the transport and the routing of signaling not related to the subscription.
The CSC-8 interface is the reference point between the server and the client performing the key management. The CSC-8 interface uses the HTTP-1 and HTTP-2 reference points.
The CSC-9 interface is the reference point between the server performing the key management and the MCPTT server. The CSC-9 interface uses the HTTP-1 and HTTP-2 reference points.
The CSC-10 interface is the reference point between the servers performing, on the one hand, the key management and, on the other hand, the group management. This interface uses the HTTP-1, HTTP-2 and possibly HTTP-3 reference points.
The CSC-11 interface is the reference point between the server and the client performing the sidelink configuration management when the mobile is out of coverage. This interface uses HTTP-1 and HTTP-2 reference points.
The CSC-12 interface is the reference point between the server and the client performing the sidelink group management, when the mobile is out of coverage. This interface uses the HTTP-1 and HTTP-2 reference points.
The CSC-13 interface is the reference point between the server performing the configuration management and the user’s database.
The signaling exchanged for the application services on the MCPTT-x interfaces and the management services on the CSC-x interfaces is carried by the SIP and HTTP protocols.
The SIP-1 interface is the reference point between the SIP client (the mobile) and the SIP core. This interface allows mobile registration, event subscription and notification, TMGI communication, session establishment and media negotiation.
The SIP-2 interface is the reference point between the SIP application server (MCPTT function) and the SIP core. This interface makes it possible to inform the application server about the mobile activities: registration, event subscription and notification, the TMGI communication, session establishment and media negotiation.
The SIP-3 interface is the reference point between SIP cores. This interface allows event subscription and notification, session establishment and media negotiation.
The HTTP-1 interface is the reference point between the HTTP client (the mobile) and the HTTP proxy server.
The HTTP-2 interface is the reference point between the HTTP server (MCPTT function) and the HTTP proxy server.
The HTTP-3 interface is the reference point between HTTP proxy servers.
The procedure for creating a group is depicted in Figure 9.6.
1) The group management client (administrator, dispatcher), authorized to create a group, sends a request to the group management server. User identities must be included in this message.
2) When creating the group, the group management server creates and stores the group information from the group configuration data. The group management server checks the maximum limit of the total number of members of the MCPTT group.
3) The group management server can notify the MCPTT server for the group creation with the information of the group members.
4) The MCPTT group members are informed by the group management server of the new configuration data of the group.
5) The group management server confirms the group creation to the group management client (administrator, dispatcher) that initialized the request.
The group affiliation procedure is described in Figure 9.7.
1) The MCPTT client requests the MCPTT server to join an MCPTT group or a set of MCPTT groups. The MCPTT client must provide their MCPTT identifier and MCPTT group identifier(s).
2) The MCPTT server checks whether the group rule is cached locally. In the opposite case, the MCPTT server requests the group rule from the group management server (2a). The MCPTT server receives group rule from the group management server (2b).
3) Depending on the group rule and the user’s subscription, the MCPTT server checks whether the MCPTT group is enabled and whether the MCPTT client is allowed to join the requested MCPTT group or not. The MCPTT server also checks the maximum limit of the total number of MCPTT groups that the user can be affiliated with at the same time.
4) If the MCPTT client is allowed to join the requested MCPTT group(s), the MCPTT server registers the user’s affiliation status for the requested MCPTT group(s).
5) The MCPTT server confirms the affiliation to the MCPTT client (5a) and updates the group management server with the user’s affiliation status for the requested MCPTT group (5b).
The session pre-establishment is a procedure between the MCPTT client and the MCPTT server in order to exchange the parameters necessary for bearer description. Once the pre-established session is complete, the bearer of the floor control messages is still active.
The MCPTT client is able to activate the voice bearer at any time:
The session pre-establishment procedure concerns different types of calls:
The session pre-establishment procedure is described in Figure 9.8.
1) The MCPTT client brings together ICE (Interactive Connectivity Establishment) candidates. The ICE mechanism is used for traversing network address translation (NAT) for SIP messages and voice streams.
2) The MCPTT client sends a request to the MCPTT server to create a pre-established session.
3) The MCPTT server performs the necessary service check, obtains the media parameters, for example by interacting with the media distribution function, and gathers the ICE candidates.
4) The MCPTT server sends a pre-established session creation response to the MCPTT client.
5) ICE candidate pair checking takes place, for example, between the MCPTT client and the media distribution function of the MCPTT server.
6) If required, the MCPTT client sends a pre-established session change request to the MCPTT server to update the ICE candidate pair for the pre-established session.
7) The MCPTT server sends a pre-established session response accepting the update of the ICE candidate pair.
The group call is activated when the mobile is under the radio coverage of the 4G network or out of coverage.
The group call is initiated by one of the group members. Initializing a pre-established group call involves inviting all other members affiliated with the group.
The group call procedure is described in Figure 9.9.
1) The MCPTT client 1 sends a group call request to the MCPTT server via the SIP core. The group call request contains the group identifier and the SDP (Session Description Protocol) message containing the media parameters.
2) The MCPTT server verifies that the MCPTT client 1 is authorized to initiate a group call for the selected group.
If allowed and if the group call is in progress for this group, the MCPTT server adds the MCPTT client 1 to the existing MCPTT group call and informs it that the MCPTT group call is already in progress.
Otherwise, the MCPTT server determines the members of this group and their affiliation status based on the information provided by the group management server.
3) The MCPTT server sends the group call request via the SIP core to MCPTT clients affiliated with the group, containing the same media parameters contained in the initial request. The MCPTT server indicates whether an acknowledgment is required for the call or not.
4) The MCPTT clients accept the group call request and a group call response is sent to the MCPTT server. This response may contain an acknowledgment of receipt.
5) The MCPTT server sends the response to the group call, including a selection of the media parameters, to the MCPTT client 1, informing it of the successful completion of the call.
6) If the MCPTT client 1 needs the acknowledgment for the MCPTT affiliate group and the group members do not acknowledge the call establishment, the MCPTT server may continue or give up the call, and then informs the MCPTT client 1.
The MCPTT server may send this notification many times to the MCPTT client 1 during the call when the MCPTT clients join the group call.
7) MCPTT clients have successfully established the user plane for communication and exchange information for the floor.
The private call is activated when the mobile is under the radio coverage of the 4G network or out of coverage.
When the mobile is under the radio coverage of the 4G network, the private call can be with or without floor control. When the mobile is not under the radio coverage, the private call is with a floor control.
The private call can be configured in two start-up modes:
The private call procedure for the automatic start-up mode is described in Figure 9.10.
1) The MCPTT client 1 sends a private call request to the MCPTT server (via the SIP core). The private call request contains an SDP offer containing one or more types of media. For a private call with floor control, the request also contains an element indicating that the MCPTT client 1 requests the floor.
2) The MCPTT server verifies whether the MCPTT client 1 is authorized to initiate the private call and whether the MCPTT client 2 is authorized to receive the private call. The MCPTT server also checks whether the MCPTT client 1 is authorized to initiate a private call in the automatic start-up mode.
3) The MCPTT server may provide the MCPTT client 1 with an indication of the call setup progress.
4) The MCPTT server sends the private call request to the MCPTT client 2. If the called party has registered with several MCPTT mobiles, the incoming private call request is then delivered only to the designated mobile.
5) The MCPTT client 2 automatically accepts the private call and an MCPTT private call response is sent to the MCPTT server (via the SIP core).
6) The MCPTT server informs the MCPTT client 1 of the successful completion of the private call.
7) MCPTT clients 1 and 2 have established the user plane for communication.
The private call procedure for the manual start-up mode is described in Figure 9.11.
1) The MCPTT client 1 sends a private call request to the MCPTT client 2 (via the SIP core).
2) The MCPTT server verifies that both MCPTT clients are allowed to establish a private call. The MCPTT server checks whether the MCPTT client 1 is authorized to initiate a call in the manual start-up mode.
3) The MCPTT server sends the private call request to the MCPTT client 2. If the MCPTT client 2 has registered several mobiles to receive the private calls, the MCPTT private call request is then transmitted only to the designated mobiles.
4) The MCPTT server may provide the MCPTT client 1 with an indication of the call setup progress.
5) The MCPTT client 2 sends a ringing indication to the MCPTT server (5a) which transfers it to the MCPTT client 1 (5b).
6) The MCPTT client 2 accepts the call using the manual start-up mode which causes the MCPTT client 2 to send a response to the private call. If the MCPTT 2 user did not accept the incoming call, the MCPTT client 2 sends a call failure response to the MCPTT server without adding the reason for the call failure.
7) The MCPTT server transfers the private call response to the MCPTT client 1.
8) The user plane for communication is established. Each user can transmit media individually.
When the floor control server receives a floor request from a participant, it decides whether or not to grant a resource according to the state of the session, the user’s profile and the priority.
When the participant receives a message attributing the floor, they may send media on the previously established uplink bearer.
Some floor control streams can also overlay call control flows to enable efficient call setup and release:
The floor procedure is described in Figure 9.12.
1) The participant A wants to send a voice medium during the session. It sends a floor request message to the floor control server which includes the floor priority.
2) The floor control server determines the action (authorization, deny or queuing) to be performed based on criteria (priority, type of participant) and decides to accept the request from participant A. The control server may limit the time during which a participant speaks.
3) The floor control server responds with an allocation message to the participant A, including the maximum allowed time.
4) The floor control server sends a floor message to the different participants.
5) The participant A begins to send a voice flow to the previously established session.
6) If one or more participants request the floor (6a), the request(s) for the floor are queued (6b) according to the decision of the floor control server, for example depending on the floor priority.
7) The floor control server sends information about the queue position to the participants.