Group management procedures apply to on-network MC service only.
Group creation provides a dedicated MC service group to individual MC service users to enable the required communication for one or multiple MC services. This includes the normal group creation by administrators as well as user regrouping by authorized user/dispatcher.
For an MC service, group regrouping enables dispatchers or authorized users to temporarily combine several MC service groups.
List of MC service IDs that are part of the group to be created corresponding to the list of the configured services (see NOTE 1)
MC service list (see NOTE 2)
O
List of MC services whose service communications are to be enabled on the group.
Proposed MC service group ID
O
MC service group ID proposed for the requested group
MC service group configuration data
O
Configuration data for the requested group (see NOTE 3)
NOTE 1:
The MC service ID list can be an empty list.
NOTE 2:
This information element shall be included in the message for creating a group configured for multiple MC services.
NOTE 3:
If the MC service group configuration data is not present it can be provided later using the "Store group configuration request" (see subclause 10.1.2.1).
A subset of the common MC service(s) to be applied for the regrouped group
Broadcast regroup
O
Indicates that only an authorized MC service user can transmit on this temporary group.
NOTE 1:
Security level refers to the configuration of media and floor control protection parameters as listed in Annex A.4, Table A.4-1.
NOTE 2:
If this information element is not present, all the MC service(s) that are common to the groups being regrouped will be applicable for the regrouped group.
List of MC services whose service communications are to be enabled on this temporary group
Result
M
Indicates the success or failure of group regroup
NOTE:
Shall be present if the Result information element indicates that the group regroup operation is successful. Otherwise MC service group ID shall not be present.
Table 10.2.2.10-1 describes the information flow group regroup teardown notification between group management servers and from the group management server to the group management client.
Table 10.2.2.11-1 describes the information flow group regroup teardown notification response between group management servers and from the group management client to the group management server.
Table 10.2.2.14-1 describes the information flow group regroup notification between group management servers and from the group management server to the group management client.
Table 10.2.2.15-1 describes the information flow group regroup notification response between group management servers and from the group management client to the group management server.
The identity of the MC service user who performs the query.
MC service group ID
M
The identity of the MC service group to be queried.
Query type
M
It indicates the query type, e.g., membership or affiliated group members.
Query result
M
The group information retrieved from the group management server based on the query type, i.e., a list of group members or a list of affiliated group member.
Table 10.2.2.23-1 describes the information flow group deletion notification from the group management server to the MC service server, and from the group management server to the group management clients for MC service users which are members of the group.
Table 10.2.2.24-1 describes the information flow group information provision request from the group management server in the primary MC system of the MC service group to the group management server in the partner MC system of the MC service group.
Table 10.2.2.25-1 describes the information flow group information provision response from the group management server in the partner MC system of the MC service group to the group management server in the primary MC system of the MC service group.
Table 10.2.2.26-1 describes the information flow group information request from the group management server in the partner MC system of the MC service group to the group management server in the primary MC system of the MC service group.
Table 10.2.2.27-1 describes the information flow group information response from the group management server in the primary MC system of the MC service group to the group management server in the partner MC system of the MC service group.
Table 10.2.2.28-1 describes the information flow group information subscribe request from the group management server in the partner MC system of the MC service group to the group management server in the primary MC system of the MC service group.
Table 10.2.2.29-1 describes the information flow group information subscribe response from the group management server in the primary MC system of the MC service group to the group management server in the partner MC system of the MC service group.
Table 10.2.2.30-1 describes the information flow group information notify request from the group management server in the primary MC system of the MC service group to the group management server in the partner MC system of the MC service group.
Table 10.2.2.31-1 describes the information flow group information notify response from the group management server in the partner MC system of the MC service group to the group management server in the primary MC system of the MC service group.
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:
The group management client, group management server, MC service server and the MC service group members belong to the same MC system.
The administrator/authorized user/dispatcher is aware of the users' identities which will be combined to form the MC service group.
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.
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.
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).
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.
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
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:
The group management client, group management server, MC service server and the MC service group members belong to the same MC system.
The group management client has retrieved the group configurations of the groups to be regrouped.
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.
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.
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.
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.
The group management server notifies the affiliated MC service group members of the constituent MC service groups by sending group regroup notification messages.
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.
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.
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:
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.
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).
The group management client of the authorized MC service user belongs to the primary MC system.
The group management client has retrieved the group configurations of the groups to be regrouped.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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).
The group management client of the authorized MC service user belongs to the primary MC system.
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.
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.
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.
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.
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.
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.
The group management server 1 provides a group regroup teardown confirmation response to the group management client of the authorized MC service user.
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.
The group management client of the MC servicer user requests the membership or affiliation list on the MC service group from the group management server by sending a group information query request. The query type is included.
The group management server checks whether the MC servicer user is authorized to perform the query. If authorized, then the group management server retrieves the requested group information based on the query type.