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.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.5 ACM user migration management  10.17.5.1 General  10.17.5.2 Adding users for migration to a partner MC system  10.17.5.3 Removing users for migration from a partner MC system  10.17.6 ACM updating MC service UE initial configuration for migration  10.17.6.1 General  10.17.6.2 Procedure  10.17.7 ACM updating MC service user profiles assigned from partner MC system  10.17.7.1 General  10.17.7.2 Procedure 
...

 

10.17.5  ACM user migration management  p. 326

10.17.5.1  General  p. 326

User migration management permits adding or removing of MC service users of primary MC system for migration at partner MC system. An authorized MC service user can request adding or removing MC service users of his primary MC system for migration at an partner MC system by means of his ACM client.

10.17.5.2  Adding users for migration to a partner MC system  p. 326

The procedure for an authorized MC service user in a primary MC system to request a partner MC system to authorize a list of MC user IDs from its MC System to migrate to that partner MC System is shown in Figure 10.17.5.2-1.
Pre-conditions:
  • The primary MC system and the partner MC system are interconnected.
  • The primary MC system and the partner MC system have implemented an ACMS.
  • The MC service user at the ACM client of the primary MC system is authorized to request adding users for migration to the partner MC system.
  • The MC service user at the ACM client of the partner MC system is authorized to respond to requests for adding a list of users for migration from the primary 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.5.2-1: Add user configuration request in partner MC system
Figure 10.17.5.2-1: Add user configuration request in partner MC system
Up
Step 1.
The primary ACMC sends add user configuration request to the primary ACMS, requesting to authorize a list of MC users from the primary MC System to migrate to the partner MC System.
Step 2.
The primary ACMS performs an authorization check to verify that the MC service user is authorized to perform this action. If the authorization check fails, the procedure is stopped.
Step 3.
The primary ACMS sends the user configuration request to the partner ACMS.
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 partner ACMS sends the stored add user configuration request to the partner ACM client.
Step 6.
The authorized MC service user of partner MC system checks the content of the add user configuration 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 configurations. The actions within the partner MC system to apply the configurations are outside the scope of the 3GPP specifications.
Step 7.
The partner ACM client sends add user configuration response to the partner ACM server.
Step 8.
The partner ACM server sends add user configuration response to the primary ACM server.
Step 9.
The primary ACM server stores the add user configuration 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 primary ACM server sends the add user configuration response to the primary ACM client.
Up

10.17.5.3  Removing users for migration from a partner MC system  p. 328

The procedure for an authorized MC service user in the primary MC system, that is sent to an authorized user in the partner MC system, to request that certain users be removed from migration access in the partner MC system is shown in Figure 10.17.5.3-1.
Pre-conditions:
  • The primary MC system and the partner MC system are interconnected.
  • The primary MC system and the partner MC system have implemented an ACMS.
  • The MC service user in the primary MC system is authorized to request a list of MC service users be removed from the partner MC system for migration from the primary 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.5.3-1: Remove user configuration request from a partner MC system
Figure 10.17.5.3-1: Remove user configuration request from a partner MC system
Up
Step 1.
The ACM client in the primary MC system sends a remove user configuration request to the ACM server in the primary MC system. This request includes a list of MC service users to be removed for migration access in the partner MC system.
Step 2.
The ACM server in the primary MC system validates whether the MC service user is authorized for the request. If the authorization check fails, the procedure is stopped.
Step 3.
The ACM server in the primary MC system sends the remove user configuration request to the ACM server in the partner MC system.
Step 4.
The ACM server 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 ACM server 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 in the partner MC System sends the remove user configuration request to the ACM client in the partner MC system.
Step 6.
The authorized MC service user of partner MC system checks the content of the request and decides whether to approve it or not. The authorized MC service user in the partner MC system takes whatever actions are needed to remove the requested user from migration access to the partner MC system. The actions within the partner MC system to remove users are outside the scope of the 3GPP specifications.
Step 7.
The ACM client of the partner MC system sends a remove user configuration response to the ACM server in the partner MC system. The target of this response is the original MC service user in the primary MC system that sent the remove user configuration request.
Step 8.
The ACM server in the partner MC system sends the remove user configuration response to the ACM server in the primary MC system.
Step 9.
The ACM server in the primary MC system stores the remove user configuration 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 in the primary MC system sends the remove user configuration response to the ACM client in the primary MC system.
Step 11.
The authorized MC service user in the primary MC system takes whatever actions are needed (if any) to update the user profiles in the primary MC system for those users that no longer have migration access to the partner MC system.
Up

10.17.6  ACM updating MC service UE initial configuration for migration  p. 330

10.17.6.1  General  p. 330

MC service UE initial configuration for migration is essential to perform migration because this configuration contains connectivity information such as APN, server URIs and other connectivity information of the partner MC system. MC service users which had been added (clause 10.17.5.2) for migration to a partner MC system will have received user profiles containing this configuration (table A.6-1) which enables them to get connected to the partner MC system.
In case changes to the connectivity information occurs, the MC service UE initial configuration shall be updated.
Up

10.17.6.2  Procedure  p. 330

The procedure for an authorized MC service user in a primary MC system to update initial MC service UE configuration data information in the partner MC system is shown in Figure 10.17.6.2-1.
Pre-conditions:
  • Primary MC system and partner MC system are interconnected.
  • Both MC systems have implemented ACM functionality.
  • The set of MC service IDs and the MC service UE initial configuration of the migrating MC service users have been already sent by the primary MC system to the partner MC system, as specified in clause 10.17.5 ACM user migration management (between interconnected MC systems).
  • 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.6.2-1: Update MC service UE initial configuration
Figure 10.17.6.2-1: Update MC service UE initial configuration
Up
Step 1.
The primary ACM client sends an update MC service UE initial configuration to the primary ACM server, providing the initial MC service UE configuration data as specified in TS 23.280, Annex 6 to the primary MC System.
Step 2.
The primary ACM server performs an authorization check to verify that the MC service user is authorized to perform this action. If the authorization check fails, the procedure is stopped.
Step 3.
The primary ACM server sends the update MC service UE initial configuration to the partner ACM server.
Step 4.
The ACM server 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 ACM server 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 partner ACM server forwards the stored update MC service UE initial configuration to the partner ACM client.
Step 6.
The authorized MC service user of partner MC system processes the received update MC service UE initial configuration.
Step 7.
The partner ACM client sends update MC service UE initial configuration response to the partner ACM server.
Step 8.
The partner ACM server sends update MC service UE initial configuration response to the primary ACM server.
Step 9.
The primary ACM client stores the update MC service UE initial configuration response as described in clause 10.17.3.1.
Step 10.
The primary ACM server forwards the update MC service UE initial configuration response to the primary ACM client.
Up

10.17.7  ACM updating MC service user profiles assigned from partner MC system  p. 332

10.17.7.1  General  p. 332

A primary MC system may request through ACM entities to add a list of its MC service user for migration to a connected partner MC system as specified in clause 10.17.5 ACM user migration management. In case the partner MC system agrees to accept these users for migration it will reply with a response containing assigned MC service user identities and MC service user profiles. Those will be applicable and valid while the requested primary MC service users are migrated into the partner MC system,
In case, the primary MC system may want to update the received MC service user profiles from the partner MC system it can send a request for updating those as described in the procedure below.
Up

10.17.7.2  Procedure  p. 332

The procedure for an authorized MC service user in a primary MC system to request MC service user profile update from a partner MC system is shown in Figure 10.17.7.2-1.
Pre-conditions:
  • Primary MC system and partner MC system are interconnected.
  • Both MC systems have implemented ACM functionality.
  • 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.7.2-1: MC service user profile update
Figure 10.17.7.2-1: MC service user profile update
Up
Step 1.
The primary ACMC sends MC service user profile update request to the primary ACMS providing the required changes for the MC service user that is migrated to the partner MC System.
Step 2.
The primary ACMS performs an authorization check to verify that the MC service user is authorized to perform this action. If the authorization check fails, the procedure is stopped.
Step 3.
The primary ACMS sends the MC service user profile update request to the partner ACMS.
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 partner ACMS forwards the stored MC service user profile update request to the partner ACMC.
Step 6.
The authorized MC service user of partner MC system checks the content of the MC service user profile 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 MC service user profile update. The actions within the partner MC system to apply this configuration are outside the scope of the 3GPP specifications.
Step 7.
The partner ACMC sends MC service user profile update response to the partner ACMS.
Step 8.
The partner ACMS sends MC service user profile update response to the primary ACMS.
Step 9.
The primary ACMS stores the MC service user profile update response. If the primary ACMC is not logged on the primary ACMS will follow the pending request procedure as described in clause 10.17.3.1.
Step 10.
The primary ACMS forwards the MC service user profile update response to the primary ACMC.
Up

Up   Top   ToC