Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.283  Word version:  18.1.0

Top   Top   Up   Prev   Next
1…   10…   10.2…   10.2.2…   10.2.3…   10.3…   10.3.3…   10.3.3.7…   10.3.4…   10.3.4.4…   10.3.5…   10.3.5.8…   10.3.6…   10.3.7…   10.3.7.5…   10.3.8…   10.4…   10.4.4…   10.5…   10.5.7…   10.6…   10.6.2…   10.6.2.3…   10.6.3…   10.6.4…   10.7…   10.8…   10.11…   10.11.4…   10.12…   10.14…   10.15…

 

10.6.3  Imminent peril callsp. 132

10.6.3.1  Generalp. 132

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 groupp. 132

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.
Copy of original 3GPP image for 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
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 statep. 134

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.
Copy of original 3GPP image for 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
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 groupp. 136

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.
Copy of original 3GPP image for 3GPP TS 23.283, Fig. 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

Up   Top   ToC