Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  17.8.0

Top   Top   Up   Prev   Next
1…   5…   7…   7.4…   7.5…   8…   9…   10…   10.1.2…   10.1.3…   10.1.5…   10.2…   10.2.3…   10.2.5…   10.3…   10.7…   10.7.3…   10.7.3.7…   10.7.3.10…   10.8…   10.8.4…   10.9…   10.9.3…   10.9.3.8…   10.10…   10.11…   10.12…   10.13…   10.13.3…   10.14…   10.15…   10.15.3…   A…   B…

 

10.2.3  Group creationWord‑p. 103

Figure 10.2.3-1 below illustrates the group creation operations by authorized MC service user/ MC service administrator to create a group. It applies to the scenario of normal group creation by an MC service administrator and user regrouping operations by authorized user/dispatcher.
Pre-conditions:
  1. The group management client, group management server, MC service server and the MC service group members belong to the same MC system.
  2. The administrator/authorized user/dispatcher is aware of the users' identities which will be combined to form the MC service group.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.2.3-1: Group creation
Figure 10.2.3-1: Group creation
(⇒ copy of original 3GPP image)
Up
Step 1.
The group management client of the administrator/dispatcher/authorized MC service user requests group create operation to the group management server. The identities of the users being combined and the information of the MC services that are enabled on the group shall be included in this message.
Step 2a.
If the proposed MC service group ID information element is not present in the group creation request, the group management server generates the MC service group ID. If the proposed MC service group ID information element is present and acceptable to the group management server, the group management server uses the proposed MC service group ID for the new group. If the proposed MC service group ID information element is present but not acceptable to the group management server, the group management server modifies proposed MC service group ID or generates the MC service group ID or rejects the group creation request.
Step 2b.
During the group creation, the group management server stores or creates and stores the information of the group as group configuration data as described in subclause 10.1.5.4. The group management server performs the check on the maximum limit of the total number (Nc6) of MC service group members for the MC service group(s).
Step 3.
The group management server may conditionally notify the MC service server regarding the group creation with the information of the group members (if any). During user regroup, the group management server notifies the MC service server regarding the group creation with the information of the temporary group members. The MC service users of the temporary group may be automatically affiliated, if configured on the MC service server.
Step 4.
The MC service group members (if any) of the MC service group are notified about the newly created MC service group configuration data.
Step 5.
The group management server provides a group creation response to the group management client of the administrator/dispatcher/authorized MC service user. The result information element indicates:  
  • success (using proposed MC service group ID); or
  • success (MC service group ID provided by the group management server); or
  • failure (proposed MC service group ID not acceptable); or
  • failure for other reason.
Up

10.2.4  Group regroupingWord‑p. 104

10.2.4.1  Temporary group formation - group regrouping within an MC systemWord‑p. 104

Figure 10.2.4.1-1 below illustrates the group regroup operations to create a temporary group within an MC system. For simplicity, only the case of two MC service groups being combined is represented, but the procedure is the same if more than two groups are combined.
The temporary group formation is applicable only for groups configured with at least one common MC service. The temporary group formation shall be rejected if any of the requested MC services are not common to all MC service groups in the list.
The temporary group created can be a broadcast group or a non-broadcast group. The broadcast regroup is used for one-way communication where only an authorized MCX user is allowed to transmit and all other regroup members are only allowed to receive the communication (e.g. a call from a dispatcher to all regroup members). The non-broadcast regroup is used for two-way communication where all regroup members can transmit and receive (i.e, the regroup group call behaves like a normal non-broadcast group call). The broadcast regroup satisfies the temporary group-broadcast group requirements defined in TS 22.179 and is an alternative to the "Temporary group - broadcast group call" procedure (subclause 10.6.2.5.3 in TS 23.379).
Pre-conditions:
  1. The group management client, group management server, MC service server and the MC service group members belong to the same MC system.
  2. The group management client has retrieved the group configurations of the groups to be regrouped.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.2.4.1-1: Group regroup for the groups within the same MC system
Up
Step 1.
The group management client of the MC service user requests group regroup operation to the group management server, which is the group management server of one of the groups to be regrouped. The identities of the groups being combined shall be included in this message. The group management client may indicate the security level required for the temporary group. The group management client may indicate the priority level required for the temporary group. The group management client indicates whether the temporary group is a broadcast regroup.
Step 2.
The group management server checks whether group regroup operation is performed by an authorized MC service user, based on group policy. The group management server checks whether group1 or group2 is a temporary group. If group 1 or group2 is a temporary group, then the group regrouping will be rejected, otherwise the group regrouping can proceed.
Step 3.
The group management server creates and stores the information of the temporary group, including the temporary MC service group ID, the MC service group ID of the groups being combined, the priority level of the temporary group, the security level of the temporary group, and whether the temporary group is a broadcast regroup. If the authorized MC service user does not specify the security level and the priority level, the group management server shall set the lowest security level and the highest priority of the constituent groups. If MC service types of the groups being combined are not identical, group management server determines the overlapping part and stores the MC service list for the temporary group.
Step 4.
The group management server notifies the MC service server regarding the temporary group creation with the information of the constituent groups, i.e. temporary MC service group ID, group1's MC service group ID and group2's MC service group ID. If MC service list is included, MC service server stores it and provides MC service types accordingly.
Step 5.
The group management server notifies the affiliated MC service group members of the constituent MC service groups by sending group regroup notification messages.
Step 6.
The affiliated MC service group members of the constituent MC service groups send individual group regroup notification response messages.
Step 7.
The group management server provides a group regroup response to the group management client of the authorized MC service user. If MC service list is included, group management client stores it and initiates MC service types accordingly.
Step 8.
The affiliated MC service group members of the constituent MC service groups individually request group configuration data from the group management server for the temporary group, as described in clause 10.1.5.2. The group configuration data includes security, priority, and other parameters.
Up

10.2.4.2  Temporary group formation involving multiple MC systemsWord‑p. 106

Figure 10.2.4.2-1 below illustrates the group regroup operations to create a temporary group involving multiple MC systems. For simplicity, only the case of two MC service groups being combined is represented, but the procedure is the same if more than two groups are combined.
Pre-conditions:
  1. The security aspects of sharing the user information between primary and partner MC systems shall be governed as per the service provider agreement between them. In this case, we consider the partner MC system does not share their users' information to the primary MC system.
  2. The primary MC system consists of the group management server 1 and MC service server (primary). The partner MC system consists of the group management server 2 and MC service server (partner).
  3. The group management client of the authorized MC service user belongs to the primary MC system.
  4. The group management client has retrieved the group configurations of the groups to be regrouped.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.2.4.2-1: Temporary group formation - group regrouping involving multiple MC systems
Up
Step 1.
The group management client of the MC service user (e.g. dispatcher) requests group regroup operation to the group management server 1 (which is the group management server of one of the groups to be regrouped). The identities of the groups being combined shall be included in this message. The group management client may indicate the security level required for the temporary group. The group management client may indicate the priority level required for the temporary group. The group management client indicates whether the temporary group is a broadcast regroup.
Step 2.
The group management server checks whether group regroup operation is performed by an authorized MC service user, based on group policy. The group management server 1 checks whether group1 is a temporary group. If group1 is a temporary group, then the group regrouping will be rejected, otherwise the group regrouping can proceed.
Step 3.
The group management server 1 forwards the group regroup request to the target group management server 2 with the information of the group management server 2 MC service groups.
Step 4.
The group management server 2 checks whether group2 is a temporary group. If group2 is a temporary group, then the group regrouping will be rejected, otherwise the group regrouping can proceed.
Step 5.
The group management server 2 provides a group regroup response. Due to security aspects concerning sharing information among different MC systems, the group management server 2 does not share the users' information of the groups under its management to the group management server 1. Any regroup action that violates the rules specified in subclause 10.2.4.4 shall cause a negative response and the current procedure to proceed to step 15.
Step 6.
The group management server 1 creates and stores the information of the temporary group, including the temporary MC service group ID, off-network information, and the MC service IDs of the groups being combined, the priority level of the temporary group, the security level of the temporary group, and whether the temporary group is a broadcast regroup. If the authorized MC service user does not specify the security level and the priority level, the group management server shall set the lower security level and the higher priority of the constituent groups.
Step 7.
The group management server 1 notifies the group management server 2 about its group regroup operation.
Step 8.
The group management server 2 acknowledges the group management server 1 and the group management server 2 also stores the information about the temporary group including the temporary MC service group ID, the MC service group IDs of the groups being combined, the priority level of the temporary group and the security level of the temporary group.
Step 9.
The group management server 2 notifies the partner MC service server regarding the temporary group creation with the information of the constituent groups i.e. temporary MC service group ID, group1's MC service group ID and group2's MC service group ID.
Step 10.
Partner MC service server acknowledges the notification from the group management server 2.
Step 11.
The group management server 2 notifies the affiliated MC service group members of the constituent MC service groups of the group management server 2, possibly with an indication of a lower security level.
Step 12.
The affiliated MC service group members of the constituent MC service groups of the group management server 2 send individual group regroup notification responses to the group management server 2.
Step 13.
The group management server 1 notifies the MC service server of the primary system regarding the temporary group creation with the information of the constituent groups, i.e. temporary MC service group ID, group1's MC service group ID and group2's MC service group ID. If there are active calls to be merged, then the group management server 1 includes an indication to merge active calls.
Step 14.
Primary MC service server acknowledges the notification from the group management server 1.
Step 15.
The group management server 1 notifies the affiliated MC service group members of the constituent MC service groups of the group management server 1 by sending group regroup notification messages.
Step 16.
The affiliated MC service group members of the constituent MC service groups of group management server 1 send individual group regroup notification responses to the group management server 1.
Step 17.
The group management server 1 provides a group regroup response to the group management client of the authorized MC service user (e.g. dispatcher).
Step 18.
The affiliated MC service group members of the constituent MC service groups of the group management servers individually request group configuration data from the group management servers for the temporary group, as described in clause 10.1.5.2. The group configuration data includes security, priority, and other parameters.
Up

10.2.4.2a  Temporary group tear down within an MC system |R17|Word‑p. 108

Figure 10.2.4.2a-1 below illustrates the tearing down procedure of temporary group created through the group regroup operation. The procedure can be used when, e.g., the specific task for which the temporary group was created has been completed or a busier period occurs. For simplicity, only the teardown case for a temporary group with two MC service groups is represented. The procedure is applicable for more than two groups combined in this temporary group.
Pre-condition:
  • The temporary group to be torn down is comprised of multiple MC service groups, and is created through the group regrouping procedure as described in subclause 10.2.4.1.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.2.4.2a-1: Temporary group tear down within an MC system
Up
Step 1.
The group management client of the MC service user requests group regroup teardown operation to the group management server (which is the group management server where the temporary group is created and stored). The identity of the temporary group (MC service group ID) being torn down shall be included in this message. This message may route through some other signalling nodes.
Step 2.
The group management server checks whether group regroup operation is performed by an authorized MC service user, based on group policy. The group management server checks whether the MC service group ID is a temporary group. If MC service group ID is not a temporary group, then the group regroup teardown request will be rejected, otherwise the group regroup teardown can proceed.
Step 3.
The group management server tears down the temporary group, i.e., remove the temporary group related information.
Step 4.
The group management server notifies the MC service server regarding the temporary group teardown.
Step 5.
Any active group call for the temporary group is preserved until it is completed.
Step 6.
The group management server notifies the affiliated MC service group members regarding the temporary group teardown by sending the group regroup teardown notification (6a) and receives a group regroup teardown notification response (6b) messages.
Step 7.
The group management server provides a group regroup teardown confirmation response to the group management client of the authorized MC service user.
Up

10.2.4.3  Temporary group tear down involving multiple group host serversWord‑p. 109

Figure 10.2.4.3-1 below illustrates the tearing down procedure of temporary group created through the group regroup operation. The procedure can be used when, e.g., the specific task for which the temporary group was created has been completed or a busier period occurs. For simplicity, only the teardown case for a temporary group with two MC service groups is represented. The procedure is applicable for more than two groups combined in this temporary group.
Pre-conditions:
  1. The security aspects of sharing the user information between primary and partner MC systems shall be governed as per the service provider agreement between them. In this case, it considers the partner MC system does not share their users' information to the primary MC system.
  2. The primary MC system consists of the group management server 1 and MC service server (primary). The partner MC system consists of the group management server 2 and MC service server (partner).
  3. The group management client of the authorized MC service user belongs to the primary MC system.
  4. The temporary group to be torn down is comprised of multiple MC service groups, and is created through the group regrouping procedure as described in subclause 10.2.4.2.
Copy of original 3GPP image for 3GPP TS 23.280, Figure 10.2.4.3-1: Temporary group tear down
Figure 10.2.4.3-1: Temporary group tear down
(⇒ copy of original 3GPP image)
Up
Step 1.
The group management client of the MC service user requests group regroup teardown operation to the group management server 1 (which is the group management server where the temporary group is created and stored). The identity of the temporary group (MC service group ID) being torn down shall be included in this message. This message may route through some other signalling nodes.
Step 2.
The group management server checks whether group regroup operation is performed by an authorized MC service user, based on group policy. The group management server 1 checks whether the MC service group ID is a temporary group. If MC service group ID is not a temporary group, then the group regroup teardown request will be rejected, otherwise the group regroup teardown can proceed.
Step 3.
The group management server 1 tears down the temporary group, i.e., remove the temporary group related information.
Step 4.
The group management server 1 notifies the primary MC service server regarding the temporary group teardown.
Step 5.
Any active group call for the temporary group is preserved until it is completed.
Step 6.
The group management server 1 notifies the affiliated MC service group members regarding the temporary group teardown by sending the group regroup teardown notification (6a) and receives a group regroup teardown notification response (6b) messages.
Step 7.
The group management server 1 sends a group regroup teardown notification (7a) and receives a group regroup teardown notification response (7b) messages with the group management server 2 - group management server in another MC system regarding the temporary group teardown.
Step 8.
The group management server 2 notifies the partner MC service server.
Step 9.
The group management server 2 notifies the affiliated MC service group members regarding the temporary group teardown by sending the group regroup teardown notification (9a) and receives a group regroup teardown notification response (9b) messages. Any active group call for the temporary group is preserved until it is completed.
Step 10.
The group management server 1 provides a group regroup teardown confirmation response to the group management client of the authorized MC service user.
Up

10.2.4.4  Group regroup rules |R15|Word‑p. 110

To prevent routing issues and complexity related to group regrouping, the following rules shall be applied:
  • Group regroup in either single MC system or multiple MC systems can take place if:
    • None of the groups to be regrouped are temporary groups; and
    • The groups to be regrouped are not already regrouped into another temporary group; and
    • If the policy of the MC system does not allow a temporary group to include groups that are currently in emergency state, then regrouping of groups can take place if none of the groups to be regrouped are in emergency state.
  • If the policy of the MC system allows a temporary group to include groups from other MC systems, group regrouping containing groups with multiple MC systems can take place if:
    • the MC service server (controlling role) for the regrouped group is the MC service server (controlling role) for all MC service groups involved in the regrouping; or
    • the MC service server (controlling role) for the regrouped group is an MC service server (controlling role) for at least one of the MC service groups involved in the regrouping; or
    • the MC service server (controlling role) for the regrouped group is an MC service server homed by at least one of the MC service groups and the MC system of any involved MC service group allows floor control for the set of regrouped groups to be deferred to the MC service server (controlling role) of the temporary group.
  • If the policy of the MC system does not allow a temporary group to include groups from other MC systems, regrouping of groups with members spanning multiple MC systems can take place if:
    • the MC service server (controlling role) for the regrouped group is the MC service server (controlling role) for all MC service groups involved in the regrouping; or
    • the MC service server (controlling role) for the regrouped group is an MC service server (controlling role) for at least one of the MC service groups involved in the regrouping, and the MC service servers with the controlling roles for all of the groups that are regrouped are within the same MC system.
Up

Up   Top   ToC