Content for TS 24.174 Word version: 17.6.0

4.1 Introduction 4.2 Description 4.3 Operational requirements 4.4 Coding requirements 4.5 Signalling requirements 4.6 Service interactions 4.7 Parameter values and timers 4.8 Service configuration for multi-device and multi-identity

4 Multi-device and multi-identity p. 9

4.1 Introduction p. 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.

4.2 Description p. 9

4.2.1 MuD service description p. 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.

4.2.2 MiD service description p. 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.

4.3 Operational requirements p. 10

4.3.1 Provision/withdrawal p. 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 side p. 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 network p. 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 side p. 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 requirements p. 11

No specific coding requirements are defined in the present document.

4.5 Signalling requirements p. 11

4.5.1 General p. 11

Configuration of the MiD services by the user should take place over the Ut interface using XCAP as enabling protocol as described in TS 24.623.

The enhancements to the XML schema for use over the Ut interface is described in clause 4.8.

4.5.2 Activation/deactivation of MuD/MiD services p. 11

4.5.2.1 General |R17| p. 11

The services and individual identities can be activated or deactivated following procedures in the following clauses.

4.5.2.2 Activation of MuD and MiD services |R17| p. 11

The MuD and MiD services are activated at provisioning and deactivated at withdrawal or at the user's request.

If the MuD, MiD or both services are activated, the user controls whether identities can be used for incoming and outgoing calls by activation/deactivation of identities.

4.5.2.3 Activation/deactivation of identities |R17| p. 11

Via activation/deactivation of identities in case of MiD service, the user controls if the identity is active on its device. Via activation/deactivation of identities in case of MuD service, the user controls if the identity is active on each device in federation separately. If the user of MuD service is also using MiD service, the user controls if each identity is active on each device separately. There is a separate <ue-instance> element for each of the device, distinguishable by the "identity" attribute. The "identity" attribute takes the form of a pvalue as derfined in RFC 3261 and can be set by the operator to a value linked with the IMS private user identity. The "alias" attribute is modifiable by the user and is filled with a user-friendly identifier making the UE instance easier distinguishable among all the devices in federation.

The user of MuD, MiD or both services decides which of the identities that it is allowed to use and can be registered are active and can be used for incoming and outgoing calls by changing the "Activated" attribute in the <Registered-identity> elements in the service configuration data.

The user of MiD service decides which of the identities that have been allowed to be used for the user but cannot be registered are active and can be used for incoming and outgoing calls by changing the "Activated" attribute in the <Shared-identity> elements in the service configuration data.

The user decides if it permits another user to use its native identity. The user decides which users among those who have been allowed to use its identity, can use this identity for incoming and outgoing calls by changing the "Activated" attribute in the <Delegated-user> elements in the service configuration data.

4.5.3 Invocation and operation p. 12

4.5.3.1 Actions at the UE of user A p. 12

4.5.3.1.1 General |R17| p. 12

If user A wishes to use a native identity, the UE shall include in the outgoing INVITE or MESSAGE request the From header field and may include the P-Preferred-Identity header field(s) as specified in TS 24.229. The From header field and the P-Preferred-Identity header field (if included) shall contain the native identity.

If user A wishes to use an alternative identity or a virtual identity that the UE has registered, the UE shall include in the outgoing INVITE or MESSAGE request the From header field and the P-Preferred-Identity header field. The P-Preferred-Identity header field and the From header field shall contain the alternative identity or the virtual identity.

If user A wishes to use the identity C, the UE shall include in any outgoing INVITE or MESSAGE requests, an Additional-Identity header field, defined in TS 24.229, set to the selected identity and shall include the native identity in the From header field. The UE can learn the identity C by device configuration as specified in TS 24.175 or by using the service configuration in clause 4.8.

The UE may support being configured with the identities to be used in the "MultiIdentity" leaf node of TS 24.175.

When establishing an emergency session and performing the emergency related procedures defined in TS 24.229, the UE shall only use the native identity.

A UE supporting the MuD service may synchronize the local call log with the network stored call log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS [10]. If the served user in the "From" header field is an identity not registered by the UE, the UE shall deduce that the call was originated using the Additional-Identity header field.

4.5.3.1.2 Call pull handling |R17| p. 12

The UE may pull a session from another federated UE by performing the following steps:

the UE learns about the session to pull by subscribing to the dialog event package, specified in RFC 4235;
the UE sends an INVITE request towards the far end populated as follows:
1. the Request-URI is set to the uri in the <target> element of the <remote> element;
2. a Replaces header field containing the dialog identifiers contained as attributes in the <dialog> element of the <dialog-info> element; and
3. any other header field or body as determined by the service logic; and
when the UE receives a response to the INVITE request above the UE follows general procedures in TS 24.229.

4.5.3.1.3 Call push handling |R17| p. 12

The UE may push a session to another federated UE by performing the following steps:

the UE learns the status and identities of the other federated UEs using the dialog event package, specified in RFC 4235 and extended as specified in clause 7.X.2 in TS 24.229; and
the UE sends a REFER request towards the target UE populated as follows:

NOTE 1:
In this Release of the present document only one UE is targeted in the transfer.
1. the Request-URI is set to the own public user identity and includes a "gr" SIP URI parameter set to the value of the "identity" attribute for the target UE received in the <ue-instance> element in the <dialog-info> element in the dialog event notification; and
  
  NOTE 2:
  The value in the "identity" attribute has the same format as a GRUU, but is not a GRUU assigned by the S-CSCF. It only has local significance.
2. a Refer-to header field set to the SIP URI of the remote end and including in the headers portion of the SIP URI the headers and bodies determined by the service logic.

4.5.3.2 Actions at the AS serving user A p. 13

4.5.3.2.1 General p. 13

Upon receiving an incoming initial INVITE, REFER or MESSAGE request containing an Additional-Identity header field, the AS shall determine the served user as specified in TS 24.229, clause 5.7.1.3A.2herwise, if the received Additional-Identity header field does not contain any of the served user's registered identities the AS shall:TS 24.229. Otherwise, if the received Additional-Identity header field does not contain any of the served user's registered identities the AS shall:

verify that the user is authorized to use the identity received in the Additional-Identity header field as specified in clause 4.5.3.2.2; and
if the user is not authorized to use the identity included in the Additional-Identity header field, then the AS shall reject the incoming request. The originating request may be rejected by operator policy with a 403 (Forbidden) response including a warning header field 399 "Identity not allowed".

If the user is authorized to use the identity in the Additional-Identity header field then the AS shall generate a new SIP request based on the received SIP request in accordance with the procedures in TS 24.229, clause 5.7.3 with the following clarifications:

remove any P-Served-User header field and insert a P-Served-User header field with the identity taken from the Additional-Identity header field in the received request;
remove any existing Route header field and insert a Route header field pointing to an I-CSCF or to the S-CSCF hosting the identity in the Additional-Identity header field in the received request;
in the Route header field above, append the "orig" parameter to the URI; and
insert the Additional-Identity header field with the same value as in the received SIP request.

The AS shall send the generated SIP request and may refrain from the invocation of other MMTel services serving the native identity.

If the AS updates the Call Log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] the AS shall populate the "From" attribute of the call log object with the value in the Additional-Identity header field, provided the user is authorized to use this identity.

4.5.3.2.2 Authorization of the Additional-Identity header field p. 13

The AS serving user A shall authorize the usage of the identity contained in the Additional-Identity header field as the originating identity by checking:

if the identity contained in the Additional-Identity header field is included in the user's service data associated to the native identity of the originating user; and
if the "Activated" attribute of the <Shared-identity> element of the <multi-identity> element in the service configuration data is set to "true".

Otherwise, user A is not authorized to use the identity contained in the Additional-Identity header field as the originating identity.

4.5.3.2.3 Call pull handling |R17| p. 14

An AS supporting call pull handling, when receiving an INVITE request as specified in clause 4.5.3.1.2 shall verify that the calling user is allowed to pull a call. If the call pull is allowed, the AS forwards the received INVITE request in accordance with TS 24.229, otherwise the AS rejects the request with an appropriate response code.

4.5.3.2.4 Call push handling |R17| p. 14

An AS supporting call push handling, when receiving a REFER request as specified in clause 4.5.3.1.3 shall

verify that the user is allowed to push a call; and
if the call push is allowed, based on local policy, either
1. forward the REFER request towards the REFER target; or
2. start 3pcc procedures as specified in TS 24.628 to:
  1. transfer the originating leg from the originator of the REFER reqeust to the REFER target; and
  2. if necessary, update the terminating leg.

The AS shall use the "gr" SIP URI parameter in the Request-URI to identify the REFER target UE. If the AS knows that the content of the "gr" SIP URI parameter is not a GRUU assigned by the S-CSCF the AS shall remove the "gr" SIP URI parameter from the Request-URI before forwarding the request.

4.5.3.3 Actions at the AS serving identity C p. 14

Upon receiving an incoming INVITE or MESSAGE request containing an Additional-Identity header field, the AS shall:

determine the served user as defined in TS 24.229;
if the user identified in the P-Asserted-Identity is not allowed to use the identity in the Additional-Identity header field, reject the request using a 403 (Forbidden) response including a warning header field 399 "Identity not allowed" and skip the rest of the steps;
replace the identity in the From header field with the identity in the Additional-Identity header field;
depending on local configuration, related to the operator policy and regulatory requirements, allowing to determine whether an originating external alternative identity or an originating virtual identity is to be used as an originating identity (calling party number):
1. if the P-Asserted-Identity header can be modified, replace the identity in the P-Asserted-Identity header field with the identity in the Additional-Identity header field; or
2. if the P-Asserted-Identity header cannot be modified, set the Privacy header field "id" to keep the native identity private in the P-Asserted-Identity header field as defined in RFC 3325;
if the identity of the originating user can be verified, based on local policy initiate addition of an Identity header field attesting the identity C;
remove the Additional-Identity header field received in the request; and
perform any other originating services as performed by the service logic,

before forwarding the request downstream.

4.5.3.4 Actions at the AS serving identity D p. 14

For a terminating user, upon receiving an incoming INVITE or MESSAGE request, the AS shall perform any terminating services as performed by the service logic before forwarding the request downstream.

If the AS service determines based on configuration that the AS shall forward the request to any of the identities that can use the identity received in the Request-URI, the AS shall for each forwarded request modify the request as follows:

the Request-URI is set to the identity configured in the AS; and
an Additional-Identity header field, defined in TS 24.229, is added and set to the identity received in the Request-URI.

If the AS supports calling number verification using signature verification and attestation information as specified in TS 24.229, the AS treats the forwarding to the identities above as diversions, i.e. uses the "div" PASSporT as specified in RFC 8946.

If the AS identifies the INVITE request as a PSAP callback, the MiD service shall not be triggered.

4.5.3.5 Actions at the AS serving user B p. 15

Upon receiving an INVITE or MESSAGE request not containing an Additional-Identity header field and if the terminating user is subscribed to the MuD service, the AS shall when sending the request to the UEs verify whether the identity in the Request-URI is activated by the MiD service and on the target UE. The AS shall only send the request to a target UE if the identity is active both in the MiD service and on the target UE. If the user does not subscribe to the MiD service, but the user has the received identity configured in the implicit registration set, the AS considers the identity to be activated by the MiD service.

Upon receiving an INVITE or MESSAGE request containing an Additional-Identity header field and if the terminating user is subscribed to the MuD and the MiD service, the AS shall when sending the request to the UEs verify whether the identity in the Additional-Identity header field is activated by the MiD service and on the target UE. The AS shall only send the request to a target UE if the identity is active both in the MiD service and on the target UE. The AS may refrain from the invocation of other MMTel services configured for the user of the native identity.

If the AS updates the Call Log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] the AS shall populate the "To" attribute of the call log object with the value in the Additional-Identity header field, provided the user is authorized to use this identity.

An AS supporting call pull and call push handling, uses the procedures specified in clauses 4.5.3.2.3 and 4.5.3.2.4.

4.5.3.6 Actions at the UE of user B p. 15

A UE supporting the MiD service shall support the receipt of the Additional-Identity header field, defined in TS 24.229, in SIP requests initiating a dialog or standalone transaction.

A UE supporting the MuD service may synchronize the local call log with the network stored call log as specified in OMA-TS-CPM_Message_Storage_Using_RESTFul_API [9] and OMA-TS-REST_NetAPI_NMS [10]. If the served user in the "To" header field is an identity not registered by the UE, the UE shall deduce that the call was originated using the Additional-Identity header field.

A UE supporting call pull and call push handling uses the procedures specified in clauses 4.5.3.1.2 and 4.5.3.1.3.

4.6 Service interactions p. 15

4.6.1 Originating Identification Presentation (OIP) p. 15

No impact. Neither service shall affect the operation of the other service.

4.6.2 Originating Identification Restriction (OIR) p. 15

No impact.

4.6.3 Terminating Identification Presentation / Terminating Identification Restriction (TIP/TIR) p. 16

4.6.3.1 MuD p. 16

No impact.

4.6.3.2 MiD p. 16

For TIP, the AS serving identity D shall in SIP responses remove the P-Asserted-Identity header field received from UE-B and insert a P-Asserted-Identity identifying the served user.

For TIR, the AS serving identity D shall pass any Privacy header field unchanged towards the originating user.

4.6.4 Advice of Charge p. 16

No impact. Neither service shall affect the operation of the other service.

4.6.5 Communication Waiting (CW) p. 16

For MuD, if there are ongoing communications, it is a service option whether to send an incoming initial INVITE to all federated UEs or only those UEs with ongoing communications.

For MiD, no impact.

4.6.6 Communication Hold p. 16

No impact. Neither service shall affect the operation of the other service.

4.6.7 Explicit Communication Transfer (ECT) p. 16

4.6.7.1 Interactions for MuD service p. 16

No impact; i.e. neither service shall affect the operation of the other service.

4.6.7.2 Interactions for MiD service p. 16

4.6.7.2.1. Actions at the UE acting as transferor

When the UE initiates a communication transfer, the UE shall use the same identity in the Referred-By header field as was indicated for the established session. If the UE uses identity C or identity D for the established session, the UE shall add the Addditional-Identity header field containing this identity.

4.6.7.2.1 Actions at the UE acting as transferor p. 16

4.6.7.2.2 Actions at the AS serving the transferor p. 16

4.6.7.2.2.1 Identifying a request for communication transfer p. 16

See TS 24.629 on the criteria to determine that a REFER request is to be treated as a request for transfer of an existing communication.

4.6.7.2.2.2 Handling of transfer requests p. 16

When a REFER request identified as a request for transfer is received from the served user and the Additional-Identity header field is included in the REFER request the AS shall authorize the use of the Additional-Identity header field as specified in clause 4.5.3.2.2. If the user is authorized to use the Additional-Identity header field the AS shall forward the REFER request as follows:

if the REFER request was received inside the dialog, the AS forwards the request in the existing dialog towards the transferee; or
if the REFER request was received outside the existing dialog, as specified in TS 24.629, the AS forwards the REFER request towards the transferee with the same considerations as specified for an initial INVITE request in clause 4.5.3.2.1.

4.6.7.2.2.3 Actions at the AS serving the identity C or identity D p. 17

When a REFER request identified as a request for transfer that contains an Additional-Identity header field containing a URI of the served user is received the AS shall in addition to the procedures in clause 4.5.3.3 verify that the Referred-By header field is consistent with the Additional-Identity header field, and if necessary replace the Referred-By header field value with the identity in the received Additional-Identity header field. The AS then forwards the REFER request following normal procedures.

4.6.8 Conference calling (CONF) p. 17

4.6.8.1 Interactions for MuD service p. 17

No impact, i.e. neither service shall affect the operation of the other service.

4.6.8.2 Interactions for MiD service p. 17

4.6.8.2.1 UE procedures for MiD service p. 17

To be able to later use the CONF service, when the UE sends an INVITE request to a second user, the UE shall use the same identity as the UE used when setting up the first communication.

When creating the conference with an INVITE request the UE shall use the same identity as the UE used in the communications now on HOLD. If the UE uses identity C or identity D for the established sessions, the UE shall add the Addditional-Identity header field containing this identity. The UE sets the Request-URI to the same conference factory URI as the UE uses for the native identities.

When the UE adds a conference participant using the procedures in clause 5.3.1.5.3 in TS 24.147, the UE shall set the Referred-By header field in the REFER request to the same identity as the one used when creating the original session(s). If this identity is a non-registered identity (identity C or identity D) the UE adds the Additional-Identity header field containing this identity.

4.6.8.2.2 Actions at the AS serving the conference call initiator p. 17

If the AS receives an INVITE request with a Request-URI to a conference factory used in the serving network and an Additional-Identity header field, the AS in addition to the procedures in clause 4.5.3.2.1 replaces the Request-URI with a default conference factory URI for MMTel (as specified in TS 23.003) valid in the home network of the identity in the Additional-Identity header field.

4.6.8.2.3 Actions at the AS serving the identity C or identity D p. 17

If the AS receives an INVITE request, addressed to a default conference conference factory URI for MMTel as specified in TS 23.003, including an Additional-Identity header field the AS may in additon to the procedures in clause 4.5.3.3 modify the Request-URI to include any conference factory URI of the serving network.

If the AS receives a REFER request containing an Additional-Identity header field, the AS shall in additon to the procedures in clause 4.5.3.3 verify that the identity in the Referred-By header field is consistent with the Additional-Identity header field, and if necessary replace the Referred-By header field value with the identity in the received Additional-Identity header field. The AS then forwards the REFER request following normal procedures.

4.6.9 Closed User Group (CUG) p. 17

For MuD no impact, i.e. neither service shall affect the operation of the other service.

For MiD, CUG imposes restrictions on both incoming and outgoing calls. The MiD shall not use any identity C or identity D that are restricted by the CUG service.

4.6.10 Completion of Communications to Busy Subscriber (CCBS) p. 18

No impact, i.e. neither service shall affect the operation of the other service.

4.6.11 Communication Diversion (CDIV) p. 18

At the AS serving the user holding the terminating external alternative or virtual identity, the CFU (communication forwarding unconditional) take precedence over execution of MiD and MuD services.

At the terminating side, it is implementation specific to select CDIV service when different CDIV services apply to different federated UEs.

4.6.12 Malicious Communication Identification (MCID) p. 18

4.6.13 Anonymous Communication Rejection (ACR) and Communication Barring (CB) p. 18

The Incoming Communications Barring (ICB), Outgoing Communications Barring (OCB) and Anonymous Call Rejection (ACR) of the non-native identity take precedence over MuD and MiD services.

4.6.14 Message Waiting Indication (MWI) p. 18

In case of the MuD service, there is no impact on the operation of the other service.

The MWI is not supported for the identities, which are shared.

4.6.15 Flexible Alerting (FA) p. 18

MuD service can be combined with FA with no impacts.

Terminating MiD service is competing with FA.

4.6.16 Enhanced Calling Name (eCNAM) p. 18

In case of the MuD service, if the terminating user with MuD service has eCNAM activated, incoming calls to an identity shall apply eCNAM to all federated UEs.

4.6.17 Multi-Device (MuD) p. 18

When a user has the MiD service, any external alternative or virtual identity that is authorized to be used and activated by the MiD service can be activated on any of the Federated UEs as part of the user's MuD service.

4.6.18 Multi-Identity (MiD) p. 18

No impact. The activation of an identity by the MiD service is a condition for that identity to be active on a federated UE by the MuD service.

4.6.19 Customized Alerting Tones (CAT) p. 19

No impact.

4.6.20 Customized Ringing Signal (CRS) p. 19

No impact.

4.7 Parameter values and timers p. 19

No parameters and timers are defined in the present document.

4.8 Service configuration for multi-device and multi-identity p. 19

4.8.1 General p. 19

The multi-device and multi-identity documents are subtrees of the simservs document specified in TS 24.623. As such, multi-device and multi-identity documents use the XCAP application usage in TS 24.623.

XML schema:

Implementations in compliance with the present document shall implement the XML schema that minimally includes the XML schema defined in clause 4.8.2 and the simservs XML schema specified in TS 24.623.

Data semantics:

The semantics of the multi-device and multi-identity XML configuration document is specified in clause 4.8.3.

The UE can only read the MuD and MiD configuration document and modify the "Activated" attribute of the <Registered-identity>,<Shared-identity> and <Delegated-user> elements.

4.8.2 XML schema p. 19

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap"
targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/xcap"
elementFormDefault="qualified"
attributeFormDefault="unqualified" >
  <xs:include schemaLocation="XCAP.xsd"/>
  <xs:element name="multi-device" substitutionGroup="ss:absService">
    <xs:annotation>
      <xs:documentation>Element describing the multi-device specific features for a given UE instance</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:extension base="ss:simservType">
          <xs:sequence>
            <!-- Element identitifying the UE among federated UEs, containing the attributes "identity" for IMPI and "alias" for user friendly name) -->
            <xs:element name="ue-instance" minOccurs="1" maxOccurs="unbounded">
              <xs:complexType>
                <xs:sequence>
  <!-- Element containing the identity the UE can use, which can be registered -->
                  <xs:element name="Registered-identity" type="ss:Registered-identityType" minOccurs="1" maxOccurs="unbounded"/>
  <!-- Element containing the identity the UE can use since it is shared with it -->
                  <xs:element name="Shared-identity" type="ss:Shared-identityType" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="identity" type="xs:string"/>
                <xs:attribute name="alias" type="xs:string"/>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:element name="multi-identity" substitutionGroup="ss:absService">
    <xs:annotation>
      <xs:documentation>Element describing the multi-identity specific features</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:extension base="ss:simservType">
          <xs:sequence>
  <!-- Element containing the delegated identity, i.e., which can use the identity of the UE since it is shared with it -->
            <xs:element name="Delegated-user" type="ss:Delegated-userType" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:complexType name="Registered-identityType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="Activated" type="xs:boolean" default="true"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Shared-identityType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="Activated" type="xs:boolean" default="true"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Delegated-userType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="Activated" type="xs:boolean" default="true"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:schema>

4.8.3 Semantics |R17| p. 20

4.8.3.1 General p. 20

This clause contains the description of the data elements in the XML schema.

4.8.3.2 multi-device element p. 20

This is a root element for elements related to MuD service. This element contains one or more occurrences of <ue-instance> element.

The <ue-instance> element represents the instance of the UE. If the user of the UE is subscribed to the MuD service, there is a dedicated element per each of the devices within MuD. This element has following attributes:

"identity" – a unique identity allowing to distinguish the UEs within the user's federated UEs. The "identity" value shall take the form of a pvalue as defined in IETF RFC 3261 and is derived from the IMS private user identity using the name-based UUID algorithm specified in RFC 4122. The hash algorithm shall be SHA-1.;
"alias" – a user friendly identifier of given UE instance.

Each <ue-instance> element contains one or more <Registered-identity> element, containing the identity, which can be registered by a given UE instance. The identity has an attribute associated, which indicates if the identity can be used for incoming and outgoing communication.

Each <ue-instance> element contains zero or more occurrences of <Shared-identity> element, containing the shared identity for a given UE instance. The identity has an attribute associated, which indicates if the identity can be used for incoming and outgoing communication.

4.8.3.3 multi-identity element p. 21

This is a root element for elements related to MiD service. This element contains zero or more occurrences of <Delegated-user> element.

The <Delegated-user> element contains the delegated identity that is allowed to use the native identity. The identity has an attribute associated, which indicates if the user of delegated identity can use the native identity for incoming and outgoing communication.