Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  19.0.1

Top   Top   Up   Prev   Next
1…   5…   5.2.8…   6   7…   7.3.2   7.4…   7.4.3…   7.5…   8…   9…   9.2.2…   9.2.2.2…   9.3…   10…   10.1.2…   10.1.3…   10.1.4.3…   10.1.4.5…   10.1.5…   10.1.6…   10.2…   10.2.3…   10.2.4.2…   10.2.4.3…   10.2.5…   10.2.7…   10.3…   10.6…   10.7…   10.7.3…   10.7.3.4…   10.7.3.7…   10.7.3.7.3   10.7.3.8…   10.7.3.10…   10.8…   10.8.4…   10.8.5…   10.9…   10.9.3…   10.9.3.5…   10.9.3.8…   10.9.3.9…   10.9.3.9.3…   10.9.3.9.4…   10.9.3.10…   10.9.3.10.4…   10.9.3.10.6…   10.10…   10.10.1.2.3…   10.10.2…   10.10.3…   10.10.3.3…   10.10.3.4…   10.11…   10.11.5…   10.12…   10.13…   10.13.3…   10.13.7…   10.13.10…   10.14…   10.15…   10.15.3…   10.15.3.3…   10.15.3.4…   10.16…   10.16.3…   11…   11.3…   11.5…   11.5.2…   11.5.3…   11.5.3.3.2A…   11.5.4…   A…   B…   C…

 

10.2.4.2  Temporary group formation involving multiple MC systemsp. 108

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.
Reproduction of 3GPP TS 23.280, Fig. 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|p. 110

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.
Reproduction of 3GPP TS 23.280, Fig. 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

Up   Top   ToC