HK1243248B - System and method for implementing a transfer of control of a collaborative session using sip protocol - Google Patents

Description

System and method for implementing control transfer of a collaborative session using the SIP protocol

This application is a divisional application of Chinese patent application No. 201080030007.8 (“System and method for implementing control transfer of collaborative sessions using SIP protocol”).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 61/175,403, filed May 4, 2009, of the same title, and is incorporated herein by reference.

Technical Field

The present disclosure relates generally to media and/or control function management for sessions in a mobile communication system, and more particularly to systems and methods for enabling transfer of media and/or control functions between devices.

Background Art

As used herein, the term "device" may refer to the terms "mobile station" (MS), "user agent," or "user equipment" (UE), which may include electronic devices such as fixed and mobile phones, personal digital assistants, handheld or laptop computers, smartphones, printers, fax machines, televisions, set-top boxes and other video display devices, home audio equipment and other home entertainment systems, home monitoring and control systems (e.g., home surveillance, alarm systems, and climate control systems), enhanced home appliances (e.g., computerized refrigerators), and similar devices with network communication capabilities. In some configurations, UE may refer to a mobile wireless device. Such a UE, being a mobile wireless device, may or may not include a storage module, which may be internal or removable, such as (but not limited to) a Subscriber Identity Module (SIM) or a UICC card, which may include an ISIM application, high-density flash memory, MicroSD, R-UIM, etc. SIM/UICC functionality may also be provided by downloadable software (SIM/UICC security software). The term may also refer to devices with similar capabilities but that are not readily portable, such as desktop computers, set-top boxes, TVs, IPTVs, or network nodes. The term "device" also encompasses the term "SIP User Agent (UA)," which can be fixed or mobile. When a UA is a network node, the network node can represent another function (e.g., a UA or fixed-line device) and emulate or simulate that UA or fixed-line device. For example, for some UAs, the IMS SIP client that typically resides on the device actually resides in the network and relays SIP message information to the device using optimized protocols. In other words, some functions traditionally performed by a UA can be distributed in the form of a remote UA, where the remote UA represents a UA in the network. The term "UA" may also refer to any hardware or software component that can terminate a communication session, including but not limited to a SIP session. Furthermore, the terms "user agent," "UA," "user equipment," "UE," and "node" may be used synonymously herein. Those skilled in the art will appreciate that these terms are used interchangeably in this application.

The UE may operate in a wireless communication network that provides high-speed data communication. For example, the UE may operate in accordance with Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS) technologies. Today, such UEs may also operate in accordance with Enhanced Data Rates for GSM Evolution (EDGE), or Enhanced GPRS (EGPRS) or Enhanced GPRS Phase 2 (EGPRS2). Other wireless networks in which the UE may operate include, but are not limited to, CDMA, UMTS, E-UTRAN, WiMax, and WLAN (e.g., 802.11). The UE may also operate in a fixed network environment (e.g., xDSL, DOCSIS wired network, Ethernet, or optical network). Some UEs may have multi-mode operation capabilities, wherein the UE may operate on more than one access network technology, either on one access network at a time or, in some devices, using multiple access technologies simultaneously.

EDGE/EGPRS/EGPRS2 is an example of a digital mobile communication technology that allows for increased data transmission rates and improved data transmission reliability. This network is often classified as a 2.75G network technology. Since approximately 2003, EDGE has been introduced into GSM networks around the world, starting in North America. EDGE/EGPRS/EGPRS2 can be used for any packet-switched application, such as those involving Internet connectivity. High-speed data applications (such as video and other multimedia services) benefit from the increased data capacity of EGPRS. UEs can also operate in other wireless technologies, such as (but not limited to) WiMAX, Wi-Fi, etc.

As communication networks become increasingly complex, network infrastructure is moving away from the telephony-based concept of a single identity (e.g., a phone number) that uniquely maps to a single phone line, cell phone, or other UE. For example, the Session Initiation Protocol (SIP) and other related Internet-based communication technologies support multiple devices registering with the network, each sharing the same user identity (e.g., a SIP or Tel Uniform Resource Identifier (URI)) or a set of overlapping or identical identities. This set of identities is referred to as an Implicit Registration Set (IRS). In keeping with the evolution of communication networks, SIP also supports a variety of media types, including (but not limited to) text, data for applications, audio, and video, within the same session established between the network and the UE. Those skilled in the art will appreciate that devices/SIP UAs can have different capabilities, such as a small screen that supports video or an IPTV that supports HDTV. Therefore, it would be advantageous if a conversation between two or more devices/SIP UAs with video and voice components, initiated on a small screen, could have its video component moved to the HDTV when the user approaches the HDTV. This capability is called Inter-UE Transfer (IUT) and is defined in 3GPP TS 23.237 and 3GPP TS 24.292.

In order to provide efficient operation of the network and related devices in IUT, PNM and other services (such as BlackBerry Alliance), some networks include a manager or controller UE, which has the ability to manage devices or sessions transmitted in a target UE group, where the target UEs in the target UE group are all associated with a network server. In this case, the manager or controller UE can be configured to manage the operation of various features/parameters available via one or more other UEs. In some cases, the controller function can be transferred from the controller UE to another UE capable of providing the controller function. In some cases, multiple UEs can act as controllers. In some cases, the controller UE can implement personal network management (PNM) controller functions. In some cases, the UE has multiple user agents, one for each access network. Similarly, the manager or controller UA can be configured to manage the operation of various features/parameters available via one or more other UAs. The manager or controller UA can also be a manager or controller UE. Below, unless it is obvious from the context, the terms UE and UA are generally used interchangeably.

SIP enables UEs to be configured so that: based on which UE a communication is addressed to, the UE can be notified based on the sender identity used for communication filtering and service redirection. For example, a user can configure a call/communication forwarding service to allow family members to be provided with a specific public user identity (e.g., home phone number or email address) to reach the user directly through the user's mobile phone, and friends or family members can be forwarded to personal voicemail, while colleagues can be forwarded to the office phone, which is ultimately forwarded to corporate voicemail.

Thus, SIP allows a user to have a consistent identity across multiple UEs, which may include a home phone, a personal mobile phone, a work phone, a company mobile phone, a vacation home phone, a laptop voice-over-IP (VoIP) client, a fax machine, and the like. A consistent public user identity also enables a user to be found regardless of which UE the user happens to be currently using. This flexibility minimizes the need to maintain large device-specific contact lists to identify each user in an address book and to decide which device is best when attempting to establish communication (each user (and all of their associated cell phones, home phones, computers, etc.) can be identified by a single identity). Thus, it is possible to communicate with someone using only a single identity, provided that the network and/or the terminating user determines the most appropriate UE for contacting the individual.

In a network that implements SIP and has a manager or controller UE, it is desirable to ensure that new sessions are established to the UE with the best capabilities to handle content (which may include various media types). When a user has access to a television or computer screen/monitor, it may not be optimal to receive media, including video content, on a regular office phone that is not designed to display video content or has a very small video screen. In addition, when a UE is already engaged in a session that uses one or more media types and the UE receives an invitation to add or modify one or more media types to the session, the controller UE should be identified so that the user can request that the new media type be transferred to a different UE that can support and process or present the new media type. For example, if a user is engaged in an audio session on the user's mobile phone and the user wishes to receive the added video streaming media on another device, the controller UE provides the user with the ability to select another device (e.g., a laptop PC) to receive and display the added video streaming media based on, for example, device capabilities and user preferences.

Furthermore, a user may use different devices for the controller of a session during the duration of a session. For example, a user may be outdoors in a garden accepting a session or one or more media components of a session on his mobile phone, but then move into the house and transfer the audio and video components to his desktop computer, and, because the user now wishes to control the session from his desktop computer, he also transfers control of the session from his mobile phone to his desktop computer. Ultimately, controller state functionality should only be transferred between specific member UEs that are capable of becoming controller devices and that are authorized by the network to receive controller functionality (e.g. a basic TV is unlikely to have the ability to interact with the user to perform controller functionality). It is therefore important to provide a secure mechanism for distributing and processing transfer requests for sessions, media and controller functionality between a group of UEs that may be used by different subscribers (e.g. shared devices such as a home phone and TV).

Summary of the Invention

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, reference is now made to the following brief description and detailed description taken in conjunction with the accompanying drawings, wherein like reference numerals represent like parts.

FIG1 illustrates an example flow for transferring media and IUT controller functionality between UEs associated with a network;

FIG2 illustrates an exemplary communication network for implementing the present system for performing IUT media and/or controller function transfer between UEs connected to the network;

FIG3 shows an example process for registering a UE with an IMS network and resulting in registration with an SCC AS;

FIG4 illustrates an exemplary allowed IUT list management object for identifying one or more IUT-capable UEs, including a controllable UE, or both a controller UE and a controllable UE;

Figures 5a and 5b show parameters and DDF of the exemplary allowed IUT list MO shown in Figure 4;

FIG6 shows an example flow for providing IUT controller functionality to a UE, where authorization is requested only from a single controller UE;

FIG7 shows an example flow for providing IUT controller functionality to a UE, where only authorization is requested from multiple controller UEs;

FIG8 shows an example flow of transferring media A and controller functions to a UE as requested by an IUT controller UE;

FIG9 shows an example flow for transferring media A and a controller function from UE-1 to UE-2, where the incoming session request includes a controller function identifier and is transmitted over the Gm reference point, and media A is sent via a circuit-switched network;

FIG10 shows an example flow for transferring media A and a controller function from UE-1 to UE-2, wherein the incoming session request includes a controller function identifier and the incoming session is transmitted over the I1 reference point, and media A is sent via the CS network;

FIG11 shows a plurality of UEs associated with a user, with a collaborative session being established between a subset of the UEs;

Figures 12a and 12b illustrate example processes for terminating collaborative session establishment upon receiving a session invitation request;

FIG13 illustrates an example process for transferring IUT controller functionality from a first PS UE to a second PS UE, where the first UE and the second UE may use the same bearer or different bearers;

FIG14 is an illustration of an alternative message flow for transferring media/controller functionality to another UE in a collaborative session using a Gm reference point;

FIG15 is an illustration of an alternative message flow for transferring media/controller functionality to another UE in a collaborative session using the I1 reference point;

FIG16 is an illustration of an alternative message flow for a controller-initiated transfer of ongoing session information;

FIG17 illustrates a wireless communication system including an embodiment of a user agent;

FIG18 shows a block diagram of a user agent including a digital signal processor (DSP) and memory;

FIG19 illustrates a software environment that may be implemented by a processor of a user agent;

FIG20 illustrates an example of a system including processing components suitable for implementing a method for providing continuity of session transitions between networks;

FIG21 is an illustration of an exemplary structure for storing information describing associated controllers and controllable UEs within a network;

FIG22 is an illustrative diagram of example information stored in a network (e.g., stored in an HSS);

23 is an illustrative diagram of example indicators with reference bit value locations.

DETAILED DESCRIPTION

The present disclosure overcomes the aforementioned deficiencies by providing systems and methods for media and/or control function management in a mobile communication system, and more particularly, by providing systems and methods for enabling media transfer and/or control function transfer between devices.

In one example, a method for transferring controller functionality from a first user equipment (UE) to a second UE that may belong to the same party includes establishing a session for transmitting media content between the first UE and a third UE. Initially assigning controller functionality for the session to the first UE. The method includes receiving a request from the first UE to transfer at least a subset of the controller functionality for the session to the second UE, and determining the second UE's ability to implement the controller functionality. When the second UE has the ability to operate as a controller, the method includes assigning at least the subset of the controller functionality for the session to the second UE, and responding to the request to transfer at least the subset of the controller functionality for the session to notify the first UE to release the session.

In another example, a method for transferring controller functionality from a first user equipment (UE) to a second UE includes establishing a session for transmitting media content between the first UE and a third UE. A controller functionality for the session is initially assigned to the first UE, and the first UE includes an interface. The method includes receiving a request to transfer the controller functionality for the session to the second UE via the first UE interface, sending a session controller functionality transfer request to an application server, and receiving a transfer response from the application server. When the transfer response indicates that the first UE should release the session controller functionality, the method includes releasing the session controller functionality.

In another example, a method for transferring a session for transmitting media content between a first user equipment (UE) and a third UE includes assigning a controller function for the session to the first UE, receiving a request from the first UE to transfer the session for transmitting the media content to a second UE, and determining the second UE's ability to receive the session for transmitting the media content. When the second UE is capable of receiving the session for transmitting the media content, the method includes transferring the session for transmitting the media content to the second UE, and responding to the request to transfer the session for transmitting the media content to the second UE to notify the first UE to release the session.

Various aspects of the present disclosure will now be described with reference to the accompanying drawings, wherein like reference numerals refer to like or corresponding elements throughout. However, it should be understood that the drawings and the related detailed description are not intended to limit the claimed subject matter to the specific forms disclosed. On the contrary, the present invention is intended to encompass all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.

As used herein, the terms "component," "system," and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.

As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

In addition, the disclosed subject matter can be implemented as a system, method, apparatus or manufacturing link using standard programming and/or engineering techniques to produce software, firmware, hardware or any combination thereof to control a computer or processor-based device to implement the aspects described in detail herein. The term "manufacturing link" (or alternatively "computer program product") used herein is intended to include a computer program that can be accessed from any computer-readable device, carrier or medium. For example, computer-readable media may include (but are not limited to): magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, etc.), optical disks (e.g., high-density disks (CDs), digital versatile disks (DVDs), etc.), smart cards and flash memory devices (e.g., cards, memory sticks, etc.). In addition, it should be appreciated that a carrier wave can be used to carry computer-readable electronic data, such as the carrier wave used in sending and receiving emails or the carrier wave used in accessing a network (e.g., the Internet or a local area network (LAN)). Of course, those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope or spirit of the subject matter of the claimed rights.

The present system provides media and/or control function management for implementing media transfer or control function transfer between devices associated with a communication network. In one implementation, the system performs inter-UE transfer (IUT) according to 3GPP TS 23.237 to transfer one or more media components of a session or some or all media streams and/or controller functions (ITU controller) from one or more controller SIP UAs or UEs to one or more controleee SIP UAs or UEs. The system can be implemented in various communication networks, wherein UEs are configured to be assigned a single shared identity (e.g., Tel URI, SIP URI, MSISDN, C-MSISDN, GRUU (Globally Routable User Agent URI), etc.), or have overlapping identity information with other UEs associated with the network. Within the network, each UE can initiate various communication sessions, each session involving the communication of data, which can include multiple media types, such as (but not limited to): data for applications (media type applications), voice, text, video (including various encoding schemes), and audio.

In one configuration, the system is implemented via a network that supports SIP and has various manager or controller SIP UAs or UEs in addition to non-controller or controlled SIP UAs or UEs. Depending on (but not limited to) network rules, operator policies, user preferences, or other system requirements, the controller functionality can be moved from a first controller UE to another UE. In some cases, UEs with controller or controlled functionality can be provided via the network, where the controlled UEs are configured in a manner similar to controller UEs with similar functional capabilities and system design. When one of the UEs initially registers with the network, the first UE supporting controller functionality that registers with the wireless server is automatically designated as the manager or controller UE. In some cases, when the network receives an initial transfer request for a collaborative session sent by a UE supporting controller functionality, the UE can be automatically designated as the manager or controller UE. However, other algorithms can be used to determine the provisional controller UE in the UE cluster. After connecting to the network, the user can optionally change the controller designation from the first registered UE to one of the other registered UEs under the control of the user or other related users.

Using this system, a network serving a user with multiple UEs (all sharing a common identity) can receive an invitation to participate in a session that includes various media types. Upon receiving the invitation, the network transfers, forwards, or sends a session invitation (e.g., a SIP INVITE or SIP Re-INVITE) to the user's UE based on the media type described in the invitation, the user's specified preferred UE, or other information available to the controller UE or network. If the user is already participating in a session that uses various media types and receives an offer (e.g., a Session Description Protocol (SDP) offer) to add, delete, or modify one or more media types for the same session, the controller UE can be identified for transferring the new media type and session control functions to the different UEs.

In one implementation, when a UE (e.g., an ICS UE) receives a SIP INVITE request containing an SDP for establishing a session using an IP bearer, the ICS UE establishes the session in accordance with 3GPP TS 24.229, however, with the following caveats: First, if the SIP INVITE request contains a Target-Dialog header containing dialog parameters corresponding to an existing dialog (or a dialog in the process of being established) between the ICS UE and a Service Consistency and Continuity Application Server (SCC AS), the ICS UE treats the SIP INVITE request as another dialog that is part of the same session, the other dialog being identified by the dialog parameters contained in the Target-Dialog header. Second, if the SIP INVITE request does not include a Target-Dialog header, but there is an existing dialog (or a dialog being established) between the ICS UE and the SCC AS, the SCC AS may check whether the dialog parameters in the request correspond to the dialog parameters received in the Target-Dialog header for the existing dialog (or the dialog being established) between the ICS UE and the SCC AS. If so, the ICS UE may treat the SIP INVITE request as another dialog that is part of the same session, the dialog for which the Target-Dialog header was received. This second description may include the possibility that the requests arrived out of order compared to the order in which the requests were sent.

A controller UE configured to implement IUT according to the present system can be configured to perform one or more of the following: add one or more media streams to a session by creating a new access segment (1eg) on a different UE, add one or more media streams to a session on an existing access segment on a different UE, remove one or more media streams from a session on an access segment on a different UE, provide MMTel service control with media on the different UE (see, for example, 3GPP TS 22.173), and provide media feature updates on the different UE. Thus, each controller UE can be configured to establish and/or release a collaborative session that provides one or more sessions anchored using a specific network entity or node (e.g., an SCC AS). While maintaining an ongoing collaborative session, each controller UE can transfer media streams of the collaborative session to a target UE. Furthermore, each controller UE can be configured to transfer all or some of the available one or more media streams to the target UE with or without establishing a collaborative session. If all media streams are transferred to the target UE, the existing session on the controller UE can be released.

In one example system implementation, to enable inter-UE transfer (IUT), the SCC AS uses the ISC reference point toward the S-CSCF for inter-UE transfer execution. For example, to enable and execute IUT, the SCC AS may first analyze the information required for inter-UE transfer as described below and, based on operator policy and user preferences, determine which access network should be used. The SCC AS may then reject the inter-UE transfer request if the information does not align with operator policy. The SCC AS may retrieve the CMSISDN bound to the IMS private user identity stored in the user profile of the HSS from the Home Subscriber Server (HSS) after registration, and retrieve the controller function for inter-UE transfer bound to the IMS private user identity stored in the user profile of the HSS from the HSS after third-party registration. The SCC AS can also determine whether a UE is allowed and has controller functionality for inter-UE transfers, associate inter-UE transfer requests with anchored sessions using information provided in an incoming SIP INVITE or incoming inter-UE transfer request, and perform IMS inter-UE transfers between different UEs belonging to the same IMS subscription connected via the same or different access networks. The SCC AS can also provide charging data specific to IUT transfers, provide information about transferable UEs to the controller UE, and decide whether to update the specified operator policy for inter-UE transfers based on analysis of various service continuity-related input factors. The SCC AS can also generate operator policy for inter-UE transfers and update the operator policy for inter-UE transfers by sending it to the UE via OMA DM, including a priority between operator policy and user preferences (which can also be used to initiate an inter-UE transfer procedure for outgoing sessions), and determine whether to send an incoming session invite received from a remote party to the controller UE so that the terminating controller UE can initiate an inter-UE transfer.

Generally speaking, the SCC AS provides the functionality to merge and/or split media streams on one or more access networks in the following situations: as required by session transfer, session termination, or when the UE requests to add media streams on additional access networks during session establishment, or when the UE requests to add and/or delete media streams on one or more access networks to an existing session.

When processing the media flows of an IMS session, the SCC AS may take into account the services associated with the session.

In order to route a SIP method (SIP METHOD) (eg, SIP INVITE) on a specific access segment, it is necessary to identify the specific registration flow corresponding to the access segment.

Draft-ietf-sip-outbound describes how a SIP UA or UE can register through multiple registration flows through which requests can reach the UA or UE. As supported in 3GPP IMS, a UE uses the mechanism defined in Draft-ietf-sip-outbound to register using different flows on different access networks. As defined in Draft-ietf-sip-outbound, each flow on a different access network may contain a different "reg-id" contact header parameter in the Contact header of the SIP REGISTER request. As described in 3GPP TS 24.229, when the registering UE includes a P-Access-Network-Info header in the SIP REGISTER request: An example syntax of the extended P-Access-Network-Info header field according to 3GPP TS 24.229 is shown in Table 1.

Table 1

As can be seen from the syntax of P-Access-Network-Info, access-type indicates the access network technology used by the network over which the SIP REGISTER request is routed. However, while the "reg-id" parameter uniquely identifies a registration flow, there is no current mechanism that allows the network to direct SIP methods, such as SIP INVITE, to a specific registration flow. To enable this, a media feature tag that identifies the registration flow could be defined and included in the Contact header of the SIP REGISTER request (the "reg-id" parameter is not a media feature tag). The following are examples of two possible embodiments of such a media feature tag. Those skilled in the art will appreciate that any construction of appropriate alphanumeric characters can be used to convey the same meaning from a SIP UA/UE.

In the first example shown in Table 2, a feature tag g.3gpp.icsflow is defined that allows a string to be included in the media feature tag that identifies the flow. The string may contain the same identifier value as in the "reg-id" parameter (e.g., g.3gpp.icsflow=[regid]), or it may contain some other string, however, in one implementation, the string must be different for each registration flow. For the strings used in the media feature tag, the UE may allow the user to define human-understandable labels, as when performing media transfer, the user may need to use these labels to indicate to which access segment they wish to transfer the media type (e.g., "Internet", "Cable TV", "Cellular", "WLAN").

Table 2

In another example shown in Table 3, the existing g.3gpp.ics media feature tag is enhanced to also indicate whether the registration is coming directly from the mobile phone or from a network node, and also indicates which registration procedure is being used.

Table 3

When registering, the UE includes a P-Access-Network-Info header in the SIP REGISTER request. The P-Access-Network-Info header contains the identification of the access technology used on the access leg. The UE also includes a media feature tag in the Contact header of the SIP REGISTER request. The media feature tag contains the unique identifier of the process as described above.

The SCC AS or another network node can obtain media feature tags by subscribing to the registration event package according to RFC 3860 or the enhanced third-party registration procedure (e.g., an incoming SIP REGISTER request included in the body of a third-party SIP REGISTER request). The SCC AS can also obtain the P-Access-Network-Info header from the third-party SIP REGISTER request.

For example, the SCC AS may also obtain registration state information needed for its implementation of IMS Centralized Services (ICS) specific requirements from, for example, any received third-party Registration Request as specified in 3GPP TS 24.229 (e.g., including information contained in the body of the third-party Registration Request), from any received Registration Event Package as specified in 3GPP TS 24.229, or from the Sh interface as specified in 3GPP TS 29.328 and 3GPP TS 29.329. Using these mechanisms, the SCC AS may obtain the access-type and, if present, the access-class value and the value of the g.3gpp.icsflow media feature tag from the P-Access-Network-Info header, and associate the access-type and access-class values (if present) with the value of the g.3gpp.icsflow media feature tag so that the request may be routed over a specific flow corresponding to a specific IP-CAN.

The SCC AS or another network node stores the access-type and/or access-class information (possibly including associated location information) obtained from the P-Access-Network-Info header (which is associated with the access segment/flow identifier obtained from the media feature tag). Note that the P-CSCF may also include additional access type or access class values in the P-Access-Network-Info header, which contains the access class and access type verified by the network and thus indicated by including the "np" (network-provided) parameter. Based on operator availability and policy, the access type and/or access class from the UE-provided P-Access-Network-Info header and/or the network-provided P-Access-Network-Info header, or from both headers, may be stored in association with the access segment/flow identifier obtained from the media feature tag.

When the SCC AS (or another network node) determines, based on operator policy or user preference or user configuration, that a request containing a specific proposed media type is to be routed over a specific access leg, the SCC AS (or another network node) obtains the access leg/flow identifier previously obtained from the media feature tag and stored in association with the access type and/or access category obtained from the P-Access-Network-Info header. The SCC AS (or another network node) then includes in the request an Accept-Contact header containing a media feature tag (e.g., g.3gpp.icsflow) with a value set for the access leg/flow identifier associated with the access type and/or access category for the access leg over which the request is to be routed. The parameters "require" and "explicit" may also be optionally included in the Accept-Contact header associated with the media feature tag containing the access leg/flow identifier. As a result, the request is routed to the UE using the desired access leg using the mechanism described in RFC 3841 and, correspondingly, if the request is accepted, media is also established using that access leg.

In some implementations, the operator provisions the network operator's policy in the network and may transmit the policy to the UE, for example, during initial provisioning or via, for example, OMA DM device management. Whenever the operator updates the policy, the operator policy may be transmitted to the UE via OMA device management.

For each supported type of media or media group, the operator policy can indicate: a list of access networks restricted for session origination and session transfer; a list of preferred access networks (in order of priority) to be used by SC-capable UEs for session origination and session transfer (when these access networks become available and session transfer is possible); and whether the SC-capable UE "shall"/"should"/"may" begin transferring media streams to a target access network with a higher priority than the current access network (when the target access network becomes available and session transfer is possible). By indicating "shall", the operator forces the UE to initiate session transfer as soon as possible according to the home operator's preferred access network list. By indicating "should", the operator recommends that the UE initiate session transfer according to the home operator's preferred access network list if session transfer is possible and desired after considering local operating environment information. By indicating "may", the operator leaves it to the UE's discretion whether to initiate session transfer according to user preferences (if configured) if session transfer is possible and desired after considering local operating environment information. The UE may consider the home operator's preferred access network list regardless of whether user preferences are configured. Operator policy may also indicate whether to retain or discard non-transferable media streams in the case of partial session transfer. Generally speaking, operator policy for session transfer is consistent with operator policy for T-ADS.

User preferences may indicate, for example, a preferred access. Local operating environment information may be implementation-specific and may include items such as radio environment information, IP connection quality (jitter, delay, and packet loss), application-specific requirements, memory considerations, power considerations, etc. The UE may consider operator policy, user preferences, and local operating environment information when deciding which access to use for an outgoing session or before considering initiating a session transfer. Generally, user preferences for access transfer are not transferred to the network.

For IUT, when deciding whether the UE is allowed and capable of acting as a controller, when determining which access network to use for an incoming session, when determining which media type to send on a specific UE, and when sending an incoming session invitation from a remote party to the controller UE, the UE may indicate the following user preferences to the SCC AS via the Ut interface, and the SCC AS may consider operator policies and user preferences: preferred UE to act as a controller UE; preferred access network type for incoming sessions; preferred media type to be received on the user's specific UE; and preference for receiving incoming session invitations from remote parties on the controller UE.

Furthermore, for IUT, the UE is generally configured to support IUT controller or controlled functionality. In the case of a terminating UE, the UE can be configured to become a controller UE to apply IUT to an ongoing session when the far end sends a session invitation.

If a user wishes to direct the establishment of a media session for one or more media types over a specific access segment when performing a media transfer, the user may indicate this by selecting the access segment on their controller UE that they wish to use for the specific media type. For the strings used in the media feature tags, the UE may have previously allowed the user to define human understandable labels so that when performing a media transfer, the user can use these labels to indicate to which access segment (e.g., "Internet," "Cable TV," "Cellular," or "WLAN") they wish to transfer the media type. Alternatively, when performing a registration involving access types, the device provides a mapping between human readable access types that the user can read and the access types that the device supports. The following is an example embodiment, however, those skilled in the art will appreciate that the mapping may be more or less restricted, where the idea is to map a human readable alphanumeric string to a large number of possible P-Access-Network-Info header access type values.

For example, WLAN="IEEE-802.11"/"IEEE-802.11a"/"IEEE-802.11b"/"IEEE-802.11g"/"IEEE-802.11n"

DSL="ADSL"/"ADSL2"/"ADSL2+"/"RADSL"/"SDSL"/"HDSL"/"HDSL2"/"G.SHDSL"/"VDSL"/"IDSL"

Cellular="3GPP-GERAN"/"3GPP-UTRAN-FDD"/"3GPP-UTRAN-TDD"/"3GPP-E-UTRAN-FDD"/"3GPP-E-UTRAN-TDD"

Cable TV = "DOCSIS"

For example, if a user has a multimode-capable mobile phone that supports both WLAN and cellular (e.g., EDGE/UMTS/LTE) access, the user may wish to receive video media types over the WLAN access for reasons of bandwidth efficiency, cost efficiency, or better image quality, while using the cellular connection for voice and audio media types. To do so, the UE includes an Accept-Contact header in a request (e.g., a SIP REFER request) for requesting media transfer, the Accept-Contact header containing a media feature tag (e.g., g.3gpp.icsflow) with a value set to the access leg/flow identifier of the user-selected access leg over which the transferred media types are to be routed. The parameters "require" and "explicit" may also be optionally included in the Accept-Contact header associated with the media feature tag containing the access leg/flow identifier. In the case of a SIP REFER request, the Accept-Contact header and its value may be embedded within a Refer-To header. When the SCC AS (or another network node) receives the media transfer request, it then includes the Accept-Contact header and its value from the media transfer request in the request sent to the UE to which the media is to be transferred. This results in the request being routed to the UE using the desired access segment using the mechanism described in RFC 3841, and correspondingly, if the request is accepted, media being established using that access segment. Note that in some cases (such as the example above), the UE to which the media is to be transferred can be the same UE as the controller UE that sent the media transfer request.

Figure 1 shows an example communication flow that can be implemented by the present system to transfer media and/or IUT controller functions between SIP UAs or UEs associated with a network. The flow allows for the transfer of service control of a session containing two media components from a first controller UE (UE-1) to a second controlled UE (UE-2). For example, the first UE and the second UE may share the same public user identity by sharing the same SIP URI or TelURI, or having overlapping or identical public user identities defined by an implicit registration set (IRS). However, they will have unique private identities, such as (but not limited to): IMS private identity, IMSI, MIN, etc. In this example, UE-1 has a multimedia session established with a remote UE whose session is anchored at an SCC AS. UE-1 initially pushes for session control.

As shown in Figure 1, a multimedia session includes two media components (Media A and Media B), and UE-1 wishes to transfer collaborative session control and one of the media components (Media A) to UE-2 via the IUT. As shown in the figure, in step 101, UE-1 initiates the process of transferring collaborative session control and the media type (Media A) to UE-2 by transmitting or sending a transfer request to the SCC AS. The transfer request indicates that the collaborative session control and the media type (Media A) are to be transferred to UE-2. The transfer request may include an SDP (possibly embedded in the Refer-To header of a SIP REFER request) containing the media type to be transferred. Alternatively, the media type may be indicated by signaling an appropriate feature tag in the transfer request. UE-2 may be identified by, but is not limited to, a GRUU, a SIP URI, a Tel URI, or the like. In step 102, the SCC AS recognizes the request and performs an authentication process. The verification process may include verifying that UE-1 is permitted to perform IUT, that the identity of UE-2 (in this embodiment, UE-2's GRUU) is stored in the SCC AS (a valid registration exists), and that the media feature tags stored for the GRUU match those received in the request from UE-1. If UE-2's GRUU does not exist, or the feature tags do not match, the request may be rejected. Alternatively, the verification process may include the SCC AS retrieving the Tel URI and SIP URI of authorized UEs. If the retrieved Tel URI and SIP URI match an available UE-1, the SCC AS may identify another target UE that matches the retrieved Tel URI and SIP URI. The SCC AS will then ensure that the feature flags and the explicit and required parameters in the Accept Contact header are set to select the alternative contact as the contact of the UE performing the request.

If UE-1 is permitted to request transfer of collaborative session control and media A to UE-2, the SCC AS may transmit or send a request to UE-2 indicating that collaborative session control and media A will be transferred to UE-2. For example, a SIP method (e.g., SIP INVITE) may include UE-2's GRUU as the target and a media feature tag indicating collaborative session control (IUT controller function). The SIP method may include the required media feature tags in the Accept-Contact header along with "Explicit" and "Required." Alternatively, an SDP containing the media types to be transferred may be included. In step 103, the system establishes collaborative session control between UE-2 and the SCC AS. At this point, UE-2 becomes the controller UE for the collaborative session (based on receipt of the media feature tag indicating the IUT controller function). However, in other implementations, UE-1 may send a transfer request including the media to be transferred while maintaining collaborative session control on UE-1. In this case, the transfer request does not include an indication, identifier, token, flag, or media feature tag for collaborative session control (IUT controller function).

In one implementation, a collaborative session comprises a logical collection of one or more IP Multimedia Subsystem (IMS) sessions (possibly on two or more UEs sharing the same IMS subscription), anchored in the SCC AS appearing on the remote leg as a single IMS session. From the subscriber's perspective, the remote leg can be the call control leg between the SCC AS and the remote party (for additional examples, see 3GPP TS 23.292 for a definition of the remote leg of an IMS session using circuit-switched media).

In step 104, a session carrying Media A is established between UE-2 and the SCC AS. At this point, the system may optionally update the remote segment between the SCC AS and the remote party based on the new session establishment with UE-2. For example, the remote segment may be updated to implement a video codec adjustment or change (e.g., because the change is required by the IPTV device, otherwise the media would need to be renegotiated). After successfully establishing collaborative session control and transferring Media A to UE-2, in step 105, the SCC AS sends a transfer response to UE-1 (e.g., a SIP NOTIFY request for a final response in accordance with RFC 3515). After receiving the transfer response, in step 106, the previous session carrying Media A on UE-1 may be released, along with collaborative session control. After successfully transferring collaborative session control, UE-1 becomes a controlled UE (a UE that receives and/or sends media streams (Media B) as part of the collaborative session and is subordinate to the controller UE for session control), and UE-2 assumes the role of controller UE. Media type (Media A) is transferred between UE-2 and the remote party, while media type (Media B) continues to be transferred between UE-1 and the remote party. If the transfer is unsuccessful, the SCC AS should send a message back to UE-1 indicating the transfer failure. The message may include, but is not limited to, a SIP 488 (Not Acceptable Here) response. A warning may be included in the response indicating the reason for the failure. The message to UE-1 indicating the transfer failure may be included in a SIP NOTIFY request, which includes a SIP fragment of the response from UE-2 (e.g., a SIP 488 (Not Acceptable Here) response) in the body.

The communication flow shown in Figure 1 allows for transfer of media and collaborative session control between UEs. In addition to media and collaborative session control transfer, the above flow can also transfer controller functions between UEs after one or more controller UEs authorize the transfer of controller functions to the target UE.

In one implementation, to facilitate session transfer (e.g., for IMS service continuity), the UE can be configured to store and apply operator policies for session transfer (e.g., the policies described above). The UE can also initiate a session transfer process based on triggering criteria, including current operator policies, user preferences, and local operating environment information. This provides the SCC AS with the necessary details for performing session transfer operations. The UE can also provide its ability to support controller or controlled device functions of IUT and initiate an IUT process based on current operator policies and user preferences. This provides the SCC AS with the necessary details for performing IUT operations.

A UE may have multiple registration contexts that may use different access networks. Depending on the IUT policy and implementation in the network or application server (AS), the UE may be configured to use different access networks for some or all media transmissions. For example, based on some predefined user preferences or network/operator policies, the UE may use a wireless local area network (WLAN) radio or some other access network for video-type media transmission with appropriate properties.

The indicator indicating the attribute or target UE or specific target UE can also identify the access technology (eg supported by the same device).Using the above process, a request can be routed on a specific access leg using a specific access technology.

In other system implementations, the controller UE function may also reside in a physical box (e.g., a set-top box), or may be an executable software that resides in a personal computer, a media server, a home node B, or other devices that are not physically operated by a user. In one example, the user is surrounded by a media receiver (media sink) or a controlled device UE. The media receiver may interact with the controller UE or other media controller devices, or supplement the controller UE or other media controller devices. For example, a TV remote control may provide stop and rewind or other functions that may be intercepted and forwarded to a device or UE configured to handle various functions by the media receiver or TV. In some implementations, a single box may support multiple SIP UAs for different external physical devices. For example, a home server or set-top box may implement multiple SIP UAs for other connected devices that do not have SIP functionality (e.g., basic TVs, traditional landline phones, and home entertainment systems that do not support SIP).

Referring now to FIG. 2 , an exemplary communication network for implementing the present system to perform IUT is shown. Network 212 is a communication network and includes various components, such as a base station, an SCC AS, a call session control function (CSCF) (e.g., a P (proxy)-CSCF, an S (serving)-CSCF, and an I (interrogating)-CSCF), a mobile switching center (MSC) server, an enhanced MSC for IMS centralized services (ICS), and/or various data storage systems for storing device capabilities, user preferences, lists of controller UEs and controlled UEs for IUT, session segment mapping information for each device, and other rules or restrictions used in implementing the present system. By communicating with network 212, a UE can become associated with the network (e.g., register) and communicate with other associated UEs through network 212, or communicate with other devices configured to communicate via network 212. User 214 has multiple UEs 216, 218, and 220. UEs 216, 218, and 220 share a single identity 230 which may be defined by, for example, a Tel URI or SIP URI in IRS set A. User 222 has UEs 224 and 226 which are also connected to network 212. UEs 224 and 226 also share an identity through, for example, IRS B.

In Figure 2, user 214's UEs include several different devices. UE 216 is a cellular phone without video capabilities, UE 218 is a laptop with Voice over IP (VoIP) and video conferencing capabilities, and UE 220 is a television configured to communicate with network 212 but with minimal user input capabilities. In this example, television 220 is connected via a hardwired connection to a proxy 221 for communicating with network 212. Proxy 221 may include a home gateway, cable box, set-top box, or other system for communicating with network 212. Proxy 221 may communicate with network 212 wirelessly or via a hardwired connection. However, those skilled in the art will appreciate that some or all of proxy 221 may be incorporated into television 220. When each of UEs 216, 218, and 220 establishes a connection with network 212, IUT controller functionality may be assigned to one or more UEs associated with user 214. The IUT controller function may be assigned based on rules that evaluate any combination of UE functional capabilities, user preferences, network requirements, or data available via user 214, network 212, or any other entity in communication network 212. In this example, UE 216 (a cellular phone) is initially assigned the IUT controller function. UE 216 can then send a transfer request for specific media related to an ongoing session to either UE 218 or 220. As part of the transfer process, UE 216 may also issue a request to network 212 to transfer the IUT controller function to any of UEs 218 and 220. In some cases, depending on network-defined and user-defined rules, some or all media and IUT control functions may be transferred to UEs 224 and 226 belonging to user 222.

2 , user 214 can use cell phone 216 to initiate a phone call to UE 232 belonging to user 230. Because cell phone 216 does not support video, the established session includes only voice and no video. However, if user 230's UE 232 supports video and user 230 wishes to add video to the session, user 230 can send a request or invitation to user 214 to add video to the session. Because cell phone 216 cannot handle video, video cannot be added to the session unless user 214 instructs UE 216 to redirect to a UE that can handle video. In this example, upon receiving a request to add video to an ongoing session, UE 214 can instruct UE 216 to redirect the video-type request to laptop 218, which has video conferencing capabilities. To redirect the video-type request to laptop 218, cell phone 216 generates a message (e.g., a SIP 3xx non-final response) to redirect the video-type request to network 212 (if a final SIP response, such as a SIP 3xx response, is used, the entire session can be redirected). Depending on the system implementation, upon receiving a request to add a new media type from a remote party, the network (e.g., an SCC AS) may automatically initiate an invitation to the target UE based on, for example, device capabilities, user preferences, or network rules. Alternatively, a user interface provided by cell phone 218 may allow user 214 to instruct cell phone 218 to redirect the message to laptop 218. When network 212 (e.g., an SCC AS) receives the request to redirect the request, network 212 (e.g., an SCC AS) verifies that laptop 218 can support video-type media. This includes SCC AS 212 reviewing the media feature tag that was transmitted to SCC AS 212 as part of the SIP registration for laptop 218 and stored in SCC AS 212 against the GRUU media feature tag that registered laptop 218.

SCC AS 212 verifies that cell phone 216 has the capability to request the redirection and is authorized to make the request. If these requirements are met, SCC AS 212 can check whether the feature flag included in the SIP method from the controller (e.g., SIP INVITE) is stored relative to the SIP Contact to which the media is being redirected. If the media feature flag is present, the SCC AS redirects the request to laptop 218 by sending an INVITE request (e.g., SIP INVITE) with an SDP containing the media type. The SCC AS also sets "Explicit" and "Required" according to RFC 3841 to ensure that the correct target is selected in the S-CSCF. Upon successful redirection and collaborative session establishment, cell phone 216 can also request a transfer of IUT controller functionality to laptop 218.

In this example, the IUT controller functionality is transferred to laptop 218. Laptop 218 thus has the option of resuming the video conference session with other UEs accessible to user 214. For example, to facilitate viewing of the ongoing video conference by a larger group of people, user 214 may wish to copy some or all media from the video conference to television 220 while maintaining the video conference on laptop 218, which is configured to communicate via network 212. In this example, television 220 does not include a microphone. Thus, user 214, using laptop 218 (which has IUT controller status), instructs network 212 to copy only the video portion of the ongoing video conference session to television 220. In one implementation, the SCC AS releases the media type from the transferred segment after the transfer, necessitating signaling that a copy was requested. Signaling of a copy can be accomplished using new media feature tags, SDP variables, parameters, and/or SIP headers. In another implementation, the transferring UE releases the media type from the transferred segment after the transfer, without signaling that a copy was requested. Upon authorization of the copy, SCC AS 212 sends a message (e.g., a session invitation (SIPINVITE) with a video media type) to television 220 to facilitate viewing. However, the voice portion of the conversation remains on laptop 218 so that user 214 can continue communicating with user 230. In this example, television 220 also lacks a user interface for receiving user input to initiate additional media transfers. Accordingly, the IUT controller state remains on laptop 218 so that user 214 can transfer the video portion of the video conference from television 220 to another device. If the IUT controller state were to be transferred to the legacy television 220, there would be no mechanism for transferring the conversation to another device because the legacy television 220 does not provide an appropriate user interface for initiating such a transfer: the video portion of the conversation would not leave the legacy television 220.

Depending on the system implementation, various policies and restrictions may be applied to the number and combination of UEs that can be established for each user. For example, the network may implement restrictions that specify that only one UE with IUT controller capability can become an IUT controller; or that multiple UEs with IUT controller capability can become IUT controllers for any collaborative session; or that multiple UEs with IUT controller capability can become IUT controllers for all collaborative sessions, but only one IUT controller UE for the same collaborative session. In addition, the preferred bearer (e.g., circuit switched or packet switched) may be specified by network rules, user preferences, or a combination thereof. For example, the preferred bearer setting may depend on the media type and device capabilities, such as circuit switching for voice media type sessions and packet switching for video type sessions.

The network (e.g., SCC AS) may also use the following indications for charging purposes: an indication of which UE is the IUT controller, an identity of the UE performing the IUT controller function, an indication of the subscription set for IUT (indicating the set of UEs belonging to the same subscription), and a bearer indication (different charging may be applied depending on the bearer used).

In this system, each UE can be configured to communicate with the network (e.g., via an SCC AS or another component of the communication network) to indicate to the network (in this example, the SCC AS) whether the UE supports IUT controller functionality. In one implementation, the UE sends its capabilities to the SCC AS using, for example, a SIP message including a SIP method or SIP response, or Extensible Markup Language-Configuration Access Protocol (XCAP), or web services (e.g., using SOAP or HTTP). SIP methods include SIP REGISTER, SIP PUBLISH, SIP SUBSCRIBE, SIP NOTIFY, SIP INVITE, SIP RE-INVITE, SIP UPDATE, SIP OPTIONS, and SIP REFER. One way for the UE to send its capabilities to the SCC AS is to use a media feature tag, such as g.3gpp.iut in the Contact header. For example, SIP methods including a Contact header (e.g., SIP REGISTER, SIP SUBSCRIBE, SIP NOTIFY, SIP INVITE, SIP Re-INVITE, SIP UPDATE, SIP OPTIONS, SIP PUBLISH, and SIP REFER) can be configured to include an IUT controller media feature tag to indicate that a specific UE supports the IUT controller function. Alternatively, a SIP response (e.g., SIP 200OK) can also include a Contact header that can be configured to indicate the UE's controller capabilities.

When implemented using the Contact header, the IUT Controller feature tag may include, for example, three possible values (since the system may use other values with various names and attributes, only exemplary values are described). First, the value "Active" may indicate that the UE with the contact address associated with the IUT Controller feature tag is currently acting as the IUT Controller for the session. Second, the value "Inactive" may indicate that the UE with the contact address associated with the IUT Controller feature tag is currently acting as the IUT Controller for the session (i.e., not the active IUT Controller), but is capable of being assigned the IUT Controller role. Third, the value "Passive" may indicate that the UE with the contact address associated with the IUT Controller feature tag is currently acting as the IUT Controller for the session and is unable or unwilling to accept the IUT Controller role. Passive may also mean that the device can act as a controller, but does not have controller functionality.

In some implementations, the IUT controller indication may include two possible values for any specific UE, such as (Active, Inactive) or (Active, Passive). Example value definitions may include: g.3gpp.iutcontroller = "active" or g.3gpp.iutcontroller = "passive". In some cases, the IUT controller value is placed before the version indicator. For example, the IUT controller value may be "ActiveX", where X can be a value from 0 or 1 to Y, and Y indicates the version of IUT supported by the UE. Another example is g.3gpp.iut = [capability], where capability indicates the capabilities of the IUT device, such as whether it is a "controller" or a "controller". The controller may be extended to "activecontroller" or "passcontroller". An active controller means that the SIP UA/UE is performing controller actions for the session, while a passive controller means that the SIP UA/UE has controller capabilities but is not acting as a controller. Example definitions of feature tags are provided below in Table 4, however those skilled in the art will appreciate that any construction of appropriate alphanumeric characters may be used to convey the same meaning from a SIP UA/UE.

Table 4

In other implementations, a user can use SIP, XCAP, or the like to configure a UE supporting the IUT controller function to activate or deactivate the IUT controller settings based on user preferences. For example, the activation or deactivation settings for the IUT controller UE or the controlled UE can be placed in the XML MIME body of a SIP or XCAP message. If the IUT controller setting is activated on the UE, the UE acts as an IUT controller UE. If the IUT controller setting is deactivated on the UE, the UE acts as an IUT controlled UE. The following is an example of setting the IUT controller function for a specific UE in XML format:

In addition to informing the network whether a specific UE has the capability or is willing to act as a controller UE, the present system allows a UE that supports multiple bearers to be configured to indicate the user's preferred bearer to the network, and the network stores information such as UE capabilities and user preferences. Depending on the UE, the UE may have the ability to communicate with the network using, for example, circuit switched and/or packet switched communication protocols. For a UE that supports multiple bearers, the preferred bearer may be specified by user preferences via SIP, XCAP or other encoding schemes. In one implementation, the preferred bearer is specified based on the specific media type and/or device capabilities. For example, a specific bearer may be specified for a specific media type on a device with specific capabilities. Alternatively, a general bearer preference may be specified for all UEs, regardless of the media type and/or device capabilities. For example, the bearer preference may be specified in the XML MIME body of a SIP or XCAP message. An exemplary encoding in XML form is shown below.

Upon receiving a message indicating UE capabilities and (optionally) user preferences regarding preferred bearers for the UE, if the message includes support for IUT controller functionality on the UE and a preference to use the UE as a controller, one or more network components, such as a call session control function (e.g., P-CSCF, S-CSCF, I-CSCF), a mobile switching center (MSC) server, an enhanced MSC for ICS, or an SCC AS, may verify that the UE is allowed and capable of acting as a controller. In one embodiment, if the received message includes supported bearer types and/or a preference to use a specific bearer type, the SCC AS may also verify that the UE supports a specific bearer and is registered for the specific bearer.

During authentication, the SCC AS determines which UE(s) will act as the controller, for example, by examining the IUT Controller media feature tag in the Contact header of the SIP REGISTER request. In one implementation, the SCC AS obtains the media feature tag using a subscription registration event package or an enhanced third-party registration procedure (including an incoming SIP REGISTER request in the body of a third-party SIP REGISTER request). The SCC AS may also determine the bearers available for the registering UE. If the preferred/supported bearer value in the network's policy differs from the preferred/supported bearer value in the received message, the preferred/supported bearer value defined by the network policy may be used instead. Using the above process, a request may be routed over a specific access segment or preferred bearer using a specific access technology.

In order to verify that the UE meets specific requirements for controller function assignment and/or specific bearer assignment, the network maintains a database that stores the user's public user identity (e.g., Tel URI, SIP URI, etc.), the user's private user identity (e.g., IMS private user identity, IMSI, etc.), which UEs (e.g., instance ID, IMEI, MIN, or GRUU) belong to the same subscription set, which UEs belong to the same IUT, which UEs are capable of IUT controller functions, device identities (e.g., instance ID, IMEI, MIN, globally routable UAURI (GRUU)), a device nickname mapped to each device, session segment mapping information connected to each device, supported or preferred bearers or radio access technologies (RATs) on each UE, an address identifying each UA per RAT for a UE or an intermediate device (which supports multiple PS access technologies or multiple subscriptions or peer-to-peer (P2P) services and has at least one UE per RAT or subscription or P2P service), authorization rules for granting another UE the controller function, and other information describing or associated with the UE. The database may be stored in the HSS and accessed by the SCC AS using the Sh interface or using information received from the S-CSCF as a result of registration. The database may be stored in another entity within the network. It may be within the SCC AS or in conjunction with it. In one implementation, in order to perform a registration action, the network may check the IRS used for the UE in the database to see if the UE requesting registration has the same IRS set as the authorized UE. If the IRS set used by the registering UE is the same as the IRS set of the authorized UE stored in the database, the IRS set may indicate the specific capabilities described by the IMS private ID and whether the UE is a controller or a controlled. In addition, the IRS set may indicate whether the UE can only be controlled and whether the UE can subscribe to and unsubscribe from services.

During operation of the present system, the network node distributes a list of URIs or identities of IUT UEs (i.e., a set of URIs or identities of UEs that can request or be transferred to an IUT, or a set of URIs of controller and controllable UEs belonging to the same IUT set) to a controller UE or a set of IUT UEs, allowing identification of which UEs are controllers or controllables, which UEs support IUT controller functionality, and to which UE the IUT controller functionality can be transferred. The list of URIs or identities of IUT UEs may include information such as device nicknames, media types supported by each URI or identity of each IUT UE, and the like.

When a UE registers with the network, it will include the signature described above. As part of the registration process, the UE's GRUU is stored. This GRUU is then transmitted as a URI to all potential controller UEs. The information sent may also include an identification of whether the UE, identified by the GRUU, is an IUT controller, a controller (passive role) and a controllable, has controllable capabilities, or has legacy capabilities. If the UE is acting as a controller, supported media types, registered RATs, etc. may also be transmitted to assist the UE. If a device performs a re-registration and the media signature (including, for example, the registered RAT) has changed, this may result in a refresh of the information sent to UEs with IUT controller capabilities.

As shown in Figure 3, the UE registers with the IMS network in step 301, which results in registration with the SCC AS. The SCC AS needs to determine whether the registered device is part of the IUT set. This can be determined by the SCC AS being aware of the presence of one or more IUT-capable UEs in the same IRS. If the SCC AS can make this determination at Y in step 302, it will communicate with the OMA DM server in step 303. In step 304, the SCC AS may include the necessary identifiers in the OMA DM server so that the OMA DM server can transmit information to the necessary device or other devices requiring the information. This may include an instance ID and a list of device identifiers, which will have been obtained during the registration process. In some cases, if the ICS UE has an IMEI, the ICS UE generates an instance ID based on the IMEI before performing registration, as defined in 3GPP TS 23.003.

In another implementation, there may be some form of IUT group identifier sent when the UE registers (see example in Table 5) that identifies the IUT group, allowing subscribers from different IRSs to be in the same IUT group. In this case, the SCC AS will check when the UE registers if it is part of an IUT set. One possible embodiment of the IUT group identifier may be a new media feature tag or an extension of a previously defined media feature tag. For example, 3.gpp.iutgroup = [variable].

Table 5

In one implementation, when distributing the list of URIs or identifiers of IUT UEs, the address of the serving SCC AS may also be included and provided via Open Mobile Alliance Device Management (OMA DM), Client Provisioning, or other device management and provisioning protocols. To distribute the list of URIs or identifiers of IUT UEs, the network may use over-the-air mechanisms such as, but not limited to, Unstructured Supplementary Service Data (USSD), Short Message Service (SMS), Multimedia Broadcast Multicast Service (MSMS), Cell Broadcast, IP pipes running over GPRS in GERAN, UTRAN, LTE, WLAN, WiMax, or CDMA2000. The identifying URI may be a TEL URI (E.164 number), a SIP URI containing a public user identity, or a Globally Routable User Agent URI (GRUU). The list may also be provided in a removable memory module, including, but not limited to, a USIM, SIM, R-UIM, UICC, or compact flash. Alternatively, other configuration management mechanisms may be used, for example, the SIP CONFIG FRAMEWORK as described in draft-ietf-sipping-config-framework.

The list of URIs or identifiers of IUT UEs can be updated periodically, or aperiodically by broadcasting, sending, or transmitting the list, broadcasting updates, or by each controller UE requesting the updated list only when the list changes or is updated. Alternatively, the list can be updated by transmitting updated information directly to each UE, for example, via a user interface, or by providing physical media containing the updated list to the UE. The list of URIs on the UE is updated when other UEs belonging to the same IUT group that can use the IRS set register or deregister. Updating the list of URIs or identifiers of IUT UEs can be important because UEs can be added (or registered) to/removed (or deregistered) from serving network entities, such as an HSS, S-CSCF, or SCC AS in the serving network (e.g., S-CSCF, HSS, or SCC AS). Updates can include deleting, adding, or modifying entries as described above. A network node, such as an SCC AS or a DM server, provides the list of URIs or identifiers of IUT UEs.

FIG4 illustrates an exemplary allowed IUT list management object for identifying one or more IUT UEs. MO 440 includes a root node 442, which can serve as a placeholder for zero or one fixed node accounts. An AllowedIUTEntries internal node 444 can be used to provide a reference to a list of subscription set IDs and can include a runtime node 446 as a placeholder for one or more subscription set IDs. The runtime node 446 can include a reference to a URI or identifier for one or more IUT UEs, device nicknames, and/or media tokens. An additional runtime node 450 can serve as a placeholder for an IUT_URI (i.e., the URI or identifier for each IUT UE), a device nickname, or a media token dataset. The runtime node 450 can include leaves 452, 454, and 456 for storing IUT_URIs, device nicknames, media tokens, or other data.

If only one subscription set exists for a UE, the illustrated nodes may not be present in the MO. The illustrated nodes may be added for scalability purposes, for example, if a user has multiple subscription sets for an IUT UE. Various nodes may be included in the MO (not necessarily required), such as (but not limited to): an IUT URI (i.e., the URI or identifier of the IUT UE) node corresponding to the IUT URI in the MO, a Device Nickname node, or both. A Media Token node for the device may also be included in the MO. Figures 5a and 5b illustrate the parameters and DDF details of the Allowed IUT List MO shown in Figure 4. An Elementary File may also be used to distribute the list of URIs or identifiers of IUT UEs. An exemplary Elementary File (EF) is provided below and may be used to provide definitions for the Allowed IUT List (EFAIUTL), IUT Device Nickname (EFIUTDN), IUT Media Token (EFIUMT), and IUT Controller Indication (EFIUTCONTI). When used in this manner, the EF may be included in, for example, a USIM, SIM, R-UIM, UICC, or high-density flash memory.

The first example EF includes an EF _AIUTL (Allowed IUT List), which is shown in Table 6. The EF may contain an encoding of the IUT URI (i.e., the URI or identifier of the IUT UE) (or device nickname) of the UEs belonging to the Allowed IUT List. In addition, for each IUT URI (or device nickname) in the list, a link to the corresponding device nickname (or IUT URI), media token, and IUT controller indication may be provided. The Allowed IUT List TLV object may include one or more IUT List TLVs, each of which is associated with one or more of a TEL URI, a SIP URI, a GRUU, an Instance ID, an IMEI, etc. Example Allowed IUT List information is shown below in Table 7.

Table 6

Table 7

In Table 7, the content of the IUT List tag '80' may include an allowed IUT list for each IUT subscription set, which may be applied to one or more of the following provided in the value field of this TLV: TEL URI, SIP URI, GRUU, Instance ID, IMEI, etc.

An example encoding for an IUT List Tag '80' is shown in Table 8. In this example, unused bytes may be set to a value of 'FF'.

Table 8

Another exemplary EF includes the EF _IUTDN (IUT Device Nickname) shown in Table 9. The EF can be configured to contain the IUT Device Nickname. In this example, the association between the IUT URI and the corresponding device nickname is provided in the EF _AIUTL . Generally speaking, in this example, the encoding can be performed using one of the UCS2 encoding options defined in TS 31.101.

Table 9

Another exemplary EF includes the EF _IUTMT (IUT Media Token) shown in Table 10. This EF contains the IUT Media Token. In this example, the association between the IUT device URI and the corresponding media token is provided in the EF _AIUTL .

Table 10

For this EF, an example IUT Media Token tag is shown in Table 11.

describe Tagged Value IUT Media Token '80s

Table 11

For this EF, example IUT Media Token information is shown in Table 12.

Table 12

In the example shown in Table 12, the IUT Media Token tag '80' may have the content of the IUT Media Token, such as text, video, audio, etc., and may be encoded using one of the UCS2 encoding options defined in TS 31.101.

Another example EF includes the EF _IUTCONTI (IUT Controller Indication) shown in Table 13. This EF may contain an IUT Controller Indication. An association between an IUT URI and a corresponding IUT Controller Indication is provided in the EF _AIUTL . The IUT Controller Indication may be provided in text format or icon format.

Table 13

In this EF, the indicator state for each indicator type can be 1 bit long and can be encoded or set as follows. If the bit value is equal to 1, the indication is set to active. However, if the bit value is equal to 0, the indication is set to inactive. For example, Figure 23 is an illustration of an example indicator with reference bit value positions.

In the absence of other useful information besides the URI or identity of the IUT UE, a list of URIs or identities of the IUT UE is defined and made available. In this case, the IUT UE can collect information about other identified UEs or unilaterally take action to modify the list by communicating with the SCC AS or other components of the network. In one example, the IUT controller UE sends a SIP OPTIONS to the UEs identified in the list to determine the capabilities of the other IUT UEs (e.g., by using the IUT controller feature flag received in the 200 OK response) and discover which IUT UE(s) are currently available and have IUT capabilities, as well as which IUT UE(s) can have the IUT controller functionality transferred to them. Via a message such as a 200 (OK) response returned in response to a message such as a SIP OPTIONS request, the IUT controllable UE can obtain the capabilities of the other UEs, including a media feature flag indicating support for the IUT controller/controllable functionality.

Once a list of URIs or identifiers for IUT UEs has been determined and optionally updated, a database within the network (e.g., stored in an SCC AS, HSS, etc.) can store information identifying the controller UE and the controllable UEs. This information can be stored in any suitable medium, such as a computer database or other electronic storage medium. The database can include any suitable table structure based on system requirements. FIG21 is an illustrative diagram of an exemplary structure for storing information describing associated controller and controllable UEs within the network (e.g., within a Home Subscriber Server (HSS)). In FIG21 , user A has three devices belonging to an IUT set, and device 1 is an IUT controller. The remaining devices operate as IUT controllable UEs.

Figure 22 is an illustrative diagram of example information stored in the network (e.g., within the HSS). Figure 22 shows data for three users, each of which is in the same subscription member set. In the table below, User A and User B have IUT controller functionality and can establish IUT authorization rules, while User C acts as an IUT controller.

Within the table, a subscription set is a collection of UEs of the same user for IUT purposes, based on the same subscription or different subscriptions (where the different subscriptions are governed by a roaming agreement). A subscription member set is a collection of UEs between members that are allowed to transfer between UEs, which can belong to the same operator subscription or different operator subscriptions governed by a roaming agreement. Within the table, for an IUT UE set, each UE is distinguished as either an IUT controller UE or an IUT controllable UE. Each UE has a device ID, such as a GRUU, instance ID, or IMEI, which can be mapped to a nickname (e.g., "Bedroom TV," "My Mobile," etc.). In addition, for each UE, the table defines the UE's ability to support specific media types and formats.

Depending on the system implementation, information describing the controller and controlled UEs may be stored in various network components. For example, authorization rules may be stored in the XDMS, and a document link to the authorization rules stored in the XDMS may be stored in a subscription database. In one example, a link to a media token for each device or various authorization rules for IUT control is stored in a database or another network entity.

The network can perform subscription set binding for implementing IUT. Depending on the inter-operator agreement (exchange of subscriber information and subscriber device information between networks), subscription sets can be with the same operator or between different operators. The system can support IUTs with the same subscription set. The same subscription set should be indicated as a "subscription set indication" for the IUT on the network, and this indication can be provided to UEs with the same subscription set in a memory (e.g., ME, USIM, or ISIM).

The network should also have the ability to store a "most recent preferred configuration." For example, if a user has split a video call session between two UEs (voice on the device with ID I, video on the device with ID II) on an initial call, the network can be set to persist that configuration for subsequent video calls that result in the call being terminated on multiple UEs.

The network should also be able to store the "UE that most recently served as a controller." For example, at the time of initial communication, for a collaborative session, UE-1 served as the IUT controller, while UE-2 served as the IUT controllable UE. After the initial communication is terminated and a new collaborative session is established, UE-1, which was previously the controller UE, becomes the controller UE based on information configured in the network as follows: For subsequent new communications after the previous communication is terminated, the most recent controller UE configuration is maintained.

When a UE registers with a network, the UE will send information identifying the UE to the network. The registration information may include a request to assign a controller function within the network to the UE. In one example, the UE provides the network with an IMS private identity, an IMS public user identity, and an instance ID of the UE for identification purposes, as well as a feature tag that previously identified the UE as having IUT controller capabilities. The registration information may be provided to the SCC AS, which may then verify the registration information. The SCC AS may then query a database that stores information about the UE and its subscribers to determine whether the subscriber and/or UE combination is allowed to act as a controller. The database may be local or external. Example external databases include an HSS and an internal database in the SCC AS. The registration information may be sent using the Sh interface or via the ServiceInfo field of the Cx interface.

By checking the combination of the above-listed identification information, the SCC AS can determine whether the UE is authorized to become a controller. Accordingly, the SCC AS can check the private ID if all devices are allowed to become controllers, or check the private ID and IMEI if only devices using the private ID can be controllers. Alternatively, if a controller can only be registered by combining the private ID with the device (IMEI) and public user ID, the SCC AS can check the private ID, IMEI, and public ID.

In some implementations, after registering a UE, the SCC AS provides the UE with a token, flag, or indication to be used in subsequent SIP methods to identify the UE as authorized to act as a controller. The token or indication can be included in a signature tag, a new P-header, or an XML body. Alternatively, the SCC AS can mark the UE's registration record in the SCC AS as capable of acting as a controller UE. Thus, when the UE sends an INVITE or another SIP method, the SCC AS can check its bindings to determine whether the UE is capable of performing controller functions.

The system may also perform additional checks to determine if a device in the system is already acting as a controller, and when another device requests controller functionality, the system may deny the request and provide an indication to the device (which may include an out-of-band signaling mechanism), or accept the request based on the above rules.

Controller functionality for a specific UE can be restricted to controlling other UEs operated by the same user associated with the controller UE. However, in some implementations of the present system, a specific controller UE for one user can have controller functionality for other UEs belonging to other users, where the specific controller UE and the other UEs are under the same subscription membership. In this case, the specific UE can provide a mechanism that allows the user to set authorization rules that authorize a target UE that has requested execution of the controller functionality to perform the controller functionality, and the network (e.g., SCC AS or XDMS) can process the authorization rules and determine whether to allow the target UE to perform the controller functionality. In other implementations of executing the controller functionality, the UE may be required to obtain approval from an existing controller UE or from one or more target UEs that the controller UE has assigned. In some cases, any target UE in the wireless server can be authorized to perform the controller functionality. The UE can perform the controller functionality based on temporary restrictions, functional restrictions (e.g., only allowing transfer of specific media types), or can be permanent. Any controller UE can be assigned to set temporary permission rules, functional permission rules, or other permission rules for transferring controller functionality to UEs operated by other users.

Figure 6 illustrates an example process for providing IUT controller functionality to a UE, where authorization is requested only from a single controller UE. In step 601, the controlee UE sends a request message to the network to receive the IUT controller functionality. In step 602, the server (e.g., using an S-CSCF or SCC AS) queries authorization rules stored on the server itself or in another network entity (e.g., an XDMS) configured by the controller UE and finds that no temporary, functional, or other restrictions are imposed on the assignment of the IUT controller functionality, and that authorization of the IUT controller assignment requires authorization only by the controller UE. In step 603, the network sends a request message to the controller UE authorizing or approving the target controlee UE to receive the controller functionality. In step 604, if the controller UE user accepts the request, the controller UE sends an OK response. In this step, the controller UE user can set temporary/permanent permissions. In some cases, these restrictions on temporary/permanent permissions are predefined within the network. In step 605, the server sends an OK response, granting the controller functionality to the controlee UE. The OK response in step 604 may be different from that in step 605. The server may include in the response: a) a temporary or permanent password, and b) a token, identifier, or certificate that allows the target controllable UE to obtain controller functionality. If the target UE receives only temporary permission to act as an IUT controller, the temporary password may become invalid when the target UE releases or leaves the current session, or when the target UE exits a program that provides a user interface for changing some settings or parameters on the controllable UE, and thus the target UE will not retain the IUT controller functionality.

Figure 7 illustrates an example process for providing IUT controller functionality to a UE, where authorization or approval is requested only from multiple controller UEs. In step 701, a controllable UE sends a request message to a server to receive the IUT controller functionality. In step 702, the server identifies a UE with an existing IUT controller functionality, searches the authorization rules set by the identified controller, and discovers that the server requires authorization or approval from one or more users (or user UEs) with the IUT controller functionality. Users can designate themselves and/or users with controller functionality. In step 703, the network sends a request message to the controller UE to authorize the target controllable UE to receive the IUT controller functionality. In step 704, if the designated user accepts the request, the designated user's UE sends an OK response. When authorizing provision of the IUT controller functionality, the designated controller UE can set various permissions or restrictions. Alternatively, the user with the controller UE can define various temporary permission restrictions, functional permission restrictions, or permanent permission restrictions and communicate them within the network. In step 705, if all designated users authorize the controller functionality, the server sends an OK response. The OK response in step 704 may be different from that in step 705. If the controller UE has set permissions or other restrictions on providing the IUT controller function, the network includes these restrictions when issuing authorization to the target controller UE. If the target UE only receives temporary permission to act as an IUT controller, when releasing or leaving the current session, or when exiting a program that provides a user interface to change some settings or parameters on the controlled UE, the temporary password may become invalid, and thus the target UE does not retain the IUT controller function.

Depending on the system implementation, the IUT controller UE may be determined before a session is established, during the session establishment process, or after a specific session has been established. In some cases, the UE that is capable of supporting the IUT controller functionality and sends the initial transfer request is initially designated as the IUT controller UE. If the IUT controller UE is determined before a session is established, the UE may request assignment of the IUT controller functionality based on the UE's capability to operate as an IUT controller UE and associated user preferences. The UE may allow the user to assign only one UE as the active IUT controller from a list of available URIs or identifiers of IUT UEs. Different IUT controller settings may be established for different UEs of the same user. If the IUT controller is assigned at session establishment, as described above, the UE may send a session establishment request, such as a SIP INVITE, SIP Re-INVITE, or SIP REFER request, with the IUT controller feature flag set to "Active."

In some cases, the SCC AS can ensure that all terminating Invites for sessions are routed to the UE that is the IUT controller by including a media feature tag in the Accept-Contact header indicating the IUT controller according to RFC 3841.

In some cases, it may be desirable to assign a single IUT controller UE for any ongoing session. Therefore, to ensure that the system only assigns a single IUT controller UE, upon receiving a request to assign IUT controller functionality to a particular UE, the network may verify the following: the requesting UE has IUT control capabilities (e.g., the presence of a media feature tag in the contact header indicating IUT controller capabilities); the requesting UE is authorized to act as an IUT controller (authorization may be achieved by checking the IMS private user id associated with the UE's registration to see if controller functionality is allowed, as described above); there is a policy from a network node (SCC AS or policy database) that only one UE should be the IUT controller for all ongoing sessions; and there are no other assigned IUT controller UEs for the same user. If all of these conditions are met, the network sends an affirmative response that the requesting UE is to become the IUT controller. The network may send an indication to other IUT UEs specifying which UE (e.g., using a GRUU) has been assigned the IUT controller functionality. This can be achieved by the UE subscribing to notifications and, when a controller has been assigned, sending a notification to the UE containing the controller's GRUU. If one or more of the above conditions are not met, the network may reject the request. In the rejection request, the network may include a reason code explaining the reason for rejecting the request.

When registering a specific UE as a controller, it is important to provide an authentication or authorization mechanism to ensure that controller functionality is assigned only to authorized users and/or authorized UEs. In one example, in addition to user subscriptions, the IUT subscription is a family subscription. The family subscription may include subscriptions for the father, mother, and children. In this example, authorization functionality in the network can be used to verify that a specific UE is permitted to act as a controller UE within the family subscription. One example network implementation provides two separate authorization levels.

First, the network determines whether the device being subscribed is allowed to belong to the same subscription member. This can be the result of filtering criteria, however, again, this is done by the SCC AS, so other filtering criteria can send SIP methods to that AS. There may be information in the Service Info field from the HSS that goes transparently to the SCC AS, indicating whether it has IUT capabilities as a result of the UE performing SIP REGISTRATION. For example, in some cases, there may be information in the SCC AS that determines whether the device being subscribed is capable of performing controller functions. Alternatively, this information can be provided via the IMSI or private identity. For example, all family members belong to the same personal network, but only the father has the ability to set his device as a controller for the mother and the children's other devices.

Next, the SCC AS determines whether the registering UE is allowed to become the IUT controller. This can be done by examining the GRUU information of the registering UE. This information can also be stored within the HSS or SCC AS, allowing the subscriber to indicate which device can be the controller. Alternatively, it is possible to link this information to the registration message, where a private ID is present when the UE registers. This private ID can be used to determine whether the UE is capable of using IUT. Capabilities such as IMSI private IDs can be "assigned controller" or "controlled." Therefore, any UE originating from a private user ID with an "assigned controller" is allowed to set that UE as the controller.

An IMS private ID that can access the IRS can have a specific profile. For example, a family subscription can include four IMS private IDs: the father, the mother, and two children. The father is the only one allowed to assign a controller. There are all identical subscription members, which can be called a subscription member set.

Assuming two IMS private IDs can designate a controller for a group, one IMS private ID must have override authority, or if you are allowed to be the controller, you will be notified if another UE becomes the controller. If you are the current controller, you can reject or allow the change. This requires subscribing to status notifications within the network and, upon receiving notification that the network has specific policies, asking the other controller whether control capabilities can be changed.

The IUT controller UE may be determined before session establishment, during session establishment, or when requesting an IUT controller transfer function to another UE. When the IUT controller UE is determined before session establishment, the UE sends a request for IUT controller functionality based on the UE's capabilities and user preferences. The UE may allow the user to assign multiple UEs as active IUT controllers from a list of URIs or identifiers of IUT UEs. When the IUT controller UE is determined during session establishment, and when any UE with IUT controller capabilities requests an IUT controller function transfer to another UE, the UE sends a request with a media feature tag indicating the IUT controller function, such as a SIP INVITE, a SIP re-INVITE, or a SIP REFER request. The media feature tag may be an IMS Communication Service Identifier (ICSI) value or an IMS Application Reference Identifier (IARI) value that identifies the IUT controller function to be transferred. When the network receives the request, the network checks that: the requesting UE is capable of acting as an IUT controller; the requesting UE is authorized to act as an IUT controller (e.g., by checking the IMS private user id associated with the UE's registration to see if controller functionality is allowed); and that there are multiple policies (e.g., from a policy database) for the UE to become an IUT controller for any ongoing session or for the same collaborative session.

If all of the above conditions are met, the network sends the following affirmative response: the requesting UE is to become the IUT controller. The network may send an indication to other IUT UEs (e.g., using GRUU information) of which UE is the IUT controller. If one or more of the above conditions are not met, the network may reject the request and optionally provide a reason code explaining why the request was rejected.

When established as an IUT controller UE, the controller UE can request the network to transfer media types to a specific controlled UE or to transfer IUT controller functions to another UE. In order for the IUT controller UE to transfer media and/or controller functions to a controlled UE, the IUT controller UE sends a message (e.g., a SIP REFER request) to the network (e.g., an SCC AS). The SIP REFER request may contain another message embedded within the URI in the REFER-TO header, such as at least some of the SIP header and/or SDP content of a SIP INVITE request or SIP Re-INVITE request, which the SCC AS is to send to the controlled UE identified by the URI in the Refer-To header. The SIP INVITE request or SIP RE-INVITE request sent to the controlled UE may contain data identifying the media types to be transferred to the controlled UE. To allow the controlled UE to determine that control is being transferred to it, the SIP INVITE request also includes an identifier that identifies the IUT controller function. The identifier may include: a) a URI identifying the IUT controller function in a SIP header field; b) a new SIP URI parameter (i.e., an IUT controller URI parameter) in the Request-URI or the URI in the TO header; c) a media feature tag indicating that the IUT controller is to be included in the Accept-Contact header (per RFC 3841); d) an IMS Communication Service Identifier (ICSI) value or an IMS Application Reference Identifier (IARI) value identifying that the IUT controller function should be transferred, for example, by including a "g.3gpp.app_ref" feature tag in the Accept-Contact header (note that, per RFC 3840, the UE had previously registered the media feature tag in the Contact header of the SIP REGISTER request at registration); or e) a new SIP header field indicating the IUT controller function (e.g., a P header per RFC 3427). In another implementation, the 3.gpp.iut feature tag may be extended with additional options to identify that the controller function is being transferred. An example embodiment is included below in Table 14.

Table 14

Other embodiments may also include the UE setting the media feature flag to "controller" when executing a request to transfer controller functionality. When the SCC AS receives the request, it checks the status of the UE from which the message was received. If the UE's status is assigned as a controller, the UE knows that it intends to transfer controller functionality to the target device identified in the message. When the SCC AS sends the message to the target device, the message may include a token or identifier identifying that the controller functionality is being assigned to the UE.

The example in Figure 8 below shows a process for transferring IUT controller functions and/or media types from a first controller to another UE at the request of an IUT controller UE. In the example, UE-1 has a multimedia session established with a remote party, which is anchored at an SCC AS. The multimedia session contains two media components (Media A and Media B), and UE-1 wants to transfer collaborative session control and one of the media types (Media A) to another UE-2. In the example, UE-1 and UE-2 may have registered using the same access network bearer or different network access bearers. UE-1 and UE-2 may use different Internet Protocol-Inter-Network Connections (IP-CANs), for example, a 3GPP IP-CAN on UE-1 and a non-3GPP IP-CAN on UE-2. The anchored SCC AS or another network entity can determine which bearer to use for each UE. It is assumed that UE-1 and UE-2 belong to the same subscriber.

Whenever a UE acquires IP connectivity via an IP CAN, it can register with the IMS as defined in TS 23.228. In this case, the user profile contains a CMSISDN bound to an IMS private user identity. The S-CSCF can follow the procedures defined in TS 23.218 for performing third-party registrations with the SCC AS. When using CS access for media, the UE can register with the IMS as specified in TS 23.292. When registering with the IMS as defined in TS 23.228, the UE can indicate its ability to support IUT controller or controllable functions. An example SIP REGISTER request for the S-CSCF performing a third-party registration with the SCC AS is shown below in Table 15.

Table 15

Figure 8 illustrates a process for transferring IUT controller functionality to a UE at the request of an IUT controller UE. In step 801, UE-1 decides to transfer collaborative session control and media type (Media A) to UE-2. UE-1 sends a request to the SCC AS, indicating that the current collaborative session control and media type (Media A) will be transferred to UE-2. In step 802, the SCC AS (or any other network component) recognizes the transfer request, verifies that UE-2 is allowed and capable of acting as a controller, verifies that UE-2 has registered the appropriate capabilities (e.g., feature flags according to RFC 3840), determines which bearer to use for UE-2 based on device capabilities, user preferences, and/or network policies, and determines whether UE-2 has already registered the selected bearer. In step 803, the SCC AS generates and sends a Session Establishment Request message to UE-2 using the Gm or I1 reference point, or other data transfer method, indicating that the collaborative session control and media type (Media A) will be transferred. In step 804, collaborative session control is established between UE-2 and the SCC AS. UE-2 becomes the controller UE for the established collaborative session. In step 805, a session for transmitting media type (Media A) between UE-2 and the remote party is established. At this point, the remote leg is updated accordingly. After collaborative session control and media type (Media A) are successfully established on UE-2, in step 806, the SCC AS sends a response message to the transfer request message or another message notifying UE-1 of the result of the transfer request message (e.g., a SIP NOTIFY request sent in response to the final response received as a result of a SIP REFER request, in accordance with RFC 3515). Finally, in step 807, the media type (Media A) session previously on UE-1 may be released, along with collaborative session control. At this point, UE-1 becomes the controlled UE.

Figure 9 shows a flow chart for transferring IUT controller functionality from UE-1 to UE-2, where an incoming session request is transmitted over the Gm reference point and media is sent via a circuit-switched network. An MSC server enhanced for ICS can be an exemplary interworking entity for implementing the illustrated process. Alternatively, the interworking entity can include a traditional MSC server and MGCF. When the interworking entity corresponds to the MSC server and MGCF, the CS bearer establishment procedure follows steps 11-17 of Figure 7.4.2.2.2-2 of TS 23.292.

9 , in steps 901 and 902 , UE-1 decides to transfer collaborative session control and media A to UE-2. Therefore, UE-1 sends a request to the SCC AS via the IMS entity, indicating that the current collaborative session control and media A will be transferred to UE-2. In this example, the IUT controller UE may initiate a transfer request via, for example, a SIP REFER, by sending a request with the following information: 1) source UE (may be included in a From header field, a P-Asserted-Identity header field, or a P-Served-User header field), 2) target UE (may be included in a Refer-To header field), 3) IUT controller transfer indication (may be included in an Accept-Contact header field, e.g., embedded in an INVITE request or embedded in a Refer-To header field), 4) Target-Dialog-ID (may be included in a Target-Dialog header field containing an existing dialog identifier if the target UE is already part of a collaborative session, and no Target-Dialog-ID when this is a new session for the target UE), and 5) media type (e.g., audio, video, file, etc.) (e.g., included in a Refer-To header field).

In step 905, the SCC AS identifies the request (e.g., a SIP REFER request), verifies that UE-2 is allowed and capable of acting as a controller, verifies that UE-2 has registered appropriate capabilities, such as: feature flags according to RFC 3840; what bearer to use for UE-2 based on device capabilities, user preferences, and/or network policies; and whether UE-2 has registered the selected bearer. If UE-2 is not allowed to act as a controller, the SCC AS may reject the request. If UE-2 rejects the collaborative session control transfer, an appropriate response indicating the rejection is sent. The response may indicate the reason for rejecting the transfer. When the provided media type or code is unacceptable, such a response may be a SIP 488 (Not Acceptable Here). A warning may be included in the response indicating the reason for the failure. The message to UE-1 indicating the transfer failure may be included in a SIP NOTIFY request, which includes a SIP fragment of the response from UE-2 (e.g., a SIP 488 (Not Acceptable Here) response) in the body.

In steps 906 and 907 , if the message received in step 905 includes media transfer for audio or video, the SCC AS generates and sends a session establishment request message to UE- 2 . The session establishment request message (e.g., a SIP INVITE request or a SIP re-INVITE subsequently sent to receive a SIP REFER) includes the following information: 1) source UE (which may be included in the Referred-By header field and the P-Asserted-Identity header field, the P-Preferred-Identity header field, or the P-Served-User header field), 2) target UE (which may be included in the To header field and the Request-URI field), 3) IUT controller transfer indication (which may be included in the Accept-Contact header field), 4) Target-Dialog (which may be included in the Target-Dialog header field containing the existing dialog if the target UE is already part of a collaborative session, and no Target-Dialog if this is a new session for the target UE), and 5) media type (e.g., audio, video, file, etc.) (which may be included in the SDP embedded in the invite request). The request may also include the PSI DN to be used for CS call establishment, which identifies the session. If the SDP contains an M line allowing bearer establishment over CS, UE-2 sends a CS call setup message to the interworking entity in step 910, using the PSI DN as the B-number. In step 911, the interworking entity (e.g., an MSC server enhanced for ICS) responds with a call proceeding message and begins establishing the CS bearer control signaling path. In steps 912 and 913, the interworking entity sends a SIP INVITE to the SCC AS via the IMS entity. When the SCC AS receives the INVITE in step 913, it can retrieve session information using the PSI DN. In step 916, when the interworking entity receives a SIP 200 OK response from the SCC AS via the IMS entity, the interworking entity maps the received SIP 200 OK response into a CONNECT message and sends it to UE-2. Upon receiving the CONNECT message, UE-2 sends a CONNECT ACK message to the interworking entity in step 917. In step 920, UE-2, the interworking entity, and the SCC AS complete the establishment of the CS bearer control signaling path. Collaborative session control is established between UE-2 and the SCC AS. UE-2 becomes the controller UE for the established collaborative session. In step 921, media type (Media A) communication is exchanged between UE-2 and the remote party. If SDP information needs to be changed, the remote leg is updated accordingly. In steps 922 and 923, after collaborative session control and media type (Media A) are successfully established on UE-2, the SCC AS sends a response message to the transfer request message, or a message notifying UE-1 of the result of the transfer request message using, for example, a SIP Notification (SIP Notification) message. Finally, in step 926, the media type (Media A) session previously on UE-1 is released, along with collaborative session control. UE-1 becomes the controlled UE. Note that in the above example, steps involving the communication of conventional acknowledgement messages are not described. If all media flows on UE-1 are transferred to UE-2, the existing session on UE-1 can be released.

Figure 10 illustrates the process of transferring IUT controller functions and media from UE-1 to UE-2, where incoming sessions are transmitted over the I1 reference point and media is sent via the CS network. In one implementation, an MSC server enhanced for ICS can be an exemplary interworking entity. Alternatively, the interworking entity can include a traditional MSC server and MGCF. When the interworking entity corresponds to the MSC server and MGCF, the CS bearer establishment procedure follows steps 1011-1017 in Figure 7.4.2.2.2-2 of TS 23.292.

In steps 1001 and 1002, UE-1 decides to transfer collaborative session control and media A to UE-2. Therefore, UE-1 sends a request to the SCC AS via the IMS entity, indicating that the current collaborative session control and media A will be transferred to UE-2. In one implementation, UE-1 sends a transfer request, for example, via a SIP REFER method with the following information: 1) source UE (which may be included in a From header field, a P-Asserted-Identity header field, or a P-Served-User header field), 2) target UE (which may be included in a Refer-To header field), 3) IUT controller transfer indication (which may be included in an Accept-Contact header field, e.g., embedded in an INVITE request or embedded in a Refer-To header field), 4) Target-Dialog (which may be included in a Target-Dialog header field containing an existing dialog identifier if the target UE is already part of a collaborative session, and no Target-Dialog when this is a new session for the target UE), and 5) media type (e.g., audio, video, file, etc.) (which may be included in a Refer-To header field).

In step 1005, the SCC AS identifies the request (e.g., a SIP REFER request). If UE-2 is SIP-registered with the SCC AS, the SCC AS verifies that UE-2 is permitted and capable of acting as a controller, verifies that UE-2 has registered appropriate capabilities (e.g., feature flags according to RFC 3840), determines which bearer to use for UE-2 based on device capabilities, user preferences, and/or network policies, and determines whether UE-2 has already registered the selected bearer. If UE-2 is not permitted to act as a controller, the SCC AS may reject the request. If UE-2 rejects the collaborative session control transfer, an appropriate response indicating the rejection and, optionally, the reason for the rejection is sent.

In step 1006, the SCC AS has determined that UE-2 is unreachable over the Gm reference point. This may be because, for example, the UE does not have an active SIP registration. In another example, UE-2 may be SIP registered but has informed the SCC AS via the I1 protocol that the Gm reference point is unavailable. If the message received in step 1002 contains an SDP line for audio or video, the SCC AS generates and sends an incoming call request message to UE-2 via the I1 reference point. The incoming call request message includes an indication of the IUT controller function and an indication to trigger UE-2 to establish a bearer. If the UE does not already have the selected bearer established, a transport mechanism such as (but not limited to) USSD, SMS, MBMS, Cell Broadcast, or an IP pipe running over GPRS in GERAN, UTRAN, LTE, WLAN, WiMax, or CDMA2000 may be used.

In step 1007, UE-2 sends a CS call setup message to the interworking entity. In step 1008, the interworking entity responds with a call proceeding message and begins establishing the CS bearer control signaling path. In steps 1009 and 1010, the interworking entity sends a SIP INVITE to the SCC AS via the IMS entity. In step 1013, when the interworking entity receives a SIP 200 OK response from the SCC AS via the IMS entity, it maps the received SIP 200 OK response into a Connect message and sends it to UE-2.

In step 1014, upon receiving the Connect message, UE-2 sends a Connect ACK message to the interworking entity. In step 1017, UE-2, the interworking entity, and the SCC AS complete the establishment of the CS bearer control signaling path. At this point, collaborative session control is established between UE-2 and the SCC AS. UE-2 becomes the controller UE for the established collaborative session.

In step 1018, media type (Media A) is established between UE-2 and the remote party. At this point, the remote segment is updated accordingly. In steps 1019 and 1020, after collaborative session control and media type (Media A) are successfully established on UE-2, the SCC AS sends a response message to the transfer request message, or a message indicating the result of the transfer request message using, for example, a SIP NOTIFY message, to UE-1. In step 1023, Media A previously on UE-1 may be released, and collaborative session control may be released. At this point, UE-1 becomes the controlled UE. Note that in the above example, no steps involving the communication of conventional positive acknowledgement messages are described. If all media flows on UE-1 are transferred to UE-2, the existing session on UE-1 may be released.

The above examples describe a process that results in the successful forwarding of IUT controller functionality or media to a qualified controller-capable UE. However, if the transfer is unsuccessful, the system may send various message response reason codes or indications to the requesting UE to provide an explanation of why the transfer failed. Example response reason codes or indications include: no IUT controller capability (thus, the UE cannot make a valid request for controller status), an IUT controller UE already exists for the session (e.g., in cases where only a single UE can be an IUT controller), UEs not under the same subscription, maximum limit of IUT controllers, unavailable (unregistered, no battery, etc.), not authorized to act as an IUT controller, unsupported media type, unsupported media format, no new session allowed because the maximum number of simultaneous sessions has been reached, busy, etc. The response reason code or indication may be included in a SIP Warning header included in the response. In some cases, the rejection response and associated reason code or indication may be included in the body of the SIP NOTIFY request, for example, within a SIP fragment containing a portion of the response message received at the SCC AS or other network node.

During operation of the present system, an IUT controller UE can subscribe to receive notifications describing ongoing sessions on specific UEs or all UEs associated with a user. The notifications can identify the various ongoing sessions and their associated controlees and/or controller UEs. In one example, user A has initiated two sessions, one with user C and user D, and another with user B. Regarding the sessions with users C and D, user A has three sessions for its set of IUT controller UEs (i.e., devices 1, 2, and 3). Regarding the session with user B, user A has two sessions on its set of IUT UEs (i.e., devices 2 and 3). In this example, user A may wish to receive information describing the currently ongoing sessions associated with the user's IUT UEs. In this case, user A can send a request (e.g., SIP SUBSCRIBE) and use the Dialog Event package described in RFC 4235 to obtain a response (e.g., SIP NOTIFY) with the following information set for each Target-Dialog:

-Target-Dialog

- Participating user ID (SIP URI, TEL URI or nickname)

-IUT device ID/nickname

-IUT controller device ID/nickname

- The media type or file for each session (i.e., for a particular collaboration session, a notification that there are three different sessions on user A's device)

As illustrated in the example shown in FIG11 , multiple UEs may exist for user A for all ongoing sessions. For collaborative session X involving communications with user C's device 68 or 70, user A's device 60 has issued a transfer request to user A's device 64. Furthermore, for collaborative session Y involving communications with user B's device 66, user A's device 62 has issued a transfer request to user A's device 64. When a new invitation for a new media type is received on user A's device 62, user A's device 60 may send a media transfer request or redirection request to transfer the new invitation to user A's device 64. If the media transfer request or redirection request is successfully accepted, a success notification is forwarded to the controller UE for that session or to all IUT controller UEs (user A's devices 60 and 62). Depending on user preferences and device capabilities, the user can configure notifications to be received on all controller UEs or designate which of multiple controller UEs receives notifications, rather than assigning notifications to all controller UEs. As shown in FIG11 , although multiple UEs exist for user A, only one IUT controller UE exists for each collaborative session. Thus, when the session state on a particular collaborative session has changed, only the controller UE of that particular collaborative session receives the notification.

In some implementations, there may be a large amount of notification traffic eligible to be sent to any controller UE. A filtering mechanism may be implemented within the notification mechanism on the network and/or each individual UE to optimize the amount of notification traffic sent to the controlling UE.

For terminating sessions, in one implementation of the present system, whichever UE first receives the request for session establishment and is able to accept it can be assigned controller functionality (otherwise, the UE that has already accepted the session will be stuck with that session and will not be able to send a transfer request to another UE of the user). Upon receiving the initial session establishment request (e.g., SIP INVITE, SIP re-INVITE, or SIP UPDATE) from the remote party, the network may need to ensure that the request is routed to a UE that is a controller and/or supports controller functionality. Once a session has been established, the terminating user may wish to transfer control of the collaborative session to another UE of the same user. If the target UE does not have IUT controller capabilities and is not an IUT controller UE, the target UE cannot make a transfer request to the other UE. However, in some cases, a transfer may still occur. For example, the UE may allow the user to provide redirection settings on the network, i.e., to redirect the request to a specific UE, such as a controller UE designated by the user, when an INVITE request arrives on the terminating side. Furthermore, the UE may allow the user to establish user preferences (possibly in combination with media type and device capabilities) to indicate which bearer to use for session establishment. For example, a user with two UEs may establish a user preference to use a packet-switched bearer for voice-type sessions on UE-1 and a circuit-switched bearer for video-type sessions on UE-2.

Alternatively, if there is no redirection setting, when the terminating network receives the invitation request, the network sends a request to ask the user whether to accept the invitation on the UE or redirect to another UE (i.e., the controller UE). If the user decides to redirect to another UE (which is the controller UE), the network sends a response containing the transferred UE identity to the terminating network, and the terminating network sends the invitation request to the UE designated by the user.

Alternatively, if there is no redirection setting, when the terminating UE receives an invite request, the UE asks the user whether to accept the invite or redirect to another UE. If the user decides to redirect to another UE (i.e., the controller UE), the network sends a redirection request to the terminating network. In this case, the terminating network sends an invite request to the UE assigned by the user. When the terminating network receives (e.g., via the SCC AS) an invite request (e.g., SIP INVITE, SIP RE-INVITE, or SIP UPDATE), the terminating network determines which terminating UE is to become the IUT controller based on device capabilities, user preferences, and/or policies, and determines which bearer to use for the terminating UE. The network checks whether the terminating UE has registered for the identified bearer. If not, the network can send an indication to the terminating UE to initiate bearer registration. After the bearer registration is successful, the network (e.g., via the SCC AS) sends an invite request message (e.g., SIP INVITE) indicating that session control and a specific media type are to be given to the target terminating UE. Upon receiving the Ack or OK response message, the SCC AS may send an indication to the remote party that the media stream has been redirected to a different UE.

Figures 12a and 12b illustrate a process for terminating collaborative session establishment when a remote party sends a session invite request. In one implementation, an MSC server enhanced for ICS may be an exemplary entity for the interworking entity. Alternatively, the interworking entity may include a traditional MSC server and an MGCF. The example process assumes that UE-1 has established device capabilities/user preferences to act as an IUT controller and to use PS bearers for video-type session establishment. UE-2 has established device capabilities/user preferences to use CS bearers for voice media-type session establishment. Figure 12a illustrates the high-level process as follows. In step 1101, the terminating network (e.g., an SCC AS) receives an invite message (e.g., a SIP INVITE or SIP re-INVITE). In step 1102, the SCC AS determines which terminating UE becomes the IUT controller based on device capabilities, user preferences, and/or policies, and determines which bearer to use for the terminating UE based on device capabilities, user preferences, and/or policies. In this example, the SCC AS determines that UE-1 will act as the IUT controller and use a PS bearer with a video media type, while UE-2 uses a CS bearer with a voice media type. In steps 1103 and 1104, the SCC AS sends an invite request message (e.g., SIP INVITE) to the interworking entity via the IMS entity to establish a collaborative session for UE-2. In step 1105, the interworking entity sends a CS call setup message to UE-2. In step 1106, UE-2, the interworking entity, and the SCC AS complete the establishment of the CS bearer control signaling path, and the SCC AS and the remote party complete the remote leg establishment. A collaborative session with a voice media type is established between UE-2 and the SCC AS, and the remote leg between the SCC AS and the remote party is established.

In steps 1107 and 1108, the SCC AS sends an invite request message (e.g., SIP INVITE) to UE-1 via the IMS entity. In step 1109, a collaborative session with the video media type is established between UE-1 and the SCC AS, and the remote leg between the SCC AS and the remote party is updated. UE-1 obtains collaborative session control that allows the application of the IUT transfer request.

In the steps shown in Figure 12a, in one implementation, it is assumed that UE-1 and UE-2 belong to the same subscriber (i.e., the same subscription set), and the SCC AS determines to establish a collaborative session on UE-2 via the CS network and on UE-1 via the PS network, with UE-1 maintaining control of the collaborative session. In some cases, when the interworking entity corresponds to an MSC server and an MGCF, the CS bearer establishment procedure follows steps 11-17 in Figure 7.4.2.2.2-2 of TS 23.292.

Figure 12b shows more detail than Figure 12a, as follows: In step 1201, the terminating network (e.g., SCC AS) receives an invite message (e.g., SIP INVITE or SIP re-INVITE). In step 1202, the SCC AS determines which terminating UE becomes the IUT controller based on device capabilities, user preferences, and/or policies, and also determines which bearer to use for the terminating UE based on device capabilities, user preferences, and/or policies. In this example, the SCC AS determines that UE-1 serves as the IUT controller and uses a PS bearer with a video media type, while UE-2 uses a CS bearer with a voice media type. In steps 1203 and 1204, the SCC AS sends an invite request message (e.g., SIP INVITE) to the interworking entity via the IMS entity to establish a collaborative session with UE-2. In steps 1205 and 1206, the interworking entity sends a CS call setup message to UE-2 and receives a CS call connect message. In steps 1207 through 1209, a SIP 200 OK response message is sent to the remote party via the IMS entity and the SCC AS. The remote party sends a SIP ACK to the interworking entity in steps 1210 through 1212, and the interworking entity sends a CONNECT response message to UE-2. In step 1214, a session with a voice media type is established between UE-2 and the remote party.

In steps 1215 through 1217, the SCC AS sends an invite request message (e.g., a SIP INVITE) to the terminating UE-1 to establish a session with the video media type. At this point, collaborative session control with the SCC AS is established, and the terminating UE-1 becomes the IUT controller. Upon receiving a SIP 200 OK response from UE-2 via the interworking entity and the IMS entity, as shown in steps 1218 through 1220, the SCC AS sends a SIP UPDATE to the remote party in step 1221 to update the remote leg. Following a successful SIP response in steps 1222 through 1225, a collaborative session with the video media type is established between UE-1 and the SCC AS in step 1226, and the remote leg between the SCC AS and the remote party is updated. Note that in the above example, the steps involved in communicating conventional acknowledgement messages are not fully described.

Figure 13 shows a process for transferring IUT controller functionality from PS UE-1 to PS UE-2. UE-1 and UE-2 may use the same bearer or different bearers. Even if packet-switched bearers are used on UE-1 and UE-2, it is possible to use a 3GPP IP-CAN on UE-1 and a non-3GPP IP-CAN on UE-2. In steps 1301 and 1302, UE-1 decides to transfer collaborative session control and media A to UE-2. Therefore, UE-1 sends a request to the SCC AS via the IMS entity, indicating that the current service control and media type (Media A) will be transferred to UE-2. In step 1305, the SCC AS recognizes the request (e.g., a SIP REFER request), verifies that UE-2 is allowed and capable of acting as a controller, and determines the PS bearer to use for UE-2 based on device capabilities, user preferences, and/or policies in the network.

In steps 1306 and 1307, the SCC AS generates and sends a session establishment request message, such as a SIP INVITE request (or SIP Pre-INVITE) indicating collaborative session control and media type (Media-A). The stream identifier media feature tag in the Accept-Contact header described above can be used to route the session establishment request to the desired access leg (bearer). In step 1312, collaborative session control is established between UE 2 and the SCC AS. UE 2 becomes the controller UE for the established collaborative session. In step 1313, media type (Media-A) communication is established between UE 2 and the remote party. The remote leg is updated accordingly. In steps 1314 and 1315, after the collaborative session control and media type (Media-A) are successfully established on UE 2, the SCC AS sends a response message to the transfer request message or a message notifying UE 1 of the result of the transfer request message, such as a SIP NOTIFY message. In step 1318, the previous media type (Media A) and collaborative session control on UE 1 may be released. UE 1 becomes the controlled UE. Note that in the above example, steps involving the communication of conventional acknowledgement messages are not described.

The present system and method can be used to provide an IUT controller transfer application. An example method implemented by the present system indicates at least one of being able to perform an IUT controller function and being unable to perform the IUT controller function. The method includes providing an indication of being able to support the IUT: controller function in a session initiation protocol (SIP) message, and providing an indication of being not able to support the IUT: controller function in a session initiation protocol (SIP) message. A media feature tag can be used to indicate at least one of being able to perform the IUT controller function and being not able to support the IUT: controller function. The media feature tag can indicate at least one of the following values: "Active", indicating an IUT controller that is capable of acting as an IUT controller and is currently acting as an IUT controller for a collaborative session; "Inactive", indicating an IUT controller that is capable of acting as an IUT controller but is not currently acting as an IUT controller for a collaborative session; and "Passive", indicating an IUT controller that is not capable of acting as an IUT controller for a collaborative session.

Depending on the implementation, the media feature tag may be included in the Contact header. A Session Initiation Protocol (SIP) message may include one of the following: a SIP REGISTER request, a SIP INVITE request, a SIP Re-INVITE request, a SIP UPDATE request, a SIP PRACK request, a SIP REFER request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP SUBSCRIBE request, a SIP NOTIFY request, a SIP OPTIONS request, and a SIP response.

An example method for transferring IUT controller functionality from one device to another includes providing an indication of a transfer of IUT controller functionality in a Session Initiation Protocol (SIP) message. The indication of the transfer of IUT controller functionality may be indicated using a media feature tag. The media feature tag may be included in an Accept-Contact header. The Session Initiation Protocol (SIP) message may be one of the following: a SIP INVITE request, a SIP Re-INVITE request, a SIP UPDATE request, a SIP PRACK request, a SIP REFER request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP SUBSCRIBE request, a SIP NOTIFY request, a SIP OPTIONS request, and a SIP INFO request. The media feature tag may be included in an Accept-Contact header, which itself may be included in a Refer-To header.

The method may include, in response, receiving an indication of one of a successful IUT transfer or an unsuccessful IUT transfer. The indication may include a SIP response, a SIP UPDATE request, a SIP PRACK request, a SIP NOTIFY request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP OPTIONS request, or a SIP MESSAGE request. Alternatively, the indication may be one of the following: a media feature tag in a Contact header, a media feature tag in the body of a SIP request or a SIP response, a media feature tag in a SIPfrag of the body of a SIP request or a SIP response, or a media feature tag encoded in XML format.

Alternatively, the method may provide for transferring the IUT controller functionality from one point of attachment to another. The attachment point technologies may include IEEE-802.11, IEEE-802.11a, IEEE-802.11b, IEEE-802.11g, IEEE-802.11n, 3GPP-GERAN, 3GPP-UTRAN-FDD, 3GPP-UTRAN-TDD, 3GPP-E-UTRAN-FDD, 3GPP-E-UTRAN-TDD, ADSL, ADSL2, ADSL2+, RADSL, SDSL, HDSL, HDSL2, G.SHDSL, VDSL, IDSL, 3GPP2-1X, 3GPP2-1X-HRPD, 3GPP2-UMB, DO 3GPP-HSPA, 3GPP-GERAN, 3GPP-UTRAN, 3GPP-E-UTRAN, 3GPP-WLAN, 3GPP-GAN, or 3GPP-HSPA. However, in some cases, other access technologies, categories, or types may be used.

Another example method for transferring IUT controller functionality from one device to another includes receiving an indication of a transfer of IUT controller functionality in a Session Initiation Protocol (SIP) message. The indication of the transfer of IUT controller functionality may be indicated using a media feature tag. The media feature tag may be included in an Accept-Contact header. The Session Initiation Protocol (SIP) message may be one or more of: a SIP INVITE request, a SIP Re-INVITE request, a SIP UPDATE request, a SIP PRACK request, a SIP REFER request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP SUBSCRIBE request, a SIP NOTIFY request, a SIP OPTIONS request, or a SIP INFO request. The media feature tag may be included in an Accept-Contact header, which itself may be included in a Refer-To header. The method may include, in response, sending an indication of one of a successful IUT transfer and an unsuccessful IUT transfer. The indication may be included in one of the following: a SIP response, a SIP UPDATE request, a SIP PRACK request, a SIP NOTIFY request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP OPTIONS request, and a SIP MESSAGE request. The indication may be one of the following: a media feature tag in a Contact header, a media feature tag in the body of a SIP request or a SIP response, a media feature tag in a SIPfrag in the body of a SIP request or a SIP response, or a media feature tag encoded in XML format. The method may include executing an active IUT controller function for the collaborative session.

The system can also be configured to direct SIP requests to a specific access application. An example method for identifying a registration process on an access network includes providing an identifier in a P-Access-Network-Info header of a Session Initiation Protocol (SIP) REGISTER request that identifies the type of access network on which the SIP REGISTER request is transmitted, and providing a media feature tag in a Contact header of the Session Initiation Protocol (SIP) REGISTER request that includes a value that uniquely identifies the registration process relative to all other registration processes for the same device. The media feature tag may include a value derived from a "reg-id" contact header parameter included in the SIP REGISTER request. The media feature tag may include a value that is a text string. The media feature tag includes a value that is a text string entered by a user. An example method for identifying a registration procedure on an access network includes: obtaining an identifier identifying an access type or access category of an access network on which the SIP REGISTER request is transmitted from a P-Access-Network-Info header of a Session Initiation Protocol (SIP) REGISTER request; obtaining a media feature tag from a Contact header of the Session Initiation Protocol (SIP) REGISTER request, the media feature tag including a value that uniquely identifies the registration procedure relative to all other registration procedures for the same device; and associating the access type or access category with the value from the media feature tag. The content of the Session Initiation Protocol (SIP) REGISTER request may be obtained using at least one of the following: a body of a received third-party registration request, a P-Access-Network-Info header in the received third-party registration request, and a registration event package within the body of a SIP NOTIFY request. The method may include receiving a SIP request or generating a SIP request, determining that the SIP request is to be routed to a specific access segment identified by an access type or access class value, retrieving a media feature tag value associated with the access type or access class value, and including the retrieved media feature tag value in an Accept-Contact header of the SIP request. The SIP request may be one of the following: a SIP INVITE request, a SIP Re-INVITE request, a SIP UPDATE request, a SIP PRACK request, a SIP REFER request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP SUBSCRIBE request, a SIP OPTIONS request, and a SIP INFO request.

An example method for identifying a registration process on an access network to which a request is to be sent includes providing a media feature tag in an Accept-Contact header of a SIP request, the media feature tag including a value that uniquely identifies the registration process for a device. The media feature tag may include a value that is a text string. The media feature tag may include a value that is a text string entered by a user. The SIP request may be one of the following: a SIP INVITE request, a SIP RE-INVITE request, a SIP UPDATE request, a SIP PRACK request, a SIP REFER request, a SIP PUBLISH request, a SIP MESSAGE request, a SIP SUBSCRIBE request, a SIP OPTIONS request, and a SIP INFO request. The media feature tag may be included in an Accept-Contact header, which itself may be included in a Refer-To header.

Figure 14 is an illustration of an alternative message flow for transferring media/controller functionality to another UE in a collaborative session using the Gm reference point. The message flow shown in Figure 14 illustrates an example method for transferring media and IUT controller functionality from UE-1 to UE-2, wherein the incoming session is communicated over the Gm reference point and media is established via the CS network. In this example, it is assumed that UE-1 and UE-2 belong to the same subscriber (i.e., the same subscription set), the interworking entity corresponds to an MSC enhanced for ICS, and the termination procedure for CS media using the Gm reference point shown in TS 23.292 is followed. In this example, when the interworking entity corresponds to an MSC server and an MGCF, the CS bearer establishment procedure can follow steps 11-17 of Figure 7.4.2.2.2-2 of TS 23.292.

14 , in step 1401, UE 1 decides to transfer media A and collaborative session control to UE 2, and sends a transfer request to an IMS entity, indicating that the current collaborative session control and media A are to be transferred to UE 2. In step 1402, the IMS entity forwards the transfer request to the SCC AS, and in step 1403, the SCC AS identifies the transfer request, verifies that UE 2 is allowed and capable of acting as a controller, performs T-ADS based on UE 2's capabilities, user preferences, and/or network policies, and selects a CS domain for establishing media A. If UE 2 is not allowed to act as a controller or the transfer request cannot be successfully executed, the SCC AS rejects the request with this reason and stops performing the following steps.

Still referring to Figure 14 , in step 1404, the SCC AS generates and sends an INVITE request to the IMS entity, as described in TS 23.292. This INVITE request indicates Media A and Collaborative Session Control, and instructs UE-2 to initiate the CS bearer establishment procedure. In step 1405, the IMS entity forwards the received INVITE request to UE-2. In step 1406, UE-2 sends a CS Call Setup message to the interworking entity. In step 1407, the interworking entity responds with a Call Proceeding message and begins establishing the CS bearer control signaling path. In steps 1408 and 1409, the interworking entity sends the INVITE to the SCC AS via the IMS entity. In step 1410, UE-2, the interworking entity, and the SCC AS complete the establishment of the CS bearer control signaling path. Collaborative session control is established between UE-2 and the SCC AS. UE-2 becomes the controller UE for the established collaborative session. In step 1411, Media A is established between UE-2 and the remote party. The remote leg is updated accordingly. In step 1412, after successfully transferring collaborative session control and media A to UE 2, the SCC AS sends an IUT Transfer Result message to the IMS entity. In step 1413, the IMS entity forwards the IUT Transfer Result message to UE-1. Finally, in step 1414, the previous media A and collaborative session control are released. UE 1 becomes the controlled UE.

Figure 15 is an illustration of an alternative message flow for transferring media/controller functionality to another UE in a collaborative session using the I1 reference point. The message flow shown in Figure 15 illustrates an example method for transferring IUT controller functionality from UE-1 to UE-2, where the incoming session is communicated over the I1 reference point and media is established via the CS network. In this example, it is assumed that UE-1 and UE-2 belong to the same subscriber (i.e., the same subscription set), the interworking entity corresponds to an MSC enhanced for ICS, and the termination procedure for CS media using the I1 reference point shown in TS 23.292 is followed. In this example, when the interworking entity corresponds to an MSC server and an MGCF, the CS bearer establishment procedure follows steps 11-17 of Figure 7.4.2.2.2-2 of TS 23.292.

Referring to Figure 15 , in step 1501, UE 1 decides to transfer Media A and collaborative session control to UE 2 and sends a transfer request to an IMS entity, indicating that the current collaborative session control and Media A are to be transferred to UE 2. In step 1502, the IMS entity forwards the transfer request to the SCC AS. In step 1503, the SCC AS identifies the transfer request, verifies that UE-2 is permitted and capable of acting as a controller, performs T-ADS based on UE-2's capabilities, user preferences, and/or network policies, and selects a CS domain for establishing Media A. If UE-2 is not permitted to act as a controller or the transfer request cannot be successfully executed, the SCC AS rejects the request with this reason and stops the following steps. In step 1504, the SCC AS generates and sends an incoming call request to UE-2 via the I1 reference point. As described in TS 23.292, the incoming call request indicates that UE-2 initiates a CS bearer establishment procedure and that collaborative session control and Media A are to be transferred to UE-2.

Still referring to Figure 15 , in step 1505, UE-2 sends a CS Call Setup message to the interworking entity. In step 1506, the interworking entity responds with a Call Proceeding message and begins establishing the CS bearer control signaling path. In steps 1507 and 1508, the interworking entity sends an Invite to the SCC AS via the IMS entity. In step 1509, UE-2, the interworking entity, and the SCC AS complete the establishment of the CS bearer control signaling path. Collaborative session control is established between UE-2 and the SCC AS. UE-2 becomes the controller UE for the established collaborative session. In step 1510, media A is established between UE-2 and the remote party. The remote leg is updated accordingly. In step 1511, after successfully transferring collaborative session control and media A to UE-2, the SCC AS sends an IUT Transfer Result message to the IMS entity. In step 1512, the IMS entity forwards the IUT Transfer Result message to UE-1 and, in step 1513, releases the previous media A and collaborative session control. UE 1 becomes the controlled UE.

FIG16 is an illustration of an alternative message flow for controller-initiated transfer of ongoing session information. In the example shown in FIG16 , UE-1, UE-2, and UE-3 may be under the same user subscription. There is a session with media A between UE-2 and a remote party, and another session with media B between UE-3 and the remote party. FIG16 illustrates the information flow for UE-1 requesting state information for all ongoing sessions of the user's IUT UE.

Referring to FIG. 16 , in step 1601, UE-1 sends a request to the SCC AS for information about the ongoing sessions of the user's IUT UE. The request may include the information to be received in the response. This information may include the ongoing sessions of the user's IUT UE, the media type of each ongoing session, and/or the source and target UEs of each ongoing session. In step 1602, the SCC AS examines all ongoing sessions of the user's IUT UE and filters the requested information to find that there is a session A with media type A between UE-2 and the remote party, and another session B with media type B between UE-3 and the remote party. In step 1603, the SCC AS sends a response to UE-1 regarding the status of all ongoing sessions on UE-2 and UE-3.

In the following implementation of this system, the SCC AS can act as a B2BUA: In the case where media transport in the PS domain is selected, the SCC AS provides services to the terminating ICS UE and receives the initial SIP INVITE request for media transport in the PS domain, resulting from the initial filtering criteria and T-ADS results. If multiple contacts are registered in the PS domain and T-ADS selects different IP-CANs for establishing different media types, the SCC AS can create a SIP INVITE request for each selected PS domain IP-CAN according to 3GPP TS 24.229. The SIP INVITE request may include: i) an Accept-Contact header containing a media feature tag g.3gpp.icsflow containing a value associated with the access type or access category of the selected PS domain IP-CAN at the registry, and a media feature tag g.3gPP.ics containing the value "principal" and the parameters "require" and "explict", and ii) if a known leg for the session already exists or is in the process of being established between the SCC AS and the ICS UE using a different IP-CAN, a Target-Dialog header containing dialog parameters for the existing dialog between the SCC AS and the ICS UE (the SCC AS may include a Target-Dialog header in the SIP INVITE request so that the ICS UE can correlate different requests as part of the same session), and iii) an SDP for the selected media type to be established using the IP-CAN.

If multiple contacts are registered in the PS domain and the T-ADS chooses to establish all media types on the same IP-CAN, the SCC AS may create a SIP INVITE request in accordance with 3GPP TS 24.229 and may include in the request: i) an Accept-Contact header containing the media feature tag g.3gpp.icsflow and the media feature tag g.3gpp.ics, where the media feature tag g.3gpp.icsflow contains a value associated with the access type or access category of the selected PS domain IP-CAN at the registration point, and the media feature tag g.3gpp.ics contains the value "principal" and the parameters "require" and "explicit", ii) if a known leg for this session already exists or is being established between the SCC AS and the ICS UE using a different IP-CAN, a Target-Dialog header containing the dialog parameters for this existing dialog between the SCC AS and the ICS UE (the SCC AS may include the Target-Dialog header in the SIP INVITE request so that the ICS The UE can correlate different requests as part of the same session), and iii) SDP for all media types included in the initial SIP INVITE request.

If only a single contact is registered in the PS domain, the SCC AS may create a SIP INVITE request in accordance with 3GPP TS 24.229 and may include in the request i) an Accept-Contact header containing the media feature tag g.3gpp.ics containing the value "principal" and the parameters "require" and "explicit", and ii) SDP for all media types included in the initial SIP INVITE request.

Now referring to Figure 17, a wireless communication system including an embodiment of an exemplary UE 1700 is shown. The UE can be operated to implement various aspects of the present disclosure, but the present disclosure should not be limited to these implementations. Although shown as a mobile phone, the UE can take various forms, including wireless handsets, pagers, personal digital assistants (PDAs), portable computers, tablet computers, laptop computers, smart phones, printers, fax machines, televisions, set-top boxes and other video display devices, home audio equipment and other home entertainment systems, home monitoring and control systems (e.g., home monitoring alarm systems and climate control systems) and enhanced home appliances (e.g., computerized refrigerators). Many suitable devices combine some or all of these functions. In some embodiments of the present disclosure, the UE 1700 is not a general-purpose computing device (e.g., a portable computer, laptop computer or tablet computer), but a dedicated communication device (e.g., a mobile phone, wireless handset, pager or PDA) or a telecommunications device installed in a vehicle. The UE 1700 can also be a device with similar functions but not portable (e.g., a desktop computer, set-top box or network node), include such a device or be included in such a device. UE 1700 may support specialized activities such as gaming, inventory control, job control and/or task management functions.

UE 1700 includes a display 702. UE 1700 also includes a touch-sensitive surface, a keyboard, or other input keys, generally referred to as 704, for user input. The keyboard can be a full-size or reduced alphanumeric keyboard, such as QWERTY, Dvorak, AZERTY, and continuous keyboards, or a traditional numeric keypad with letters associated with a telephone keypad. Input keys may include a scroll wheel, an exit or escape key, a trackball, and other navigation or function keys that are pressed inward to provide other input functions. UE 1700 may present options for the user to select, controls for the user to manipulate, and/or a cursor or other indicator for the user to guide.

UE 1700 may also accept data input from the user, including dialed digits or various parameter values for configuring the operation of UE 1700. UE 1700 may also execute one or more software or firmware applications in response to user commands. In response to user interaction, these applications may configure UE 1700 to perform various customized functions. Furthermore, UE 1700 may be programmed and/or configured over the air, for example, from a wireless base station, wireless access point, or a peer UE 1700.

Among the various applications executable by UE 1700 is a web browser that causes display 702 to display a web page. The web page can be obtained via wireless communication with a wireless network access node, a cell tower, a peer UE 1700, or any other wireless communication network or system 1702. Network 1702 is coupled to a wired network 1704, such as the Internet. Via wireless links and the wired network, UE 1700 accesses information on various servers (e.g., server 1706). Server 1706 can provide content that can be displayed on display 702. Alternatively, UE 1700 can access network 1702 through a peer UE 1700, which acts as an intermediary in a relay-type or hop-type connection.

18 shows a block diagram of a UE 1700. Although various known components of the UE 1700 are described, in embodiments, a subset of the listed components and/or additional components not listed may be included in the UE 1700. The UE 1700 includes a digital signal processor (DSP) 1802 and a memory 1804. As shown, UE 1700 may also include an antenna and front end unit 1806, a radio frequency (RF) transceiver 1808, an analog baseband processing unit 1810, a microphone 1812, an earpiece speaker 1814, a headset port 1816, an input/output interface 1818, a removable memory card 1820, a universal serial bus (USB) port 1822, a short-range wireless communication subsystem 1824, an alarm 1826, a keypad 1828, a liquid crystal display (LCD) including a touch-sensitive surface 1830, an LCD controller 1832, a charge-coupled device (CCD) camera 1834, a camera controller 1836, and a global positioning system (GPS) sensor 1838. In one embodiment, UE 1700 may include another display that does not provide a touch-sensitive screen. In one embodiment, DSP 1802 may communicate directly with memory 1804 without going through input/output interface 1818.

The DSP 1802, or some other form of controller or central processing unit, operates to control the various components of the UE 1700 according to embedded software or firmware stored in the memory 1804 or in memory contained within the DSP 1802 itself. In addition to the embedded software or firmware, the DSP 1802 may execute other applications that are stored in the memory 1804 or made available via information carrier media such as portable data storage media (e.g., a removable memory card 1820), or made available via wired or wireless network communications. The application software may include a compiled set of machine-readable instructions that configure the DSP 1802 to provide the desired functionality, or the application software may be high-level software instructions that are processed by an interpreter or compiler to indirectly configure the DSP 1802.

An antenna and front end unit 1806 may be provided to convert between wireless signals and electrical signals so that the UE 1700 can send and receive information from a cellular network or some other available wireless communication network or from a peer UE 1700. In one embodiment, the antenna and front end unit 1806 may include multiple antennas to support beamforming and/or multiple-input multiple-output (MIMO) operations. As known to those skilled in the art, MIMO operations may provide spatial diversity, which may be used to overcome difficult channel conditions and/or increase channel throughput. The antenna and front end unit 1806 may include antenna tuning and/or impedance matching components, RF power amplifiers, and/or low noise amplifiers.

The RF transceiver 1808 provides frequency shifting, converts received RF signals to baseband, and converts baseband transmit signals to RF. In some descriptions, a radio transceiver or RF transceiver may be understood to include other signal processing functions, such as modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions. For clarity, the description herein separates the description of this signal processing from the RF and/or radio level and conceptually allocates this signal processing to the analog baseband processing unit 1810 and/or DSP 1802 or other central processing unit. In some embodiments, the RF transceiver 1808, portions of the antenna and front end 1806, and the analog baseband processing unit 1810 may be combined into one or more processing units or application-specific integrated circuits (ASICs).

The analog baseband processing unit 1810 can provide various analog processing for inputs and outputs, such as analog processing for inputs from a microphone 1812 and earphone 1816 and outputs to earphone 1814 and headset 1816. Thus, the analog baseband processing unit 1810 may have ports for connecting to a built-in microphone 1812 and earphone speaker 1814, which enables the UE 1700 to be used as a cellular phone. The analog baseband processing unit 1810 may also include ports for connecting to a headset and other hands-free microphone and speaker configurations. The analog baseband processing unit 1810 can provide digital-to-analog conversion in one signal direction and analog-to-digital conversion in the opposite signal direction. In some embodiments, at least some of the functions of the analog baseband processing unit 1810 may be provided by a digital processing component (e.g., by a DSP 1802 or other central processing unit).

The DSP 1802 can perform modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions associated with wireless communications. In an embodiment, for example, in a code division multiple access (CDMA) technology application, for transmitter functions, the DSP 1802 can perform modulation, encoding, interleaving, and spreading, while for receiver functions, the DSP 1802 can perform despreading, deinterleaving, decoding, and demodulation functions. In another embodiment, for example, in an orthogonal frequency division multiple access (OFDMA) technology application, for transmitter functions, the DSP 1802 can perform modulation, encoding, interleaving, inverse fast Fourier transform, and cyclic prefix addition, while for receiver functions, the DSP 1802 can perform cyclic prefix removal, fast Fourier transform, deinterleaving, decoding, and demodulation. In other wireless technology applications, the DSP 1802 can perform other signal processing functions or a combination of signal processing functions.

DSP 1802 can communicate with a wireless network via analog baseband processing unit 1810. In some embodiments, this communication can provide internet connectivity, allowing users to access internet content and send and receive emails or text messages. Input/output interface 1818 interconnects DSP 1802 and various memories and interfaces. Memory 1804 and removable memory card 1820 can provide software and data to configure the operation of DSP 1802. Among the interfaces, there may be a USB interface 1822 and a short-range wireless communication subsystem 1824. USB interface 1822 can be used to charge UE 1700 and can also enable UE 1700 to function as a peripheral device to exchange information with a personal computer or other computer system. Short-range wireless communication subsystem 1824 may include an infrared port, a Bluetooth interface, an IEEE 802.11-compliant wireless interface, or any other short-range wireless communication subsystem, enabling UE 1700 to wirelessly communicate with other nearby mobile devices and/or wireless base stations.

The input/output interface 1818 may also connect the DSP 1802 to an alarm 1826, which, when triggered, enables the UE 1700 to provide an alert to the user, for example, by ringing, playing a melody, or vibrating. The alarm 1826 may serve as a mechanism for alerting the user of any of a variety of events, such as an incoming call, a new text message, and an appointment reminder by vibrating silently or playing a specific pre-assigned melody for a particular caller.

A keypad 1828 is coupled to the DSP 1802 via the interface 1818 to provide a mechanism for the user to make selections, enter information, or otherwise provide input to the UE 1700. The keyboard 1828 can be a full-size or reduced alphanumeric keyboard, such as QWERTY, Dvorak, AZERTY, and continuous keyboards, or a traditional numeric keypad with letters associated with a telephone keypad. Input keys can include a scroll wheel, an exit or escape key, a trackball, and other navigation or function keys that are pressed inward to provide additional input functionality. Another input mechanism can be an LCD 1830, which can include touchscreen capabilities and can also display text and/or graphics to the user. An LCD controller 1832 couples the DSP 1802 to the LCD 1830.

A CCD camera 1834 (if equipped) enables the UE 1700 to take digital pictures. The DSP 1802 communicates with the CCD camera 1834 via a camera controller 1836. In another embodiment, a camera operating based on a technology other than a charge-coupled device can be used. A GPS sensor 1838 is coupled to the DSP 1802 to decode global positioning system signals, thereby enabling the UE 1700 to determine its location. Various other peripherals may also be included to provide additional functionality, such as radio and television reception.

FIG19 illustrates a software environment 1902 that DSP 1802 can implement. DSP 1802 executes operating system drivers 1904, which provide a platform for it and the software to operate from. Operating system drivers 1904 provide drivers to UA hardware using standardized interfaces that are accessible to application software. Operating system drivers 1904 include application management services ("AMS") 1906, which transfer control between applications running on UE 1700. FIG19 also illustrates a web browser application 1908, a media player application 1910, and a Java applet 1912. Web browser application 1908 configures UE 1700 to operate as a web browser, allowing users to enter information into forms and select links to retrieve and view web pages. Media player application 1910 configures UE 1700 to retrieve and play audio or audiovisual media. Java applets 1912 configure UE 1700 to provide games, applications, and other functionality. Component 1914 may provide the functionality described herein.

The UE 1700, access device, and other components described above may include a processing component capable of executing instructions related to the above-mentioned actions. Figure 20 shows an example of a system 2000, which includes a processing component 2010 suitable for implementing one or more embodiments disclosed herein. In addition to the processor 2010 (which may be a central processing unit (CPU) or a DSP), the system 2000 may include a network connection device 2020, a random access memory (RAM) 2030, a read-only memory (ROM) 2040, an auxiliary memory 2050, and an input/output (I/O) device 2060. In some embodiments, a program for implementing the determination of the minimum number of HARQ process IDs may be stored in the ROM 2040. In some cases, some of these components may not appear, or may be combined in various combinations with each other or with various combinations of other components not shown. These components may be located in a single physical entity, or may be located in multiple physical entities. Any actions described herein as being performed by the processor 2010 may be performed by the processor 2010 alone, or by the processor 2010 in combination with one or more components shown or not shown in the figure.

The processor 2010 executes instructions, codes, computer programs, or scripts that may be accessed from the network connection device 2020, RAM 2030, ROM 2040, or secondary storage 2050 (which may include various disk-based systems, such as hard disks, floppy disks, or optical disks). Although only one processor 2010 is shown, multiple processors may be present. Therefore, although instructions may be discussed as being executed by a processor, the instructions may be executed by one or more processors simultaneously, serially, or in other ways. The processor 2010 may be implemented as one or more CPU chips.

The network connection device 2020 may take the form of a modem, a modem bank, an Ethernet device, a Universal Serial Bus (USB) interface device, a serial interface, a token ring device, a Fiber Distributed Data Interface (FDDI) device, a wireless local area network (WLAN) device, a wireless transceiver device (e.g., a Code Division Multiple Access (CDMA) device), a Global System for Mobile Communications (GSM) wireless transceiver device, a Worldwide Interoperability for Microwave Access (WiMAX) device, and/or other well-known devices for connecting to a network. These network connection devices 2020 may enable the processor 2010 to communicate with the Internet or one or more telecommunications networks, or with other networks from which the processor 2010 may receive information or to which the processor 2010 may output information.

The network connection device 2020 may also include one or more transceiver components 2025 capable of wirelessly transmitting and/or receiving data in the form of electromagnetic waves (e.g., radio frequency signals or microwave frequency signals). Alternatively, the data may be transmitted in or on the surface of an electronic connector, in a coaxial cable, in a waveguide, in an optical medium (e.g., optical fiber), or in other media. The transceiver component 2025 may include separate receiving and transmitting units or a single transceiver. The information transmitted and received by the transceiver 2025 may include data processed by the processor 2010 or instructions to be executed by the processor 2010. This information may be received from and output to the network in the form of, for example, computer data baseband signals or signals embedded in a carrier wave. The data may be sorted in various orders, as desired for processing or generating the data or for transmitting or receiving the data. Baseband signals, signals embedded in a carrier wave, or other types of signals currently in use or hereafter developed may be referred to as transmission media, and transmission media may be generated according to a number of methods known to those skilled in the art.

RAM 2030 can be used to store volatile data and possibly instructions to be executed by processor 2010. ROM 2040 is a non-volatile memory device that typically has a smaller memory capacity than secondary storage 2050. ROM 2040 can be used to store instructions and possibly data that is read during the execution of the instructions. Access to ROM 2030 and RAM 2040 is generally faster than access to secondary storage 2050. Secondary storage 2050 typically includes one or more disk drives or tape drives and can be used for non-volatile storage of data or as an overflow data storage device if RAM 2030 is not large enough to hold all working data. Secondary storage 2050 can be used to store programs that are loaded into RAM 2030 when such programs are selected for execution.

The I/O devices 2060 may include a liquid crystal display (LCD), a touch screen display, a keyboard, a keypad, switches, a dial, a mouse, a trackball, a voice recognizer, a card reader, a paper tape reader, a printer, a video monitor, or other well-known input devices. Similarly, the transceiver 2025 may be considered a component of the I/O devices 2060 instead of, or in addition to, being a component of the network connection device 2020. Some or all of the I/O devices 2060 may be substantially similar to the various components (e.g., display and input) depicted in the previously described diagram of the UE 1700.

Although several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods may be implemented in many other specific forms without departing from the spirit and scope of the present disclosure. The present examples are to be considered illustrative rather than restrictive, and the intention is not to be limited to the details given herein. For example, various elements or components may be combined or integrated into another system, and certain features may be omitted or not implemented.

Likewise, the techniques, systems, and methods described and illustrated as discrete or separate in various embodiments may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as connected or directly connected or communicating with each other, whether electronically, mechanically, or otherwise, may be indirectly connected or communicated with via some interface, device, or intermediate component. Other examples of changes, substitutions, and modifications may be discovered and made by those skilled in the art without departing from the principles and scope disclosed herein.

Claims (18)

1. A method for transferring control, comprising: Obtain a media feature tag sent to the network by the terminal in a Session Initiation Protocol (SIP) registration request, the media feature tag containing information indicating the access network technology used by the terminal for registration; and By selecting an access network according to the indicated access network technology, a SIP request for transferring session control between terminals is sent. The SIP request includes an "Accept Contact" header field containing a media feature marker set to information that was previously included by the terminal in the SIP registration request. 2. The method of claim 1, wherein the SIP request for transferring control is a SIP REFER message. 3. The method of claim 1, wherein the terminal includes a first terminal, and the request for control of transferring the session is from the first terminal to the second terminal. 4. The method of claim 3, wherein the request for control of the transfer session includes a request for media transfer. 5. The method of claim 4, wherein the acquisition and the transmission are performed by a network node, and the request for transfer control is sent from the network node to the second terminal. 6. The method according to claim 5, wherein the network node includes a service consistency and continuity application server "SCC AS". 7. The method of claim 5, wherein the request for control of the transfer session is sent to the second terminal via the access network in response to a request received from the first terminal. 8. The method according to claim 1, wherein the indicated access network technology is a wireless local area network (WLAN) technology. 9. The method according to claim 1, wherein the indicated access network technology is cellular access network technology. 10. The method of claim 1, wherein the request for transferring control of the session is to divide the media stream. 11. A network node, comprising: At least one processor is configured as follows: Obtain a media feature tag sent to the network by the terminal in a Session Initiation Protocol (SIP) registration request, the media feature tag containing information indicating the access network technology used by the terminal for registration; and By selecting an access network according to the indicated access network technology, a SIP request for transferring session control between terminals is sent. The SIP request includes an "Accept Contact" header field containing a media feature marker set to information that was previously included by the terminal in the SIP registration request. 12. The network node of claim 11, wherein the SIP request for transfer control is a SIP REFER message. 13. The network node of claim 11, wherein the request for transfer control includes a request for media transfer. 14. The network node of claim 11, wherein the network node includes a service consistency and continuity application server "SCC AS". 15. The network node of claim 11, wherein the terminal is a first terminal, and the at least one processor is configured to: in response to a request received from the first terminal, send a request for control of transferring a session to a second terminal via the access network. 16. The network node according to claim 11, wherein the indicated access network technology is a wireless local area network (WLAN) technology. 17. The network node according to claim 11, wherein the indicated access network technology is cellular access network technology. 18. A non-transitory storage medium for storing instructions, said instructions causing network nodes to: Obtain a media feature tag sent to the network by the terminal in a Session Initiation Protocol (SIP) registration request, the media feature tag containing information indicating the access network technology used by the terminal for registration; and By selecting an access network according to the indicated access network technology, a SIP request for transferring session control between terminals is sent. The SIP request includes an "Accept Contact" header field containing a media feature marker set to information that was previously included by the terminal in the SIP registration request.