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.281  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   5…   6…   7…   7.1.2.3…   7.1.2.3.1.2…   7.1.2.3.2…   7.1.2.4…   7.1.2.5.2…   7.1.3…   7.2…   7.2.2.3…   7.2.2.4…   7.2.3…   7.3…   7.4…   7.4.3…   7.5…   7.5.2.3…   7.6…   7.7…   7.7.1.3…   7.7.1.3.2A…   7.7.1.3.4…   7.7.1.3.6…   7.7.2…   7.7.2.7…   7.7.2.9…   7.8…   7.11…   7.17…   7.19…   7.19.2.8…   7.19.3…   7.19.3.1.4…   7.19.3.2…   7.19.3.2.3…   7.19.3.2.6…   A… 
7.1.2.5.2 MCVideo imminent peril group call  7.1.2.5.2.1 MCVideo imminent peril group call commencement  7.1.2.5.2.2 Imminent peril group call upgrade  7.1.2.5.2.3 MCVideo imminent peril group call cancel  7.1.2.6 MCVideo emergency alert (on-network and off-network)  7.1.2.7 MCVideo ad hoc group emergency alert (on-network)  7.1.2.8 Group call handling with preconfigured regroup update procedures  7.1.2.8.1 Call request to MCVideo group during an in-progress preconfigured group regroup  7.1.2.8.2 Call request to regroup group after group regroup has been cancelled 
...

 

7.1.2.5.2  MCVideo imminent peril group call  p. 49
7.1.2.5.2.1  MCVideo imminent peril group call commencement  p. 49
The procedure focuses on the case where an authorized MCVideo user is initiating an imminent peril group call for communicating with the affiliated MCVideo members of that MCVideo group. This procedure will gain elevated access privilege for the MCVideo client if it is not already in that state. The access privilege for other applications will not necessarily be affected.
Procedures in Figure 7.1.2.5.2.1-1 are the signalling control plane procedures for the MCVideo client initiating establishment of an imminent peril group call with an MCVideo group i.e., MCVideo users on MCVideo client 1, MCVideo client 2 and MCVideo client 3 belong to the same MCVideo group which is defined on MCVideo group management server.
Pre-conditions:
  1. The MCVideo group is previously defined on the group management server with MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
  2. All members of the MCVideo group belong to the same MC system.
  3. The initiating MCVideo client 1 has been provisioned with an MCVideo group that has been designated in the provisioning to be used for imminent peril communications.
  4. MCVideo client 1, MCVideo client 2 and MCVideo client 3 may have an activated functional alias to be used during the emergency group communication.
  5. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.5.2.1-1: MCVideo imminent peril group call
Figure 7.1.2.5.2.1-1: MCVideo imminent peril group call
Up
Step 1.
The user at the MCVideo client 1 initiates an imminent peril group call.
Step 2.
MCVideo client 1 sends an MCVideo imminent peril group call request towards the MCVideo server. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo imminent peril group call request. The request contains an indication of the in-progress imminent peril. The MCVideo server records the identity of the MCVideo 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 MCVideo group is considered to be in an in-progress imminent peril state until cancelled. The request may contain an indication of an implicit transmit media request.
Step 3.
The MCVideo server implicitly affiliates MCVideo client 1 to the imminent peril group if the client is not already affiliated.
Step 4.
MCVideo server checks whether the provided functional alias is allowed to be used and has been activated for the MCVideo user, and whether the MCVideo user of MCVideo client 1 is authorized for initiation of imminent peril group calls on the indicated MCVideo group, and if authorized, it resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based on the information from group management server.
Step 5.
The MCVideo server configures the priority of the underlying bearers for all participants in the MCVideo group.
Step 6.
MCVideo server sends the imminent peril group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of the in-progress imminent peril.
Step 7.
MCVideo users are notified of the incoming imminent peril call, and, if available, the functional alias of the initiating user is displayed.
Step 8.
The receiving MCVideo clients send the MCVideo imminent peril group call response to the MCVideo server to acknowledge the imminent peril call request. For a multicast call, these acknowledgements are not set.
Step 9.
The MCVideo server sends the MCVideo imminent peril group call response to the MCVideo user 1 to inform the successful imminent peril call establishment. If the MCVideo imminent peril request contained an implicit transmit media request, the OK message contains the result of the implicit transmit media request.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 have successfully established media plane for communication. MCVideo transmission control participant 1, transmission control participant 2 and transmission control participant 3 exchange transmission control information e.g., MCVideo client 1 receives the transmit media granted information over the established media plane, while the other MCVideo clients receive media available notification with forced reception mode information. MCVideo client 1 indicates to the MCVideo user that the permission is granted to transmit media, while the other MCVideo clients in the imminent peril call will be receiving that media.
Up
7.1.2.5.2.2  Imminent peril group call upgrade  p. 51
The procedure focuses on the case where an authorized MCVideo user is upgrading an MCVideo group call to an imminent peril group call while the MCVideo group call is already in progress.
Procedures in Figure 7.1.2.5.2.2-1 are the signalling control plane procedures for the MCVideo client upgrading an MCVideo group call on an MCVideo group to an imminent peril group call.
Pre-conditions:
  1. The MCVideo group is previously defined on the group management server with MCVideo client 1, MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
  2. All members of the MCVideo group belong to the same MC system.
  3. An MCVideo group call is already in progress.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.5.2.2-1: MCVideo group call upgrade to an imminent peril group call
Figure 7.1.2.5.2.2-1: MCVideo group call upgrade to an imminent peril group call
Up
Step 1.
The MCVideo user at MCVideo client 1 initiates an imminent peril call.
Step 2.
MCVideo client 1 requests the MCVideo server to upgrade the MCVideo group to an in-progress imminent peril state by sending an MCVideo imminent peril group call request. The request may contain an indication of an implicit transmit media request.
Step 3.
The MCVideo server adjusts the priority of the underlying bearer for all participants in the MCVideo group.
Step 4.
MCVideo server sends the MCVideo imminent peril group call request towards the MCVideo clients of each of those affiliated MCVideo group members.
Step 5.
MCVideo users are notified of the in-progress imminent peril state of the MCVideo group.
Step 6.
The receiving MCVideo clients send the MCVideo imminent peril group call response to the MCVideo server to acknowledge the MCVideo imminent peril group call request. For a multicast call, these acknowledgements are not set.
Step 7.
The MCVideo server sends the MCVideo imminent peril group call response to the MCVideo user 1 to confirm the upgrade request. If the MCVideo imminent peril group call request contained an implicit transmit media request, the OK message contains the result of the implicit transmit media request.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 continue with the MCVideo group call, which has been transformed into an imminent peril group call.
Up
7.1.2.5.2.3  MCVideo imminent peril group call cancel  p. 53
The procedure focuses on the case where an authorized MCVideo user cancels an MCVideo group's in-progress imminent peril state.
Procedures in Figure 7.1.2.5.2.3-1 are the signalling control plane procedures for the MCVideo client cancelling an MCVideo group's in-progress imminent peril state.
Pre-conditions:
  1. The MCVideo group is previously defined on the group management server with MCVideo client 1, MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
  2. All members of the MCVideo group belong to the same MC system.
  3. The MCVideo group is an in-progress imminent peril state and has prioritized bearer support.
  4. MCVideo group members have been notified about the MCVideo group's in-progress imminent peril state.
  5. MCVideo client 1 previously initiated the in-progress imminent peril.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.5.2.3-1: MCVideo imminent peril group call cancel
Figure 7.1.2.5.2.3-1: MCVideo imminent peril group call cancel
Up
Step 1.
The user at the MCVideo client 1 initiates an imminent peril cancel.
Step 2.
MCVideo client 1 sends an MCVideo imminent peril group call cancel request to the MCVideo server.
Step 3.
The MCVideo server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCVideo server cancels/resets the in-progress imminent peril state.
Step 4.
MCVideo server resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based upon the information from group management server.
Step 5.
The MCVideo server sends an MCVideo imminent peril group call cancel request to the MCVideo group members.
Step 6.
MCVideo group members are notified of the in-progress imminent peril cancel.
Step 7.
The receiving MCVideo group members send the MCVideo imminent peril group call cancel response to the MCVideo server to acknowledge the in-progress MCVideo imminent peril group call cancel request. For a multicast scenario, these acknowledgements are not set.
Step 8.
The MCVideo server sends the MCVideo imminent peril group call cancel response to the MCVideo user 1 to confirm the MCVideo imminent peril group call cancel request.
Up

7.1.2.6  MCVideo emergency alert (on-network and off-network)  p. 54

The MCVideo server shall support the procedures and related information flows as specified in subclauses 10.10 of TS 23.280 with the following clarifications:
  • The MC service ID is the MCVideo ID;
  • The MC service server is the MCVideo server;
  • The MC service group ID is the MCVideo group ID and
  • The MC service user profile index is the MCVideo user profile index.

7.1.2.7  MCVideo ad hoc group emergency alert (on-network) |R18|  p. 54

The MCVideo server 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 ID is the MCVideo ID;
  • The MC service server is the MCVideo server;
  • The MC service group ID is the MCVideo group ID and
  • The MC service user profile index is the MCVideo user profile index.

7.1.2.8  Group call handling with preconfigured regroup update procedures |R19|  p. 54

7.1.2.8.1  Call request to MCVideo group during an in-progress preconfigured group regroup  p. 54
Figure 7.1.2.8.1-1 illustrates the procedure when a user attempts to setup an MCVideo group call on a group involved in an in-progress preconfigured MCVideo group regroup.
Pre-conditions:
  • The MCVideo client is an affiliated member of MCVideo group A that is part of an in-progress preconfigured group regroup with MCVideo groups B and C.
  • MCVideo group D is being used as the preconfigured regroup group.
  • The MCVideo client has missed the preconfigured regroup request message (e.g. poor signalling conditions, race condition).
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.8.1-1: Procedure for call request to MCVideo group during an in-progress preconfigured group regroup
Figure 7.1.2.8.1-1: Procedure for call request to MCVideo group during an in-progress preconfigured group regroup
Up
Step 1.
The MCVideo client attempts to start a call on MCVideo group A. The MCVideo client sends a group call request message to the MCVideo server containing MCVideo group A as the target group.
Step 2.
The MCVideo server checks to see whether MCVideo group A is currently part of a preconfigured group regroup. In this case the group A is part of an active preconfigured group regroup.
Step 3.
The MCVideo server sends a group call response to the MCVideo client indicating that the call setup is denied because the group is part of an in-progress group regroup.
Step 4.
The MCVideo client notifies the user of the group call setup failure.
Step 5.
The MCVideo server initiates the adding a user to regroup group due to communication request to the group being regrouped procedure as described in clause 10.15.3.4 of TS 23.280.
Up
7.1.2.8.2  Call request to regroup group after group regroup has been cancelled  p. 55
Figure 7.1.2.8.2-1 illustrates the procedure when a user attempts to setup a MCVideo group call on a preconfigured regroup group after the preconfigured MCVideo group regroup has been cancelled.
Pre-conditions:
  • The MCVideo client is a member of MCVideo group A that was part of an in-progress preconfigured group regroup with MCVideo groups B and C that has been cancelled. MCVideo group D was used as the MCVideo regroup group.
  • The MCVideo client has missed the preconfigured regroup cancel request message (e.g. poor signalling conditions, race condition).
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.8.2-1: Procedure for call request to regroup group after the group regroup is cancelled
Figure 7.1.2.8.2-1: Procedure for call request to regroup group after the group regroup is cancelled
Up
Step 1.
The MCVideo client attempts to start a call on MCVideo group D, the MCVideo regroup group. The MCVideo client sends a group call request message to the MCVideo server containing MCVideo group D as the target group.
Step 2.
The MCVideo server checks to see whether MCVideo group D is currently being cancelled or not. In this case the regroup group D is no longer active.
Step 3.
The MCVideo server sends a group call response to the MCVideo client indicating that the call setup is denied because the regroup group is no longer active.
Step 4.
The MCVideo client notifies the user of the group call setup failure.
Step 5.
The MCVideo server initiates the regroup group cancel notification due to communication request to the cancelled regroup group as described in clause 10.15.3.4 of TS 23.280.
Up

Up   Top   ToC