HK1176788A - Method and apparatus for inter user-equipment transfer (iut), access transfer and fallback initiated by a service centralization and continuity application server (scc as) - Google Patents

Description

Method and apparatus for inter-user equipment transfer (IUT), access transfer, and fallback initiated by a service centralization and continuity application server (SCC AS)

Cross Reference to Related Applications

This application claims the benefit of entitled U.S. provisional application No. 61/289,662 filed on 12/23/2009, U.S. provisional application No. 61/290,042 filed on 12/24/2009, U.S. provisional application No. 61/308,193 filed on 2/25/2010, and U.S. provisional application No. 61/308,086 filed on 2/25/2010, the contents of which are incorporated herein by reference.

Background

The Internet Protocol (IP) multimedia subsystem (IMS) is an architectural framework for delivering IP-based multimedia services. A wireless transmit/receive unit (WTRU) may connect to the IMS through different access networks including, but not limited to, networks based on the following technologies: universal Mobile Telecommunications System (UMTS) terrestrial radio access network (UTRAN), Long Term Evolution (LTE), worldwide interoperability for microwave access (WiMax), or Wireless Local Area Network (WLAN) technologies. In accordance with IMS, one feature that may be used is to transfer IMS sessions between multiple WTRUs that have IMS capabilities. Therefore, it is advantageous to initiate inter-user equipment transfer (IUT), access transfer, and session fallback (fallback) between IMS capable WTRUs by a service centralization and continuity application server (SCC AS).

Disclosure of Invention

Methods and apparatus for inter-user equipment transfer (IUT), Access Transfer (AT), and fallback for IP Multimedia (IM) Subsystem (IMs) sessions initiated by a service centralization and continuity application server (SCC AS). The SCC AS receives information including availability information, capability information, or preference information and processes the information to determine IUT and/or AT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and to initiate the IUT and/or AT.

Drawings

A more particular understanding can be obtained from the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

FIG. 1B is a system diagram of an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in FIG. 1A;

fig. 1C is a system diagram of an example radio access network and an example core network that may be used within the communication system shown in fig. 1A;

FIG. 2 is a diagram of an example of an Internet Protocol (IP) multimedia subsystem;

FIG. 3 shows an embodiment of a communication session using third party call control;

FIG. 4 shows an embodiment of a communication session using first party call control;

FIG. 5 shows an embodiment of a communication session using third party call control;

FIG. 6 shows an embodiment of a communication session using first party call control;

FIG. 7 shows a diagram of a communication session including policy and reporting functions;

FIG. 8A1 shows an example of an IUT initiated by a SCC AS based on policy or profile information;

FIG. 8A2 is a continuation of FIG. 8A 1;

FIG. 8B1 shows an example of an access transfer initiated by the SCC AS based on policy or profile information;

FIG. 8B2 is a continuation of FIG. 8B 1;

fig. 9a1 shows an example of an IUT initiated by the SCC AS based on location information;

FIG. 9A2 is a continuation of FIG. 9A 1;

FIG. 9B1 shows an example of an access transfer initiated by the SCC AS based on location information;

FIG. 9B2 is a continuation of FIG. 9B 1;

fig. 10a1 shows an example of a load balancing IUT initiated by the SCC AS;

FIG. 10A2 is a continuation of FIG. 10A 1;

FIG. 10B1 shows an example of a load balancing access transfer initiated by a SCC AS;

FIG. 10B2 is a continuation of FIG. 10B 1;

fig. 11a1 shows an example of a fallback IUT initiated by the SCC AS;

FIG. 11A2 is a continuation of FIG. 11A 1;

FIG. 11B1 shows an example of a fallback access transfer initiated by a SCC AS;

FIG. 11B2 is a continuation of FIG. 11B 1;

FIG. 11C1 shows an alternative embodiment of FIG. 11A;

FIG. 11C2 is a continuation of FIG. 11C 1;

FIG. 11D1 shows an alternative embodiment of FIG. 11B;

FIG. 11D2 is a continuation of FIG. 11D 1;

fig. 12a1 shows an example of an IUT initiated by the SCC AS based on radio coverage;

FIG. 12A2 is a continuation of FIG. 12A 1;

fig. 12B1 shows an example of an access transfer initiated by the SCC AS based on radio coverage; and

FIG. 12B2 is a continuation of FIG. 12B 1.

Detailed Description

Fig. 1A is an illustration of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides voice, data, video, messaging, broadcast, etc. content to a plurality of wireless users. The communication system 100 may allow multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), and so on.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN) 104, a core network 106, a Public Switched Telephone Network (PSTN) 108, the internet 110, and other networks 112, although it is understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

Communication system 100 may also include base station 114a and base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the internet 110, and/or the network 112. The base stations 114a, 114B may be, for example, Base Transceiver Stations (BTSs), node B, e node bs, home (home) node bs, home enodeb, site controller, Access Points (APs), wireless routers, and so forth. Although each base station 114a, 114b is depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104, which may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of a cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, whereby multiple transceivers may be used for each sector in a cell.

The base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, Infrared (IR), Ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple access system and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 116 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement IEEE802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, temporary Standard 2000 (IS-2000), temporary Standard 95 (IS-95), temporary Standard 856 (IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like radio access technologies.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may use any suitable RAT to facilitate wireless connectivity in a local area, such as a business, residence, vehicle, campus, and so forth. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-a, etc.). As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, the base station 114b may not need to access the internet 110 via the core network 106.

The RAN 104 may communicate with a core network 106, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102 d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RAN 104 and/or the core network 106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to a RAN 104 that may use E-UTRA radio technology, the core network 106 may also communicate with another RAN (not shown) that may use GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN108, the internet 110, and/or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a system of globally interconnected computer network devices using common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in a TCP/IP internet protocol cluster. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, in other words, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU102 c shown in fig. 1A may be configured to communicate with a base station 114a that uses a cellular-based radio technology and with a base station 114b that may use an IEEE802 radio technology.

Figure 1B is a system diagram of an example WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be appreciated that WTRU102 may include any subcombination of the foregoing elements while maintaining a consistent implementation.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, and the transceiver 120 may be coupled to a transmit/receive element 122. Although fig. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may be integrated in one electronic package or chip.

The transmit/receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114 a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, for example, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive RF and optical signals. It should be appreciated that transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Furthermore, although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU102 may include any number of transmit/receive elements 122. More specifically, the WTRU102 may use MIMO technology. Thus, in one embodiment, the WTRU102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) that transmit and receive wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and to demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from and store information in any suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The non-removable memory 106 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and so forth. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located in the WTRU102, such as on a server or a home computer (not shown).

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power for other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled with a GPS chipset 136, which the GPS chipset 136 may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU102 may acquire location information via any suitable location determination method while maintaining consistent embodiments.

The processor 118 may also be coupled to other peripherals 138, which peripherals 138 may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, BluetoothA module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, and so forth.

Fig. 1C is a system diagram of RAN 104 and core network 106 according to one embodiment. As described above, the RAN 104 may use E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with a core network 106.

The RAN 104 may include enodebs 140a, 140B, 140c, but it should be appreciated that the RAN 104 may include any number of enodebs while remaining consistent with an embodiment. The enodebs 140a, 140B, 140c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 140a, 140B, 140c may implement MIMO technology. Thus, for example, the enodeb 140a may use multiple antennas to transmit wireless signals to the WTRU102a and to receive wireless signals from the WTRU102 a.

Each enodeb 140a, 140B, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 1C, the enode bs 140a, 140B, 140C may communicate with each other through an X2 interface.

The core network 106 shown in fig. 1C may include a mobility management gateway (MME) 142, a serving gateway 144, and a Packet Data Network (PDN) gateway 146. While each of the foregoing elements are described as being part of the core network 106, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

MME 142 may be connected to each enodeb 142a, 142B, 142c in RAN 104 via an S1 interface and may act as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and so on. MME 142 may also provide control plane functionality to switch between RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

The serving gateway 144 may be connected to each enodeb 140a, 140B, 140c in the RAN 104 via an S1 interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The serving gateway 144 may also perform other functions such as anchoring the user plane during inter-enodeb handovers, triggering paging when downlink data is available for the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.

The serving gateway 144 may also be connected to a PDN gateway 146, which PDN gateway 146 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The core network 106 may facilitate communication with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the core network 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to a network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 2 is a diagram of an example of an Internet Protocol (IP) IP multimedia core network (IM CN) including an IP Multimedia (IM) Subsystem (IMs) 200, an IM network 202, a Circuit Switched (CS) network 204, a conventional network 206 in communication with a wireless transmit/receive unit (WTRU) 210. IMS 200 includes Core Network (CN) elements for provisioning IM services delivered over the packet switched domain, where the IM services may be, for example, audio, video, text, chat, or a combination thereof. AS shown, IMS 200 includes a home (home) subscriber server (HSS) 220, an Application Server (AS) 230, a Call Session Control Function (CSCF) 240, a Breakout Gateway Function (BGF) 250, a Media Gateway Function (MGF) 260, and a service centralization and continuity application server (SCC AS) 270. In addition to the logical entities and signal paths shown in fig. 2, the IMS may comprise any other logical entity configuration, which may be located in one or more physical devices. Although not shown in this logical example, the WTRU may be a separate physical unit and may be connected to the IM CN via a base station such as a node B or enhanced node B (enb).

The WTRU210 may be any type of device configured to operate and/or communicate in a wired and/or wireless environment.

HSS 220 may maintain and provide subscription (subscription) related information to support network entities handling IM sessions. For example, the HSS may include identification information, security information, location information, and profile information for IMS users.

The AS 230 may be a SIP application server, an OSA application server, or a CAMEL IM-SSF, the AS 230 may provide value added IM services and may reside in a home (home) network or a third party location. The AS may be comprised in a network, such AS a home network, a core network or a separate AS network. The AS may provide IM services. For example, the AS may perform functions of terminating User Agents (UAs), redirect servers, originating UAs, SIP proxies, or third party call control.

CSCF 240 may include a proxy CSCF (P-CSCF), a serving CSCF (S-CSCF), an emergency CSCF (E-CSCF), or an interrogating CSCF (I-CSCF). For example, the P-CSCF may provide a first point of contact for WTRUs within the IMS, the S-CSCF may handle session state, and the I-CSCF may provide a point of contact within the operator' S network for IMS connections destined to subscribers of the network operator or roaming subscribers currently located in the service area of the network operator.

BGF 250 may include an Interconnection Border Control Function (IBCF), a Breakout Gateway Control Function (BGCF), or a transfer gateway (TrGW). Although described as part of a BGF, each of the IBCF, BGCF, or TrGW may represent a different logical entity and may be located in one or more physical entities.

The IBCF may provide dedicated functions on the SIP/SDP protocol layers to perform interconnections between operator domains. For example, the IBCF may enable the following functions: communication between SIP applications, network topology hiding, control of transport plane functions, screening SIP signaling information, selecting the appropriate signaling interconnect, and generating charging data records.

The BGCF may determine the route of the IMS message, e.g., a SIP message. The determination is based on information received in the signaling protocol, management information, or database access. For example, for a PSTN/CS domain terminal, the BGCF may determine in which network a PSTN/CS domain outage may occur, and may select the MGCF.

The TrGW may be located on the media path and may be controlled by the IBCF and may provide network address and port translation, as well as protocol translation.

MGF 260 may include a Media Gateway Control Function (MGCF), a Multimedia Resource Function Controller (MRFC), a Multimedia Resource Function Processor (MRFP), an IP multimedia subsystem-media gateway function (IMS-MGW), or a Media Resource Broker (MRB). Although described as part of an MGF, each of the MGCF, MRFC, MRFP, IMS MGW, or MRB may represent a different logical entity and may be located in one or more physical entities.

The MGCF may control call state connection control of media channels in the IMS; can communicate with CSCF, BGCF and circuit switching network entity; a route for an incoming call from a conventional network may be determined; protocol conversion can be performed between ISUP/TCAP and IM subsystem call control protocol; and may forward those out-of-band information received in the MGCF to the CSCF/IMS-MGW.

MRFC and MRFP may control media stream resources. MRFC and MRFP may mix the input media streams; a media stream may be issued (source), e.g. for multimedia announcements; the media stream may be processed, for example by performing audio transcoding or media analysis; and job (floor) control may be provided, for example by managing access rights to shared resources in a conferencing environment.

The IMS-MGW may terminate bearer channels from the circuit switched network and media streams from the packet network, e.g. RTP streams in an IP network. The IMS-MGW may support media conversion, bearer control and payload processing, such as codecs, echo cancellers or conference bridges. IMS-MGW can interact with MGCF aiming at resource control; resources such as echo cancellers can be managed; a codec may be included. The IMS-MGW may comprise resources for supporting UMTS/GSM transport media.

The MRB may support a heterogeneous MRF resource pool shared by multiple heterogeneous applications. When required by a consuming application, the MRB may specify or release certain MRF resources for the call, depending on, for example, specified MRF attributes. For example, when assigning MRF resources to an application, the MRB may evaluate: a particular characteristic of a media resource required for one or more calls; an application identifier; rules for allocating MRF resources in different applications; SLA or QoS criteria per application or per subscriber; or a capability model for a particular MRF resource.

The SCC AS 270 may provide communication session service continuity, e.g., duplicate, transfer, add, or delete communication session service continuity, between, for example, a plurality of WTRUs in one subscription. The SCC AS may perform access transfer, session transfer or duplication, terminate access domain selection (T-ADS), and process multiple media flows. The SCC AS may merge or split media flows over one or more access networks. For example, when a WTRU requests to add a media flow on an additional access network during session establishment, or when a WTRU requests to add or delete a media flow for an existing session on one or more access networks, the media flows may be split or merged to implement session transfer, session termination.

The communication session may be performed using a communication system between the WTRU and the remote device, such as the communication system shown in fig. 1A, and the WTRU may be, for example, the WTRU shown in fig. 1B. The WTRU may access the communication system via a RAN, such as the RAN shown in figure 1C, or any other wired or wireless access network. The communication session may include a service, such as an IP Multimedia (IM) service provided by IMS as shown in fig. 2.

The WTRU, remote device, or network may control the communication session. For example, communication session control may include starting or stopping media flow, adding or removing media flow, transferring or copying media flow on another WTRU, adjusting bit rate, or terminating communication. For example, the WTRU may initiate a communication session with a remote device. The WTRU may initially control the communication session. The WTRU may transfer or share control of the communication session with a remote device.

Figure 3 shows an example of a communication session 300 between a WTRU 310 and a remote device 320 using IMS. The communication session 300 may include a media flow 330 (media path) and control signaling 340 (control path) between the WTRU 310 and the remote device 320 via a network 350, where the network 350 may be, for example, the IM CN shown in fig. 2. IM CN 350 may include SCC AS 352, AS 354, CSCF 356, and MGF 358.

The communication session 300 may be anchored on an SCC AS 352 associated with the WTRU 310. For example, SCC AS 352 may maintain information about the communication session, such AS a media stream identifier and a control device identifier, and may provide call control for communication session 300. For simplicity, the portion of the communication session between the WTRU 310 and the SCC AS 352 may be referred to AS an access leg (leg), and the portion of the communication session between the SCC AS 352 and the remote device 320 may be referred to AS a remote leg.

To establish the communication session 300 using IMS, the WTRU 310 may initiate a connection (access leg) via the IM CN 350. The WTRU 310 may receive the media stream 330 via the MGF 358 and may receive the control signaling 340 via the CSCF 356. The remote device 320 may participate in the communication session 300 via a remote network (remote segment), such as via the internet 360.

Figure 4 shows an example illustration of a point-to-point communication session 400 between a WTRU 410 and a remote unit 420 using IMS. The communication session 400 may include a media stream 430 and control signaling 440 established via a network, which may include an IM CN 450, such as the one shown in fig. 2. IM CN 450 may include CSCF 452 and MGF 458. In addition, the WTRU 410 may also receive control signals and media streams directly from a remote device without using an IM CN.

To establish the communication session 400 using IMS, the WTRU 410 may initiate a connection (access leg) via the IM CN 450. In the access segment, WTRU 410 may receive media flow 430 via MGF 458 and may receive control signaling 440 via CSCF 452. The WTRU 410, the remote unit 420, or both may maintain communication and may perform call control functions for the communication session 400. Remote device 420 may participate in communication session 400 via a remote network (remote segment), such as via internet 460.

The source WTRU and the target WTRU may be associated via a collaborative session, which may be anchored in a third party, such AS the SCC AS.

The source WTRU may initially control the communication session or may share control with a remote device. The source WTRU may transfer control to the target WTRU or may share control with the target WTRU.

Fig. 5 shows an example illustration of a communication session 500. The source WTRU 510 and the target WTRU 515 may participate in a communication session 500 with a remote device 520 via a network 550, such as the IM CN shown in figure 2. IM CN 550 may include SCC AS 552, AS 554, CSCF 556, and MGF 558.

The communication session 500 may be anchored on an SCC AS 552 associated with the WTRU 510. For simplicity, the portion of the communication session between the WTRU 510/515 and the SCC AS 552 may be referred to AS an access segment, and the portion of the communication session between the SCC AS 552 and the remote device 520 may be referred to AS a remote segment.

On the access segment, the source WTRU 510 and the target WTRU 515 may receive the replicated media flows 570A/570B via MGF 558 and the replicated control signaling 540A/540B via SCC AS 552 and CSCF 556. Remote device 520 may participate in communication session 500 via a remote network, such as via the internet 560.

Fig. 6 shows an example illustration of a replicated point-to-point communication session 600. The source WTRU 610 and the target WTRU 615 may participate in a replicated point-to-point communication session 600 with a remote device 620 via a network 650, which may be, for example, an IM CN as shown in figure 2. IM CN 650 may include CSCF 656 and MGF 658.

For simplicity, the portion of the communication session between WTRU 610/615 and CSCF 656 may be referred to as the access segment, while the portion of the communication session between CSCF 656 and remote device 620 may be referred to as the remote segment.

On the access segment, the source WTRU 610 and the target WTRU 615 may receive the replicated media flows 680A/680B via the MGF 658 and the replicated control signaling 640A/640B via the CSCF 656. Remote device 620 may participate in communication session 600 via a remote network, such as via internet 660. Although fig. 6 shows the media stream as being replicated by MGF 658, the media stream may also be replicated by remote device 620, for example using multiple transmitters.

Fig. 7 shows a diagram of a communication session 700 that includes policy and reporting functionality.

The source WTRU 710 and the target WTRU 715 may participate in a communication session 700 with a remote device 720 via a network 750, which may be, for example, an IM CN as shown in figure 2. IM CN 750 may include SCC AS 752, AS 754, CSCF756, and MGF 758.

The communication session 700 may be anchored on an SCC AS 752 associated with the WTRU 710. For simplicity, the portion of the communication session between WTRU 710/715 and SCC AS 752 may be referred to AS the access segment, and the portion of the communication session between SCC AS 752 and remote device 720 may be referred to AS the remote segment.

On the access segment, the source WTRU 710 and the target WTRU 715 may receive the replicated media flows 770A/770B via the MGF 758, and may receive replicated control signaling 740A/740B via the SCC AS 752 and the CSCF 756. Remote device 720 may participate in communication session 700 via a remote network, such as via the internet 760.

Further, on the access segment, policy function 725 and reporting device 727/729 may provide policy and reporting information to SCC AS 752 via CSCF756, where the policy function may be implemented using a Media Independent Handover (MIH) server, or it may also be an Application Network Discovery and Selection Function (ANDSF).

Policy information for devices located inside the network and for a given network may be accessed via a policy function 725 located in the node and may be stored with profile information for each device and network. The policy function 725 may provide access to policy information via CSCF 756. Policy information may include, but is not limited to: whether a WTRU is part of an implicit collaborative session with another WTRU (part), whether media streams may or may not be transferred between WTRUs, which WTRU is preferred for media streams, the type of media that may or may not be transferred or received by another network, and the type of media that may or may not be transferred or received by another WTRU.

Reporting information for devices located within the network and the designated network may be accessed via one or more reporting functions 727/729 located in one or more nodes. The reporting function may convey the reporting information to SCC AS 752 via CSCF 756. The reporting information may include, but is not limited to: a network overload event, a network location change event, a WTRU location change event, a network indicated WTRU access loss, a WTRU or network indicated imminent loss of WTRU access, and registration of another WTRU.

Fig. 8a1 and 8a2 show examples of IUTs (e.g., voice/video data) 800 that are initiated by the SCC AS810 for another WTRU based on policy and/or profile information.

Session continuity may be provided by transferring session information to the WTRU2804 when the WTRU1802 is active in an IMS session. Session transfer procedures initiated by the SCC AS810 may also be run, controlled and anchored by the SCC AS 810. To perform session transfer, policy function 806 provides policy information to SCC AS 810. The SCC AS810 receives the policy information and initiates a transfer from the WTRU1802 to the WTRU2804 according to the received policy information.

An IMS capable WTRU1802 communicates with the remote party 812 via the SCC AS810 and using SIP signaling. The SIP message may be an IMS control plane message. The IMS-capable WTRU1802, the SCC AS810, and the remote party 812 may establish one or more media flows (e.g., #1 … M) 814. The SCC AS810 is the session anchor and it maintains session state information for all active and inactive sessions.

Prior to the IUT initiating the session, the SCC AS810 may discover that the WTRU2804 is a potential target for session transfer originating from the WTRU1802 by receiving IMS registration information 816 from the WTRU2804 via the CSCF 808. The registration information may include availability information, capability information, or preference information.

The SCC AS810 may request policy information by sending a get policy request 818 to the policy function 806. The get policy request 818 is optional if the policy information is already stored on the SCC AS 810. Policy information may also be received periodically, where the periodic reception may be based on time or based on location, but is not so limited. Further, the registration information may be received periodically, wherein the periodic reception may be based on time or based on location, but is not limited thereto. The registration information may be analyzed against policy information. In response to get policy request 818, policy function 806 sends get policy response 820 to SCC AS 810.

The SCC AS810 may decide to transfer the IMS session information to the WTRU 2804. The decision may be based on one or more pre-configured parameters, profiles, policy information, or input from the user. In addition, the SCC AS810 may determine that the WTRU2804 is part of an implicit collaborative session with the WTRU1802 and that the WTRU2804 is not a preferred candidate for all or some of the media flows. For media streams permitted to be transferred to the WTRU2804, the media streams may be determined based on preconfigured parameters or policy information.

The SCC AS sends an IMS registration response 822 to the WTRU2804 via the CSCF 808 and initiates transfer of the media flow (# n +1 … M) 824 to the WTRU2804 via the CSCF 808. All media streams that are determined not to be transferable to the WTRU2804 based on the policy information of the WTRU2804 may not be transferable to the WTRU 2804. The WTRU2804 sends an update media flow request (e.g., re-invite) 826 to the CSCF 808. CSCF 808 sends the update media flow request 826 to remote party 812. The remote party 812 updates the media flow 827 and sends an update media flow Acknowledgement (ACK) 828 to the WTRU2804 via the CSCF 808. WTRU2804 transmits an initiate media flow transfer response (e.g., notification) 830 to SCC AS810 via CSCF 808. The SCC AS810 sends an IUT release media flow request (# n +1 … M) 832 to the WTRU1802 via the CSCF 808. WTRU1802 releases media flow 834 and exchanges release media flow and SIP terminate (SIP BYE) request 836 with CSCF 808. The WTRU1802 sends an IUT release media flow response 840 to the CSCF 808. CSCF 808 exchanges SIP BYE 838 with remote party 812.

A media stream (# 1 … n) 844 may be established between the WTRU2804 and the remote party 812. The WTRU1802 may exchange media streams (# n +1 … M) 842 with the remote party 812.

At any point in the methods of fig. 8a1 and 8a2, additional operations may be performed between the WTRU1802, WTRU2804, policy function 806, CSCF 808, SCC AS810, and remote party 812 according to IMS IUT procedures. Once the embodiments shown in fig. 8a1 and 8a2 are completed, the WTRU1802 and WTRU2804 may participate in a collaborative session, or the collaborative session may have been transferred to the WTRU 2804.

In an alternative embodiment of fig. 8a1 and 8a2, the SCC AS810 initiates session information IUT based on policy and/or profile information. In this embodiment, the SCC AS810 transmits and receives additional IUT signals. After WTRU2804 sends an update media flow request (e.g., re-invite) 826 to CSCF 808 and before CSCF 808 sends update media flow request 826 to remote party 812, CSCF 808 sends update media flow request 846 to SCC AS810 and SCC AS810 sends response 846. Further, after remote party 812 updates media flow 827 and sends an update media flow ACK 828 to WTRU2804 via CSCF 808, and before WTRU2804 transmits initiate media flow transfer response 830, CSCF 808 sends an update media ACK 848 to SCC AS810, and SCC AS810 sends response 848.

Fig. 8B1 and 8B2 show examples of access transfers (e.g., voice/video data) 850 initiated by SCC AS 858 for another network based on policy and/or profile information.

When the WTRU 851 is active in an IMS session, session continuity may be provided by transferring session information to another network, such as a Radio Access Network (RAN). Session transfer procedures initiated by SCC AS 858 may also be run, controlled and anchored by SCC AS 858. To perform session transfer, policy function 854 provides policy information to SCC AS 858. SCC AS 858 receives the policy information and initiates a transfer from one RAN to another based on the received policy information.

The WTRU 851 communicates with the remote party 860 via the RAN1852 using SIP signaling and via the SCC AS 858. The SIP message may be an IMS control plane message. The WTRU 851 may establish one or more media flows (e.g., #1 … M) 862 via the RAN1852, the SCC AS 858 and the remote party 860. The SCC AS 858 is the session anchor point and it maintains session state information for all active and inactive sessions.

By receiving IMS registration information 864 from RAN2853 via CSCF 856 before initiating a session access transfer, SCC AS 858 may discover that RAN2853 is a potential target for a session transfer originating from RAN 1852. The SCC AS 858 may request policy information by sending a get policy request 866 to the policy function 854. The get policy request 866 is optional if policy information is already available on the SCC AS 858. In response to the get policy request 866, the policy function 854 sends a get policy response 868 to the SCC AS 858.

The SCC AS 858 may decide to transfer IMS session information to the RAN 2853. The decision may be based on one or more pre-configured parameters, profiles, policy information, or input from the user. Additionally, the SCC AS 858 may decide that the RAN2853 is not a preferred candidate for all or some of the media flows. For media streams permitted to be transferred to RAN2853, these media streams may be determined based on preconfigured parameters or policy information.

SCC AS 858 sends an IMS registration response 870 to RAN2853 via CSCF 856 and initiates a media flow transfer (# n +1 … M) 872 to RAN2853 via CSCF 856. For all media streams that are determined not to be transferable to RAN2853 based on the policy information of RAN2853, those media streams may not be transferable to RAN 2853. RAN2853 sends an update media flow request (e.g., re-invite) 874 to CSCF 856. CSCF 856 sends the update media stream request 874 to remote party 860. Remote party 860 updates media flow 876 and sends an update media flow ACK 878 to RAN2853 via CSCF 856. RAN2853 conveys an initiate media flow transfer response (e.g., notification) 880 to SCC AS 858 via CSCF 856. SCC AS 858 sends an access transfer release media flow request (# n +1 … M) 882 to RAN1852 via CSCF 856. RAN1852 releases media flow 884 and exchanges the release media flow with CSCF 856 with SIP BYE request 886. RAN1852 sends an access transfer release media flow response 890 to SCC AS 858 via CSCF 856. CSCF 856 exchanges SIP BYE 888 with remote party 860.

A media stream (# 1 … n) 896 may be established between RAN2853 and remote party 860. RAN1852 may exchange media streams (# n +1 … M) 894 with remote party 860.

At any point in the methods of fig. 8B1 and 8B2, additional operations may be performed between WTRU 851, RAN1852, RAN2853, policy function 854, CSCF 856, SCC AS 858, and remote party 860 in accordance with an IMS access transfer procedure. Once the embodiments shown in fig. 8B1 and 8B2 are completed, the RAN1852 and RAN2853 may participate in the collaborative session, or the session may have been transferred to the RAN 2853.

In an alternative embodiment of fig. 8B1 and 8B2, SCC AS 858 initiates access transfer of session information based on policy and/or profile information. In this embodiment, SCC AS 858 transmits and receives further access transfer signals. After RAN2853 sends update media flow request (e.g., re-invite) 874 to CSCF 856, and before CSCF 856 sends update media flow request 874 to remote party 860, CSCF 856 will send update media flow request 897 to SCC AS 858, and SCC AS 858 will send response 897. Further, after remote party 860 has updated media flow 876 and sent an update media flow ACK 878 to RAN2853 via CSCF 856, and before RAN2853 transmits an initiate media flow transfer response 880, CSCF 856 sends an update media ACK 898 to SCC AS 858 and SCC AS 858 sends a response 898.

Fig. 9a1 and 9a2 show examples of IUTs (e.g., voice/video data) 900 that are initiated by the SCC AS910 for another WTRU based on the reporting information.

Session continuity may be provided by transferring session information to the WTRU2904 while the WTRU1902 is active in an IMS session. Session transfer procedures initiated by the SCC AS910 may also be run, controlled and anchored by the SCC AS 910. To perform session transfer, the reporting function 906 provides reporting information (e.g., the new location of the WTRU) to the SCC AS 910. The SCC AS910 receives the reporting information and initiates a transfer from the WTRU1902 to the WTRU2904 based on the received reporting information.

The SCC AS910 may be informed of an event, such AS a new location of the WTRU, prior to session initiation or session-proceeding IUT. The event may be provided to SCC AS910 by a Media Independent Handover (MIH) server, an Application Network Discovery and Selection Function (ANDSF), or via other reporting nodes. The SCC AS may send a request 914 to register for the event to a reporting function. Explicit event registration is optional. The registration may be based on a configuration procedure.

An IMS-capable WTRU1902 communicates with a remote party 912 via an SCC AS910 and using SIP signaling. The SIP message may be an IMS control plane message. The IMS-capable WTRU1902, SCC AS910, and remote party 912 may establish one or more media flows (e.g., # n +1 … M) 916. Additionally, the IMS-capable WTRU2904, SCC AS910, and remote party 912 may establish one or more media flows (e.g., #1 … n) 918. The SCC AS910 is the session anchor and maintains session state information for all active and inactive sessions.

The SCC AS910 may receive an indication 920 from the reporting function that an event has occurred. For example, the location of the WTRU1902 may change from location 1 to location 2. The SCC AS910 determines 922 that the WTRU2904 is a potential target for session transfer processing at location 1 and performed on some media flows from the WTRU 1902. The SCC AS determines 922 which media flows may be permitted to be transferred to the WTRU 2904. This determination 922 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS910 sends an initiate media flow transfer (# n +1 … p) 924 to the WTRU2904 via the CSCF 908. For all media streams that may be determined to be unable to transfer to the WTRU2904 based on the policy information of the WTRU2904, these media streams may not be transferred to the WTRU 2904. The WTRU2904 sends an update media flow request (e.g., re-invite) 926 to the CSCF 908. CSCF 908 sends the update media stream request 926 to remote party 912. Remote party 912 updates media flow 928 and sends an update media flow ACK 930 to WTRU2904 via CSCF 908. The WTRU2904 transmits an initiate media flow transfer response (e.g., notification) 932 to the SCC AS910 via the CSCF 908. The SCC AS910 sends an IUT release media flow request (# n +1 … M) 934 to the WTRU1902 via the CSCF 908. The WTRU1902 releases the media flow 936 and exchanges the release media flow with the CSCF 908 and the SIP BYE request 938. The WTRU1902 sends an IUT release media flow response 942 to the SCC AS910 via the CSCF 908. CSCF 908 exchanges SIP BYE 940 with remote party 912.

A media stream (# 1 … n) 946 may be established between WTRU2904 and remote party 912. WTRU1902 may exchange a media stream (# n +1 … M) 944 with remote party 912.

At any point in the methods of fig. 9a1 and 9a2, additional operations may be performed between the WTRU1902, the WTRU2904, the reporting function 906, the CSCF 908, the SCC AS910, and the remote party 912 according to IMS IUT procedures. Once the embodiments shown in fig. 9a1 and 9a2 are completed, the WTRU1902 and WTRU2904 may participate in a collaborative session, or the session may have been transferred to WTRU 2904.

In an alternative embodiment of fig. 9a1 and fig. 9a2, SCC AS910 initiates session information IUT based on the reporting information. In this embodiment, the SCC AS910 sends and receives additional IUT signals. After WTRU2904 sends an update media flow request (e.g., re-invite) 926 to CSCF 908, and before CSCF 908 sends the update media flow request 926 to remote party 912, CSCF 908 sends an update media flow request 948 to SCC AS910, and SCC AS910 sends a response 948. Further, after remote party 912 updates media flow 928 and sends an update media flow ACK 930 to WTRU2904 via CSCF 908, and before WTRU2904 transmits an initiate media flow transfer response 932, CSCF 908 sends an update media ACK949 to SCC AS910, and SCC AS910 sends a response 949.

Fig. 9B1 and 9B2 show examples of access transfers (e.g., voice/video data) 950 to another network based on the reported information and initiated by the SCC AS 958.

When WTRU 951 is active in an IMS session via RAN 1952, service continuity may be provided by transferring session information to RAN 2953. Session transfer procedures initiated by SCC AS958 may also be run, controlled, and anchored by SCC AS 958. To perform session transfer, reporting information (e.g., new location of RAN 1) is provided to SCC AS 958. SCC AS958 receives the reporting information from reporting function 954 and initiates a transfer from RAN 1952 to RAN2953 according to the received reporting information.

The SCC AS958 may be notified of an event, such AS a new location of the RAN 1952, prior to session initiation or session access transfer. The SCC AS958 may send a request to register the event 962 to the reporting function 954. Explicit event registration is optional. The registration may be based on a configuration procedure.

The WTRU 951 communicates with the remote party 960 via RAN 1952 and via RAN2953 using SIP signaling and via SCC AS 958. The SIP message may be an IMS control plane message. WTRU 951, via RAN 1952, SCC AS958, and remote party 960, may establish one or more media streams (e.g., # n +1 … M) 964. In addition, WTRU 951, via RAN2953, SCC AS958, and remote party 960, may establish one or more media flows (e.g., #1 … n) 966. The SCC AS958 is the session anchor and maintains session state information for all active and inactive sessions.

SCC AS958 may receive an indication 968 from reporting function 954 indicating that an event occurred. For example, the location of RAN 1952 may have changed from location 1 to location 2. The SCC AS958 determines 970 that the RAN2953 is a potential target for session transfer processing at location 1 and performed on some media flows from the RAN 1952. The SCC AS958 determines 970 which media streams may be permitted to be transferred to the RAN 2953. This determination 970 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS958 sends an initiate media flow transfer (# n +1 … p) 972 to the RAN2953 via the CSCF 956. For all media streams that are determined not to be transferable to RAN2953 based on the policy information of RAN2953, those media streams may not be transferable to RAN 2953. RAN2953 sends an update media flow request (e.g., re-invite) 974 to CSCF 956. CSCF956 sends the update media stream request 974 to remote party 960. Remote party 960 updates media flow 976 and sends an update media flow ACK 978 to RAN2953 via CSCF 956. The RAN2953 conveys an initiate media stream transfer response (e.g., notification) 980 to the SCC AS958 via CSCF 956. The SCC AS958 sends an access transfer release media flow request (# n +1 … p) 984 to the RAN 1952 via CSCF 956. RAN 1952 releases media stream 986 and exchanges the release media stream with CSCF956 and SIP BYE request 988. RAN 1952 sends an access transfer release media flow response 992 to SCC AS958 via CSCF 956. CSCF956 exchanges SIP BYE 990 with remote party 960.

A media flow (# 1 … p) 996 may be established between RAN2953 and remote party 960. RAN 1952 may exchange media streams (# p +1 … M) 994 with remote party 960.

At any point in the methods of fig. 9B1 and 9B2, additional operations may be performed between the WTRU 1951, RAN 1952, RAN2953, reporting function 954, CSCF956, SCC AS958, and remote party 960 according to an IMS access transfer procedure. Once the embodiments shown in fig. 9B1 and 9B2 are complete, the RAN 1952 and RAN2953 may participate in a collaborative session, and the session may have been transferred to the RAN 2953.

In an alternative embodiment of fig. 9B1 and 9B2, SCC AS958 initiates access transfer of session information based on the reported information. In this embodiment, SCC AS958 sends and receives additional access transfer signals. After RAN2953 sends an update media flow request (e.g., re-invite) 974 to CSCF956, and before CSCF956 sends the update media flow request 974 to remote party 960, CSCF956 sends an update media flow request 997 to SCC AS958, and SCC AS958 sends a response 997. Further, after remote party 960 has updated media flow 976 and sent an update media flow ACK 978 to RAN2953 via CSCF956, and before RAN2953 conveys an initiate media flow transfer response 980, CSCF956 sends an update media ACK 998 to SCC AS958, and that SCC AS958 sends a response 998.

Fig. 10a1 and fig. 10a2 show examples of load balancing IUTs (e.g., voice/video data) 1000 initiated by the SCC AS 1010 between WTRUs based on reporting information.

Service continuity and load balancing may be provided by transferring session information to WTRU21004 when WTRU11002 is active in an IMS session. Session transfer procedures initiated by the SCC AS 1010 may also be run, controlled and anchored by the SCC AS 1010. To perform session transfer, reporting function 1006 provides reporting information (e.g., a network overload event) to SCC AS 1010. The SCC AS 1010 receives the reporting information and initiates a transfer from WTRU11002 to WTRU21004 based on the received reporting information.

Prior to initiating a session or performing a session IUT, the SCC AS 1010 may be notified of an event such AS a network overload event. The SCC AS 1010 may send a request to the reporting function 1006 to register 1014 the event. Explicit event registration is optional. The registration may be based on a configuration procedure.

An IMS-capable WTRU11002 communicates with a remote party 1012 using SIP signaling and via an SCC AS 1010. The SIP message may be an IMS control plane message. An IMS-capable WTRU11002, SCC AS 1010, and remote party 1012 may establish one or more media flows (e.g., # n +1 … M) 1016. Additionally, an IMS-capable WTRU21004, SCCAS 1010, and remote party 1012 may establish one or more media streams (e.g., #1 … n) 1018. The SCC AS 1010 is the session anchor and maintains session state information for all active and inactive sessions.

The SCC AS 1010 may receive an indication 1020 from the reporting function that an event has occurred. For example, SCC AS 1010 may receive information about network overload event 1020. The SCC AS 1010 determines that the WTRU21004 is a potential target and may be used to transfer session information, where the determination may be made based on whether the access technology of the WTRU21004 may offload session information from the congested network of the WTRU 11002. The SCC AS determines 1022 which media streams may be permitted to be transferred to the WTRU 2. The determination 1022 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS 1010 sends an initiate media flow transfer (# n +1 … p) request 1024 to the WTRU21004 via the CSCF 1008. For all media flows that may be determined not to be transferable to the WTRU21004 based on the policy information of the WTRU21004, the media flows may not be transferable to the WTRU 21004. WTRU21004 sends an update media flow request (e.g., re-invite) 1026 to CSCF 1008. CSCF1008 sends the update media stream request 1026 to remote party 1012. Remote party 1012 updates media flow 1028 and sends an update media flow ACK 1030 to WTRU21004 via CSCF 1008. The WTRU21004 transmits an initiate media flow transfer response (e.g., notification) 1032 to the SCC AS 1010 via the CSCF 1008. The SCC AS 1010 sends an IUT release media flow request (# n +1 … M) 1034 to the WTRU11002 via the CSCF 1008. WTRU11002 releases media flow 1036 and exchanges the release media flow with CSCF1008 and SIP BYE request 1038. The WTRU11002 sends an IUT release media flow response 1042 to the SCC AS 1010 via the CSCF 1008. CSCF1008 exchanges SIP BYE 1040 with remote party 1012.

A media stream (# 1 … M) 1046 may be established between the WTRU21004 and the remote party 1012.

At any point in the methods of fig. 10a1 and 10a2, additional operations may be performed between the WTRU11002, WTRU21004, reporting function 1006, CSCF1008, SCC AS 1010, and remote party 1012 according to IMS IUT processing. Once the embodiments shown in fig. 10a1 and fig. 10a2 are completed, WTRU11002 and WTRU21004 may participate in a collaborative session, or the session may have been transferred to WTRU 21004.

Fig. 10B1 and 10B2 show examples of load balancing access transfers (e.g., voice/video data) 1050 initiated by the SCC AS 1058 between networks based on the reported information.

Service continuity and load balancing may be provided by transferring session information from the RAN 11052 to the RAN21053 when the WTRU 1051 is active in an IMS session. Session transfer procedures initiated by SCC AS 1058 may also be run, controlled, and anchored by SCC AS 1058. To perform the session transfer, reporting information (e.g., a network overload event) may be provided to the SCC AS 1058. SCC AS 1058 receives the reporting information and initiates a transfer from RAN 11052 to RAN21053 in accordance with the received reporting information.

SCC AS 1058 may be notified of an event, such AS a network overload event for RAN 11052, prior to initiating a session or performing an access transfer of the session. SCC AS 1058 may send a request 1062 for a registration event to reporting function 1054. Explicit event registration is optional. The registration may be based on a configuration procedure.

The WTRU 1051 communicates with the remote party 1060 via the RAN 11052 and via the RAN21053 using SIP signaling and via the SCC AS 1058. The SIP message may be an IMS control plane message. The WTRU 1051 may establish one or more media streams (e.g., # n +1 … M) 1064 via the RAN 11052, the SCC AS 1058, and the remote party 1060. In addition, the WTRU 1051 may establish one or more media flows (e.g., #1 … n) 1066 via the RAN21053, SCC AS 1058, and remote party 1060. The SCC AS 1058 is the session anchor and maintains session state information for all active and inactive sessions.

SCC AS 1058 may receive an indication from reporting function 1054 that an event 1068 occurred. For example, the SCC AS may receive information about a network overload event 1068. SCC AS 1058 determines that RAN21053 is a potential target and is available to transfer session information, where the determination may be made based on whether the access technology of RAN21053 can offload session information from the congested network of RAN 11052. SCC AS 1058 determines 1070 which media streams may be permitted to be transferred to RAN 21053. The determination 1053 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

SCC AS 1058 sends an initiate media flow transfer (# n +1 … M) request 1072 to RAN21053 via CSCF 1056. For all media streams that are determined not to be transferable to RAN21053 based on policy information of RAN21053, those media streams may not be transferable to RAN 21053. RAN21053 sends an update media flow request (e.g., re-invite) 1074 to CSCF 1056. CSCF1056 sends the update media stream request 1074 to remote party 1060. Remote party 1060 updates media flow 1076 and sends an update media flow ACK 1078 to RAN21053 via CSCF 1056. RAN21053 conveys an initiate media stream transfer response (e.g., notification) 1080 to SCC AS 1058 via CSCF 1056. SCC AS 1058 sends an access transfer release media flow request (# n +1 … M) 1082 to RAN 11052 via CSCF 1056. RAN 11052 releases media flow 1084 and exchanges the release media flow and SIP BYE request 1086 with CSCF 1056. RAN 11052 sends an access transfer release media flow response 1090 to SCC AS 1058 via CSCF 1056. The CSCF exchanges SIP BYE 1088 with the remote party 1060.

A media stream (# 1 … M) 1094 can be established between RAN21053 and remote party 1060.

At any point in the methods of fig. 10B1 and 10B2, additional operations may be performed between the WTRU 1051, RAN 11052, RAN21053, reporting function 1054, CSCF1056, SCC AS 1058, and remote party 1060 in accordance with the IMS access transfer procedure. Once the embodiments shown in fig. 10B1 and fig. 10B2 are implemented, RAN 11052 and RAN21053 may be participating in a collaborative session, or the session may have been transferred to RAN 21053.

Fig. 11a1 and 11a2 show examples of IUT fallback (e.g. voice/video data) 1100 initiated by SCC AS1105 based on reporting information.

When WTRU11101 is active in an IMS session, session continuity may be provided by transferring session information to WTRU 21102. To perform the session transfer, reporting information (e.g., registration information) is provided for the SCC AS 1105. The SCC AS1105 receives the report information and initiates a transfer from WTRU11101 to WTRU 21102. The SCC AS1105 may also receive report information indicating an event, such AS a loss of access for the WTRU 11101. The SCC AS1105 may initiate session information fallback (e.g., transfer) for the WTRU21102 based on the reporting information. An indication that the transfer is a fallback IUT transfer may also be sent. The SCC AS1105 may be notified of an event, such AS an access network loss event, prior to initiating a session or conducting a session IUT. The SCC AS1105 may send a request 1107 for a registration event to the reporting function 1103. Explicit event registration is optional. The registration may be based on a configuration procedure.

An IMS capable WTRU11101 communicates with the remote party 1106 using SIP signaling and via the SCC AS 1105. The SIP message may be an IMS control plane message. The IMS-capable WTRU11101, SCC AS1105, and the remote party 1106 may establish one or more media flows (e.g., # n +1 … M) 1108. Additionally, the IMS-capable WTRU21102, SCC AS1105, and the remote party 1106 may establish one or more media flows (e.g., #1 … n) 1109. The SCC AS1105 is the session anchor and maintains session state information for all active and inactive sessions.

SCC AS1105 may receive an indication 1110 from reporting function 1103 indicating that an event occurred. For example, SCC AS1105 may receive information about access network loss event 1110. The SCC AS1105 determines 1112 that the WTRU21102 is a potential target and available for transferring session information. The SCC AS1105 determines 1112 which media flows may be permitted to be transferred to the WTRU 21102. The determination may be made based on one or more pre-configured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS1105 sends an initiate media flow transfer (# n +1 … M) request 1113 to the WTRU21102 via the CSCF 1104. All media streams that may be determined to be unable to transfer to WTRU21102 based on the policy information of WTRU21102 may not be transferred to WTRU 21102. WTRU21102 sends an update media flow request (e.g., re-invite) 1114 to SCC AS1105 via CSCF 1104. SCC AS1105 sends an update media flow request 1114 back to CSCF1104, and CSCF1104 sends the update media flow request 1114 to remote party 1106. Remote party 1106 updates media flow 1115 and sends update media flow response 1116 to CSCF 1104. The CSCF1104 then sends a response 1116 to the SCC AS1105, and the SCC AS1105 sends the response 1116 to the WTRU 21102. WTRU21102 transmits an IUT media flow ACK 1117 to SCC AS1105 via CSCF 1104.

A media flow (# 1 … M) 1118 may be established between the WTRU21102 and the remote party 1106.

At any point in the methods of fig. 11a1 and 11a2, additional operations may be performed between the WTRU11101, the WTRU21102, the reporting function 1103, the CSCF1104, the SCC AS1105, and the remote party 1106 in accordance with IMS IUT procedures. Once the embodiments shown in fig. 11a1 and 11a2 are completed, WTRU11101 and WTRU21102 may participate in a collaborative session, or the session may be transferred to WTRU 21102.

Fig. 11B1 and 11B2 show examples of access transfer fallback (e.g., voice/video data) 1125 initiated by the SCC AS1131 based on the reporting information.

Service continuity may be provided by transferring session information from the RAN 11127 to the RAN21128 when the WTRU 1126 is active in an IMS session. To perform session transfer, reporting information (e.g., registration information) is provided for the SCC AS 1131. The SCC AS1131 receives the reporting information and initiates a transfer from the RAN 11127 to the RAN 21128. The SCC AS may also receive reporting information indicating an event, such AS a loss of access by the RAN 11127. The SCC AS1131 may initiate a session information fallback (e.g., transfer) to the RAN21128 based on the reporting information.

The SCC AS1131 may be informed of an event, such AS an access network loss event, before initiating a session or performing a session IUT. The SCC AS1131 may send a request to the reporting function 1129 for a registration event 1133. Explicit event registration is optional. The registration may be based on a configuration procedure.

The WTRU 1126 communicates with the remote party 1132 using SIP signaling via the RAN 11127 and via the SCC AS 1131. The SIP message may be an IMS control plane message. The WTRU 1126 may establish one or more media streams (e.g., # n +1 … M) 1134 via the RAN 11128, SCC AS1131, and remote party 1132. Additionally, the WTRU 1126 may establish one or more media streams (e.g., #1 … n) 1135 via the RAN21128, SCC AS1131, and remote party 1132. The SCC AS1131 is the session anchor and maintains session state information for all active and inactive sessions.

The SCC AS1131 may receive an indication from the reporting function 1129 that an event has occurred. For example, the SCC AS1131 may receive information about an access network loss event 1136. The SCC AS1131 determines that the RAN21128 is a potential target and is available for transferring session information. The SCC AS1131 determines 1137 which media streams may be permitted to be transferred to the RAN 21128. This determination 1137 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS1131 sends an initiate media flow transfer (# n +1 … M) request 1138 to the RAN21128 via the CSCF 1130. All media streams determined to be unable to be transferred to the RAN21128 based on the policy information of the RAN21128 may not be transferred to the RAN 21128. The RAN21128 sends an update media flow request (e.g., re-invite) 1139 to the SCC AS1131 via CSCF 1130. SCC AS1131 sends an update media flow request 1139 back to CSCF 1130, which CSCF 1130 sends the update media flow request 1139 to remote party 1132. Remote party 1132 updates media flow 1140 and sends an update media flow response 1141 to CSCF 1130. The CSCF 1130 sends the response 1141 to the SCC AS1131, and the SCC AS1131 sends the response 1141 to the RAN 21128. RAN21128 transmits an access transfer media flow ACK 1142 to SCC AS1131 via CSCF 1130.

A media stream (# 1 … M) 1143 may be established between RAN21128 and remote party 1132.

At any point in the methods of fig. 11B1 and 11B2, additional operations may be performed between the WTRU 1126, RAN 11127, RAN21128, reporting function 1129, CSCF 1130, SCC AS1131, and remote party 1132 in accordance with an IMS access transfer procedure. Once the embodiments shown in fig. 11B1 and 11B2 are completed, the RAN 11127 and the RAN21128 may participate in a collaborative session, or the session may have been transferred to the RAN 21128.

Fig. 11C1 and 11C2 show an alternative embodiment 1150 of fig. 11a1 and 11a 2.

Service continuity may be provided by transferring session information to the WTRU21152 while the WTRU 11151 is active in an IMS session. To perform session transfer, the reporting function 1153 provides reporting information (e.g., registration information) to the SCC AS 1155. The SCC AS1155 receives the report information and initiates a transfer from WTRU 11151 to WTRU 21152. The SCC AS1155 may also receive reporting information indicating an event, such AS a loss of access by the WTRU 11151. The SCC AS1155 may initiate session information fallback (e.g., transfer) for the WTRU21152 based on the reporting information.

Prior to initiating a session or conducting a session IUT, the SCC AS1155 may be notified of an event, such AS an access network loss event. The SCC AS1155 may send a registration event request 1157 to the reporting function 1153. Explicit event registration is optional. The registration may be based on a configuration procedure.

The IMS capable WTRU 11151 communicates with the remote party 1156 using SIP signaling and via the SCC AS 1155. The SIP message may be an IMS control plane message. The IMS capable WTRU 11151, SCC AS1155, and remote party 1156 may establish one or more media flows (e.g., # n +1 … M) 1159. Additionally, the IMS-capable WTRU21152, SCC AS1155, and remote party 1156 may establish one or more media flows (e.g., #1 … n) 1159. The SCC AS1155 is the session anchor point and maintains session state information for all active and inactive sessions.

The SCC AS1155 may receive an indication 1160 from the reporting function 1153 indicating that an event has occurred. For example, SCC AS1155 may receive information regarding access network loss events 1160. The SCC AS1155 determines 1161 that the WTRU21152 is a potential target and may be used for session information transfer. The SCC AS1155 determines 1161 which media streams may be permitted to be transferred to the WTRU 21152. The determination 1161 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS1155 sends an initiate media flow transfer (# n +1 … M) request 1162 to the WTRU21152 via the CSCF 1154. All media flows that may be determined to be unable to transfer to the WTRU21152 based on the policy information of the WTRU21152 may not be transferred to the WTRU 21152. The WTRU21152 sends an update media flow request (e.g., re-invite) 1164 to the remote party 1156 via the CSCF 1154. Remote party 1156 updates media flow 1165 and sends an update media flow response 1166 to CSCF 1154. The CSCF 1154 sends an initiate media flow transfer (# n +1 … M) request 1167 to the WTRU 21152. The WTRU21152 transmits an update media response 1166 to the SCC AS1155 via the CSCF 1154.

A media flow (# 1 … M) 1168 may be established between the WTRU21152 and the remote party 1156.

At any point in the methods of fig. 11C1 and 11C2, additional operations may be performed between the WTRU 11151, the WTRU21152, the reporting function 1153, the CSCF 1154, the SCC AS1155, and the remote party 1156 in accordance with IMS IUT procedures. Once the embodiments shown in fig. 11C1 and 11C2 are completed, the WTRU 11151 and WTRU21152 may participate in a collaborative session, or the session may have been transferred to the WTRU 21152.

Fig. 11D1 and 11D2 show an alternative embodiment 1175 of fig. 11B1 and 11B 2. Service continuity may be provided by transferring session information from the RAN 11177 to the RAN 21178 while the WTRU 1176 is active in an IMS session. To perform session transfer, reporting function 1179 provides reporting information (e.g., registration information) to SCC AS 1181. The SCC AS1181 receives the report information and initiates a transfer from the RAN 11177 to the RAN 21178. The SCC AS1181 may also receive reporting information indicating an event, such AS an access loss of the RAN 11177. The SCC AS1181 may initiate a session information fallback (e.g., transfer) to the RAN 21178 based on the reported information.

SCC AS1181 may be notified of an event, such AS an access network loss event, prior to initiating a session or conducting a session transfer. The SCC AS1181 may send a registration event request 1183 to a reporting function 1179. Explicit event registration is optional. The registration may be based on a configuration procedure.

The WTRU 1176 communicates with a remote party 1182 via the RAN 11177 using SIP signaling and via the SCC AS 1181. The SIP message may be an IMS control plane message. The WTRU 1176 may establish one or more media streams (e.g., # n +1 … M) 1184 via the RAN 11177, SCC AS1181, and remote party 1182. In addition, the WTRU 1176 may establish one or more media streams (e.g., #1 … n) 1185 via the RAN 21178, SCC AS1181, and remote party 1182. The SCC AS1181 is the session anchor and maintains session state information for all active and inactive sessions.

SCC AS1181 may receive an indication 1186 from reporting function 1179 indicating that an event has occurred. For example, SCC AS1181 may receive information regarding access network loss event 1186. SCC AS1181 determines that RAN 21178 is a potential target and is available to transfer session information. The SCC AS1181 determines 1187 which media streams may be permitted to be transferred to the RAN 21178. The determination 1187 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

SCC AS1181 sends an initiate media stream transfer (# n +1 … M) request 1188 to RAN 21178 via CSCF 1180. All media streams determined to be unable to be transferred to RAN 21178 based on the policy information of RAN 21178 may not be transferred to RAN 21178. RAN 21178 sends an update media flow request (e.g., re-invite) 1190 to remote party 1182 via CSCF 1180. Remote party 1182 updates media stream 1191 and sends an update media stream response 1192 to CSCF 1180. CSCF1180 sends an initiate media stream transfer (# n +1 … M) 1193 to RAN 21178. RAN 21178 conveys an update media response 1192 to SCC AS1181 via CSCF 1180.

A media stream (# 1 … M) 1194 can be established between RAN 21178 and remote party 1182.

At any point in the methods of fig. 11D1 and 11D2, additional operations may be performed between the WTRU 1176, RAN 11177, RAN 21178, reporting function 1179, CSCF1180, SCC AS1181, and remote party 1182 in accordance with an IMS access transfer procedure. Once the embodiments shown in fig. 11D1 and 11D2 are completed, the RAN 11177 and RAN 21178 may participate in the collaborative session, or the session may have been transferred to the RAN 21177.

Fig. 12a1 and 12a2 show examples of IUTs 1200 based on reporting information related to radio coverage events and session information (e.g., voice/video data) initiated by SCC AS 1210.

Service continuity may be provided by transferring session information to WTRU21204 while WTRU 11202 is active in an IMS session. To perform session transfer, the reporting function 1206 may provide reporting information based on the radio coverage event to the SCC AS 1210. The SCC AS1210 receives the reporting information and initiates a transfer from WTRU 11202 to WTRU21204 based on the received reporting information.

Prior to session initiation or IUT handling of the session, the SCC AS1210 may be notified of an event, such AS the WTRU 11202 coming to lose the current access network. The SCC AS1210 may send a registration event request 1214 to the reporting function 1206. Explicit event registration is optional. The registration may be based on a configuration procedure.

An IMS-capable WTRU 11202 communicates with a remote party 1212 using SIP signaling and via an SCC AS 1210. The SIP message may be an IMS control plane message. The IMS-capable WTRU 11202, SCC AS1210, and remote party 1212 may establish one or more media flows (e.g., # n +1 … M) 1216. Additionally, the IMS-capable WTRU21204, SCC AS1210, and remote party 1212 may establish one or more media flows (e.g., #1 … n) 1218. The SCC AS1210 is the session anchor and maintains session state information for all active and inactive sessions.

The SCC AS1210 may receive an indication 1220 from the reporting function 1206 indicating an impending event. For example, the SCC AS1210 may receive information 1220 that the WTRU 11202 is about to lose the current access network. The SCC AS1210 determines that the WTRU21204 is a potential target and may be used to transfer session information. The SCC AS1210 determines 1222 which media flows may be permitted to be transferred to the WTRU 21204. The determination 1222 may be made based on one or more pre-configured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS1210 sends an initiate media flow transfer (# n +1 … M) request 1224 to the WTRU21204 via the CSCF 1208. All media flows that may be determined not to be transferable to the WTRU21204 based on the policy information of the WTRU21204 may not be transferable to the WTRU 21204. The WTRU21204 sends an update media flow request (e.g., re-invite) 1226 to the CSCF 1208. The CSCF1208 sends an update media stream request 1226 to the remote party 1212. Remote party 1212 updates media flow 1228 and sends an update media flow ACK1230 to WTRU21204 via CSCF 1208. The WTRU21204 transmits an initiate media flow transfer response (e.g., notification) 1232 to the SCC AS1210 via CSCF 1208. The SCC AS1210 sends an IUT release media flow request (# n +1 … M) 1234 to the WTRU 11202 via the CSCF 1208. WTRU 11202 releases media flow 1236 and exchanges the release media flow with CSCF1208 along with SIP BYE request 1238. WTRU 11202 sends an IUT release media flow response 1242 to CSCF 1208. The CSCF1208 exchanges SIP BYE1240 with the remote party 1212.

A media stream (# 1 … M) 1244 may be established between WTRU21204 and remote party 1212.

At any point in the methods of fig. 12a1 and 12a2, additional operations may be performed between the WTRU 11202, the WTRU21204, the reporting function 1206, the CSCF1208, the SCC AS1210, and the remote party 1212 in accordance with IMS IUT procedures. Once the embodiments shown in fig. 12a1 and 12a2 are completed, WTRU 11202 and WTRU21204 may participate in the collaborative session, or the session may be transferred to WTRU 21204.

In an alternative embodiment of fig. 12a1 and 12a2, SCC AS1210 initiates IUT of session information based on radio coverage events. In this embodiment, the SCC AS1210 sends and receives additional IUT signals. After WTRU21204 sends an update media flow request (e.g., re-invite) 1226 to CSCF1208, and before CSCF1208 sends the update media flow request 1226 to remote party 1212, CSCF1208 sends the update media flow request 1246 to SCC AS1210, and SCC AS1210 sends a response to the CSCF. Further, after remote party 1212 updates media flow 1228 and sends update media flow ACK1230 to WTRU21204 via CSCF1208, and before WTRU21204 transmits initiate media flow transfer response 1232, CSCF1208 sends update media ACK 1248 to SCC AS1210, and SCC AS1210 sends response 1248 to CSCF 1208.

Fig. 12B1 and 12B2 show examples of access transfers 1250 of session information (e.g., voice/video data) initiated by SCC AS 1258 based on reported information related to radio coverage events.

Service continuity may be provided by transferring session information to RAN21253 when RAN 11252 is active in an IMS session. To perform session transfer, reporting information based on radio coverage events may be provided to SCC AS 1258. The SCC AS 1258 receives the reporting information from the reporting function 1254 and initiates a transfer from the RAN 11252 to the RAN 21253.

Prior to initiating a session or performing an access transfer for a session, SCC AS 1258 may be notified of an event, such AS the impending loss of the current access network by RAN 11252. The SCC AS 1258 may send a registration event request 1262 to the reporting function 1254. Explicit event registration is optional. The registration may be based on a configuration procedure.

The WTRU 1251 communicates with the remote party 1260 via the RAN 11252 using SIP signaling and via the SCC AS 1258. The SIP message may be an IMS control plane message. The WTRU 1251 may establish one or more media flows (e.g., # n +1 … M) 1264 via the RAN 11252, the SCC AS 1258, and the remote party 1260. In addition, the WTRU 1251 may establish one or more media flows (e.g., #1 … n) 1266 via the RAN21253, the SCC AS 1258, and the remote party 1260. The SCC AS 1258 is a session anchor point and maintains session state information for all active and inactive sessions.

The SCC AS 1258 may receive an indication 1268 from the reporting function indicating an impending event. For example, the SCC AS 1258 may receive information 1268 that the RAN 11252 is about to lose the current access network. The SCC AS 1258 determines 1270 that RAN21253 is a potential target and available to transfer session information. The SCC AS 1258 determines 1270 which media streams may be permitted to be transferred to the RAN 21253. The determination 1270 may be made based on one or more preconfigured parameters, profiles, policy information, reporting information, or input from a user.

The SCC AS 1258 sends an initiate media flow transfer (# n +1 … M) request 1272 to the RAN21253 via the CSCF 1256. All media streams determined to be unable to be transferred to RAN21253 based on the policy information of RAN21253 may not be transferred to RAN 21253. RAN21253 sends an update media flow request (e.g., re-invite) 1274 to CSCF 1256. CSCF1256 sends the update media flow request 1274 to remote party 1260. Remote party 1260 updates media flow 1276 and sends an update media flow ACK1278 to RAN21253 via CSCF 1256. RAN21253 conveys an initiate media stream transfer response (e.g., notification) 1280 to SCC AS 1258 via CSCF 1256. The SCC AS 1258 sends an access transfer release media flow request (# n +1 … M) 1282 to the RAN 11252 via the CSCF 1256. RAN 11252 releases media flow 1284 and exchanges the release media flow and SIP BYE request 1286 with CSCF 1256. RAN 11252 sends an access transfer release media flow response to CSCF 1290. CSCF1256 exchanges SIP BYE 1288 with remote party 1260.

A media stream (# 1 … M) 1292 can be established between RAN21253 and remote party 1260.

At any point in the methods of fig. 12B1 and 12B2, additional operations may be performed between the WTRU 1251, RAN 11252, RAN21253, reporting function 1254, CSCF1256, SCC AS 1258, and remote party 1260 according to IMS IUT procedures. Once the embodiments shown in fig. 12B1 and fig. 12B2 are complete, RAN 11252 and RAN21253 may participate in a collaborative session, or the session may have been transferred to RAN 21253.

In an alternative embodiment of fig. 12B1 and 12B2, SCC AS 1258 initiates an access transfer of session information based on a radio coverage event. In this embodiment, SCC AS 1258 sends and receives additional access transfer signals. After RAN21253 sends an update media flow request (e.g., re-invite) 1274 to CSCF1256, and before CSCF1256 sends the update media flow request 1274 to remote party 1260, CSCF1256 sends an update media flow request 1293 to SCC AS 1258, and SCC AS 1258 sends a response 1293 to CSCF 1256. Further, after remote party 1260 has updated media flow 1276 and sent an update media flow ACK1278 to RAN21253 via CSCF1256, and before RAN 21256 transmits an initiate media flow transfer response 1280, CSCF1256 sends an update media ACK 1294 to SCC AS 1258, and SCC AS 1258 sends a response 1294 to CSCF 1256.

Examples

1. A service centralization and continuity application server (SCC AS) for initiating inter-user equipment transfer (IUT) of an IP Multimedia (IM) Subsystem (IMs) media session, the SCC AS comprising:

a receiver configured to receive information, wherein the information comprises availability information, capability information, or preference information.

2. The SCC AS of embodiment 1, further comprising:

a processor configured to process the information to determine IUT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and initiate IUT.

3. The SCC AS of any of embodiments 1-2, further comprising:

a transmitter configured to transmit an IUT request to a target device.

4. An SCC AS in any of embodiments 1-3 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

5. The SCC AS of embodiment 4 wherein the policy information and/or profile information includes whether the first WTRU is part of an implicit collaborative session with a second WTRU, whether a media session may be transferred between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

6. The SCC AS according to any of embodiments 1-5, wherein the information is reporting information and the reporting information is received from a reporting function node.

7. The SCC AS of embodiment 6 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

8. A service centralization and continuity application server (SCC AS) for initiating Access Transfer (AT) of an IP Multimedia (IM) Subsystem (IMs) media session, the SCC AS comprising:

a receiver configured to receive information, wherein the information comprises availability information, capability information, or preference information.

9. The SCC AS of embodiment 8, further comprising:

a processor configured to process the information to determine AT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and to initiate an AT.

10. The SCC AS in any one of embodiments 8-9, further comprising:

a transmitter configured to transmit an AT request to a target device.

11. The SCC AS in any one of embodiments 8-10 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

12. The SCC AS of embodiment 11 wherein the policy information and/or profile information includes whether the first WTRU is part of an implicit collaborative session with the second WTRU, whether a media session may be transferred between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

13. An SCC AS in any of embodiments 8-12 wherein the information is reporting information and the reporting information is received from a reporting function node.

14. The SCC AS of embodiment 13 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

15. A method for inter-user equipment transfer (IUT) of an IP Multimedia (IM) Subsystem (IMs) media session initiated by a service centralization and continuity application server (SCC AS), the method comprising:

information is received, wherein the information includes availability information, capability information, or preference information.

16. The method of embodiment 15, further comprising:

the information is processed to determine IUT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and initiate IUT.

17. The method as in any one of embodiments 15-16, further comprising:

an IUT request is transmitted to the target device.

18. A method as in any of embodiments 15-17 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

19. The method of embodiment 18 wherein the policy information and/or profile information includes whether the first WTRU is part of an implicit collaborative session with the second WTRU, whether a media session may be transferred between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

20. A method as in any of embodiments 15-19 wherein the information is reporting information and the reporting information is received from a reporting function node.

21. The method of embodiment 20 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

22. A method for Access Transfer (AT) of an IP Multimedia (IM) Subsystem (IMs) media session initiated by a service centralization and continuity application server (SCC AS), the method comprising:

information is received, wherein the information includes availability information, capability information, or preference information.

23. The method of embodiment 22, further comprising:

the information is processed to determine AT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and to initiate an AT.

24. The method as in any one of embodiments 22-23, further comprising:

an AT request is transmitted to the target device.

25. A method as in any of embodiments 22-25 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

26. The method of embodiment 25 wherein the policy information and/or profile information includes whether the first WTRU is part of an implicit collaborative session with the second WTRU, whether a media session may be transferred between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

27. A method as in any of embodiments 22-26 wherein the information is reporting information and the reporting information is received from a reporting function node.

28. The method of embodiment 27 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, another WTRU registration, a load balancing event.

Although the features and elements of the present invention are described in the particular combinations disclosed above, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, Read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (20)

1. A service centralization and continuity application server (SCC AS) for initiating inter-user equipment transfer (IUT) of an IP Multimedia (IM) Subsystem (IMs) media session, the SCC AS comprising:

a receiver configured to receive information, wherein the information comprises availability information, capability information, or preference information;

a processor configured to process the information to determine IUT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and initiate IUT; and

a transmitter configured to transmit an IUT request to a target device.

2. The SCC AS of claim 1 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

3. The SCC AS of claim 2 wherein the policy information and/or the profile information includes whether a first WTRU is part of an implicit collaborative session with a second WTRU, whether the media session is transferrable between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

4. The SCC AS of claim 1 wherein the information is reporting information and the reporting information is received from a reporting function node.

5. The SCC AS of claim 4 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

6. A service centralization and continuity application server (SCC AS) for initiating Access Transfer (AT) of an IP Multimedia (IM) Subsystem (IMs) media session, the SCC AS comprising:

a receiver configured to receive information, wherein the information comprises availability information, capability information, or preference information;

a processor configured to process the information to determine AT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and to initiate an AT; and

a transmitter configured to transmit an AT request to a target device.

7. The SCC AS of claim 6 wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

8. The SCC AS of claim 7 wherein the policy information and/or the profile information includes whether a first WTRU is part of an implicit collaborative session with a second WTRU, whether the media session is transferrable between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media flow transfer.

9. The SCC AS of claim 6 wherein the information is reporting information and the reporting information is received from a reporting function node.

10. The SCC AS of claim 9 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

11. A method for inter-user equipment transfer (IUT) of an IP Multimedia (IM) Subsystem (IMs) media session initiated by a service centralization and continuity application server (SCC AS), the method comprising:

receiving information, wherein the information comprises availability information, capability information, or preference information;

processing the information to determine IUT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and initiate IUT; and

an IUT request is transmitted to the target device.

12. The method of claim 11, wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

13. The method of claim 12, wherein the policy information and/or the profile information includes whether a first WTRU is part of an implicit collaborative session with a second WTRU, whether the media session is transferrable between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media stream transfer.

14. The method of claim 11, wherein the information is reporting information and the reporting information is received from a reporting function node.

15. The method of claim 14 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.

16. A method for Access Transfer (AT) of an IP Multimedia (IM) Subsystem (IMs) media session initiated by a service centralization and continuity application server (SCC AS), the method comprising:

receiving information, wherein the information comprises availability information, capability information, or preference information;

processing the information to determine AT capabilities of one or more IMS-capable wireless transmit/receive units (WTRUs) and to initiate an AT; and

an AT request is transmitted to the target device.

17. The method of claim 16, wherein the information is policy information and/or profile information and the policy information is received from a policy function node.

18. The method of claim 17, wherein the policy information and/or the profile information includes whether a first WTRU is part of an implicit collaborative session with a second WTRU, whether the media session is transferrable between the first WTRU and the second WTRU, and whether the first WTRU or the second WTRU is preferred for media stream transfer.

19. The method of claim 16, wherein the information is reporting information and the reporting information is received from a reporting function node.

20. The method of claim 19 wherein the reporting information includes a network overload event, a network location change event, a network access loss event, a WTRU location change event, a WTRU access loss, an impending loss of access for a WTRU, registration of another WTRU, a load balancing event.