9.2.1. Functional architecture

The GCS application server supports the following functions (Figure 9.1):

• – signaling exchanged via the GC1 interface with the mobile;
• – delivery of the downlink data to a group of mobiles using multicast transmission of the evolved multimedia broadcast/multicast service (eMBMS), via the MB2-U interface with the broadcast/multicast service center (BM-SC);
• – reception of the uplink data, using the unicast transmission of the EPS network, via the SGi interface with the PDN gateway (PGW);
• – management of multicast transmission via the MB2-C interface with the BM-SC entity;
• – bidirectional exchange of data, using the unicast transmission of the EPS network, via the SGi interface with the PGW entity;
• – session management, via the Rx interface with the policy and charging rules function (PCRF);
• – support for service continuity allowing the mobile to switch between unicast transmission and multicast transmission.

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).

9.2.2. Protocol architecture

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 interface is used by the GCS application server to interact with the BM-SC entity for managing eMBMS bearers;
• – the GCS application server can use the service of several BM-SC entities, each with a separate interface;
• – the BM-SC entity can provide services to several GCS application servers via a separate MB2 interface;

• – an eMBMS session is supported by a single BM-SC entity and is provided to a single GCS application server;
• – the information describing the user plane (IP address and UDP port for destination side), for data stream transmission on the MB2-U interface, must be exchanged via the MB2-C interface.

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.

9.3.1. Functional architecture

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.

9.3.1.1. Application services

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:

• – keeping track of the mobile location with regard to the availability of the multicast service;
• – requesting the allocation of resources to the BM-SC entity for transmission using the eMBMS network;
• – announcing the association of multicast resources with calls;
• – determining for each MCPTT mobile involved in a given call whether to use the unicast or multicast transmission;
• – informing the media distribution function for flows requiring support.

The MCPTT server acting as control is responsible for the following functions:

• – the call control, such as the application of rules for participation in group calls;
• – the interface with the group management server for the group policy and affiliation status information of the users served by this server;
• – the entity of the floor control management in a group call and a private call;
• – the management of the media processing entity (conference, transcoding).

The MCPTT server acting as participant is responsible for the following functions:

• – the call control, for example, authorization to participate in group calls;
• – the support of group affiliation for the MCPTT user, including enforcement of the maximum number of simultaneous group affiliations;
• – the relay of the call control and floor control messages between the MCPTT client and the MCPTT server acting as a control;
• – the media processing for its users (transcoding, recording, legal interception) for both unicast and multicast flows.

9.3.1.2. Management services

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.

9.3.2. Protocol architecture

9.3.2.1. Application services

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.

9.4.1. Group creation

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.

9.4.2. Group affiliation

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).

9.4.3. Session pre-establishment

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:

• – immediately after the pre-established session procedure;
• – using SIP signaling when an MCPTT call is initiated.

The session pre-establishment procedure concerns different types of calls:

• – group calls;
• – private calls;
• – group emergency calls;
• – group calls in case of imminent danger;
• – private emergency calls;
• – emergency alerts.

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.

9.4.4. Group call

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.

9.4.5. Private call

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 automatic start-up mode, in which the establishment of the private call does not require any action on the part of the recipient;
• – the manual start-up mode, in which the establishment of the private call requires the recipient to accept or reject the establishment of the call.

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.

9.4.6. Floor

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 call setup request is possibly routed in the request for floor in the uplink or in the information for floor in the downlink;
• – the call release request is possibly routed in the request for floor release in the uplink or in the downlink.

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.