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.379  Word version:  19.4.0

Top   Top   Up   Prev   Next
1…   7…   10…   10.5…   10.6…   10.6.2.3…   10.6.2.4…   10.6.2.5…   10.6.2.6…   10.6.2.9…   10.6.3…   10.7…   10.7.3…   10.7.5…   10.7.6…   10.9…   10.9.1.3.3…   10.9.1.4…   10.9.2…   10.10…   10.12…   10.19…   10.19.3…   10.19.3.1.4…   10.19.3.2…   10.19.3.2.4…   10.19.3.2.6…   A… 
10.6.2.6 Emergency and imminent peril procedures  10.6.2.6.1 MCPTT emergency group call  10.6.2.6.2 MCPTT imminent peril group call  10.6.2.6.3 MCPTT emergency alert (on-network)  10.6.2.6.3a MCPTT ad hoc group emergency alert (on-network)  10.6.2.7 Location of current talker 
...

 

10.6.2.6  Emergency and imminent peril procedures  p. 81

10.6.2.6.1  MCPTT emergency group call  p. 81
10.6.2.6.1.1  MCPTT emergency group call commencement  p. 81
The procedure describes the case where an MCPTT client is initiating an MCPTT emergency group call with the affiliated MCPTT members of that MCPTT group. An MCPTT client in the MCPTT emergency state gains elevated access privilege for all of the MCPTT user's mission critical applications. Initiating an MCPTT emergency group call puts the MCPTT group into the in-progress emergency state. While in the in-progress emergency state, all MCPTT group calls in the MCPTT group are processed as MCPTT emergency group calls by the MCPTT server until the in-progress emergency state of the MCPTT group is cancelled.
Figure 10.6.2.6.1.1-1 shows the procedures for the MCPTT client initiating establishment of an MCPTT emergency group call with an MCPTT group i.e., MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 belong to the same MCPTT group which is defined on MCPTT group management server.
Pre-conditions:
  1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. The initiating MCPTT client 1 has been provisioned with an MCPTT group that has been designated via provisioning as the MCPTT emergency group.
  4. Optionally, MCPTT client 1 may use an activated functional alias for the group communication.
  5. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.1.1-1: MCPTT emergency group call
Figure 10.6.2.6.1.1-1: MCPTT emergency group call
Up
Step 1.
The user at the MCPTT client 1 initiates an MCPTT emergency group call. MCPTT client 1 sets its MCPTT emergency state. The MCPTT user at MCPTT client 1 may select a functional alias used for the call. The MCPTT emergency state of MCPTT client 1 is retained until explicitly cancelled by the user of MCPTT client 1.
Step 2.
MCPTT client 1 sends an MCPTT emergency group call request towards the MCPTT server. The MCPTT server records the identity of the MCPTT user that initiated the MCPTT emergency group call until the MCPTT emergency state of the group is cancelled. Once an MCPTT emergency call has been initiated, the MCPTT group is considered to be in an in-progress emergency state until the emergency state of the group is cancelled. If configured to send an MCPTT emergency alert when initiating an MCPTT emergency group call, the request also contains an indication that an MCPTT emergency alert is to be initiated. The request may contain an indication of an implicit floor request.
Step 3.
The MCPTT server implicitly affiliates MCPTT client 1 to the emergency group if the client is not already affiliated.
Step 4.
MCPTT server checks whether the MCPTT user of MCPTT client 1 is authorized for initiation of MCPTT emergency calls on the indicated MCPTT group, and if authorized, it resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based on the information from group management server. The MCPTT server checks whether the provided functional alias, if present, can be used and has been activated for the user.
Step 5.
The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.
Step 6.
MCPTT server sends the MCPTT emergency group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of the in-progress emergency. The request contains an indication of an MCPTT emergency alert if the request from the originator indicated MCPTT emergency alert.
Step 7.
MCPTT users are notified of the incoming MCPTT emergency group call. The functional alias of the group call initiating MCPTT user may be displayed.
Step 8.
The receiving MCPTT clients send the MCPTT emergency group call response to the MCPTT server to acknowledge the MCPTT emergency group call request. For a multicast call, these acknowledgements are not sent. The receiving MCPTT client check whether it is already involved in an MCPTT emergency group call when using this functional alias and whether the maximum number of parallel MCPTT emergency group calls when using this functional alias has been reached.
Step 9.
The MCPTT server sends the MCPTT emergency group call response to the MCPTT user 1 to inform the successful MCPTT emergency call establishment.
MCPTT client 1, MCPTT client 2 and MCPTT client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane, while the other MCPTT client's receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the MCPTT emergency group call will be receiving that media. MCPTT client 1 can override other clients in the call except those that are also in the MCPTT emergency state.
Up
10.6.2.6.1.2  MCPTT group call upgraded to an MCPTT emergency group call  p. 83
The procedure focuses on the case where an authorized MCPTT user is upgrading an MCPTT group call to an MCPTT emergency group call while the MCPTT group call is already in progress.
Procedures in Figure 10.6.2.6.1.2-1 are the signalling control plane procedures for the MCPTT client upgrading an MCPTT group call on an MCPTT group to an MCPTT emergency group call.
Pre-conditions:
  1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. An MCPTT group call is already in progress.
  4. The initiating MCPTT client 1 has been configured to send an MCPTT emergency alert when upgrading an MCPTT emergency group call.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.1.2-1: MCPTT group call upgraded to an MCPTT emergency group call
Figure 10.6.2.6.1.2-1: MCPTT group call upgraded to an MCPTT emergency group call
Up
Step 1.
The MCPTT user at MCPTT client 1 initiates a group emergency. MCPTT client 1 sets its MCPTT emergency state. The MCPTT emergency state of MCPTT client 1 is retained until explicitly cancelled by the user of MCPTT client 1.
Step 2.
MCPTT client 1 requests the MCPTT server to upgrade the MCPTT group to an in-progress emergency state by sending an MCPTT emergency group call request. If configured to send an MCPTT alert when initiating an MCPTT emergency upgrade, the request also contains an indication that an MCPTT alert is to be initiated. The request may contain an indication of an implicit floor request.
Step 3.
The MCPTT server adjusts the priority of the underlying bearer for all or selected participants in the MCPTT group call that receive the communication over unicast.
Step 4.
MCPTT server sends the MCPTT emergency group call request towards the MCPTT clients of each of those affiliated MCPTT group members. The request contains an indication of an MCPTT emergency alert if the request from the originator indicated MCPTT emergency alert.
Step 5.
MCPTT users are notified of the in-progress emergency state of the MCPTT group.
Step 6.
The receiving MCPTT clients send the MCPTT emergency group call response to the MCPTT server to acknowledge the MCPTT group emergency request. For a multicast call, these acknowledgements are not sent.
Step 7.
The MCPTT server sends the MCPTT emergency group call response to the MCPTT user 1 to confirm the upgrade request.
MCPTT client 1, MCPTT client 2 and MCPTT client 3 continue with the MCPTT group call, which has been transformed into an MCPTT emergency group call. MCPTT client 1 can override other clients in the call except those that are also in the MCPTT emergency state.
Up
10.6.2.6.1.3  MCPTT in-progress emergency group state cancel  p. 85
The procedure describes the case where an MCPTT client cancels an MCPTT group's in-progress emergency state. The emergency state of the group may alternatively be cancelled by the emergency alert cancellation procedure specified in subclause 10.10.1.2.2.2 of TS 23.280.
Procedures in Figure 10.6.2.6.1.3-1 are the signalling control plane procedures for the MCPTT client cancelling an in-progress emergency of a group.
Pre-conditions:
  1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. MCPTT group members have been notified about the in-progress emergency.
  4. The MCPTT group is in the in-progress emergency state and has prioritized bearer support when a call is in progress.
  5. MCPTT client 1 is authorized to cancel an in-progress emergency for the group.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.1.3-1: MCPTT in-progress emergency group state cancel
Figure 10.6.2.6.1.3-1: MCPTT in-progress emergency group state cancel
Up
Step 1.
The user at the MCPTT client 1 initiates an MCPTT in-progress emergency group state cancel.
Step 2.
MCPTT client 1 sends an MCPTT in-progress emergency group state cancel request to the MCPTT server.
Step 3.
MCPTT server resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based upon the information from group management server.
Step 4.
The MCPTT server verifies that the user of MCPTT client 1 is authorized to cancel the emergency state of this MCPTT group. The MCPTT server cancels/resets the in-progress emergency state of the MCPTT group.
Step 5.
If a call is currently in progress, the MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required.
Step 6.
The MCPTT server sends an MCPTT in-progress emergency group state cancel request to the MCPTT group members.
Step 7.
MCPTT group members are notified of the MCPTT in-progress emergency group state cancel.
Step 8.
The receiving MCPTT clients send the MCPTT in-progress emergency group state cancel response to the MCPTT server to acknowledge the MCPTT in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.
Step 9.
The MCPTT server sends the MCPTT in-progress emergency group state cancel response to the MCPTT user 1 to confirm the MCPTT in-progress emergency group state cancel. If the MCPTT in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCPTT client 1 resets its local emergency status.
Up
10.6.2.6.2  MCPTT imminent peril group call  p. 87
10.6.2.6.2.1  MCPTT imminent peril group call commencement  p. 87
The procedure focuses on the case where an authorized MCPTT user is initiating an imminent peril group call for communicating with the affiliated MCPTT members of that MCPTT group. This procedure will gain elevated access privilege for the MCPTT client if it is not already in that state. The access privilege for other applications will not necessarily be affected.
Procedures in Figure 10.6.2.6.2.1-1 are the signalling control plane procedures for the MCPTT client initiating establishment of an imminent peril group call with an MCPTT group i.e., MCPTT users on MCPTT client 1, MCPTT client 2 and MCPTT client 3 belong to the same MCPTT group which is defined on MCPTT group management server.
Pre-conditions:
  1. The MCPTT group is previously defined on the group management server with MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. 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.
  4. Optionally, MCPTT client 1 may use an activated functional alias for the group communication.
  5. The MCPTT server may have subscribed to the MCPTT functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.2.1-1: MCPTT imminent peril group call
Figure 10.6.2.6.2.1-1: MCPTT imminent peril group call
Up
Step 1.
The user at the MCPTT client 1 initiates an imminent peril group call. The MCPTT user at MCPTT client 1 may select a functional alias used for the call.
Step 2.
MCPTT client 1 sends an MCPTT imminent peril group call request towards the MCPTT server. The request contains an indication of the in-progress imminent peril. The MCPTT server 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 cancelled. The request may contain an indication of an implicit floor request. If the group call request includes an implicit floor request it may also include location information.
Step 3.
The MCPTT server implicitly affiliates MCPTT client 1 to the imminent peril group if the client is not already affiliated.
Step 4.
MCPTT server checks whether the MCPTT user of MCPTT client 1 is authorized for initiation of imminent peril group calls on the indicated MCPTT group, and if authorized, it resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based on the information from group management server. The MCPTT server checks whether the provided functional alias, if present, can be used and has been activated for the user.
Step 5.
The MCPTT server configures the priority of the underlying bearers for all participants in the MCPTT group.
Step 6.
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. If location information was included in the imminent peril group call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
Step 7.
MCPTT users are notified of the incoming imminent peril call. The functional alias of the group call initiating MCPTT user may be displayed.
Step 8.
The receiving MCPTT clients send the MCPTT imminent peril group call response to the MCPTT server to acknowledge the imminent peril call request. For a multicast call, these acknowledgements are not set.
Step 9.
The MCPTT server sends the MCPTT imminent peril group call response to the MCPTT user 1 to inform the successful imminent peril call establishment.
MCPTT client 1, MCPTT client 2 and MCPTT client 3 have successfully established media plane for communication. MCPTT floor participant 1, floor participant 2 and floor participant 3 exchange floor control information e.g., MCPTT client 1 receives the floor granted information over the established media plane, while the other MCPTT clients receive floor taken information. MCPTT client 1 indicates to the MCPTT user that the floor is available to send media, while the other MCPTT clients in the imminent peril call will be receiving that media.
Up
10.6.2.6.2.2  Imminent peril group call upgrade  p. 89
The procedure focuses on the case where an authorized MCPTT user is upgrading an MCPTT group call to an imminent peril group call while the MCPTT group call is already in progress.
Procedures in Figure 10.6.2.6.2.2-1 are the signalling control plane procedures for the MCPTT client upgrading an MCPTT group call on an MCPTT group to an imminent peril group call.
Pre-conditions:
  1. The MCPTT group is previously defined on the group management server with MCPTT client 1, MCPTT client 2 and MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. An MCPTT group call is already in progress.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.2.2-1: MCPTT group call upgrade to an imminent peril group call
Figure 10.6.2.6.2.2-1: MCPTT group call upgrade to an imminent peril group call
Up
Step 1.
The MCPTT user at MCPTT client 1 initiates an imminent peril call.
Step 2.
MCPTT client 1 requests the MCPTT server to upgrade the MCPTT group to an in-progress imminent peril state by sending an MCPTT imminent peril group call request. The request may contain an indication of an implicit floor request. If the imminent peril group call request includes an implicit floor request it may also include location information.
Step 3.
The MCPTT server adjusts the priority of the underlying bearer for all participants in the MCPTT group.
Step 4.
The MCPTT server sends the MCPTT imminent peril group call request towards the MCPTT clients of the affiliated MCPTT group members. If location information was included in the imminent peril group call request, the MCPTT server checks the privacy policy of the MCPTT user to decide if the location information of MCPTT client 1 can be provided to other users on the call (refer to Annex A.3 "Authorisation to provide location information to other MCPTT users on a call when talking").
Step 5.
MCPTT users are notified of the in-progress imminent peril state of the MCPTT group.
Step 6.
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 set.
Step 7.
The MCPTT server sends the MCPTT imminent peril group call response to the MCPTT user 1 to confirm the upgrade request.
MCPTT client 1, MCPTT client 2 and MCPTT client 3 continue with the MCPTT group call, which has been transformed into an imminent peril group call.
Up
10.6.2.6.2.3  MCPTT in-progress imminent peril group state cancel  p. 91
The procedure focuses on the case where an authorized MCPTT user cancels an MCPTT group's in-progress imminent peril state.
Procedures in Figure 10.6.2.6.2.3-1 are the signalling control plane procedures for the MCPTT client cancelling an MCPTT 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 MCPTT client 3 affiliated to that MCPTT group.
  2. All members of the MCPTT group belong to the same MCPTT system.
  3. The MCPTT group is in an in-progress imminent peril state and has prioritized bearer support.
  4. MCPTT group members have been notified about the MCPTT group's in-progress imminent peril state.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.6.2.3-1: MCPTT in-progress imminent peril group state cancel
Figure 10.6.2.6.2.3-1: MCPTT in-progress imminent peril group state cancel
Up
Step 1.
The user at the MCPTT client 1 initiates an in-progress imminent peril group state cancel.
Step 2.
MCPTT client 1 sends an MCPTT in-progress imminent peril group state cancel request to the MCPTT server.
Step 3.
Based on the user profile configuration and the local policy (e.g. initiator of the MCPTT imminent peril group state), the MCPTT server verifies that the user of MCPTT client 1 is authorized to cancel the imminent peril state of this MCPTT group. The MCPTT server cancels/resets the in-progress imminent peril state of the MCPTT group. If not verified, the MCPTT server shall ignore the request.
Step 4.
The MCPTT server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCPTT server cancels/resets the in-progress imminent peril group state.
Step 5.
MCPTT server resolves the MCPTT group ID to determine the members of that MCPTT group and their affiliation status, based upon the information from group management server.
Step 6.
The MCPTT server sends an MCPTT imminent peril group state cancel request to the MCPTT group members.
Step 7.
MCPTT group members are notified of the in-progress imminent peril group state cancel.
Step 8.
The receiving MCPTT group members send the MCPTT in-progress imminent peril group state cancel response to the MCPTT server to acknowledge the MCPTT in-progress imminent peril group state cancel request. For a multicast scenario, these acknowledgements are not set.
Step 9.
The MCPTT server sends the MCPTT in-progress imminent peril group state cancel response to the MCPTT user 1 to confirm the MCPTT in-progress imminent peril group state cancel request.
Up
10.6.2.6.3  MCPTT emergency alert (on-network)  p. 92
The MCPTT service shall support the procedures and related information flows as specified in subclauses 10.10.1 of TS 23.280 with the following clarifications:
  • The MC service client is the MCPTT client;
  • The MC service server is the MCPTT server;
  • The MC service group ID is the MCPTT Group ID; and
  • The MC service user profile index is the MCPTT user profile index.
10.6.2.6.3a  MCPTT ad hoc group emergency alert (on-network) |R18|  p. 92
The MCPTT service shall support the procedures and related information flows as specified in subclauses 10.10.3 of TS 23.280 with the following clarifications:
  • The MC service client is the MCPTT client;
  • The MC service server is the MCPTT server;
  • The MC service group ID is the MCPTT Group ID; and
  • The MC service user profile index is the MCPTT user profile index.

10.6.2.7  Location of current talker  p. 92

Figure 10.6.2.7-1 shows the high level procedure to for MCPTT service to provide the location information about the current talking user to all the receiving MCPTT users.
Precondition:
  1. There is on-going group call involving MCPTT client 1 and MCPTT client 2.
  2. MCPTT client 1 is the current talking user.
  3. MCPTT server has obtained the location information of MCPTT client 1 according to subclause 10.9 in TS 23.280.
Reproduction of 3GPP TS 23.379, Fig. 10.6.2.7-1: Providing location information of the current talker
Figure 10.6.2.7-1: Providing location information of the current talker
Up
Step 1.
MCPTT client 1 gets the floor to transmit voice media.
Step 2.
MCPTT server checks the privacy policy (authorisation to provide location information to other MCPTT users on a call when talking, as defined in Annex A.3) of the current talking MCPTT user to decide if the location information of MCPTT client 1 can be provided to other MCPTT users on the call. MCPTT server acquires the location of the current talker from the location management server as described in subclause 10.9.3.6 of TS 23.280. Optionally, the MCPTT server acquires the location of the current talker directly from the floor request received from MCPTT client 1 in step 1.
Step 3.
MCPTT server provides the location information of MCPTT client 1 to MCPTT client 2. Optionally, the location information may be provided in the floor taken message sent to MCPTT client 2 according to subclause 10.9.1.3.1.
Up

10.6.2.8  Void

10.6.2.8.1  Void
10.6.2.8.2  Void
10.6.2.8.3  Void

Up   Top   ToC