15 User Identities, Authentication, multi-device

21.9163GPPRelease 16Release descriptionTS

15.1 User Identities and Authentication


User Identities and Authentication




Bischinger, Kurt; Deutsche Telekom

Summary based on the input provided by Deutsche Telekom AG in SP-200131.

The feature allows the use of a User Identifier [1], which is independent of existing identifiers relating to a 3GPP subscription or UE, for Network Slice-Specific Authentication and Authorization. [1][2][3]

The actual identity provisioning service with creation, managing and authentication of identities is not specified by 3GPP, but the interworking of the 3GPP system with some external entity to authenticate the User Identity and to authorize the user for access to a specific network slice, in addition to the 3GPP network slice selection and authorization.

Rel. 15 Network slice selection (i.e. the procedure to select an AMF that supports the required Network Slices and establishing PDU Session(s) to the required Data network via the Network Slice instance(s) with its Control Plane and User Plane Network Functions) is based on the NSSAI, which consists of one or more S-NSSAIs.

Now with the Rel. 16 feature, Subscription information allows the indication which S-NSSAIs are subject to Network Slice-Specific Authentication and Authorization (NSSAA). For those S-NSSAIs the AMF invokes an EAP-based Network Slice-Specific authentication procedure in which the AUSF exchanges AAA protocol messages with a potentially external AAA Server (AAA-S) via an optional AAA Proxy (AAA-P) to authenticate and authorize a UE for the network slice. Depending on the result of the procedure a UE is either authorized for a network slice, re-allocated to a different one or deregistered. A re-authentication and re-authorization procedure may be triggered by the AAA Server at any time. [2][3]

Security aspects are specified in detail in [4], UE and network capabilities to support and perform NSSAA in [5], message flows for interworking to the AAA-S in [6], flags to indicate that a slice is subject to NSSAA are defined in [7] as well as [8] and the impact on the AUSF is captured in [9].


List of related CRs: select "TSG Status = Approved" in:

[1] TS 22.101, Service aspects; Service principles

[2] TS 23.501, System architecture for the 5G System (5GS)

[3] TS 23.502, Procedures for the 5G System (5GS)

[4] TS 33.501, Security architecture and procedures for 5G System

[5] TS 24.501, Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3

[6] TS 29.561, 5G System; Interworking between 5G Network and external Data Networks; Stage 3

[7] TS 29.503, 5G System; Unified Data Management Services; Stage 3

[8] TS 29.505, 5G System; Usage of the Unified Data Repository services for Subscription Data; Stage 3

[9] TS 29.509, 5G System; Authentication Server Services; Stage 3

15.2 Multi-device and multi-identity


Multi-device and multi-identity




Peter Bleckert, Ericsson


Stage 1 of Multi-device and multi-identity




Peter Bleckert, Ericsson


CT aspects of Multi-device and multi-identity




Axell, Jörgen, Ericsson


CT1 aspects of Multi-device and multi-identity




Axell, Jörgen, Ericsson


CT3 aspects of Multi-device and multi-identity




Axell, Jörgen, Ericsson

Summary based on the input provided by Ericsson in SP-201113.

The "Multi-device and multi-identity" (MUD) Feature enables the realization of the IMS enhancement for Multi-device and multi-identity.

With the increasing number of smart devices having call capabilities, the number of IMS-capable devices a single user can use also increases. GSMA RILTE have been working with specifying multi-device solutions and asked 3GPP to create requirements for all their use cases to be specified. This work item specifies the user experience requirements for a consistent user experience when the user uses these services.

Furthermore, the work also covers use cases where a user can allow another user (or possibly the same user) to use one or more of its identities. One example is for a user wishing to be able to use the work identity for the private phone. I.e. originated calls should show the work identity and terminating calls to the work identity should go to the private phone and include information that the work identity is called. Another example is to use a group identity, where employees can make calls on behalf of the group or firm and calls to the group are distributed to any member of the group.

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 Stage 1 requirements are document in chapter 4.6 in TS 22.173 [2]. No architecture changes were needed, and stage 3 were defined in the CT1 WID [5] and resulted in TS 24.174 [6] and TS 24.175 [7].


List of related CRs: select "TSG Status = Approved" in:

[1] Tdoc SP-180315, “New WID on multi-device and multi-identity (MuD)”

[2] TS 22.173 "Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1"

[3] Tdoc SP-180316, CR to TS 22.173, “Multi-device requirements”

[4] Tdoc SP-180768, CR to TS 22.173, “Update to MUD identities”

[5] Tdoc CP-182227, WID in CT1 “Multi-device and multi-identity”

[6] TS 24.174 “Support of multi-device and multi-identity in the IP Multimedia Subsystem (IMS); Stage 3”

[7] TS 24.175 “Management Object (MO) for multi-device and multi-identity in the IP Multimedia Subsystem (IMS)”