10.6.3 Imminent peril calls

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

10.6.3.1 General

This subclause addresses various aspects of imminent peril call interworking.

LMR systems do not support imminent peril. Imminent peril calls can be propagated into the LMR system by the IWF as normal group calls or emergency group calls. The decision of the LMR group call type is outside the scope of the present document.

Where the group is defined in the MCPTT system and where the IWF has affiliated to an MCPTT group with a single affiliation on behalf of all LMR group members, only a single IWF imminent peril group call request / IWF imminent peril cancel request message is sent to the IWF at the commencement / cancel of an imminent peril group call. Where the group is defined in the MCPTT system and where the IWF has passed through individual affiliations for each group member in the LMR system, the MCPTT system shall send individual IWF imminent peril group call request / IWF imminent peril cancel request messages to the IWF for all affiliated group members in the LMR system in accordance with primary and partner MCPTT system behaviour. In both cases, the distribution of the messages to group members in the LMR system is out of scope of the present document.

Where the group is defined in the LMR system, the IWF shall send individual IWF imminent peril group call request / IWF imminent peril cancel request messages to the MCPTT server for all affiliated MCPTT group members in accordance with primary and partner MCPTT system behaviour.

10.6.3.2 Imminent peril group call initiated by an MCPTT user on an interworking group

Figure 10.6.3.2‑1 shows the procedure for an imminent peril group call initiated by a user in the MCPTT system. The figure is based upon the figure for imminent peril group call in 3GPP TS 23.379 [7], subclause 10.6.2.6.2.1.

NOTE 1: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

NOTE 2: The imminent peril interworking group call procedures reuse the information flows defined in 3GPP TS 23.379 [7].

Pre-conditions:

1. The initiating MCPTT client 1 has been provisioned with an MCPTT group that has been designated in the provisioning to be used for imminent peril communications

2. The MCPTT group is an interworking group defined in the MCPTT system.

3. MCPTT client 2 is affiliated to the MCPTT group.

4. The IWF is connected to, and is authorized to, interwork with the MCPTT system.

5. At least one LMR user has affiliated to the MCPTT group.

6. The mapping relationship of group and user identities between the MCPTT system and the LMR system has been configured at the IWF.

NOTE 3: For all the signalling messages passing through the IWF between the MCPTT system and the LMR system, the IWF performs the identity conversion and protocol translation.

Figure 10.6.3.2-1: Imminent peril group call initiated by a MCPTT user to an interworking group defined in the MCPTT system

1. An MCPTT user initiates an imminent peril group call.

2. The MCPTT client sends an MCPTT imminent peril group call request to the MCPTT server. The request contains an indication of the in-progress imminent peril. The request may also contain an indication of an implicit floor request and may also contain the location of the calling party.

3. The MCPTT server implicitly affiliates MCPTT client 1 to the imminent peril group if the client is not already affiliated.

4. The MCPTT server checks whether the MCPTT user of MCPTT client 1 is authorized for initiation of imminent peril group calls on the indicated interworking group defined in the MCPTT system. If authorized, it resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status. 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.

5. The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.

NOTE 4: Successive calls during the in-progress imminent peril state will all receive the adjusted bearer priority.

6. The MCPTT server records the imminent peril state of the group. The MCPTT server also records the identity of the MCPTT user that initiated the imminent peril group call until the in-progress imminent peril state is cancelled. Once an imminent peril group call has been initiated, the MCPTT group is considered to be in an in-progress imminent peril state until that state is cancelled.

7. The MCPTT server sends the IWF imminent peril group call request(s) to the IWF. If the IWF has affiliated to this group on behalf of the group’s LMR users, only one IWF imminent peril group call request message is sent to the IWF. If the MCPTT server has received individual affiliations from the group’s LMR users, an individual IWF imminent peril group call request is sent to the IWF for each affiliated LMR user.

8. The IWF responds with the IWF imminent peril group call response(s) to MCPTT server to inform of the successful MCPTT imminent peril call establishment.

NOTE 5: The IWF can reject the request if it does not support imminent peril group calls. IWF actions for priority are out of scope of the present document.

NOTE 6: How the LMR group members are called within the LMR system is out of scope of the present document.

9. The MCPTT server sends the imminent peril group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of the in-progress imminent peril. MCPTT users are notified of the incoming imminent peril call. The MCPTT clients acknowledge the imminent peril call request as specified in 3GPP TS 23.379 [7].

10. The MCPTT server sends the MCPTT imminent peril group call response to the MCPTT user 1 to inform the successful imminent peril call establishment.

NOTE 7: Step 10 can occur at any time following step 5, and prior to step 11 depending on the conditions to proceed with the imminent peril call.

11. The LMR users via the IWF and the affiliated MCPTT clients have successfully established the media plane for communication. The MCPTT system, where the interworking group is defined, is the controlling system of the group call.

10.6.3.3 Group call initiated by a user in the LMR system on an interworking group in imminent peril state

Figure 10.6.3.3‑1 shows the procedure for a group call initiated by an LMR user (represented by the IWF) on an interworking group where the group is currently in imminent peril state within the MCPTT system.

NOTE 1: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

NOTE 2: The imminent peril interworking group call procedures reuse the information flows defined in 3GPP TS 23.379 [7].

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 1, MCPTT client 2, and LMR users (represented by the IWF) affiliated to that MCPTT group.

2. The IWF is connected to, and is authorized to interwork with, the MCPTT system.

3. The interworking group information is available at the IWF.

4. The interworking group is currently in imminent peril state within the MCPTT system.

5. The mapping relationship of group and user identities between the MCPTT system and the LMR system has been configured at the IWF.

6. LMR user initiates a group call.

NOTE 3: For all the signalling messages passing through the IWF between the MCPTT system and the LMR system, the IWF performs the identity conversion and protocol translation.

Figure 10.6.3.3-1: Group call initiated by a user in the LMR system on an interworking group in imminent peril state

1. The IWF does not track the imminent peril state of the group and sends an IWF group call request including an MCPTT group ID to the MCPTT server for call establishment. If floor control is requested by the calling LMR user, an indication of implicit floor request is included and the location information of the requestor if required.

2. The MCPTT server determines that the MCPTT group is currently in imminent peril state.

3. The MCPTT server converts the request and sends an MCPTT imminent peril group call request to all of the affiliated MCPTT clients.

3a. If the group has other affiliated LMR users than the calling party and the MCPTT server has received individual affiliations from those LMR users, an individual IWF imminent peril group call request is sent to the IWF for each affiliated LMR user.

4. The receiving MCPTT clients send the MCPTT imminent peril group call response to the MCPTT server to acknowledge the MCPTT imminent peril group call request. For a multicast call, these acknowledgements are not sent.

4a. The IWF returns IWF imminent peril group call response(s) to the MCPTT server.

5. The MCPTT server sends the IWF imminent peril group call response message to the IWF.

6. The LMR users (via the IWF) and the affiliated MCPTT clients have successfully established the media plane for communication. The MCPTT system where the interworking group is defined is the controlling system of the group call.

The IWF, MCPTT client 1, and MCPTT client 2 continue with the MCPTT group call, which receives adjusted bearer priority within the MCPTT system due to the MCPTT group being in imminent peril state.

NOTE 4: IWF actions for priority are out of scope of the present document.

10.6.3.4 In-progress imminent peril state cancel on an interworking group

This procedure describes the case where an authorized MCPTT user cancels an interworking group’s in-progress imminent peril state.

Figure 10.6.3.4‑1 shows the procedures for the MCPTT client cancelling an interworking group’s in-progress imminent peril state.

NOTE 1: The end of an imminent peril call does not cancel the MCPTT group’s in-progress imminent peril state. It is explicitly cancelled by an authorized user.

NOTE 2: For simplicity, a single MCPTT server is shown in place of a user home MCPTT server and a group hosting MCPTT server.

NOTE 3: The in-progress imminent peril interworking group state cancel procedures reuse the information flows defined 3GPP TS 23.379 [7].

Pre-conditions:

1. The MCPTT group is previously defined on the group management server with MCPTT client 1, MCPTT client 2, and LMR users (represented by the IWF) affiliated to that MCPTT group.

2. The IWF is connected to, and is authorized to interwork with, the MCPTT system.

3. The interworking group information is available at the IWF.

4. The interworking group is currently in in-progress imminent peril state within the MCPTT system and has prioritized bearer support.

5. The mapping relationship of group and user identities between the MCPTT system and the LMR system has been configured at the IWF.

NOTE 4: For all the signalling messages passing through the IWF between the MCPTT system and the LMR system, the IWF performs the identity conversion and protocol translation.

6. MCPTT client 1 previously initiated the imminent peril group call.

Figure 10.6.3.4-1: In-progress imminent peril group state cancel on an interworking group

1. The user at the MCPTT client 1 initiates an in-progress imminent peril state cancel.

2. MCPTT client 1 sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT server.

3. The MCPTT server checks whether the MCPTT user 1 at MCPTT client 1 is authorized to cancel the in-progress imminent peril group state.

4. The MCPTT server cancels/resets the in-progress imminent peril group state.

5. The MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required.

6. The MCPTT server sends an IWF in-progress imminent peril group state cancel request(s) to the IWF. If the IWF has affiliated to this group on behalf of the group’s LMR users, only one IWF in-progress imminent peril group state cancel request is sent to the IWF. If the MCPTT server has received individual affiliations from the group’s LMR users, an individual IWF in-progress imminent peril group state cancel request is sent (to the IWF) for each affiliated LMR user.

7. The IWF sends the IWF in-progress imminent peril group state cancel response(s) to the MCPTT server.

NOTE 5: The IWF responds even if it does not support imminent peril group calls. IWF actions for priority are out of scope of the present document.

8. The MCPTT server sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT group members.

NOTE 6: Steps 6 and 8 can occur in any order following step 5.

9. MCPTT group members are notified of the in-progress imminent peril group state cancel.

10. MCPTT client 2 sends the MCPTT in-progress imminent peril group state cancel response to the MCPTT server to acknowledge the in-progress MCPTT in-progress imminent peril group state cancel request. For a multicast scenario, this acknowledgement is not sent.

11. The MCPTT server sends the MCPTT in-progress imminent peril group state cancel response to the MCPTT client 1 to confirm the MCPTT in-progress imminent peril group state cancel request.

NOTE 7: Step 11 can occur at any time following step 5.