10.16 Generic procedures for migration

23.2803GPPCommon functional architecture to support mission critical servicesRelease 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.16.1 General

Migration provides a means for an MC service user to obtain MC service directly from a partner MC system. This subclause describes generic procedures for migration which are variations of specific procedures detailed in 3GPP TS 23.379 [16], 3GPP TS 23.281 [12] and 3GPP TS 23.282 [13]. These procedures should be read in conjunction with specific procedures in those specifications.

10.16.2 Migration during an ongoing group communication

10.16.2.1 General

This provides the capability for an MC service user to migrate to another MC system during an ongoing group communication and to continue the group communication in the other MC system.

Editor’s note: Further study is needed for MCData services.

10.16.2.2 Procedure

The procedure is based on the following existing procedures:

– MC service group de-affiliation procedure as described in clause 10.8.4.2, or

– De-affiliation from MC service group(s) defined in partner MC service system as described in clause 10.8.4.3.

– MC service user receiving MC service from a partner MC system as described in clause 10.1.4.3.2.

– MC service group affiliation procedure as described in clause 10.8.3.1, or

– Affiliation to MC service group(s) defined in partner MC system as described in clause 10.8.3.2 or clause 10.8.3.2a.

– Late entry MCPTT group call as described in 3GPP TS 23.379 [16] clause 10.6.2.3.1.1.4 (pre-arranged group call) and 3GPP TS 23.379 [16] clause 10.6.2.3.1.2.5 (chat group call).

– Late entry MCVideo group call as described in 3GPP TS 23.281 [12] clause 7.1.2.3.1.1.4 (pre-arranged) and 3GPP TS 23.281 [12] clause 7.1.2.3.1.2.6 (chat group call).

Pre-conditions:

1. The MC service client is a receiving party in one or more ongoing group calls in the primary MC system.

2. The MC service UE detects the need to change the MC system.

Figure 10.16.2.2-1: Migration to partner MC system during an ongoing group call

1. The MC service client requests de-affiliation from MC service groups. The MC service groups are either defined in the primary MC system (see clause 10.8.4.2) or the partner MC system (see clause 10.8.4.3).

2. After migration to the partner MC system, the configuration management client triggers retrieval of the MC service user profile used within the partner MC system (see clause 10.1.4.3.2).

NOTE 1: User authentication, service authorisation and signalling plane procedures are not shown.

3. The MC service client requests affiliation to MC service groups. The MCPTT groups are either defined in the primary MC system (see clause 10.8.3.1) or the partner MC system (see clause 10.8.3.2 or clause 10.8.3.2a).

4. If any of the received group calls are ongoing in the partner MC system, the partner MC system shall initiate a late-entry procedure towards the MC service client. If any of the received group calls are taken place in the primary MC system but not yet in the partner MC system, the affiliation by the migrated MC service UE triggers the late-entry procedure which then includes the MC service UE and the partner MC system into the group call.

The MC service client may indicate the successful migration of group communications to the MC service user.

10.16.2.3 Void

10.16.2.3.1 Void

10.16.3 Private call using functional alias towards a partner MC system

10.16.3.1 General

This provides the possibility for an MC service user to initiate a private MC service call using a functional alias, defined in the partner MC system, as target address towards an MC service user in a partner MC system.

10.16.3.2 Information flows

10.16.3.2.1 MC service functional alias resolution request

Table 10.16.3.2.1-1 describes the information flow MC service functional alias resolution request from the MC service server to the MC service functional alias controlling server and from the MC service functional alias controlling server to another MC service functional alias controlling server.

Table 10.16.3.2.1-1: MC service functional alias resolution request information elements

Information Element	Status	Description
MC service ID	M	The MC service ID of the calling party
Functional alias	O	The functional alias of the calling party
Functional alias	M	The functional alias of the called party

10.16.3.2.2 MC service functional alias resolution response

Table 10.16.3.2.2-1 describes the information flow MC service functional alias resolution response from the MC service functional alias controlling server to another MC service functional alias controlling server, the MC service functional alias controlling server to the MC service server and the MC service server to the MC service client.

Table 10.16.3.2.2-1: MC service functional alias resolution response information elements

Information Element	Status	Description
MC service ID	M	The MC service ID of the calling party
MC service ID	M	The corresponding MC service ID of the called functional alias. Return "NONE" if no one activates the targeted Functional Alias.

10.16.3.3 Procedure

Figure 10.16.3.3-1 represents a generic MC service private call setup procedure to allow using the functional alias as called party address, i.e., the MC service ID address is resolved by the partner MC system through the primary MC service server and primary MC service functional alias controlling server.

Additional new pre-condition:

1. A secured connection has been established between the MC service functional alias controlling servers in different MC systems.

Figure 10.16.3.3-1: Private call setup in automatic commencement mode, users in multiple MC systems

1-2. Same as in 3GPP TS 23.379 [16] clause 10.7.2.2.3.1, 3GPP TS 23.281 [12] clause 7.2.2.3.1 or corresponding procedures in 3GPP TS 23.282 [13], but MC service private call request contains a functional alias of invited user.

3. If the MC service private call request contains a functional alias instead of an MC service ID as called party, the MC service server checks whether MC service client 1 can use the functional alias to setup a private call. If authorized, the MC service server 1 resolves the functional alias to the corresponding MC service ID for which the functional alias is active by using subsequent steps 4-7.

4. The MC service server 1 sends an MC service functional alias resolution request message to the MC service functional alias controlling server 1 to resolve the functional alias of the called party.

5. The MC service functional alias controlling server 1 determines that the functional alias belongs to the partner MC system and forwards the MC service functional alias resolution request message to MC service functional alias controlling server 2.

6. The MC service functional alias controlling server 2 resolves the functional alias and determines the corresponding MC service ID to terminate the call and returns it to the MC service functional alias controlling server 1 in the MC service functional alias resolution response message.

NOTE: Depending on implementation the MC service server can apply additional call restrictions and decide whether the call is allowed to proceed with the resolved MC service ID(s) (e.g., whether the MC service ID is within the allowed area of the functional alias). If the MC service server detects that the functional alias used as the target of the private call request is simultaneously active for multiple MC service users, then the MC server server can proceed by selecting an appropriate MC service ID based on some selection criteria. The selection of an appropriate MC service ID is left to implementation. This selection criteria can include rejection of the call, if no suitable MC service ID is selected.

7. The MC service functional alias controlling server 1 returns the corresponding MC service ID to MC service server 1 in the MC service functional alias resolution response message. The MC service server 1 checks if MC service user at MC service client 1 is authorized to initiate the private call to the MC service user at MC service client 2. If not authorized stop the procedure, otherwise continue with step 8.

8. The MC service server 1 responds with a MC service functional alias resolution response message that contains the resolved MC service ID back to MC service client 1.

9. The MC service client 1 sends a new MC service private call request towards the resolved MC service ID according 3GPP TS 23.379 [16] clause 10.7.2.2.3.1, 3GPP TS 23.281 [12] clause 7.2.2.3.1 or corresponding procedures in 3GPP TS 23.282 [13].

10-14. Same as in 3GPP TS 23.379 [16] clause 10.7.2.2.3.1, 3GPP TS 23.281 [12] clause 7.2.2.3.1 or 3GPP TS 23.282 [13] clause 7.14.2.2.

15. The receiving MC service client 2 accepts the private call automatically, and an acknowledgement is sent to the MC service server 2.

16. The MC service server 2 forwards the MC service private call response message to MC service server 1.

17-18. Same as in 3GPP TS 23.379 [16] clause 10.7.2.2.3.1, 3GPP TS 23.281 [12] clause 7.2.2.3.1 or corresponding procedures in 3GPP TS 23.282 [13].

10.16.4 Migration during an onging private communication

10.16.4.1 General

This subclause provides a generic guidance on the behaviour an MC service client follows to perform migration during an ongoing private communication, e.g., MCPTT private call. Once the MC service client detects the need to migrate during an ongoing private communication, it may initate preparations and UE configuration which facilitate migration as mentioned in clause 10.1.1.2. The described procedure is applicable to the scenarios whether an MC service client is migrating into its primary MC system or a partner MC system.

10.16.4.2 Procedure

Figure 10.16.4.2-1 represents a generic procedure to be followed when migration is needed to be done during an ongoing private communication, such as MCPTT private call, or MCVideo private call.

Figure 10.16.4.2-1: Migration during ongoing private communication.

1. A private call takes place between MC service client 1 and MC service client 2, where the former is connected to MC system A and the latter to MC system B.

2. The MC service client 1 detects the need to migration into MC system C and MC service server 1 is notified to be prepared for possible service interruption. Furthermore, upon detection, MC service client 1 performs initial steps to be considered prior migration, e.g., UE configuration, authorization, and selection of user profile that permits migration, as described in clause 10.1.1.2

3. MC service client 1 releases the private communication towards the MC service client 2 as described in clause 10.7.2.2.3.1 of 3GPP TS 23.379 [16] for MCPTT private call, or in clause 7.2.2.3.3.1 of 3GPP TS 23.281 [12] for MCVideo private call. A call release reason IE "release due to migration" may be included so that MC service client 2 is informed.

4. Migration takes place and MC system C retrieves MC service client 1 profile:

4a. if MC system C is the primary MC system, retrieval of MC service client 1 profile takes place according to clause 10.1.4.3.1.

4b. if MC system C is a partner MC system, retrieval of MC service client 1 profile takes place according to clause 10.1.4.3.2.

5. Registration procedure takes place:

5a. If system C is the primary MC system, the procedure takes place according to clause 10.6.1.

5b. If system C is a partner MC system, the procedure takes place according to clause 10.1.6.2.

6. MC service client 1 initiates a new private communication toward MC service client 2 as described in clause 10.7.2.2.1 of 3GPP TS 23.379 [16] for MCPTT private call, or in clause 7.2.2.3.1 of 3GPP TS 23.281 [12] for MCVideo private call.

10.16.5 Generic private call procedure towards a migrated MC service user

10.16.5.1 General

This subclause describes a generic private communication procedure towards a migrated MC service user at a partner MC system. This generic private communication can be an MCPTT private call, an MCVideo private call, or a one-to-one MCData communication. For the generic private call, this procedure is used in conjunction with the corresponding MCPTT, MCVideo and MCData procedures described in 3GPP TS 23.379 [16], 3GPP TS 23.281 [12], or 3GPP TS 23.282 [13], respectively.

Once an MC service user is migrated, he or she will be assigned a new MC service ID by the migrated MC system and this MC service ID will be used for all his/her communications. When another MC service user communicates with the migrated MC service user using the newly assigned MC service ID, the private call request described in clause 10.7.2.1.1 in 3GPP TS 23.379 [16], in clause 7.2.2.2.1 in 3GPP TS.23.281 [12], or the corresponding procedures in 3GPP TS 23.282 [13] applies.

For callers that are not aware of the migrated MC service user $s new MC service ID, the migrated MC service user is also reachable by his/her MC service ID assigned by the primary MC system via redirection done by the primary MC system$ s MC service server described in this procedure.

10.16.5.2 Private call redirection

Table 10.16.5.2-1 describes the information flow of a private call redirection, which is sent from the MC service server to an MC service client initiating a private call towards a migrated MC service user.

Table 10.16.5.2-1: Private call redirection

Information element	Status	Description
MC service ID	M	The MC service ID of the MC service user initiating a private call, i.e., calling party. The MC service ID can either be MCPTT ID, MCVideo ID, or MCData ID.
MC service ID	M	The MC service ID of the target MC service user (i.e., called party), which the MC service user has obtained from its primary MC system before migration. The MC service ID can either be MCPTT ID, MCVideo ID, or MCData ID.
MC service ID	M	The MC service ID of the target MC service user, which the MC service user has obtained from its migrated MC system after Migration. The MC service ID can either be MCPTT ID, MCVideo ID, or MCData ID.
Redirection reason	O	The MC service server informs the calling party that the target MC service user has migrated.

10.16.5.3 Procedure

Figure 10.16.5.4-1 presents a generic private communication procedure from MC service user 1 towards a migrated MC service user 2 where the MC system A is the primary MC system of MC service user 2 before migration, and the MC system B is the MC system that the MC service user 2 has migrated

Pre-conditions:

– MC system A and MC system B are interconnected.

– MC system A is the primary MC system of MC service user 2 before migration. MC system B is the MC system that MC service user 2 has migrated.

– The MC service server A is aware that MC service user 2 has migrated and is informed of its MC service ID provided by MC system B, as described in clause 10.6.3.3.

Editor’s note: It is FFS whether the KMS URI of the migrated MC service user is preconfigured in the calling MC service user`s user profile.

Figure 10.16.5.3-1: MC private call towards a migrated MC service user.

1. The MC service client 1 initiates a private call request towards MC service user 2 (MC service client 2) who has migrated to MC system B. The private call request includes among others the MC service ID of MC service user 2, which is provided by its primary MC system, as the target, i.e., called party. The private call request is described in clause 10.7.2.1.1 in 3GPP TS 23.379 [16], in clause 7.2.2.2.1 in 3GPP TS 23.281 [12], or the corresponding procedures in 3GPP TS 23.282 [13].

2. MC service server A checks that MC service user2 has migrated to MC system B with a new MC service ID assigned by MC system B.

3. The MC service server A sends a private call redirection towards the MC service client 1, to inform MC service user 1 that MC service user 2 has migrated and its new MC service ID of MC service user 2 assigned by the migrated MC system. The MC service client 1 releases the private call request at step 1.

4. The MC service client 1 initiates a private call towards MC service user 2, including the MC service ID of MC service user 2 obtained from MC system The initiated private call can either be an MCPTT private call, an MCVideo private call, or a corresponding one-to-one MCData communication, and shall perform the procedures as described in 3GPP TS 23.379 [16], 3GPP TS 23.281 [12], or 3GPP TS 23.282 [13], respectively.

NOTE: If end-to-end encryption is required, the migrated MC service user 2 is assumed to have the necessary security information needed to establish a protected call, as defined in 3GPP TS 33.180 [25].