Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.174  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   4.5…   4.6…   4.6.8…   4.7…   A…

 

4  Multi-device and multi-identityp. 9

4.1  Introductionp. 9

The Multi-Device (MuD) service is an operator specific service which enables a user to use different UEs that are registered under the same public user identity. The UEs can be of different types (e.g. phone, tablet, wearable device, PC) and can support a communication log.
The Multi-Identity (MiD) service is an operator specific service which enables a user to use different identities. A served user can use a single UE to receive calls addressed to any of its identities and to make calls using any of its identities.
The MuD and MiD services can be used at the same time.
The UE can indicate to the network which identities are active at the UE. If the identity is not active at the UE, the user cannot use given identity in a communication at the UE.
Up

4.2  Descriptionp. 9

4.2.1  MuD service descriptionp. 9

The MuD service enables a served user to use, in a communication, any of the UEs that are configured to use the same public user identity, i.e. any of the federated UEs.
The MuD service enables a synchronization of communication logs between the federated UEs which support communication log. The communication log provides lists of incoming and outgoing, missed, accepted and rejected calls. If the served user accepts or rejects call from one of the federated UEs or when a missed call notification has been read on one of the federated UEs, the communication logs of the other federated UEs are updated so the served user will see the same information on different federated UEs.
An outgoing call can be made from any of the federated UEs. A federated UE can indicate to the network which public user identities are (de)activated at the federated UE.
An incoming call towards the served user is sent to all federated UEs where that public user identity is active at the federated UE. The call can be accepted on any of the federated UEs which are alerting the served user of an incoming call. The federated UEs can synchronize the call logs by using the call log functionality in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS [10].
A federated UE can if authorized by the AS push a call to any other of the federated UEs. A federated UE can if authorized pull a call from any of the other federated UEs.
The number of UEs using the same public user identity is implementation specific.
If the user of the MuD service also subscribes to the MiD service then the user can use non-native identities in addition to native identities on federated UEs. A federated UE can indicate to the network which of these non-native identities are (de)activated at the federated UE.
Up

4.2.2  MiD service descriptionp. 10

The MiD service enables a served user to use any of its identities i.e. native and non-native identities for communication using a single UE. A native identity is always registered by the UE. An alternative identity and a virtual identity can be either registered by the UE, or the UE can be authorized to use these identities based on configuration in the user's service data. An external alternative identity cannot be registered by the UE, but the UE can be authorized to use this identity based on configuration in the user's service data.
When making a call the served user selects one of its identities that will be used by the UE as an originating identity (calling party number) in an outgoing call. Upon reception of an incoming call the UE provides to the served user an indication on which of its identities the served user is contacted (called party number).
The UE can indicate to the network which identities are active at the UE. A native identity is always active at the UE.
Several users of the MiD service can share the same non-native identity for communication.
The number of non-native identities used by a user using a single UE is implementation specific.
If the user of the MiD service also subscribes to the MuD service then the user can use non-native identities on federated UEs. In such case, the UE can indicate to the network which of these non-native identities are active at each federated UE separately.
Up

4.3  Operational requirementsp. 10

4.3.1  Provision/withdrawalp. 10

The MiD service and the MuD service are provided after prior arrangement with the service provider.
The MiD service and the MuD service are withdrawn at the served user's request or for administrative purposes.

4.3.2  Requirements on the originating network sidep. 10

For the MiD service, the originating network shall support the Additional-Identity header field.
For the MuD service the originating network shall support using a token to identify the registration as specified in TS 24.229.

4.3.3  Requirements in the networkp. 10

For the MiD service, a network serving an external alternative identity shall support adding the Additional-Identity header field.
For the MuD service no specific requirements are needed in the network.

4.3.4  Requirements on the terminating network sidep. 10

For the MiD service, the terminating network shall support the Additional-Identity header field.
For the MuD service the terminating network shall support using a token to identify the registration as specified in TS 24.229.

4.4  Coding requirementsp. 11

No specific coding requirements are defined in the present document.

Up   Top   ToC