5 Functional entities

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

This clause associates the functional entities with the MCPTT roles described in the stage 2 architecture document (see 3GPP TS 23.379 [3]).

5.2 MCPTT client

To be compliant with the procedures in the present document, an MCPTT client shall:

– act as the user agent for all MCPTT application transactions (e.g. initiation of a group call); and

– support handling of the MCPTT client ID as described in clause 4.10.

To be compliant with the on-network procedures in the present document, an MCPTT client shall:

– support the MCPTT client on-network procedures defined in 3GPP TS 23.379 [3];

– support the GCS UE procedures defined in 3GPP TS 23.468 [57] for unicast delivery, MBMS delivery and service continuity;

– act as a SIP UA as defined in 3GPP TS 24.229 [4];

– generate SDP offer and SDP answer in accordance with 3GPP TS 24.229 [4] and clause 6.2;

– act as a floor participant responsible for floor requests and implement the on-network procedures for floor requests as specified in 3GPP TS 24.380 [5];

– for registration and service authorisation, implement the procedures specified in clause 7.2;

– for pre-established sessions, implement the procedures specified in clause 8.2.1, clause 8.3.1, clause 8.4.1, and the procedures specified in 3GPP TS 24.380 [5];

– for affiliation, implement the procedures specified in clause 9.2;

– for functional alias management, implement the procedures specified in clause 9A.2;

– for group call functionality (including broadcast, emergency and imminent peril), implement the MCPTT client procedures specified in clause 10.1; and

– for private call functionality (including emergency), implement the MCPTT client procedures specified in clause 11.1;

– for emergency alert, implement the procedures specified in clause 12.1;

– for location reporting, implement the procedures specified in clause 13.3; and

– for MBMS transmission usage, implement the procedures in clause 14.3.

To be compliant with the off-network procedures in the present document, an MCPTT client shall:

– support the off-network procedures defined in 3GPP TS 23.379 [3];

– support the MCPTT off-network protocol (MONP) defined in clause 15;

– act as a floor participant for floor requests and implement the off-network procedures for floor requests as specified in 3GPP TS 24.380 [5];

– act as a floor control server providing distributed floor control and implement the off-network procedures for floor control as specified in 3GPP TS 24.380 [5];

– implement the procedures for ProSe direct discovery for public safety use as specified in 3GPP TS 24.334 [28];

– implement the procedures for one-to-one ProSe direct communication for Public Safety use as specified in 3GPP TS 24.334 [28];

– implement the procedures for one-to-many ProSe direct communication for Public Safety use as specified in 3GPP TS 24.334 [28];

– for group call functionality (including emergency and imminent peril), implement the MCPTT client procedures specified in clause 10.2;

– for broadcast group call functionality implement the procedures specified in clause 10.3; and

– for private call functionality (including emergency), implement the MCPTT client procedures specified in clause 11.2.

To be compliant with the service continuity procedures in the present document, an MCPTT client shall:

– implement the registration requirements for service continuity as specified in clause 7.2.1; and

– implement the procedures specified in clause 14A.

To be compliant with the on-network and off-network procedures in the present document requiring end-to-end private call security key distribution, an MCPTT client shall support the procedures specified in 3GPP TS 33.180 [78].

To be compliant with the procedures for confidentiality protection of XML elements in the present document, the MCPTT client shall implement the procedures specified in clause 6.6.2.

To be compliant with the procedures for integrity protection of XML MIME bodies in the present document, the MCPTT client shall implement the procedures specified in clause 6.6.3.

5.3 MCPTT server

5.3.1 General

An MCPTT server can perform the controlling role for group calls and private calls as defined in 3GPP TS 23.379 [3].

An MCPTT server can perform the participating role for group calls and private calls as defined in 3GPP TS 23.379 [3].

An MCPTT server can perform a non-controlling role for temporary group calls involving groups from multiple MCPTT systems as specified in 3GPP TS 23.379 [3].

An MCPTT server can perform a non-controlling role for temporary group calls involving groups only from the primary MCPTT system.

An MCPTT server performing the participating role can serve an originating MCPTT user.

An MCPTT server performing the participating role can serve a terminating MCPTT user.

The same MCPTT server can perform the participating role and controlling role for the same group session.

The same MCPTT server can perform the participating role and non-controlling role for the same group session.

When referring to the procedures in the present document for the MCPTT server acting in a participating role for the served user, the term, "participating MCPTT function" is used.

When referring to the procedures in the present document for the MCPTT server acting in a controlling role for the served user, the term "controlling MCPTT function" is used.

When referring to the procedures in the present document for the MCPTT server acting in a non-controlling role for a group call, the term "non-controlling MCPTT function of an MCPTT group" is used.

To be compliant with the procedures in the present document, an MCPTT server shall:

– support the MCPTT server procedures defined in 3GPP TS 23.379 [3];

– implement the role of an AS performing 3rd party call control acting as a routing B2BUA as defined in 3GPP TS 24.229 [4];

– support the GCS AS procedures defined in 3GPP TS 23.468 [57] for unicast delivery, MBMS delivery and service continuity;

– generate SDP offer and SDP answer in accordance with 3GPP TS 24.229 [4] and clause 6.3;

– implement the role of a centralised floor control server and implement the on-network procedures for floor control as specified in 3GPP TS 24.380 [5];

– for registration and service authorisation, implement the procedures specified in clause 7.3;

– for pre-established sessions, implement the procedures specified in clause 8.2.2, clause 8.3.2, clause 8.4.2 and the procedures specified in 3GPP TS 24.380 [5];

– for affiliation, implement the procedures specified in clause 9.2.2;

– for functional alias management, implement the procedures specified in clause 9A.2.2;

– for group call functionality (including broadcast, emergency and imminent peril), implement the MCPTT server procedures specified in clause 10.1;

– for private call functionality (including emergency), implement the MCPTT server procedures specified in clause 11.1; and

– for priority sharing, implement the MCPTT server procedures in clause 6.7.

To be compliant with the procedures in the present document requiring the distribution of private call keying material between MCPTT clients as specified in 3GPP TS 33.180 [78], an MCPTT server shall ensure that the keying material is copied from incoming SIP messages into the outgoing SIP messages.

To be compliant with the procedures for confidentiality protection of XML elements in the present document, the MCPTT server shall implement the procedures specified in clause 6.6.2.

To be compliant with the procedures for integrity protection of XML MIME bodies in the present document, the MCPTT server shall implement the procedures specified in clause 6.6.3.

5.3.2 Functional connectivity models

The following figures give an overview of the connectivity between the different functions of the MCPTT server as described in clause 5.3.1.

NOTE: Separate boxes are shown for each of the functions of the MCPTT server. In each MCPTT system, these functions can be physically combined into one MCPTT server or can be implemented on more than one MCPTT server. For example, there could be an instantiation of an MCPTT server that only serves as a controlling MCPTT function, but not as a participating MCPTT function for any MCPTT clients. When an MCPTT server supports more than one function, then sending requests from one function to another does not incur a traversal of the underlying IMS SIP core network.

Figure 5.3.2-1 shows the basic functions of the MCPTT server when operating within the primary MCPTT system.

Figure 5.3.2-1: Functions of the MCPTT server in the primary MCPTT system

Figure 5.3.2-2 shows the use of the non-controlling MCPTT function of an MCPTT group within the primary MCPTT system. This can occur due to group re-grouping of groups within the same MCPTT system, where the MCPTT server(s) of one or more of the constituent groups are not controlled by the same controlling MCPTT function as that of the temporary group. The non-controlling MCPTT function of an MCPTT group either provide the identities of the users of the group to the controlling MCPTT function, or the non-controlling MCPTT function of an MCPTT group can invite the users of the group on behalf of the controlling MCPTT function.

Figure 5.3.2-2: The non-controlling function operating in the primary MCPTT system

Figure 5.3.2-3 shows the roles of the MCPTT server in a mutual aid relationship between a primary MCPTT system and a partner MCPTT system. Here, the controlling MCPTT function is in the primary MCPTT system and the called user is homed in a partner MCPTT system.

Figure 5.3.2-3: Mutual aid relationship between the primary MCPTT system and a partner MCPTT system with the controlling MCPTT function in the primary MCPTT system

Figure 5.3.2-4 shows the roles of the MCPTT server in a mutual aid relationship between a primary MCPTT system and a partner MCPTT system. Here, the controlling MCPTT function is in the partner MCPTT system.

Figure 5.3.2-4: Mutual aid relationship between the primary MCPTT system and a partner MCPTT system with the controlling MCPTT function in the partner MCPTT system

Figure 5.3.2-5 shows the roles of the MCPTT server in a mutual aid relationship between a primary MCPTT system and a partner MCPTT with the use of a non-controlling MCPTT function of an MCPTT group within the partner MCPTT system. This can occur due to group re-grouping where the MCPTT server(s) of one or more of the constituent groups are homed on the partner system. If the primary MCPTT system and partner MCPTT system operate in a trusted mutual aid relationship, then the non-controlling MCPTT function of an MCPTT group can provide the identities of the users of the group to the controlling MCPTT function. If the primary MCPTT system and partner MCPTT system operate in an untrusted mutual aid relationship, then the non-controlling MCPTT function of an MCPTT group invites the users of the group on behalf of the controlling MCPTT function.

Figure 5.3.2-5: Mutual aid relationship between the primary MCPTT system and a partner MCPTT system involving the use of a non-controlling MCPTT function of an MCPTT group in the partner MCPTT system

Figure 5.3.2-6 illustrates a functional connectivity model involving multiple partner systems where the partner system that owns the group does not home any of the group members.

Figure 5.3.2-6: : Mutual aid relationship between the primary MCPTT system and more than one partner MCPTT system

Other functional connectivity models can exist.

5.3.3 Failure case

When initiating a failure response to any received request, depending on operator policy, the MCPTT server may insert a SIP Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "as" and the "role" header field parameter set to "pf-mcptt-server", "cf-mcptt-server" or "ncf-mcptt-server" depending on the current role endorsed by the MCPTT server and in accordance with clause 7.2.17 of 3GPP TS 24.229 [4].

5.3.4 Management of MBMS bearers

When providing services over MBMS, an MCPTT server acting in the participating MCPTT function role shall:

– allocate TMGIs and activate MBMS bearers in MBMS service areas to be used for MCPTT media and media control distribution via multicast, per 3GPP TS 23.468 [57] and 3GPP TS 29.468 [42];

– deactivate MBMS bearers and deallocate TMGIs when no longer necessary, per 3GPP TS 23.468 [57] and 3GPP TS 29.468 [42];

– handle MBMS bearers related notifications per 3GPP TS 23.468 [57] and 3GPP TS 29.468 [42]; and

– adjust the priority / pre-emption characteristics of MBMS bearers, as appropriate, in response to relevant events (e.g. emergency or imminent peril call), using procedures specified in per 3GPP TS 23.468 [57] and 3GPP TS 29.468 [42].

5.4 MCPTT UE-to-network relay

To be compliant with the procedures in the present document for service continuity, an MCPTT UE- to-network relay shall support the UE-to-network relay procedures as specified in 3GPP TS 24.334 [28] and 3GPP TS 23.379 [3].

5.5 MCPTT gateway server

5.5.1 General

To allow interconnection between MCPTT system in different trust domains, MC Gateway Servers can be optionally added on the path between controlling and participating MCPTT functions.

An MCPTT gateway server acts as a SIP and HTTP proxy for signalling with a partner MCPTT system in a different trust domain.

An MCPTT gateway server acts as an application and security gateway with a partner MCPTT system in a different trust domain.

An MCPTT gateway server provides topology hiding to the partner MCPTT system in a different trust domain.

An MCPTT gateway server enforces local policies and local security.

An MCPTT gateway server can be an exit point from its MCPTT system to a partner MCPTT system in a different trust domain, an entry point to its MCPTT system from a partner MCPTT system in a different trust domain, or both.

An MCPTT gateway server is transparent to MCPTT controlling and participating servers. When required for interconnection, MC gateway servers URIs are known and used by MCPTT servers in place of the PSIs of the interconnected MCPTT server. The MCPTT server does not need to know if it finally addresses directly an MCPTT controlling function or an intermediate MCPTT gateway server.

To be compliant with the procedures in the present document, an MCPTT gateway server shall:

– support the MC gateway server procedures defined in 3GPP TS 23.280 [82] and 3GPP TS 23.379 [3]; and

– support the MC gateway server procedures defined in 3GPP TS 33.180 [78];

– implement the procedures specified in clause 6.8

To be compliant with the procedures for confidentiality protection in the present document, the MCPTT gateway server shall implement the procedures specified in clause 6.6.2, acting on behalf of the MCPTT server when sending or receiving confidentiality protected content to or from an MCPTT server in another trust domain.

To be compliant with the procedures for integrity protection of XML MIME bodies in the present document, the MCPTT gateway server shall implement the procedures specified in clause 6.6.3, acting on behalf of the MCPTT server when sending or receiving integrity protected content to or from an MCPTT server in another trust domain.

5.5.2 Functional connectivity models

The following figures give an overview of the connectivity between the different functions of the MCPTT server in different trust domains when MCPTT gateway servers are used.

Figure 5.5.2-1 shows the roles of the MCPTT servers in a non trusted relationship between a primary MCPTT system and a partner MCPTT system. Here, the originating participating MCPTT function and the controlling MCPTT function are in the primary MCPTT system and a terminating participating MCPTT function is in a partner MCPTT system.

Figure 5.5.2-1: Non trusted relationship between the primary MCPTT system and a partner MCPTT system with a terminating participating MCPTT function in the partner MCPTT system

Figure 5.5.2-2 shows the roles of the MCPTT servers in a non trusted relationship between a primary MCPTT system and a partner MCPTT system. Here, the originating participating MCPTT function is in the primary MCPTT system and the controlling MCPTT function and a terminating participating MCPTT function are in a partner MCPTT system.

Figure 5.5.2-2: Non trusted relationship between the primary MCPTT system and a partner MCPTT system with a controlling MCPTT function in the partner MCPTT system

Other functional connectivity models for non trusted relationship exist, based on the same principle of use of MCPTT gateway servers, e.g. with non-controlling MCPTT functions.