Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑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…

 

5.2.8  External applications access to services in a MC systemp. 28

The MC system shall allow external applications to gain secure access to MC services by supporting authentication and authorization of external applications.

5.2.9  Migration |R15|p. 29

5.2.9.1  Generalp. 29

Migration provides means for the MC service user to obtain MC services from a partner MC system. As the MC service client receives one or multiple user profiles for the MC service user from its primary MC system (as described in clause 10.1.4.3). Each user profile contains a list of partner MC systems that the user is permitted to migrate to, along with necessary access information to facilitate service authentication, hence, facilitate migration to the partner MC system.
MC service interconnection needs to be provided between MC systems that wish to provide migration of their MC service users.
Migration of MC service users between any two MC systems can be on a bilateral or unilateral basis.
Migration may be triggered by the primary MC system or may be requested by the MC service client due to its geographical changes.
Upon a successful service authorization for migration, i.e., once the MC service user is authorized to migrate to a partner MC system, its primary MC system marks the user as migrated, is informed of the target partner MC system, and records the corresponding MC service ID of the migrated user provided by the partner MC system. Further details are described in clause 10.6.3.
The functional alias of a migrated MC service user at a partner MC system, which is defined in the partner MC system, can be utilized as a target address in private communication as described in clause 10.16.3.
During migration of an MC service user to a partner MC system, media of the MC service user's calls may need to be routed to the MC service user's primary MC system e.g. for logging purposes.
Up

5.2.9.2  PLMN utilisationp. 29

Migrated MC service users should utilize the PLMN used by the partner MC system to access MC services in the partner MC system, however, utilizing the PLMN used by the primary MC system is not precluded.
MC service users enabled for migration shall be provisioned with configuration that specifies which PLMNs may be used to migrate to other MC systems.
If the PLMN used by a partner MC system is different from the PLMN used by the primary MC system (i.e. migrating MC service user starts using the PLMN used by the partner MC system), then:
  • EPC-level roaming (see subclause 5.2.2) is needed between the PLMN used by the primary MC system and PLMN used by the partner MC system; and
  • the PLMN used by the partner MC system needs to enable local break-out for the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system; and
  • the EPS subscriptions of the PLMN used by the primary MC system utilized by the MC service users who are allowed to migrate to the partner MC system need to be provisioned with, and local break-out enabled for, the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system.
If the PLMN used by the partner MC system and the PLMN used by the primary MC system are the same (i.e. migrating MC service user continues to use the PLMN used by the primary MC system), then:
  • the EPS subscriptions of the PLMN used by the primary MC system utilized by the MC service users who are allowed to migrate to the partner MC system need to be provisioned with the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system.
Up

5.2.9.3  SIP core / IMS utilisationp. 30

Migrated MC service users should utilise the SIP core / IMS of the partner MC system.
Where connectivity and security policies allow, the same SIP core / IMS can be utilised to connect to the primary MC system and one or more partner MC systems.
For each partner MC system, MC service UEs of MC service users enabled for migration shall be provisioned with:
  • configuration that controls whether the MC service UE shall connect to the SIP core / IMS of the primary MC system or a different SIP core / IMS (i.e. SIP core / IMS of the partner MC system); and
  • where a different SIP core / IMS to the primary MC system's SIP core / IMS is to be connected to then the MC service UE shall also be configured with:
  • configuration required for the MC service UE to access the SIP core / IMS; and
  • credentials required for the MC service UE to register with the SIP core / IMS.
Up

5.2.10  Interconnection |R15|p. 30

5.2.10.1  Generalp. 30

MC service interconnection allows a first set of MC service users who are receiving MC service from a first MC system to take part in communications with a second set of MC service users, where this second set of MC service users are receiving MC service from a second MC system, and where the second MC system is in a different trust domain to the first MC system.

5.2.10.2  Connectivityp. 30

The MC service clients of the MC service users receiving MC service(s) from a first MC system and using MC service interconnection to take part in communication with MC service users in a second MC system require connectivity to only the identity management server in the second MC system.
IP connectivity is required between MC systems wishing to interconnect. The IP connectivity is used to carry the signalling and application plane protocols needed to provide MC service.
Up

5.2.10.3  Migrationp. 31

Interconnection may be used by a migrated MC service user who is receiving service from a partner MC system to take part in communication with MC service users in the primary MC system of that migrated MC service user.

5.2.10.4  Private callsp. 31

Where private calls take place using interconnection between MC service users who are receiving MC service in different MC systems, the MC system providing MC service to the calling MC service user will provide the controlling function for the private call.

5.2.10.5  Group callsp. 31

Where MC service users in a partner MC system of the group home MC system of an MC service group take part in group calls in that group, the group home MC system of the MC service group will provide the controlling function for the group call.

5.2.10.6  Group configurationp. 31

A partner MC system may apply local configuration to an MC service group configuration received from the primary MC system (i.e. the group home MC system).

5.2.10.7  MC system topology hidingp. 31

If an MC system requires internal network topology hiding, then this shall be achieved in the MC system by use of the following:
  • proxies for signalling plane functions; and
  • gateway MC service servers for application plane functions.

5.2.11  Use of priorities |R17|p. 31

5.2.11.1  Requested priorityp. 31

The MC system may allow the MC service client to request the priority of a communication by selecting the corresponding priority level. The MC service server can enforce the selected priority level in determining the application priority for resource allocation during communication establishment.
The use of the requested priority may vary depending on MC service provider's policy.

Up   Top   ToC