10.4 Private call

23.2833GPPMission Critical Communication Interworking with Land Mobile Radio SystemsRelease 18TS

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

10.4.1 Information flows for private calls

10.4.1.1 General

The following subclauses define information flows for private calls on the IWF-1 interface. Private call related information flows on reference points other than IWF-1 are defined in 3GPP TS 23.379 [7].

10.4.1.2 IWF private call request

Table 10.4.1.2-1 describes the information flow IWF private call request from the MCPTT server to the IWF and from the IWF to the MCPTT server.

Table 10.4.1.2-1: IWF private call request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
Functional alias	O	The functional alias associated with the MCPTT ID of the calling party.
MCPTT ID	M	The MCPTT ID of the called party
Use floor control indication	M	This element indicates whether floor control will be used for the private call.
SDP offer	M	Media parameters of MCPTT client.
Encryption Algorithm	O	Encryption algorithm to use for the call. The field can also indicate whether the encryption algorithm choice is determined from information in the media stream.
Encryption mode	M	Whether E2EE will be used.
Requested commencement mode	O	An indication of the commencement mode to be used.
Implicit floor request (see NOTE)	O	An indication that the user is also requesting the floor.
Location	O	Location of the calling party
NOTE: This element shall be included only when the originating client requests the floor.

10.4.1.3 IWF private call response

Table 10.4.1.3-1 describes the information flow IWF private call response from the MCPTT server to the IWF and from the IWF to the MCPTT server.

Table 10.4.1.3-1: IWF private call response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
MCPTT ID	O	The MCPTT ID of the called party
Acceptance confirmation	O	An indication whether the user has positively accepted the call.
SDP answer	M	Media parameters selected
Result	M	Result of the IWF private call request: success or failure
Encryption Algorithm(s) response	O	A list of one or more alternative encryption algorithm(s) to use for the call.
Use floor control indication response	O	This element indicates whether the floor control indication in the request is acceptable.
Implicit floor request response	O	This element indicates whether the indication that the user is also requesting the floor in the request is acceptable.

10.4.1.4 IWF ringing

Table 10.4.1.4-1 describes the information flow IWF ringing from the MCPTT server to the IWF and from the IWF to the MCPTT server.

Table 10.4.1.4-1: IWF ringing information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
MCPTT ID	M	The MCPTT ID of the called party
Ringing indication	O	Indication to the caller.

10.4.1.5 IWF call end request

Table 10.4.1.5-1 describes the information flow IWF call end request from the MCPTT server to the IWF and from the IWF to the MCPTT server.

Table 10.4.1.5-1: IWF call end request information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the calling party
MCPTT ID	M	The MCPTT ID of the called party

10.4.1.6 IWF call end response

Table 10.4.1.6-1 describes the information flow IWF call end response from the IWF to the MCPTT server.

Table 10.4.1.6-1: IWF call end response information elements

Information Element	Status	Description
MCPTT ID	M	The MCPTT ID of the responding party

10.4.2 Private call setup in automatic commencement mode

10.4.2.1 MCPTT user initiating an MCPTT private call

In this procedure, an MCPTT user is initiating an MCPTT private call (automatic commencement mode) for communicating with a user in an LMR system, with or without floor control enabled.

This subclause is based on the procedure for private call setup in automatic commencement mode – MCPTT users in multiple MCPTT systems described in 3GPP TS 23.379 [7], subclause 10.7.2.3.1.

In figure 10.4.2.1-1, an MCPTT client initiates establishment of an MCPTT private call with an LMR user.

Pre-conditions:

1. The calling MCPTT user has selected automatic commencement mode for the call;

2. The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in 3GPP TS 23.379 [7].

3. Optionally, MCPTT client may use an activated functional alias for the call.

4. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 10.4.2.1-1: Private call setup in automatic commencement mode, initiated by an MCPTT user

1. The MCPTT user at the MCPTT client initiates an MCPTT private call. The MCPTT client sends an MCPTT private call request towards the MCPTT server. The MCPTT private call request contains the MCPTT IDs corresponding to the calling MCPTT party and called LMR party and an SDP offer containing one or more media types. If available, the MCPTT user at the MCPTT client may also include a functional alias. The following parameters are also included that describe the MCPTT client’s choices:

– the encryption algorithm;

– the encryption mode (encrypted or not);

– an indication of whether the MCPTT client is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;

– requested commencement mode (automatic in this case); and

– an indication of whether the call is to be full or half duplex (whether to establish floor control).

2. The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized to initiate the private call and whether the provided functional alias, if present, can be used and has been activated for the user. Because the IWF private call request is requesting automatic commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to initiate a call in automatic commencement mode. If location information was included in the MCPTT private call request, the MCPTT server also checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in 3GPP TS 23.379 [7] Annex A.3) of the requesting MCPTT user to decide if the user’s location information may be provided to other MCPTT users on the call and the IWF.

3. If authorized, the MCPTT server sends the IWF private call request that may or may not include location of the requestor, depending on the outcome of the privacy check towards the IWF, including the original parameters and offering the same media types or a subset of the media types contained in the initial received request as per 3GPP TS 23.379 [7].

NOTE: How the IWF private call request is forwarded to the LMR system is out of scope of the present document.

4. The IWF sends an IWF private call response to the MCPTT server, indicating that the IWF does support one of the requested media types. The response indicates success or failure. If the indication is failure, the response may include one or more alternatives to the parameter values contained in step 3.

5. The MCPTT server forwards the MCPTT private call response to the MCPTT client. If the result parameter indicates success, then the MCPTT client proceeds to step 6. Otherwise, if the parameters returned in the MCPTT private call response are acceptable to the MCPTT client, then the MCPTT client can send a new MCPTT private call request with the new parameters and behaves according to those parameters. The calling MCPTT user may be notified of the change in parameters, for example, that the call is to be without floor control. The MCPTT user can choose to end the call rather than continue with the new parameters. If the parameters returned are not acceptable to the MCPTT client, then the call fails.

6. The MCPTT client has successfully established media plane for communication to the IWF and either end can transmit media. The MCPTT system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.

10.4.2.2 LMR user initiating a private call with MCPTT user

In this procedure, an LMR user is initiating a private call (in automatic commencement mode) for communicating with a user in MCPTT system, with or without floor control enabled.

This subclause is based on the procedure for private call setup in automatic commencement mode – MCPTT users in multiple MCPTT systems described in 3GPP TS 23.379 [7], subclause 10.7.2.3.1.

In figure 10.4.2.2-1, an LMR user initiates establishment of a private call with an MCPTT user.

Pre-conditions:

1. The calling LMR user has selected automatic commencement mode for the call;

2. The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in 3GPP TS 23.379 [7].

3. The LMR user at the LMR system has initiated a private call towards an MCPTT user.

4. Optionally, LMR user may use an activated functional alias (homed in the MCPTT system) for the call.

5. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

NOTE 1: Private call operation between the LMR user and the IWF are out of scope of the present document.

NOTE 2: The mapping between alternative addressing schemes of the LMR user and the corresponding functional alias is out of scope of the present document.

Figure 10.4.2.2-1: Private call setup in automatic commencement mode, initiated by an LMR user

1. The IWF sends an IWF private call request towards the MCPTT server. The IWF private call request contains the MCPTT IDs corresponding to the calling LMR party and the called MCPTT party and an SDP offer containing one or more media types. If available, the LMR party homed in the IWF may also include a functional alias. The following parameters are also included that describe the MCPTT client’s choices:

– the encryption algorithm;

– the encryption mode (encrypted or not);

– an indication of whether the LMR user is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;

– requested commencement mode (automatic in this case); and

– an indication of whether the call is to be full or half duplex (whether to establish floor control).

2. The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized and able to receive the private call. Because the IWF private call request is requesting automatic commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to receive a call in automatic commencement mode. The MCPTT server also checks whether the provided functional alias, if present, can be used and has been activated for the LMR user homed in the IWF.

3. If authorized, the MCPTT server sends the MCPTT private call request towards the MCPTT client, including the original parameters with or without the location of the calling party and offering the same media types or a subset of the media types contained in the initial received request as per 3GPP TS 23.379 [7].

4. The MCPTT client sends an MCPTT private call response to the MCPTT server indicating that the MCPTT client does support one of the requested media types. The response indicates success or failure. If the indication is failure, the response may also include one or more alternatives to the parameter values contained in step 3.

5. The MCPTT server sends the IWF private call response to the IWF offering the same media type as that sent in step 4. If the parameters returned are not acceptable to the IWF, then the call fails. If the parameters returned in the IWF private call response are different but acceptable to the IWF, then the IWF can send a new IWF private call request with the new parameters starting with step 1, which is to essentially restart the call. If there is no change of parameter, then the call proceeds to step 6.

NOTE 3: The calling LMR user may be notified of the change in parameters, for example, that the call is to be without floor control.

6. The MCPTT client has successfully established media plane for communication to the IWF and either end can transmit media. The LMR system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.

10.4.3 Private call setup in manual commencement mode

10.4.3.1 MCPTT user is initiating an MCPTT private call

In this procedure, an MCPTT user is initiating an MCPTT private call (manual commencement mode) for communicating with an LMR user via an IWF, with or without floor control enabled.

This subclause is based on the procedure for private call setup in manual commencement mode – MCPTT users in multiple MCPTT systems described in 3GPP TS 23.379 [7], subclause 10.7.2.3.2.

In figure 10.4.3.1-1, an MCPTT client initiates establishment of an MCPTT private call with an LMR user.

Pre-conditions:

1. The calling MCPTT user has selected manual commencement mode for the call.

2. The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in 3GPP TS 23.379 [7].

3. Optionally, MCPTT client may use an activated functional alias (homed in the MCPTT system) for the call.

4. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 10.4.3.1-1: Private call setup in manual commencement mode – initiated by an MCPTT user

1. The MCPTT user at the MCPTT client would like to initiate an MCPTT private call. The MCPTT client sends an MCPTT private call request towards the MCPTT server. The MCPTT private call request contains the MCPTT IDs corresponding to the calling MCPTT party and called LMR party and an SDP offer containing one or more media types. If available, the MCPTT user at the MCPTT client may also include a functional alias. The following parameters are also included that describe the MCPTT client’s choices:

– the encryption algorithm;

– the encryption mode (encrypted or not)

– an indication of whether the MCPTT client is requesting the floor;

– requested commencement mode (manual in this case), and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided; and

– an indication of whether the call is to be full or half duplex (whether to establish floor control).

2. The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized to initiate the private call and whether the provided functional alias, if present, can be used and has been activated for the user. Because the IWF private call request is requesting manual commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to initiate a call in manual commencement mode. If location information was included in the MCPTT private call request, the MCPTT server also checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in 3GPP TS 23.379 [7] Annex A.3) of the requesting MCPTT user to decide if the user’s location information may be provided to other MCPTT users on the call and the IWF.

3. If authorized, the MCPTT server sends the IWF private call request towards the IWF, including the original parameters that may or may not include location of the requestor, depending on the outcome of the privacy check, and offering the same media types or a subset of the media types contained in the initial received request as per 3GPP TS 23.379 [7].

NOTE: How the IWF private call request is forwarded to the LMR system is out of scope of the present document.

4. The IWF may report failure with an IWF private call response to the MCPTT server. The response may include one or more alternatives to the parameter values contained in step 3. If the IWF does not report failure, the process proceeds with step 6.

5. The MCPTT server forwards the MCPTT private call response to the MCPTT client. If the result parameter indicates failure, the MCPTT client may abandon the call. If the parameters in the MCPTT private call response are acceptable to the MCPTT client, then the MCPTT client can send a new MCPTT private call request with the new parameters to the MCPTT server and behaves according to those parameters. The calling user may be notified of the change in parameters, for example, that the call is to be without floor control. The calling user may choose to end the call rather than continue with the new parameters.

6. The receiving IWF sends an IWF ringing to the MCPTT server while waiting for the call to be accepted.

7. The MCPTT server forwards the MCPTT ringing to the MCPTT client. The MCPTT client may indicate to the MCPTT user that the LMR user has been notified, e.g. by producing ringback audio.

8. Once the call has been accepted by the called user, the IWF sends an IWF private call response to the MCPTT server. The IWF private call response indicates that the IWF does support one of the requested media types.

9. The MCPTT server forwards the MCPTT private call response to the MCPTT client. The MCPTT client may indicate to the MCPTT user that the call is connected, e.g. by stopping the ringback audio.

10. The MCPTT client has successfully established media plane for communication to the IWF. The MCPTT system initiating the call is responsible of granting the floor and solving the competing floor requests, and floor revoked indications.

10.4.3.2 LMR user initiating a private call with MCPTT user

In this procedure, an LMR user is initiating a private call (in manual commencement mode) for communicating with an MCPTT user via an IWF, with or without floor control enabled.

This subclause is based on the procedure for private call setup in manual commencement mode – MCPTT users in multiple MCPTT systems described in 3GPP TS 23.379 [7], subclause 10.7.2.3.2.

In figure 10.4.3.2-1, an LMR user initiates establishment of a private call with an MCPTT user.

Pre-conditions:

1. The calling LMR user has selected manual commencement mode for the call.

2. The MCPTT client is registered to the MCPTT service, as per procedure in subclause 10.2 in 3GPP TS 23.379 [7].

3. The LMR user at the LMR system has initiated a private call towards an MCPTT user.

4. Optionally, LMR user may use an activated functional alias (homed in the MCPTT system) for the call.

5. The MCPTT server has subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.

NOTE 1: Private call operation between the LMR user and the IWF are out of scope of the present document.

NOTE 2: The mapping between alternative addressing schemes of the LMR user and the corresponding functional alias is out of scope of the present document

Figure 10.4.3.2-1: Private call setup in manual commencement mode, initiated by an LMR user

1. The IWF sends an IWF private call request towards the MCPTT server. The IWF private call request contains the MCPTT IDs corresponding to the calling LMR party and called MCPTT party and an SDP offer containing one or more media types. If available, the LMR party homed in the IWF may also include a functional alias. The following parameters are also included that describe the IWF’s choices:

– the encryption algorithm;

– the encryption mode (encrypted or not)

– an indication of whether the LMR user is requesting the floor, and if the MCPTT client is requesting the floor, location information of the calling MCPTT client may be provided;

– requested commencement mode (manual in this case); and

– an indication of whether the call is to be full or half duplex (whether to establish floor control).

2. The MCPTT server checks whether the MCPTT user at the MCPTT client is authorized and able to receive the private call. Because the IWF private call request is requesting manual commencement mode, the MCPTT server also checks whether the MCPTT user at the MCPTT client is authorized to receive a call in manual commencement mode. The MCPTT server also checks whether the provided functional alias, if present, can be used and has been activated for the LMR user homed in the IWF.

NOTE 3: How the IWF private call request is forwarded to the LMR system is out of scope of the present document.

4. The MCPTT client may report failure with an MCPTT private call response to the MCPTT server. The response may include one or more alternatives to the parameter values contained in step 3. If the MCPTT client does not report failure, the process proceeds with step 6.

5. The MCPTT server forwards the MCPTT private call response to the IWF. If the result parameter indicates failure, the IWF may abandon the call. If the parameters in the IWF private call response are acceptable to the IWF, then the IWF can send a new IWF private call request with the new parameters to the MCPTT server and behaves according to those parameters. The IWF may choose to end the call rather than continue with the new parameters.

6. The MCPTT client sends an MCPTT ringing to the MCPTT server while waiting for the call to be accepted by the MCPTT user.

7. The MCPTT server sends an IWF ringing to IWF the while waiting for the call to be accepted.

8. Once the call has been accepted by the called user, the MCPTT client sends an MCPTT private call response to the MCPTT server. The IWF private call response indicates that the IWF does support one of the requested media types.

9. The MCPTT sends the IWF private call response to the IWF.

10. The MCPTT client has successfully established media plane for communication to the IWF. The LMR system initiating the call is responsible of granting the floor, solving competing floor requests and issuing floor revoked indications.

10.4.4 Private call release

10.4.4.1 MCPTT client initiated

The procedure describes the case where an MCPTT client requests release of an ongoing MCPTT private call (with or without floor control) that was established in either of the two commencement modes (manual or automatic). This subclause is based upon the subclauses for MCPTT private call release in 3GPP TS 23.379 [7], subclauses 10.7.2.2.3.1 and 10.7.2.3.3.

Procedures in figure 10.4.4.1-1 are the basic signalling control plane procedures for the MCPTT client initiating the release of an ongoing interworked private call.

Pre-conditions:

1. The MCPTT user on the MCPTT client is already registered for receiving MCPTT service and is involved in a private call with an LMR user via the IWF with or without floor control and established either in manual or automatic commencement mode, as described in subclause 10.4.2 and subclause 10.4.3.

Figure 10.4.4.1-1: Private call release – client initiated

1. The user at the MCPTT client would like to release an ongoing interworked private call with the LMR user.

2. The MCPTT client sends an MCPTT private call end request towards the MCPTT server (via SIP core) for tearing down the private call with the other client.

3. The MCPTT server sends the corresponding IWF call end request towards the IWF, addressed to the MCPTT client ID specified in the original MCPTT private call end request.

NOTE: The LMR user is also notified about the release of the private call. How the LMR user is notified is outside the scope of the present document.

4. The IWF acknowledges the IWF call end request with an IWF call end response sent towards the MCPTT server.

5. After receiving the MCPTT private call end request acknowledgement from the IWF, the MCPTT server generates an acknowledgement for the MCPTT client’s MCPTT private call end request.

6. The MCPTT client and the IWF release all the media plane resources used for the private call. Further, if the private call was established with floor control, floor control resources are released and the MCPTT client cannot make further requests for floor control or send media.

10.4.4.2 MCPTT server initiated

The procedure describes the case where an MCPTT server terminates an ongoing interworked private call (with or without floor control) that was established in either of the two commencement modes (manual or automatic). The conditions causing the MCPTT server to terminate the call could include expiry of the MCPTT administrator configured maximum duration for MCPTT private calls or expiry of the maximum time permitted for an MCPTT private call without transmission/reception. This subclause is based upon the subclauses for MCPTT private call release in 3GPP TS 23.379 [7], subclauses 10.7.2.2.3.2 and 10.7.2.3.3.

Procedures in figure 10.4.4.2-1 are the basic signalling control plane procedures for the MCPTT server initiating termination of an ongoing interworked private call.

Pre-conditions:

Figure 10.4.4.2-1: End private call – server initiated

1. Upon conditions to terminate call e.g., MCPTT administrator configured maximum duration for MCPTT private calls expiry or time out due to MCPTT private call without transmission/reception, the MCPTT server decides to initiate termination of an ongoing interworking private call between the MCPTT client and the LMR user.

2a. The MCPTT server sends an MCPTT private call end request towards the MCPTT client (via SIP core) for tearing down the private call.

2b. The MCPTT server sends a corresponding IWF call end request towards the MCPTT client identity associated with the LMR user

3. The MCPTT user at the MCPTT client is notified about the termination of the private call.

NOTE: The LMR user is also notified about the termination of the private call. How the LMR user is notified is outside the scope of the present document.

4. The MCPTT client and the IWF acknowledge the request.

5. The MCPTT client and the IWF release all the media plane resources used for the private call. Further, if the private call was established with floor control, floor control resources are released and the MCPTT client cannot make further requests for floor control or send media.

10.4.4.3 LMR user initiated

The procedure describes the case where either an LMR user or the LMR system is requesting to release an ongoing interworked private call (with or without floor control) and the call established in either of the two commencement modes (manual or automatic). This subclause is based upon the subclauses for MCPTT private call release in 3GPP TS 23.379 [7], subclauses 10.7.2.2.3.1 and 10.7.2.3.3.

Procedures in figure 10.4.4.3-1 are the basic signalling control plane procedures for the LMR user, via the IWF, initiating the release of an ongoing interworked private call.

Pre-conditions:

Figure 10.4.4.3-1: Private call release – IWF initiated

1. The LMR system would like to release an ongoing interworked private call with the MCPTT user.

2. The IWF sends an IWF call end request towards the MCPTT server for tearing down the private call with the MCPTT client.

3. The MCPTT server sends the corresponding MCPTT private call end request towards the MCPTT client specified in the original IWF call end request.

4. The MCPTT user is notified about the release of the private call.

5. The MCPTT client acknowledges the MCPTT private call end request.

6. After receiving the MCPTT private call end request acknowledgement from the MCPTT client, the MCPTT server generates an acknowledgement for the IWF’s IWF call end request.

7. The MCPTT client and the IWF release all the media plane resources used for the private call. Further, if the private call was established with floor control, floor control resources are released and the MCPTT client cannot make further requests for floor control or send media.

10.4.5 Encryption of private calls

Private calls can use MC media encryption (see 3GPP TS 33.180 [8]) between the IWF and the MCPTT client. A private call that uses an LMR vocoder may use LMR E2EE if the calling and called parties have previously been provisioned with the appropriate LMR E2EE keys.

NOTE: MC media encryption is independent of LMR E2EE techniques. MC media encryption can be applied in addition to LMR E2EE.