9 Roles for UE discovery for inter-UE transfer

24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS

9.1 Introduction

This clause specifies the target UE discovery procedures for UEs that are candidate UEs for inter UE transfer. The list of candidate UEs is a contact list such as name of the UE, which is represented in SIP through the use of SIP contact or the instance-id. The subscription of candidate UEs may be configured such that the private user identities associated with the UEs involved in inter UE transfer share the same set of implicitly registered public user identities.

9.2 SC UE

The target UE discovery procedures include the registration status (active, inactive), and the UE capabilities (e.g. support of audio/video formats, Controller UE capability, etc.).

In order to determine a list of UEs sharing the same set of implicitly registered public user identities and their capability information, the SC UE subscribes to the reg-event package as described in 3GPP TS 24.229 [7] in subclause 5.1.1.3.

NOTE 1: In order to allow inter UE transfer to UEs belonging to the same user subscription but belonging to a different set of implicitly registered public user identities, a user can have a static list of UEs that is manually administered by the user and stored locally in the user’s device (e.g. phone book). Having a static list is an implementation in the UE and has no impact on the standards.

NOTE 2: If the UE is not part of the same set of implicitly registered public user identities as the SC UE, or if the SC UE was unable to obtain the capability information of the UE through the use of reg-event package, the SC UE can send a SIP OPTIONS request to the UE to attempt to retrieve capability information. In order to avoid a lot of transactions, a SIP OPTIONS request is generated based on an action initiated by the user (e.g. after the user has finished adding a new UE in the static list, or the user explicitly asks for getting UE capability information).

9.3 SCC AS

The information of UEs that belong to the same subscription is required at the SCC AS for the purpose of authorizing that the requested inter UE transfer to the UE is allowed, i.e. to prevent the SC UE from performing Inter UE Transfer to a UE with a different user subscription.

The SCC AS obtains all the public user identities associated with the user’s subscription from the Sh interface as specified in 3GPP TS 29.328 [26] and 3GPP TS 29.329 [27].

NOTE 1: Getting the public user identities over the Sh interface allows the SCC AS to receive information of UEs sharing the same set of implicitly registered public user identities and information of UEs within the same user subscription that are not in the same set of implicitly registered public user identities. This is needed to authorize the static list of UEs that is manually administered by the user and stored locally in the user’s device.

The SCC AS can obtain the registration information (e.g. GRUU) by the following methods:

1. using the 3rd-party SIP REGISTER request as described in 3GPP TS 24.229 [7] in subclause 5.4.1.7; or

2. the SCC AS subscribes to the reg-event package as described in 3GPP TS 24.229 [7] in subclause 5.4.2.1.1.

NOTE 2: The SCC AS needs to know the public user identity for the authorization of the SIP REFER request for inter UE transfer. To get the public user identity from the public GRUU, the SCC AS can simply remove the "gr" parameter from the public GRUU. Using the 3rd-party registration or subscribing to the reg-event package allows the SCC AS to find the temporary GRUU of the UE and to correlate the GRUU with the public user identities. After correlation, the SCC AS would make a list of GRUUs that are associated with the same subscription and/or with the same set of implicitly registered public user identities.