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.16  Generic procedures for migration |R18|p. 304

10.16.1  Generalp. 304

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 TS 23.379, TS 23.281 and TS 23.282. These procedures should be read in conjunction with specific procedures in those specifications.
Up

10.16.2  Migration during an ongoing group communicationp. 304

10.16.2.1  Generalp. 304

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.

10.16.2.2  Procedurep. 304

The procedure is based on the following existing procedures:
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.
Reproduction of 3GPP TS 23.280, Fig. 10.16.2.2-1: Migration to partner MC system during an ongoing group call
Up
Step 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).
Step 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).
Step 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).
Step 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.
Up

10.16.2.3Void

10.16.3  Private call using functional alias towards a partner MC systemp. 305

10.16.3.1  Generalp. 305

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 flowsp. 305

10.16.3.2.1  MC service functional alias resolution requestp. 305
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.
Information element Status Description
MC service IDMThe MC service ID of the calling party
Functional aliasOThe functional alias of the calling party
Functional aliasMThe functional alias of the called party
Up
10.16.3.2.2  MC service functional alias resolution responsep. 306
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.
Information element Status Description
MC service IDMThe MC service ID of the calling party
MC service IDM The corresponding MC service ID of the called functional alias. Return "NONE" if no one activates the targeted Functional Alias.
Up

10.16.3.3  Procedurep. 306

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.
Reproduction of 3GPP TS 23.280, Fig. 10.16.3.3-1: Private call setup in automatic commencement mode, users in multiple MC systems
Up
Step 1-2.
Same as in clause 10.7.2.2.3.1 of TS 23.379, clause 7.2.2.3.1 of TS 23.281 or corresponding procedures in TS 23.282, but MC service private call request contains a functional alias of invited user.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 9.
The MC service client 1 sends a new MC service private call request towards the resolved MC service ID according to clause 10.7.2.2.3.1 of TS 23.379, clause 7.2.2.3.1 of TS 23.281 or corresponding procedures in TS 23.282.
Step 10-14.
Step 15.
The receiving MC service client 2 accepts the private call automatically, and an acknowledgement is sent to the MC service server 2.
Step 16.
The MC service server 2 forwards the MC service private call response message to MC service server 1.
Step 17-18.
Up

10.16.4  Migration during an onging private communicationp. 308

10.16.4.1  Generalp. 308

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 initiate 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.
Up

10.16.4.2  Procedurep. 308

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.
Reproduction of 3GPP TS 23.280, Fig. 10.16.4.2-1: Migration during ongoing private communication
Up
Step 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.
Step 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
Step 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 TS 23.379 for MCPTT private call, or in clause 7.2.2.3.3.1 of TS 23.281 for MCVideo private call. A call release reason IE "release due to migration" may be included so that MC service client 2 is informed.
Step 4.
Migration takes place and MC system C retrieves MC service client 1 profile:
Step 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.
Step 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.
Step 5.
Registration according to procedure in clause 10.6.1 takes place.
Step 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 TS 23.379 for MCPTT private call, or in clause 7.2.2.3.1 of TS 23.281 for MCVideo private call.
Up

10.16.5  Generic private call procedure towards a migrated MC service userp. 310

10.16.5.1  Generalp. 310

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 TS 23.379, TS 23.281, or TS 23.282, 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 of TS 23.379, in clause 7.2.2.2.1 of TS 23.281, or the corresponding procedures in TS 23.282 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.
Up

10.16.5.2  Private call redirectionp. 310

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.
Information element Status Description
MC service IDMThe 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 IDMThe 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 IDMThe 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.
KMS URI (NOTE)OThe KMS URI associated with the MC service ID of the migrated MC service user.
Redirection reasonOThe MC service server informs the calling party that the target MC service user has migrated.
NOTE:
If the KMS URI is not configured in the MC service user profile and is not included in the private call redirection message, then the MC service client shall obtain KMS URI using the KMS lookup procedure defined in TS 33.180.
Up

10.16.5.3  Procedurep. 310

Figure 10.16.5.3-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.
Reproduction of 3GPP TS 23.280, Fig. 10.16.5.3-1: MC private call towards a migrated MC service user
Up
Step 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 TS 23.379, in clause 7.2.2.2.1 in TS 23.281, or the corresponding procedures in TS 23.282.
If the private call request contains a functional alias instead of an MC service ID as the target party, the MC service server A checks whether the MC service user 1 at the MC service client 1 is allowed to use functional alias during private call setup.
Step 2.
MC service server A checks that MC service user 2 has migrated to MC system B with a new MC service ID assigned by MC system B.
If the private call request contains a functional alias, and if the MC service user 1 at the MC service client 1 is authorized, the MC service server A resolves the functional alias to a corresponding MC service ID of the MC service user which has activated the functional alias. If the MC service server A determines that the corresponding MC service user of the resolved MC service ID is migrated, i.e., MC service user 2 at MC service client 2 is migrated, it checks whether the resolved MC service ID of the MC service user 2 is allowed to receive a private call from the MC service ID of the MC service user 1 using functional alias based on entries in the user profile of the MC service user 2 assigned by the primary system.
Step 3.
The MC service server A sends a private call redirection towards the MC service client 1, to inform MC service user 1 that the target MC service user, i.e., 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.
Step 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 TS 23.379, TS 23.281, or TS 23.282, respectively.
Up

Up   Top   ToC