Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  19.3.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.17…   10.17.3…   10.17.5…   11…   11.3…   11.5…   11.5.2…   11.5.3…   11.5.3.3.2A…   A…   B…   C…   E…

 

10.17.3  Common ACM proceduresp. 319

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 requestsp. 319

10.17.3.1.1  Generalp. 319
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  Procedurep. 319
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
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 automaticallyp. 320

10.17.3.2.1  Generalp. 320
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 serverp. 320
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
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 clientp. 321
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
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 managementp. 322

10.17.4.1  ACM Group membership configurationp. 322

10.17.4.1.1  Generalp. 322
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  Procedurep. 322
10.17.4.1.2.1  Group membership update by authorized user from a partner MC systemp. 322
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
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

10.17.4.2  Providing interconnection MC service group IDp. 324

10.17.4.2.1  Generalp. 324
The MC system where the interconnection MC service goup is set up, here the primary MC sytems, has to provide the identity of the group to the interconnected partner MC system. The specified procedure in this clause shows how an authorized user of an ACM client in primary MC system can provide the ACM server of partner MC system,or an authorized ACM client of partner MC system with one or more new interconnection MC service group IDs.
10.17.4.2.2  Providing identity of interconnection MC service groupp. 324
The procedure, which enables an authorized MC service user of a primary MC system to provide a list of interconnection group ID(s) to a selected authorized user of a partner MC system, is shown in Figure 10.17.4.2.2-1.
Pre-conditions:
  • Primary MC system and partner MC system are interconnected.
  • Both MC systems have implemented an ACM functionality.
  • The primary MC system is the MC service group home system for one or more interconnection groups.
  • An MC service user of the primary MC system is authorized to provide a list of interconnection group IDs to partner MC system.
  • When a functional alias is used as the target of the request by an ACM client in the primary MC system, it is required that the primary ACM server has subscribed to the MC service functional alias controlling server within the primary MC system, and that the partner ACM server has subscribed to the MC service functional alias controlling server within the partner MC system.
Reproduction of 3GPP TS 23.280, Fig. 10.17.4.2.2-1: Providing interconnection MC service group ID(s) to partner MC system
Up
Step 1.
The ACM client in the primary MC system sends an interconnection group identity provision request to the ACM server in the primary MC system, providing a list of interconnection group IDs and the ID of the selected authorized user in the partner MC system.
Step 2.
The ACM server of the primary MC system checks whether the MC service user at ACM client is authorized for the request. If the authorization check fails, the procedure is stopped.
Step 3.
The ACM server of the primary MC system forwards the interconnection group identity provision request to the ACM server in the partner MC system.
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 forwards the stored interconnection group identity provision request to the ACM client of the partner MC system.
Step 6.
The selected authorized user of the partner MC System processes the interconnection group IDs, e.g. by saving the information for future use. The authorized user in the partner MC system takes whatever actions are needed to handle the request. The actions taken within the partner MC system are outside the scope of the 3GPP specifications.
Step 7.
The ACM client of the partner MC system sends a interconnection group identity provision response to the ACM server of the partner MC system.
Step 8.
The ACM server of the partner MC system forwards the interconnection group identity provision response to the ACM server in the primary MC system.
Step 9.
The ACM server of the primary MC system stores the interconnection group identity provision response. If the primary ACM client is not logged on the primary ACM server will follow the pending request procedure as described in clause 10.17.3.1.
Step 10.
The ACM server of the primary MC system forwards the interconnection group identity provision response to the ACM client of primary MC system, informing the authorized user of the primary MC system that the list of interconnection group IDs has been provided to the selected authorized user of the partner MC system.
Up

Up   Top   ToC