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

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.17…   11…   11.3…   11.5…   11.5.2…   11.5.3…   11.5.3.3.2A…   11.5.4…   A…   B…   C… 
10.17 Sharing administrative configuration between interconnected MC systems  10.17.1 General  10.17.2 Information flows  10.17.2.1 ACM data notification  10.17.2.2 Get ACM data request  10.17.2.3 Get ACM data response  10.17.2.4 Group membership update request  10.17.2.5 Group membership update response  10.17.2.6 Process indication  10.17.3 Common ACM procedures  10.17.3.1 Pending requests  10.17.3.2 Processing incoming requests automatically  10.17.4 ACM Group configuration management  10.17.4.1 ACM Group membership configuration 
...

 

10.17  Sharing administrative configuration between interconnected MC systems |R19|  p. 314

10.17.1  General  p. 314

Cooperation between MC systems encompasses a number of cases of mutual operation between them, e.g:
  • Migration during ongoing group or private call communication as specified in subclause 10.16.
  • Generic procedures for interconnection as specified in clause 10.14.
  • Migration of MC service users from an MC system considered as primary or home MC system to an partner MC system as specified in subclause 10.6.3.
  • Provisioning connectivity information of partner MC system(s) for MC service UE migration as specified in subclause 10.1.6.
  • Shared MC service groups which can be configured as described in clause 10.2.7.
The above scenarios in many cases require configurations in both the primary MC system and the partner MC system as precondition.
Sharing administrative configuration between interconnected MC systems enables MC administrators and authorized MC service users of the primary MC system and the MC administrators and authorized MC service users of the partner MC system to negotiate and and apply configuration changes between interconnected MC systems, in order to fullfil preconditions for the cooperation between interconnected MC systems.
Up

10.17.2  Information flows  p. 314

10.17.2.1  ACM data notification  p. 314

Table 10.17.2.1-1 describes the information flow of the ACM data notification from the ACM server to the ACM client.
Information element Status Description
MC service IDMThe identity of the MC service user towards the pending ACM data notification is sent.
Up

10.17.2.2  Get ACM data request  p. 314

Table 10.17.2.2-1 describes the information flow of Get ACM data request from an ACM client to the ACM server.
Information element Status Description
MC service IDMThe identity of the MC service user requesting for the download of the pending ACM data.
Up

10.17.2.3  Get ACM data response  p. 315

Table 10.17.2.3-1 describes the information flow of Get ACM data response from an ACM server to the ACM client.
Information element Status Description
MC service IDMThe identity of the MC service user requesting for the download of the pending ACM data.
ACM DataMContains all ACM requests which are pending for this user.
Up

10.17.2.4  Group membership update request  p. 315

Table 10.17.2.4-1 describes the information flow group membership update request from ACM client to ACM server in the primary MC system, from ACM server of primary MC system to ACM server of partner MC system and from ACM server to ACM client in partner MC system.
Information element Status Description
MC service IDMThe identity of the MC service user at the primary MC system who requests the information update.
Functional aliasOThe functional alias of the MC service user at the primary MC system who requests the information update.
MC service IDO (see NOTE)The identity of the MC service user at the partner MC system towards the information update is sent.
Functional aliasO (see NOTE)The functional alias of the MC service user at the partner MC system towards the information update is sent.
MC service group IDMIdentity of the MC service group.
MC service ID listMList of identities of the MC service users that are affected by this operation.
OperationMAdd to or delete from the group.
UrgencyOIndicates the level of operational urgency of the group membership update request.
NOTE:
Either the MC service ID or the functional alias must be present.
Up

10.17.2.5  Group membership update response  p. 315

Table 10.17.2.5-1 describes the information flow group membership update response from ACM client to ACM server in partner MC system, from ACM server in partner MC system to ACM server in primary MC system and from ACM server to ACM client in primary MC system.
Information element Status Description
MC service IDMThe identity of the MC service user at the primary MC system who requested the information update.
MC service group IDMIdentity of the MC service group.
ResultMIndicates the acceptance or rejection to perform the operation.
Up

10.17.2.6  Process indication  p. 315

Table 10.17.2.6-1 describes the information flow of Process indication from ACM server in partner MC system to ACM server in primary MC system and from ACM server to ACM client in primary MC system.
Information element Status Description
MC service IDMThe identity of the MC service user requesting for Group membership update and any other valid ACM request sent to partner MC system.
MC service group IDMIdentity of the MC service group.
AcknowledgementMACM request has been received, stored and processing is in progress.
Up

10.17.3  Common ACM procedures  p. 316

Processing of the incoming ACM commands can be handled by the ACM entities through one of the following methods:
  • manually by an ACM client of an authorized user or an administrator as described under the pending requests method in clause 10.17.3.1.
  • automatically either by an ACM server, or by an automated ACM client as described under clause 10.17.3.2.
Based on the local policy, rules can be defined for the use of these methods by the MC system for the execution of the different ACM transactions.
Up

10.17.3.1  Pending requests  p. 316

10.17.3.1.1  General  p. 316
This procedure provides the means to manage and respond to the incoming requests manually. It describes the manual option which is performed by the ACM client of an authorized MC service user or administrator.
This procedure provides the detailed description of the steps that are not included in other procedures for simplicity.
10.17.3.1.2  Procedure  p. 316
Upon receiving an ACM request the ACM server should forward the request to the authorized user at its MC system. Performing this process might require considerable waiting time if the target authorized user is not logged on.
In addition, when an ACM server receives a response to a previously sent ACM request, where the authorized user is not logged on, the ACM server should store the response and notify the authorized user when the user logs on again.
The common procedure for pending ACM request/response is shown in Figure 10.17.3.1.2-1.
Pre-conditions
  • The ACM server has received an ACM request, or a response, and has stored it.
  • The ACM server has received an ACM request that should be validated by an authorized user
  • The targeted ACM authorized user is currently not logged on.
Reproduction of 3GPP TS 23.280, Fig. 10.17.3.1.2-1: Pending requests Procedure
Figure 10.17.3.1.2-1: Pending requests Procedure
Up
Step 1.
An authorized MC service user of the MC system logs on to the ACM client.
Step 2.
The ACM server notifies the ACM client of the pending ACM data.
Step 3.
The ACM client requests the ACM server to send the pending ACM data.
Step 4.
The ACM server sends the stored ACM data to the ACM client.

10.17.3.2  Processing incoming requests automatically  p. 317

10.17.3.2.1  General  p. 317
This procedure provides the means to manage and respond to the incoming requests automatically. It describes the automation options performed in the ACM server or by an automated ACM client.
This procedure provides the detailed description of the steps that are not included in other procedures for simplicity.
10.17.3.2.2  Automation performed by ACM server  p. 317
The partner ACM server verifies the request and sends a response to the primary MC system. Automation performed by ACM server shown in Figure 10.17.3.2.2-1.
Reproduction of 3GPP TS 23.280, Fig. 10.17.3.2.2-1: Automation performed by ACM server
Figure 10.17.3.2.2-1: Automation performed by ACM server
Up
The following applies:
  • The partner ACM server audits the request and decides whether to apply the configurations or not.
  • The partner ACM server takes whatever actions are needed to apply the configurations to the partner MC system. The actions within the partner MC system to apply the configurations, including the interaction with other servers, are outside the scope of the 3GPP specification
  • The partner ACM server provides the means for the authorized users in the partner MC system to update the automation rules, or to terminate this automation, if required.
  • The partner ACM server provides tracking mechanism for the authorized users in the MC system for all automatically performed actions.
Up
10.17.3.2.3  Automation performed by automated ACM client  p. 318
The ACM server of the partner MC system sends the received ACM request to an automated ACM client for processing and sending a ACM response automatically to the primary MC system without human interaction, as shown in Figure 10.17.3.2.3-1.
Reproduction of 3GPP TS 23.280, Fig. 10.17.3.2.3-1: Automation performed by an automated ACM client
Figure 10.17.3.2.3-1: Automation performed by an automated ACM client
Up
The following applies:
  • The automated ACM client is enabled/logged-in and connected to ACM server
  • The automated ACM client audits and verifies the request to decide whether to apply the configurations or not.
  • The automated ACM client takes whatever actions are needed to apply the configurations to the partner MC system. The actions within the partner MC system to apply the configurations are outside the scope of the 3GPP specification
  • The MC system provides the possibility for the authorized users to update the automation rules, or to terminate the automated ACM client and accordingly the process automation, if required.
  • The partner ACM server provides tracking mechanism for the authorized users in the partner MC system for all automatically performed actions by an automated client.
Up

10.17.4  ACM Group configuration management  p. 319

10.17.4.1  ACM Group membership configuration  p. 319

10.17.4.1.1  General  p. 319
This clause address the following aspects:
  • The second precondition in clause 10.2.7.2 of TS 23.280: One or more MC service group members are defined in the partner MC system.
  • ACM entities can be used to manage/change memberships of interconnected MC service groups in partner MC systems.
10.17.4.1.2  Procedure  p. 319
10.17.4.1.2.1  Group membership update by authorized user from a partner MC system  p. 319
The procedure for an authorized MC service user in a partner MC system to request the primary MC system of the MC service group to modify group membership to an interconnection group is shown in Figure 10.17.4.1.2.1-1.
Pre-conditions
  • MC system A and MC system B are interconnected
  • MC system A and MC system B have implemented an ACMS
  • MC system B is the primary MC system of an interconnection group
  • The authorized MC service user of MC system A (the partner MC system) wants to modify the membership of MC users of system A in the interconnection group for which MC system B is the primary MC system.
  • When a functional alias is used as the target of the request by an ACM client in the MC system A, it is required that the ACM server of MC system A has subscribed to the MC service functional alias controlling server within the MC system A, and that the ACM server of MC system B has subscribed to the MC service functional alias controlling server within the MC system B.
Reproduction of 3GPP TS 23.280, Fig. 10.17.4.1.2.1-1: Group membership update by authorized user from a primary MC system
Figure 10.17.4.1.2.1-1: Group membership update by authorized user from a primary MC system
Up
Step 1.
The ACM client in primary MC system sends a group membership update request to the ACM server in his MC system, requesting to modify the membership of users from primary MC system an interconnection group for which partner MC system is the primary MC system.
Step 2.
The ACM server of the primary MC system checks whether the MC service user at the ACM client is authorized for the request.
Step 3.
The ACM server of the primary MC system sends the group membership update request to the ACM server of the partner MC system, the primary MC system of the interconnection group.
Step 4.
The ACMS of the partner MC system sends a process indication to primary MC system, and stores, verifies and assesses the incoming request.
Based on local policy,
  • the ACMS of the partner MC system may automatically handle the request as described in clause 10.17.3.2 and continues with step 8,
    or
  • the ACM server requests verification by an ACM client: If the user is not logged on the pending request procedure as described in clause 10.17.3.1 is followed. If the request targets a functional alias the ACM server of the partner MC system resolves the functional alias (based on the current state of the functional alias) and proceeds as follows:
  • if the functional alias is active for one ACM client, the request is sent to the ACM client;
  • if the functional alias is active for more than one ACM client, the ACM server sends the request to one of these ACM clients based on the local policy;
  • if the functional alias is not currently active, the ACM server of the partner MC system stores the request.
Step 5.
The ACM server of the partner MC system sends the stored group membership update request to the ACM client of partner MC system.
Step 6.
The authorized MC service user of the partner MC system (manually) screens the content of the group membership update request and decides whether to approve it or not. The authorized user in the partner MC system takes whatever actions are needed to apply the group membership update. The actions within the partner MC system to apply this configurations are outside the scope of the 3GPP specifications.
Step 7.
The ACM client of the partner MC system sends a group membership update response to the ACM server of the partner MC system.
Step 8.
The ACM server of the partner MC system sends the group membership update response to the ACM server of the primary MC system.
Step 9.
The ACM server of primary MC system stores the group membership update response. If the ACM client of primary MC system is not logged on the ACMS of primary MC system it will follow the pending request procedure as described in clause 10.17.3.1.
Step 10.
The ACM server of primary MC system sends the group membership update response to the ACM client of the primary MC system.
Up

Up   Top   ToC