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

Top   Top   Up   Prev   Next
1…   5…   6…   7…   7.1.2.3…   7.1.2.4…   7.1.3…   7.2…   7.2.3…   7.3…   7.4…   7.5…   7.6…   7.7…   7.7.1.3.5…   7.7.2…   7.8…   7.17…   7.19…   7.19.3…   7.19.3.1.4…   7.19.3.2…   7.19.3.2.5…   A… 
7.1.2.4 Broadcast group call  7.1.2.5 Emergency and imminent peril procedures  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.4  Broadcast group call  p. 42

7.1.2.4.1  General  p. 42
A broadcast group call is a special group call where the initiating MCVideo user expects no response from the other MCVideo users, i.e. no response from the recipients is required to start media transmission and the call ends when the media transmission is complete.
7.1.2.4.2  Common broadcast group call procedure  p. 42
Only the call originator can transmit media during the broadcast group call and the broadcast group call is released when the transmission is complete.
Figure 7.1.2.4.2-1 illustrates the common procedure both for broadcast group call on group-broadcast group, user-broadcast group, broadcast regrouped group, and pre-arranged groups.
Pre-condition:
  1. MCVideo client 1 and MCVideo client 2 are members of a group-broadcast group/user-broadcast group.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.4.2-1: Broadcast group call
Figure 7.1.2.4.2-1: Broadcast group call
Up
Step 1.
MCVideo user at MCVideo client 1 initiates the broadcast group call setup procedure with the indication of broadcast group call. The signalling procedure is identical to the group call setup as described in subclause 7.1.2.3.1.1 with the inclusion of the parameter for broadcast group call indicator.
Step 2.
MCVideo client 1 starts to transmit media.
Step 3.
If the media transmission from call originating MCVideo user is complete, the broadcast group call is released.
Up

7.1.2.5  Emergency and imminent peril procedures  p. 43

7.1.2.5.1  MCVideo emergency group call  p. 43
7.1.2.5.1.1  MCVideo emergency group call commencement  p. 43
The procedure describes the case where an MCVideo client is initiating an MCVideo emergency group call with the affiliated MCVideo group members of that MCVideo group. An MCVideo client in the MCVideo emergency state gains elevated access privilege for all of the MCVideo user's mission critical applications. Initiating an MCVideo emergency group call puts the MCVideo group into the in-progress emergency state. While in the in-progress emergency state, all MCVideo group calls in the MCVideo group are processed as MCVideo emergency group calls by the MCVideo server until the emergency state of the MCVideo group is cancelled.
Figure 7.1.2.5.1.1-1 shows the procedures for the MCVideo client initiating establishment of an MCVideo emergency 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 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 via provisioning as the MCVideo emergency group.
  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.1.1-1: MCVideo emergency group call
Figure 7.1.2.5.1.1-1: MCVideo emergency group call
Up
Step 1.
The user at the MCVideo client 1 initiates an MCVideo emergency group call. MCVideo client 1 sets its MCVideo emergency state. The MCVideo emergency state of MCVideo client 1 is retained until explicitly cancelled by the user of MCVideo client 1.
Step 2.
MCVideo client 1 sends an MCVideo emergency group call request towards the MCVideo server. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo emergency group call request. The request contains an indication of the MCVideo emergency. The MCVideo server records the identity of the MCVideo user that initiated the MCVideo emergency group call until the MCVideo emergency state of the group is cancelled. Once an MCVideo emergency call has been initiated, the MCVideo group is considered to be in an in-progress emergency state until the emergency state of the group cancelled. If configured to send an MCVideo emergency alert when initiating an MCVideo emergency group call, the request also contains an indication that an MCVideo emergency alert is to be initiated. The request may contain an indication of an implicit transmit media request.
Step 3.
The MCVideo server implicitly affiliates MCVideo client 1 to the emergency 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 MCVideo emergency 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 MCVideo emergency group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of the in-progress emergency. The request contains an indication of an MCVideo emergency alert if the request from the originator indicated MCVideo emergency alert.
Step 7.
MCVideo users are notified of the incoming MCVideo group call, and, if available, the functional alias of the initiating user is displayed.
Step 8.
The receiving MCVideo clients send the MCVideo emergency group call response to the MCVideo server to acknowledge the MCVideo emergency group call request. For a multicast call, these acknowledgements are not sent.
Step 9.
The MCVideo server sends the MCVideo emergency group call response to the MCVideo user 1 to inform the successful MCVideo emergency call establishment.
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 client's receive media available notification with forced reception information. MCVideo client 1 indicates to the MCVideo user that the permission is granted to transmit media, while the other MCVideo clients in the MCVideo emergency group call will be receiving that media. MCVideo client 1 can override other clients in the call except those that are also in the MCVideo emergency state.
Up
7.1.2.5.1.2  MCVideo group call upgraded to an MCVideo emergency group call  p. 45
The procedure describes the case where an authorized MCVideo user is upgrading an MCVideo group call to an MCVideo emergency group call while the MCVideo group call is already in progress.
Procedures in Figure 7.1.2.5.1.2-1 are the signalling control plane procedures for the MCVideo client upgrading an MCVideo group call on an MCVideo group to an MCVideo emergency group call.
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. An MCVideo group call is already in progress.
  4. The initiating MCVideo client 1 has been configured to send an MCVideo emergency alert when upgrading an MCVideo emergency group call.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.5.1.2-1: MCVideo group call upgraded to an MCVideo emergency group call
Figure 7.1.2.5.1.2-1: MCVideo group call upgraded to an MCVideo emergency group call
Up
Step 1.
The MCVideo user at MCVideo client 1 initiates a group emergency. MCVideo client 1 sets its MCVideo emergency state. The MCVideo emergency state of MCVideo client 1 is retained until explicitly cancelled by the user of MCVideo client 1.
Step 2.
MCVideo client 1 requests the MCVideo server to upgrade the MCVideo group to an in-progress emergency state by sending an MCVideo emergency group call request. If configured to send an MCVideo alert when initiating an MCVideo emergency upgrade, the request also contains an indication that an MCVideo alert is to be initiated. 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 emergency group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of an MCVideo emergency alert if the request from the originator indicated MCVideo emergency alert.
Step 5.
MCVideo users are notified of the in-progress emergency state of the MCVideo group.
Step 6.
The receiving MCVideo clients send the MCVideo emergency group call response to the MCVideo server to acknowledge the MCVideo group emergency request. For a multicast call, these acknowledgements are not sent.
Step 7.
The MCVideo server sends the MCVideo emergency group call response to the MCVideo user 1 to confirm the upgrade request. If the MCVideo emergency 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 MCVideo emergency group call. MCVideo client 1 can override other clients in the call except those that are also in the MCVideo emergency state.
Up
7.1.2.5.1.3  MCVideo in-progress emergency group state cancel  p. 47
The procedure describes the case where an MCVideo client cancels an MCVideo 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 7.1.2.5.1.3-1 are the signalling control plane procedures for the MCVideo client cancelling an in-progress emergency of a group.
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. MCVideo group members have been notified about the in-progress emergency.
  4. The MCVideo group is in the in-progress emergency state and has prioritized bearer support.
  5. MCVideo client 1 previously initiated the in-progress emergency for the group.
Reproduction of 3GPP TS 23.281, Fig. 7.1.2.5.1.3-1: MCVideo in-progress emergency group state cancel
Figure 7.1.2.5.1.3-1: MCVideo in-progress emergency group state cancel
Up
Step 1.
The user at the MCVideo client 1 initiates an MCVideo in-progress emergency group state cancel.
Step 2.
MCVideo client 1 sends an MCVideo in-progress emergency group state cancel request to the MCVideo server.
Step 3.
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 4.
The MCVideo server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCVideo server cancels/resets the emergency in-progress state of the MCVideo group.
Step 5.
The MCVideo server sends an MCVideo in-progress emergency group state cancel request to the MCVideo group members.
Step 6.
MCVideo group members are notified of the MCVideo in-progress emergency group state cancel.
Step 7.
The receiving MCVideo clients send the MCVideo in-progress emergency group state cancel response to the MCVideo server to acknowledge the MCVideo in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.
Step 8.
The MCVideo server sends the MCVideo in-progress emergency group state cancel response to the MCVideo user 1 to confirm the MCVideo in-progress emergency group state cancel. If the MCVideo in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCVideo client 1 resets its local emergency status.
Up
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