Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.283  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   10…   10.2…   10.3…   10.3.2   10.3.3…   10.3.4…   10.3.5…   10.3.6…   10.3.7…   10.3.8…   10.4…   10.5…   10.6…   10.6.2…   10.6.3…   10.7…   10.8…   10.11…   10.12…   10.14…   10.15…   10.17… 
10.6.3 Imminent peril calls  10.6.3.1 General  10.6.3.2 Imminent peril group call initiated by an MCPTT user on an interworking group  10.6.3.3 Group call initiated by a user in the LMR system on an interworking group in imminent peril state  10.6.3.4 In-progress imminent peril state cancel on an interworking group  10.6.4 Emergency alerts  10.6.4.1 Emergency alert initiated by LMR user  10.6.4.2 Emergency alert initiated by MC service user  10.6.5 Emergency alert cancellation  10.6.5.1 Emergency alert cancellation of an LMR user  10.6.5.2 Emergency alert cancellation of an MC service user 
...

 

10.6.3  Imminent peril calls  p. 133

10.6.3.1  General  p. 133

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

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

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 subclause 10.6.2.6.2.1 of TS 23.379.
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.
Reproduction of 3GPP TS 23.283, Fig. 10.6.3.2-1: Imminent peril group call initiated by a MCPTT user to an interworking group defined in the MCPTT system
Figure 10.6.3.2-1: Imminent peril group call initiated by a MCPTT user to an interworking group defined in the MCPTT system
Up
Step 1.
An MCPTT user initiates an imminent peril group call.
Step 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.
Step 3.
The MCPTT server implicitly affiliates MCPTT client 1 to the imminent peril group if the client is not already affiliated.
Step 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 TS 23.379 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.
Step 5.
The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.
Step 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.
Step 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.
Step 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.
Step 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 TS 23.379.
Step 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.
Step 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.
Up

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

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.
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.
Reproduction of 3GPP TS 23.283, Fig. 10.6.3.3-1: Group call initiated by a user in the LMR system on an interworking group in imminent peril state
Figure 10.6.3.3-1: Group call initiated by a user in the LMR system on an interworking group in imminent peril state
Up
Step 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.
Step 2.
The MCPTT server determines that the MCPTT group is currently in imminent peril state.
Step 3.
The MCPTT server converts the request and sends an MCPTT imminent peril group call request to all of the affiliated MCPTT clients.
Step 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.
Step 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.
Step 4a.
The IWF returns IWF imminent peril group call response(s) to the MCPTT server.
Step 5.
The MCPTT server sends the IWF imminent peril group call response message to the IWF.
Step 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.
Up

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

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.
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.
  6. MCPTT client 1 previously initiated the imminent peril group call.
Reproduction of 3GPP TS 23.283, Fig. 10.6.3.4-1: In-progress imminent peril group state cancel on an interworking group
Figure 10.6.3.4-1: In-progress imminent peril group state cancel on an interworking group
Up
Step 1.
The user at the MCPTT client 1 initiates an in-progress imminent peril state cancel.
Step 2.
MCPTT client 1 sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT server.
Step 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.
Step 4.
The MCPTT server cancels/resets the in-progress imminent peril group state.
Step 5.
The MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required.
Step 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.
Step 7.
The IWF sends the IWF in-progress imminent peril group state cancel response(s) to the MCPTT server.
Step 8.
The MCPTT server sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT group members.
Step 9.
MCPTT group members are notified of the in-progress imminent peril group state cancel.
Step 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.
Step 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.
Up

10.6.4  Emergency alerts  p. 139

10.6.4.1  Emergency alert initiated by LMR user  p. 139

In this procedure, an LMR user is initiating an emergency alert via the IWF. Figure 10.6.4.1-1 shows the procedure for an emergency alert initiated by a user in the LMR system. This subclause is based upon subclause for MCPTT emergency alerts in TS 23.379, subclause 10.6.2.6.3.1.
Pre-conditions:
  1. The MC service group is previously defined on the group management server with MC service client 1 and MC service client 2 affiliated to that MC service group.
  2. The IWF is connected to and is authorized to interwork with the MC system.
  3. The MC service group information is available at the IWF, including information that the MC service group is an interworking group (defined in the LMR system or MC the system).
  4. The mapping relationship of group and user identities between the MC system and the LMR system has been configured at the IWF.
  5. The IWF may or may not have carried out an explicit affiliation procedure with the MC service group.
  6. An emergency alert is requested on the LMR system.
Reproduction of 3GPP TS 23.283, Fig. 10.6.4.1-1: MC service emergency alert initiated by LMR user
Figure 10.6.4.1-1: MC service emergency alert initiated by LMR user
Up
Step 1.
The LMR user initiates an emergency alert.
Step 2.
The IWF sends an IWF emergency alert request to the designated MC service server. If the location of the LMR user is not available to the IWF, the IWF emergency alert request shall contain an indication that location is not available.
Step 3.
MC service server checks whether the MC service user ID that represents the LMR user is authorized for initiation of MC service emergency alerts for the indicated MC service group. The MC service server determines the affiliation status of the group members.
Step 4.
The MC service server sends an IWF emergency alert response to the IWF to confirm the IWF emergency alert request.
Step 5.
The MC service server sends an MC service emergency alert request towards the MC service clients of each of those affiliated MC service group members. The MC service emergency alert request message shall contain the following information: Location, MC service ID and MC service group ID (i.e., MC service user's selected MC service group or dedicated MC service emergency group, as per MC service group configuration) and the MC service user's mission critical organization name.
Step 6.
MC service users are notified of the MC service emergency.
Step 7.
The receiving MC service clients send an MC service emergency alert response to the MC service server to acknowledge the MC service emergency alert request.
Step 8.
If the group is an interworking group defined in the MC system, the MC service server implicitly affiliates the individual MC service ID of the LMR user to the emergency group if not already affiliated. If the IWF is configured to affiliate on behalf of all of its group members in a single affiliation step, the MC service server affiliates the IWF ID instead of an individual MC service ID.
Up

10.6.4.2  Emergency alert initiated by MC service user  p. 140

In this procedure, an MC service user is initiating an emergency alert that is delivered to the LMR system via the IWF. Figure 10.6.4.2-1 shows the procedure for an emergency alert initiated by a user in the MC system. This subclause is based upon subclause for MCPTT emergency alerts in subclause 10.6.2.6.2.1 of TS 23.379.
Pre-conditions:
  1. The MC service group is previously defined on the group management server with MC service client 1 and MC service client 2 affiliated to that MC service group.
  2. The IWF is connected to and is authorized to interwork with the MC system.
  3. The MC service group information is available at the IWF, including information that the MC service group is an interworking group (defined in the LMR system or the MC system).
  4. The mapping relationship of group and user identities between the MC system and the LMR system has been configured at the IWF.
Reproduction of 3GPP TS 23.283, Fig. 10.6.4.2-1: MC service emergency alert initiated by MC service user
Figure 10.6.4.2-1: MC service emergency alert initiated by MC service user
Up
Step 1.
The MC service user 1 initiates an emergency alert.
Step 2.
MC service client 1 sends an MC service emergency alert request to the MC service server.
Step 3.
The MC service server resolves the group ID, determines the affiliation status of the group members and checks whether the IWF should be informed. In this scenario, the group has affiliated members that are homed on the IWF, thus the IWF shall be involved. MC service server also checks whether the MC service user ID is authorized to initiate MC service emergency alerts for the indicated MC service group.
Step 4.
The MC service server sends an MC service emergency alert response to the MC service client 1 to confirm the MC service emergency alert request.
Step 5.
MC service server sends an IWF emergency alert request to the IWF. If the location of the MC service client 1 is not available, the IWF emergency alert request shall contain an indication that location is not available. If the IWF has affiliated to this group on behalf of the group's LMR users, only one IWF emergency alert request is sent to the IWF. If the IWF has sent individual affiliations for each of its LMR users, the MC service server sends an IWF emergency alert request via the IWF to each affiliated LMR group member.
Step 6.
The IWF sends an IWF service emergency alert response to the MC service server to confirm the IWF emergency alert request(s).
Step 7.
The MC service server sends an MC service emergency alert request towards the MC service clients of each of those affiliated MC service group members. The MC service emergency alert request message shall contain the following information: Location, MC service ID and MC service group ID (i.e., MC service user's selected MC service group or dedicated MC service emergency group, as per MC service group configuration) and the MC service user's mission critical organization name.
Step 8.
MC service users are notified of the MC service emergency.
Step 9.
The receiving MC service clients send an MC service emergency alert response to the MC service server to acknowledge the MC service emergency alert.
Step 10.
The MC service server implicitly affiliates the MC service client 1 to the emergency group if it is not already affiliated.
Up

10.6.5  Emergency alert cancellation  p. 142

10.6.5.1  Emergency alert cancellation of an LMR user  p. 142

In this procedure, an LMR user is cancelling the emergency alert. Figure 10.6.5.1-1 shows the procedure for emergency alert cancellation of a user in the LMR system. This subclause is based upon subclause for MCPTT emergency alert cancel in TS 23.379, subclause 10.6.2.6.3.2.
Pre-conditions:
  1. The MC service group information is available at the IWF, including information that the MC service group is an interworking group (defined in the LMR system or the MC system).
  2. The LMR user had previously successfully initiated an emergency alert via the IWF.
  3. The MC service client 1 and MC service client 2 are affiliated to the MC service group.
  4. The MC service server may have carried out an explicit or implicit affiliation procedure of the LMR user to the MC service group.
  5. he mapping relationship of group and user identities between the MC system and the LMR system has been configured at the IWF.
  6. The LMR user initiates an emergency alert cancel.
Reproduction of 3GPP TS 23.283, Fig. 10.6.5.1-1: MC service emergency alert cancellation of an LMR user
Figure 10.6.5.1-1: MC service emergency alert cancellation of an LMR user
Up
Step 1.
The IWF sends an IWF emergency alert cancel request to the MC service group to which the IWF had previously successfully sent the IWF emergency alert request on behalf of the LMR user.
Step 2.
The MC service server sends the IWF emergency alert cancel response to the IWF to confirm the IWF emergency alert cancellation.
Step 3.
The MC service server sends an MC service emergency alert cancel request to the MC service clients of the affiliated MC service group members.
Step 4.
MC service users are notified of the MC service emergency alert cancellation of the LMR user.
Step 5.
The receiving MC service clients send the MC service emergency alert cancel response to the MC service server to acknowledge the MC service emergency alert cancel request. For a multicast call scenario, these acknowledgements are not sent.
Up

10.6.5.2  Emergency alert cancellation of an MC service user  p. 143

In this procedure, an MC service user is cancelling the emergency alert. Figure 10.6.5.2-1 shows the procedure for emergency alert cancellation from a user in the MC system. This subclause is based upon subclause for MCPTT emergency alerts in subclause 10.6.2.6.2.2 of TS 23.379.
Pre-conditions:
  1. The MC service group information is available at the IWF, including information that the MC service group is an interworking group (defined in the LMR system or the MC system).
  2. The MC service client 1 had previously successfully initiated an MC service emergency alert request.
  3. The MC service client 1 is still in the emergency state.
  4. The MC service client 2 is affiliated to the MC service group.
  5. The MC service server may have carried out an explicit or implicit affiliation procedure of the LMR user with the MC service group.
  6. The mapping relationship of group and user identities between the MC system and the LMR system has been configured at the IWF.
Reproduction of 3GPP TS 23.283, Fig. 10.6.5.2-1: MC service emergency alert cancellation of an MC service user
Figure 10.6.5.2-1: MC service emergency alert cancellation of an MC service user
Up
Step 1.
The user at the MC service client 1 initiates an emergency alert cancel.
Step 2.
MC service client 1 requests the MC service server to send an MC service emergency alert cancel to the MC service group to which MC service client 1 had previously sent the emergency alert request. The MC service server resolves the group ID, determines the affiliation status of the group members and checks whether the IWF should be informed. In this scenario, the group has affiliated members that are homed on the IWF, thus the IWF shall be involved.
Step 3.
The MC service server sends the MC service emergency alert cancel response to the MC service client 1 to confirm the MC service emergency alert cancel request. MC service client 1 resets its emergency state.
Step 4.
The MC service server sends an IWF emergency alert 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 emergency alert cancel request message is sent to the IWF. If the MCPTT server has received individual affiliations from the group's LMR users, an individual IWF emergency alert cancel request message is sent to the IWF for each affiliated LMR user.
Step 5.
The IWF sends an IWF emergency alert cancel response(s) to the MC service server to acknowledge the IWF emergency alert cancel request(s).
Step 6.
The MC service server sends an MC service emergency alert cancel request towards the MC service clients of the affiliated MC service group members.
Step 7.
MC service users are notified of the MC service emergency alert cancellation of MC service client 1.
Step 8.
The receiving MC service clients send the MC service emergency alert cancel response to the MC service server to acknowledge the MC service emergency alert cancel request. For a multicast call scenario, these acknowledgements are not sent.
Up

Up   Top   ToC