Method and apparatus for radio resource management in multi-radio access technology wireless system

The method and apparatus for radio resource management in a multi-RAT wireless system allow simultaneous operation across different frequencies, addressing the challenge of resource underutilization and enhancing network performance and capacity.

JP2025166039APending Publication Date: 2025-11-05INTERDIGITAL PATENT HOLDINGS INC
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2025129695
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2011-07-29
Filing Date
2025-08-01
Publication Date
2025-11-05

AI Technical Summary

Technical Problem

Existing wireless communication systems face challenges in efficiently managing radio resources across multiple radio access technologies (RATs) due to limited spectrum availability and underutilization of resources, leading to suboptimal network performance and capacity.

Method used

A method and apparatus for radio resource management in a multi-RAT wireless system, enabling a wireless transmit/receive unit (WTRU) to simultaneously operate on multiple frequencies using different RATs, with a single RRC instance managing radio resources for all configured serving cells.

Benefits of technology

Enhances network performance by optimizing resource utilization across multiple RATs, reducing costs, and ensuring seamless service continuity while maximizing the utilization of available spectrum.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025166039000001_ABST
    Figure 2025166039000001_ABST
Patent Text Reader

Abstract

To provide a method and an apparatus for performing wireless communication in a wireless transmit / receive unit (WTRU) configured for multi-radio access technology (RAT) operation.SOLUTION: A method includes a step in which a WTRU wirelessly communicates information on a first operating frequency according to a first RAT. The WTRU also wirelessly communicates the information on a second operating frequency according to a second RAT.SELECTED DRAWING: Figure 4
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to wireless communication technology.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 61 / 513,180, filed July 29, 2011, the contents of which are incorporated herein by reference. [Background technology]

[0003] Demands for improved network coverage, improved capacity, and increased bandwidth for voice and data services in wireless systems have led to the continuous development of numerous radio access technologies (RATs). Examples of such RATs include, for example, Global System for Mobile Communications (GSM), Wideband Channel Division Multiple Access (WCDMA), High Speed ​​Packet Access (which may include High Speed ​​Downlink Packet Access (HSDPA) and High Speed ​​Uplink Packet Access (HSUPA) and their multi-carrier versions), 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (LTE Release 10 and later may include support for carrier aggregation), IEEE 802.11b / a / g / n, IEEE 802.16a / e, IEEE 802.20, Code Division Multiple Access 2000 1x (CDMA2000 1x), and 3rd Generation Partnership Project 2 (3GPP2) cdma2000 Evolution Data Optimized (cdma2000 EV-DO). Summary of the Invention [Problem to be solved by the invention]

[0004] A method and apparatus for radio resource management in a novel multi-radio access technology wireless system is provided. [Means for solving the problem]

[0005] A method and apparatus are disclosed for performing wireless communications in a wireless transmit / receive unit (WTRU) configured for multi-RAT operation, the method including the WTRU wirelessly communicating information over a first operating frequency according to a first RAT and wirelessly communicating information over a second operating frequency according to a second RAT. [Effects of the Invention]

[0006] A method and apparatus for radio resource management in a novel multi-radio access technology wireless system is provided. [Brief explanation of the drawings]

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1A] 1 is a diagram of an exemplary communication system in which the disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A. [Figure 1C] 1B is a system diagram of an example radio access network and an example core network that can be used within the communication system shown in FIG. 1A. [Figure 2] FIG. 1 is a block diagram of an example system for multi-RAT communication. [Figure 3] 1 is a block diagram of an example control plane for multi-RAT operation using one RRC instance and one RRC connection per WTRU. [Figure 4] 4 is a flow diagram of an example method of performing wireless communications in a WTRU configured for multi-RAT operation corresponding to the embodiment shown in FIG. 3. [Figure 5] 1 is a block diagram of an example control plane for multi-RAT operation using an RRC instance for each configured RAT, one RRC connection per WTRU. [Figure 6] 6 is a flow diagram of an example method of performing wireless communications in a WTRU configured for multi-RAT operation corresponding to the embodiment shown in FIG. 5. [Figure 7] FIG. 10 is a block diagram of an example control plane for multi-RAT operation using an RRC instance and an RRC connection for each configured RAT. [Figure 8] 8 is a flow diagram of an example method of performing wireless communications in a WTRU configured for multi-RAT operation corresponding to the embodiment shown in FIG. 7. [Figure 9] FIG. 1 is a block diagram illustrating E-UTRA RRC states and mobility support between E-UTRAN, UTRAN, and GERAN. DETAILED DESCRIPTION OF THE INVENTION

[0008] 1A is a diagram 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 content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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), and single-carrier FDMA (SC-FDMA).

[0009] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 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 will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, WTRUs 102a, 102b, 102c, and 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, home appliances, etc.

[0010] The communications system 100 may also include a base station 114a and a base station 114b. 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 communications networks, such as the core network 106, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0011] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals within a particular geographic area, sometimes referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, one for each sector of the cell. In another embodiment, the base station 114a may utilize multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0012] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0013] More specifically, as mentioned above, the communication system 100 may be a multiple-access system and may utilize one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 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).

[0014] 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).

[0015] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0016] 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 utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a workplace, home, vehicle, campus, etc. 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 utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114 b may not need to access the Internet 110 via the core network 106 .

[0017] The RAN 104 may communicate with the 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 of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or core network 106 may communicate directly or indirectly with other RANs that utilize the same RAT as the RAN 104 or a different RAT. For example, in addition to connecting to the RAN 104 that utilizes E-UTRA radio technology, the core network 106 may also communicate with another RAN (not shown) that utilizes GSM radio technology.

[0018] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. 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 that may utilize the same RAT as the RAN 104 or a different RAT.

[0019] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that employs cellular-based wireless technology and with a base station 114b that employs IEEE 802 wireless technology.

[0020] 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 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 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. The WTRU 102 may include any subcombination of the above elements while remaining consistent with an embodiment.

[0021] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0022] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) 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, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0023] 1B, the transmit / receive element 122 is shown as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0024] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0025] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., 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. Additionally, the processor 118 may obtain information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 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, etc. In other embodiments, the processor 118 may obtain information from, and store data in, memory located on a server or home computer (not shown), etc., rather than memory physically located on the WTRU 102.

[0026] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components within 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0027] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location-determination method while remaining consistent with an embodiment.

[0028] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, etc.

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

[0030] The RAN 104 may include eNodeBs 140a, 140b, and 140c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 140a, 140b, and 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNodeBs 140a, 140b, and 140c may implement MIMO technology. Thus, the eNodeB 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0031] Each of the eNodeBs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG. 1C, the eNodeBs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0032] 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 above elements is shown as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity different from the core network operator.

[0033] The MME 142 may be connected to each of the eNodeBs 142a, 142b, 142c in the 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, etc. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0034] The serving gateway 144 may be connected to each of the eNodeBs 140a, 140b, 140c in the RAN 104 via an S1 interface. The serving gateway 144 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. 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, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0036] The core network 106 may facilitate communications 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 PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications 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. Additionally, 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.

[0037] When RATs such as WCDMA and LTE were developed, they were created to allow the use of two or more component carriers (CCs) for transmission and reception between a WTRU and a base station. A CC may be, for example, a frequency on which a WTRU operates. For example, a WTRU may receive transmissions on a downlink (DL) CC, where the DL CC may include multiple DL physical channels. As another example, a WTRU may transmit on an uplink (UL) CC, where the UL CC may include multiple UL physical channels.

[0038] A cell includes at least a DL CC that can be associated with a UL CC based on SI received by the WTRU, either broadcast on the DL CC or using dedicated configuration signaled from the network. For example, if SI is broadcast on the DL CC, the WTRU can receive the UL frequency and bandwidth of the associated UL CC as part of the SI IE (e.g., when in RRC_IDLE for LTE or idle / CELL_FACH for WCDMA (i.e., when the WTRU does not yet have an RRC connection to the network)).

[0039] More specifically, 3GPP WCDMA Release 8 provided support for the simultaneous use of two HSDPA component carriers (2C-HSDPA), Release 9 provided support for MIMO in multi-carrier DL WCDMA and also introduced support for two HSUPA UL CCs, and Release 10 introduced support for up to four DL CCs (4C-HSDPA). In Release 11, the number of DL CCs can be increased to eight (8C-HSDPA). 3GPP LTE Release 10 introduced support for simultaneous transmission and / or reception using the radio resources of multiple CCs between a base station and a mobile station within the same transmission interval. The transmission time interval (TTI) for HSPA is a 2-ms subframe, while the TTI for 3GPP LTE Releases 8, 9, and 10 is a 1-ms subframe (each radio frame (10 ms) contains ten equally sized 1-ms subframes).

[0040] Network architectures for different RATs may support different functions in different entities within the architecture. In some RATs, similar functions (e.g., MAC functions) may be performed by different entities within the same architecture, and architectures for different RATs may include different entities. For example, in the case of UTRAN, the Radio Resource Control (RRC), Packet Data Control Protocol (PDCP), Radio Link Control (RLC), Medium Access Control Dedicated (MAC-d), and MAC-is sublayers are located in the Radio Network Controller (RNC), while the Medium Access Control High-Speed ​​(MAC-hs), MAC-i, and Layer 1 (L1) are located in the Node B. Furthermore, in the case of Universal Terrestrial Radio Access Network (UTRAN), security (e.g., encryption), segmentation, and reassembly services for MAC and in-order delivery services for PDCP are provided by RLC, while MAC ensures ordering between hybrid automatic repeat request (HARQ) processes for the RLC layer. As another example, in evolved UTRAN (eUTRAN), there is no RNC, and the RRC, PDCP, RLC, and MAC layers are all located in the eNodeB (eNB). Security (e.g., ciphering, integrity, and authentication) and in-order delivery services (e.g., during handover) are provided by PDCP, while RLC provides segmentation, re-segmentation, and reassembly services to the MAC.

[0041] One of the design objectives of LTE Release 8 was to enable operators to deploy LTE using the same sites as for legacy WCDMA deployments in order to reduce deployment and radio planning costs. Thus, network operators can deploy both WCDMA / HSPA and LTE in the same coverage area, LTE deployments can have similar coverage as existing WCDMA / HSPA deployments, and multimode WTRUs supporting both WCDMA / HSPA and LTE access can be widely deployed.

[0042] However, spectrum is a costly resource, and not all frequency bands may be available to all operators. Therefore, while operators are expected to be able to provide support for both HSPA and LTE services, carrier aggregation scenarios may be limited to at most two or three component carriers per RAT for a given operator. Additionally, while LTE is being deployed, legacy deployments may be maintained for the foreseeable future, which may result in operators experiencing periods of underutilization of radio resources / spectrum and capacity in one of the RATs.

[0043] HSPA Release 10 with MIMO provides a downlink peak data rate of 42 Mbps, and Release 10 multi-carrier HSPA can further increase the peak rate by introducing support for up to four DL CCs. LTE Releases 8 and 9 provide up to 100 Mbps in a single CC DL, and LTE Release 10 with intra-RAT carrier aggregation can further increase the peak rate by combining the transmission resources of up to five CCs. Some motivations for utilizing the combined data rate / capacity of multi-RAT deployments include, for example, reducing the cost of providing higher data rates (data enhancement scenarios), migrating from WCDMA / HSPA to LTE with limited available spectrum (migration scenarios), maximizing the utilization of deployed RATs (e.g., through load balancing), and maximizing the utilization of radio components in the WTRU (e.g., dual-band receivers).

[0044] In addition to taking advantage of increased peak rates, operators may want to reserve frequency bands for other reasons (e.g., for Home eNB deployments). Furthermore, combining HSPA resources with LTE resources may provide additional means for ensuring service continuity (e.g., for circuit-switched (CS) voice and / or for services requiring LTE data rates). Therefore, it may be desirable to have a method for allowing a WTRU to operate simultaneously on multiple frequencies, where the WTRU operates on at least one of the frequencies according to a different RAT.

[0045] The embodiments described herein may relate to a multi-mode WTRU that supports simultaneous (or quasi-simultaneous) operation on CCs of multiple different RATs. The embodiments described herein may also relate to how a multi-mode WTRU may perform radio resource management and related RRC procedures when using different RATs. In one embodiment, the WTRU may perform radio resource management and related RRC procedures using different RATs on different frequencies.

[0046] Some embodiments described herein are described with respect to a first RAT being LTE and a second RAT being WCDMA, HSUPA, and / or HSDPA, and vice versa. However, the embodiments described herein may be applicable to any wireless technology. Furthermore, although not explicitly described herein, the embodiments described herein may be applicable to a WTRU that transmits using different RATs on different frequencies only in different time intervals (i.e., some form of time division operation based on TTI) and / or where such transmissions occur within the same frequency band.

[0047] 2 is a block diagram of an example system 200 for multi-RAT communication. The shown system 200 includes a WTRU 204 and two base stations (e.g., eNBs) 202 and 206. In FIG. 2, one WTRU 204 communicates with the two base stations 202 and 206 using channels 208, 210, 212, and 214. Channels 208, 210, 212, and 214 may be any combination of UL and DL channels of any number of different RATs.

[0048] Multi-RAT operation may include any multi-mode WTRU that is simultaneously configured for operation with at least one CC (e.g., a DL CC, an UL CC, or one or more serving cells) of a first RAT and at least one CC (e.g., a DL CC, an UL CC, or one or more serving cells) of a second RAT. Operation on different CCs may occur simultaneously or quasi-simultaneously in time. For example, operation according to different RATs may be used sequentially on the same CC. A multi-mode WTRU may include any mobile terminal that supports multiple RATs, such as any combination of GSM, WCDMA, HSPA, HSDPA, HSUPA, LTE, IEEE 802.11b / a / g / n, IEEE 802.16a / e, IEEE 802.20, cdma2000 1x, and cdma2000 EV-DO.

[0049] A serving cell may include, for example, a primary cell (PCell) or a secondary cell (SCell). More specifically, for a WTRU that is not configured to use any SCells or that does not support operation over multiple CCs (carrier aggregation), there may be only one serving cell (PCell). For a WTRU configured to use at least one SCell, the serving cell may include a set of one or more cells that includes all configured PCells and all configured SCells.

[0050] In one embodiment, the WTRU 204 may wirelessly communicate information on a first operating frequency according to a first RAT and may wirelessly communicate information on a second operating frequency according to a second RAT. The communication on the first and second operating frequencies may occur via any combination of channels 208, 210, 212, and 214. For example, the WTRU 204 may wirelessly communicate information on a first operating frequency according to a first RAT (e.g., LTE) on DL channel 208 (e.g., LTE DL) and may wirelessly communicate information on a second operating frequency according to a second RAT (e.g., WCDMA) on DL channel 212 (e.g., WCDMA HSDPA). As another example, the WTRU 204 may wirelessly communicate information on a first operating frequency according to a first RAT (e.g., WCDMA) on the UL channel 212 (e.g., WCDMA HSDPA) and may wirelessly communicate information on a second operating frequency according to a second RAT (e.g., LTE) on the UL channel 214 (e.g., LTE UL).

[0051] A WTRU, such as the WTRU 204 shown in Figure 2, may be configured for multi-RAT operation. A WTRU that supports access to multiple RATs may access their resources using one of a number of different control plane configurations and any one of a number of different methods, such as, for example, the control planes and methods illustrated and described with respect to Figures 3-8.

[0052] 3 is a block diagram of an example control plane 300 for multi-RAT operation using one RRC instance 302, one state machine 304, one RRC connection 306 per WTRU, and one or more SRBs 308. The term RRC instance, as referred to hereafter, can conceptually represent use of the RRC protocol, which can include a single state machine operating using multiple RRC states (e.g., CONNECTED or IDLE in the case of the LTE RRC protocol) with corresponding state transitions, RRC procedures (including associated timers), including RRC control and measurement procedures, RRC PDUs and information elements (IEs), RRC configuration (including parameters for configuration of RRC, PDCP, RLC, MAC), and the physical (PHY) layer, without being limited to possible additional aspects or a subset of the following aspects. In the example shown in FIG. 3, one RRC instance 302 can handle management of radio resources for all configured RATs.

[0053] For HSPA, there are at least four RRC states: CELL_DCH, CELL_FACH, CELL_PCH / URA_PCH, and UTRA_IDLE. For LTE, there are two RRC states: RRC_CONNECTED and RRC_IDLE. If an RRC connection is established, the WTRU is in RRC_CONNECTED. Otherwise, the WTRU is in RRC_IDLE.

[0054] In the RRC_IDLE state, the WTRU monitors at least the paging channel to detect incoming calls, SI changes, and in one embodiment, early terrestrial warning system (ETWS) / commercial mobile alert system (CMAS) notifications, and performs neighbor cell measurements, cell selection, cell reselection, and SI acquisition. In the RRC_CONNECTED state, the WTRU transmits / receives on unicast channels and can monitor at least the paging channel and / or SI block type 1 to detect incoming calls, SI changes, and in one embodiment, ETWS / CMAS notifications. The WTRU may also be configured to use one or more secondary cells in addition to the primary cell.

[0055] For each of the RRC protocols described in the above paragraphs, a set of states, transitions, messages (e.g., protocol data units (PDUs)), and procedures are defined. Figure 9 is a block diagram 900 illustrating E-UTRA (e.g., LTE) RRC states, including, for example, a CELL_DCH state 902, a CELL_FACH state 904, a CELL_PCH and URA_PCH state 906, a UTRA_IDLE state 908, an E-UTRA RRC CONNECTED state 910, an E-UTRA RRC IDLE state 912, a GSM_Connected state 914, a GPRS packet transfer mode 916, and a GSM Idle / GPRS Packet Idle state 918. Figure 9 also illustrates mobility support between E-UTRAN, UTRAN, and GERAN.

[0056] In one embodiment, a single RRC instance 302 may manage a single RRC connection 306, which may be used to handle radio resource management for all configured serving cells of any RAT. According to this embodiment, there may be at most one RRC instance and one RRC connection per WTRU at any given time.

[0057] Figure 4 is a flow diagram 400 of an example method of performing wireless communications in a WTRU configured for multi-RAT operation, corresponding to the embodiment shown in Figure 3. In the example shown in Figure 4, the WTRU may initially access a network and establish 402 an RRC connection 306 in a first RAT (e.g., a Primary RAT (PRAT)) using an RRC instance 302. The WTRU may then receive 404 a configuration over the RRC connection 306 that adds at least one serving cell of a second RAT (e.g., a Secondary RAT (SRAT)). The WTRU may then configure 406 radio resources using the single RRC instance 302.

[0058] The primary cell (PCell) may include, for example, a cell operating on a primary frequency where a WTRU performs initial access to the system (e.g., the cell where the WTRU performs an initial connection establishment procedure, the cell where the WTRU initiates a connection re-establishment procedure, or the cell indicated as the primary cell in a handover procedure). The PCell may also correspond to a frequency indicated as part of an RRC configuration procedure. Some functions may only be supported on the PCell. For example, the UL CC of the PCell may correspond to a CC where physical UL control channel resources are configured to carry all HARQ acknowledgment / negative acknowledgment (ACK / NACK) feedback for a given WTRU. For example, in LTE, the WTRU may use the PCell to derive parameters for security functions and parameters for higher layer SI, such as non-access stratum (NAS) mobility information. Other functions that may only be supported on the PCell DL may include SI acquisition and change monitoring procedures on the broadcast channel (BCCH), and paging. For example, a PCell in WCDMA may be similar to a PCell in LTE. A secondary cell (SCell) may include, for example, a cell operating on a secondary frequency that can be configured after an RRC connection is established and used to provide additional radio resources. SI related to operation on an associated SCell may be provided using dedicated signaling when the SCell is added to the WTRU's configuration. Although parameters may have different values ​​than those broadcast on the DL of the associated SCell using SI signaling, this information may be referred to as the SI of the associated SCell, regardless of the method used by the WTRU to acquire this information.

[0059] A Primary RAT (PRAT) (or anchor RAT) may include a radio access network technology. At least one serving cell may be configured as a PCell for the PRAT. The PCell may support at least one of establishing a first RRC connection, deriving security parameters (e.g., if a single security context is used), using UL resources to transmit UL control information (UCI) (e.g., if UCI is transmitted only on serving cells of the first RAT), and / or configuring at least one serving cell with UL resources (e.g., if UL resources are configured only in the first RAT). As a result, in some embodiments, the PRAT or anchor RAT may be referred to as the first RAT. A Secondary RAT (SRAT) (or non-anchor RAT) may include a RAT for which none of the serving cells configured are for the PRAT of the WTRU's configuration.

[0060] In one embodiment, the WTRU may access an LTE cell and establish an RRC connection 306 using LTE as the PRAT using a corresponding RRC connection establishment procedure. The WTRU may be configured to use additional serving cells, which may include one or more HSPA serving cells, as the SRAT using the RRC connection reconfiguration procedure of the PRAT. In one embodiment, the RRC connection reconfiguration procedure may be performed only after security is activated in the PRAT. Furthermore, in one embodiment, the WTRU may receive an RRC message during the RRC reconfiguration procedure that includes one or more IEs related to HSPA configuration (e.g., SI configuration IE, radio bearer IE, transport channel IE, and physical channel IE).

[0061] In another embodiment, the WTRU may access an HSPA cell and establish an RRC connection 306 using HSPA as the PRAT using a corresponding RRC connection establishment procedure. The WTRU may be configured to use additional serving cells (e.g., one or more LTE serving cells) as the SRAT using the RRC connection reconfiguration procedure of the PRAT. In one embodiment, the WTRU may be configured to configure PRAT-specific information using the RRC radio bearer setup procedure of the PRAT, and may simultaneously configure the WTRU to use the SRAT serving cell. Alternatively, the WTRU may be configured to use the SRAT in the RRC connection setup using the signaling radio bearer (SRB) of the PRAT. In one embodiment, the RRC connection reconfiguration procedure may be performed only after security is activated in the PRAT. Furthermore, in one embodiment, the WTRU may receive an RRC message during the RRC reconfiguration procedure that includes one or more IEs related to LTE configuration (e.g., SI configuration IEs and / or RRC IEs, which may include at least one of a MAC-MainConfig IE, a CQI-ReportConfig IE, a PDSCH-Config IE, a PhysicalConfigDedicated IE, a RadioResourceConfigDedicated IE, and / or a RadioConfigCommon IE for the DL configuration of the serving cell, and / or at least one of a PUSCH-Config IE and / or a SoundingRS-UL-Config IE for the UL configuration of the serving cell).

[0062] SRBs are radio bearers used only for the transmission of RRC and NAS messages. SRB0 is used for RRC messages using the Common Control Channel (CCH) logical channel. SRB1 is for RRC messages (e.g., with piggybacked NAS messages) and, before the establishment of SRB2, for NAS messages, using the Dedicated Control Channel (DCCH) logical channel. SRB2 is for NAS messages and is always configured after security activation. After security activation, all RRC messages on SRB1 and SRB2 can be integrity protected and encrypted.

[0063] When CCs (or serving cells) of different RATs are aggregated and configured for a given WTRU, it may be necessary to have a method for handling management of radio resource connections. In particular, when multiple RRC connections and / or state machines (SMs) can be used for multi-RAT access (e.g., one per RAT in which the WTRU operates), it may be desirable to define a method for enabling appropriate handling of each RRC connection and the possible interactions between them. Alternatively, when only a single RRC connection and / or state machine can be used for multi-RAT access, it may be desirable to define a method by which a single RRC state machine can control multiple radio resources.

[0064] 5 is a block diagram of an example control plane 500 for multi-RAT operation using an RRC instance for each configured RAT, a state machine for each RRC instance, and one RRC connection per WTRU. More specifically, the example shown includes an RRC instance 502 for a PRAT, a state machine 504 for the PRAT, an RRC instance 508 for an SRAT, a state machine 506 for the SRAT, a single RRC connection 510, and one or more SRBs 512. In the example shown in FIG. 5, radio resources for multiple RATs (e.g., a PRAT and an SRAT) can be managed using multiple RRC instances (e.g., one control plane instance per configured RAT).

[0065] In one embodiment, the RRC instance 508 for an SRAT includes a subset of the RRC protocol for the associated RAT. For example, the RRC instance 508 for an SRAT may handle at least some radio resource management functions for the corresponding RAT (e.g., intra- and inter-frequency measurement configuration and reporting, radio link monitoring (RLM), SI maintenance, and error handling). In one embodiment, the RRC instance 508 for each SRAT may interact with the RRC instance 502 for the PRAT. In the illustrated embodiment, the RRC instance 502 manages a single RRC connection 510, which can be used to handle radio resource management for at least one RAT. There may also be an additional RRC instance (e.g., the RRC instance 508 for the SRAT) for each additional configured RAT, which may include a subset of the RRC protocol for the associated RAT (SRAT).

[0066] For an LTE serving cell, the WTRU may perform RLM and determine a UL radio link failure (RLF) if it reaches a maximum number of preamble transmissions for the random access procedure and / or a maximum number of repeated failures when performing the random access procedure on the associated serving cell. Additionally, for an LTE serving cell, the WTRU may determine a DL RLF if the RRC instance receives a number N310 of consecutive out-of-sync indications from the physical (PHY) layer after which timer T310 expires without the WTRU recovering from the error condition that started the timer.

[0067] Figure 6 is a flow diagram 600 of an example method of performing wireless communications in a WTRU configured for multi-RAT operation corresponding to the embodiment shown in Figure 5. In the example shown in Figure 6, the WTRU may initially access a network and establish an RRC connection 510 in a first RAT (e.g., PRAT) using a first RRC instance (RRC instance for PRAT 502) (602). The WTRU may then receive a configuration over the RRC connection 510 to add at least one serving cell of a second RAT (e.g., SRAT) (604). The WTRU may then use a second RRC instance (RRC instance for SRAT 508) that may configure radio resources for the SRAT using an RRC PDU (e.g., received on a different SRB) and / or configuration information received over the RRC connection 510 (606). In one embodiment, the second RRC instance 508 may initially operate according to an RRC connected mode (e.g., LTE CONNECTED or HSPA CELL_DCH). The state of the RRC instance for the SRAT may be inactive, or the RRC connected mode may be initiated by the PRAT.

[0068] For example, the WTRU may access an LTE cell and establish an RRC connection using LTE as the PRAT using a corresponding RRC connection establishment procedure. The WTRU may be configured to use additional serving cells, including, for example, one or more HSPA serving cells, as the SRAT. In one embodiment, the configuration procedure may be performed only after security has been activated in the PRAT.

[0069] In one embodiment, the configuration may be received via an RRC connection reconfiguration procedure of the PRAT. In one embodiment, the WTRU may receive an RRC message during the RRC reconfiguration procedure that includes one or more IEs related to the HSPA configuration, which may include, for example, at least one of an SI configuration IE, a radio bearer IE, a transport channel IE, a physical channel IE, and a secondary serving HS-DSCH IE. In one embodiment, the RRC instance of the PRAT may forward the received configuration information of the SRAT to the RRC instance of the corresponding SRAT, which may configure the corresponding radio resources of the SRAT.

[0070] In another embodiment, the configuration may be received on an SRB configured to be associated with the RRC instance 508 of the SRAT. In one embodiment, the WTRU may receive an RRC PDU of the RRC protocol of the SRAT on the SRB. In one embodiment, the RRC message may include one or more IEs related to the HSPA configuration, which may include, for example, at least one of an SI configuration IE, a radio bearer IE, a transport channel IE, and a physical channel IE. In one embodiment, the RRC instance of the SRAT may perform corresponding configuration procedures, such as a radio bearer control procedure and a physical channel configuration procedure.

[0071] For example, the WTRU may access an HSPA cell and establish an RRC connection 306 using HSPA as the PRAT using a corresponding RRC connection establishment procedure. The WTRU may be configured to use additional serving cells, which may include, for example, one or more LTE serving cells, as the SRAT. In one embodiment, this configuration procedure may be performed only after security has been activated in the PRAT.

[0072] In one embodiment, the configuration may be received via an RRC connection reconfiguration procedure of the PRAT. In one embodiment, the WTRU may receive an RRC message including one or more IEs related to LTE configuration, which may include, for example, an SI configuration IE, at least one of the following RRC IEs (which may include at least one of a MAC-MainConfig IE, a CQI-ReportConfig IE, a PDSCH-Config IE, a PhysicalConfigDedicated IE, a RadioResourceConfigDedicated IE, and a RadioConfigCommon IE for the DL configuration of the serving cell, and may also include at least one of a PUSCH-Config IE and a SoundingRS-UL-Config IE for the UL configuration of the serving cell). In one embodiment, the RRC instance 502 of the PRAT may forward the received configuration information of the SRAT to the RRC instance of the corresponding SRAT, which may configure the corresponding radio resources of the SRAT.

[0073] In another embodiment, the configuration may be received over an SRB configured to be associated with the RRC instance 508 of the SRAT. In one embodiment, the WTRU may receive an RRC PDU of the RRC protocol of the SRAT over an SRB. In one embodiment, the RRC message may include one or more IEs related to LTE configuration, which may include, for example, an SI configuration IE, at least one of radio resource control IEs (including at least one of a MAC-MainConfig IE, a CQI-ReportConfig IE, a PDSCH-Config IE, a PhysicalConfigDedicated IE, a RadioResourceConfigDedicated IE, and a RadioConfigCommon IE for the DL configuration of the serving cell, and at least one of a PUSCH-Config IE and a SoundingRS-UL-Config IE for the UL configuration of the serving cell). In one embodiment, the RRC instance of the SRAT may perform a corresponding RRC reconfiguration procedure, such as a radio resource configuration procedure.

[0074] 7 is a block diagram of an example control plane 700 for multi-RAT operation using an RRC instance for each configured RAT, a state machine for each RRC instance, and an RRC connection for each configured RAT. More specifically, the example shown includes an RRC instance 702 for the PRAT, a state machine 704 for the PRAT, an RRC instance 708 for the SRAT, a state machine 706 for the SRAT, an RRC connection 710 for the PRAT, an RRC connection 712 for the SRAT, and one or more SRBs 714. In the example shown in FIG. 7, radio resources for multiple RATs (e.g., the PRAT and the SRAT) can be managed using multiple RRC instances (e.g., one control plane instance per configured RAT).

[0075] Figure 8 is a flow diagram 800 of an example method of performing wireless communications in a WTRU configured for multi-RAT operation corresponding to the embodiment shown in Figure 7. In the example shown in Figure 8, the WTRU may establish 802 a first RRC connection 710 in a first RAT (e.g., PRAT) using a first RRC instance 702. The WTRU may also establish 804 a second RRC connection 712 in a second RAT (e.g., SRAT) using a second RRC instance 708.

[0076] In the embodiment shown in FIG. 7, each RRC instance 702, 708 manages one RRC connection 710, 712 for each configured serving cell of the associated RAT.

[0077] In one embodiment, the RRC connections 710, 712 may be established according to any number of different methods. In one embodiment, the WTRU may receive RRC signaling from the network over an existing RRC connection. The RRC signaling may include, for example, a request to establish an additional RRC connection to the SRAT, parameters for uniquely identifying the associated cell (e.g., frequencies (DL and UL), cell identity, and SI). In another embodiment, the WTRU may receive an RRC reconfiguration message from the network over an existing RRC connection to add at least one serving cell for the SRAT. The RRC reconfiguration message may include, for example, parameters for uniquely identifying the associated cell (e.g., frequencies (DL and UL), cell identity, and SI). In another embodiment, the WTRU may receive a request to establish an additional RRC connection to the SRAT when a packet data protocol (PDP) context is established for a new application. In another embodiment, the WTRU may autonomously initiate access to a cell of a second RAT when already connected to a first RAT. This embodiment may be used, for example, when the WTRU supports multi-RAT access using two independent RRC instances.

[0078] The WTRU may autonomously initiate access to a cell of a second RAT, for example, in response to receiving a paging message over the RAT, when the WTRU is camped on a cell with an RRC instance in idle mode. Alternatively, the WTRU may autonomously initiate access to a cell of a secondary RAT if it determines that an application requests service. For example, if the WTRU wants to initiate a CS call and it determines that it is a multi-RAT capable WTRU, it may initiate access to a cell in the secondary RAT and, in one embodiment, may indicate a reason in the RRC connection establishment. In another embodiment, the WTRU may send a request to the network over the PRAT (e.g., following a WTRU-specific trigger) indicating that it can initiate SRAT setup. The WTRU may send the request to the network, for example, in response to receiving a service request and, in one embodiment, may indicate a reason in an RRC message sent over the PRAT. In this embodiment, the WTRU may wait for an explicit setup message from the network to instantiate the SRAT RRC connection.

[0079] In one embodiment, there may be no interaction between RRC instance 702 and RRC instance 708. For example, this may be the case when a multi-mode WTRU operates as a multi-homed IP device that can be configured using NAS procedures (e.g., when, from a network connectivity perspective, each RAT may correspond to a different IP interface). More specifically, the WTRU appears to the network as a single device implementing two different IP network interfaces, and in one embodiment, each has its own PDP context (i.e., IP address), control / user data path, and security context. RRM, mobility management, scheduling, and admission control for each RRC connection may be independent of each other.

[0080] In another embodiment, there may be additional interactions between RRC instance 702 and RRC instance 708. For example, an RRC message on a first RRC connection (e.g., 710) may initiate a procedure by the WTRU by which the WTRU may enter an idle mode state, camp on (or alternatively, camp on a cell on the frequency indicated in the RRC message), acquire SI, monitor the paging channel, and / or perform a cell selection procedure to determine a suitable cell on which to access the SRAT. Alternatively, it may immediately perform initial access to a cell selected by the WTRU using the cell selection procedure, or alternatively, to a cell on the frequency indicated in the RRC message.

[0081] In one embodiment, parameters may be exchanged or may be common across multiple RRC instances, including at least one of security parameters, NAS configuration (including PDP context), and user plane parameters (if a single data path is used). For example, from a network connectivity perspective, the WTRU still appears as a single device implementing a single IP network interface with a single PDP context (i.e., IP address), a single data path, and a single security context. The required parameters may be common to all RRC instances and may be obtained, for example, from the PRAT connection and / or the initial NAS configuration. In one embodiment, RRM and mobility management for each RRC connection may be configured independently of each other. Alternatively, mobility may be based on the PRAT connection (e.g., 710).

[0082] In one embodiment, the WTRU may be configured to use zero or more SCells for PRAT.

[0083] For the embodiments described with respect to Figures 5 to 8, where the control plane includes a separate RRC instance for each configured RAT for radio resource management, the different RRC instances may interact with each other using any one of a number of different methods, e.g., for security configuration, security activation, security failure, failure handling, RRC connection reconfiguration, RLM, error recovery, state transitions, return to idle mode transactions, and actions upon PUCCH / SRS release request.

[0084] With regard to security configuration, activation, and failure, the WTRU may use a second RRC instance if it adds a first serving cell for the SRAT. In one embodiment, if security is activated for another RRC instance, the WTRU may assume that security is already activated for the second RRC instance and may apply the same configuration to integrity protection and ciphering for the access stratum, if applicable.

[0085] With respect to failure handling, the WTRU may receive control plane information (e.g., RRC PDUs or IEs) for RRC instances of an SRAT that it may have failed to process. If the WTRU receives control plane information for RRC instances of an SRAT that it may have failed to process, it may inform the network that the configuration failed, suspend any ongoing transmissions on the serving cell of the associated SRAT, disable the configuration for all serving cells of the SRAT, delete the configuration for all serving cells of the SRAT, inform the network that the configuration failed, and / or terminate the secondary RAT RRC instance or secondary RAT RRC connection. If the WTRU receives a configuration message to add, modify, or delete at least a portion of the configuration for at least one serving cell of the SRAT, the WTRU may not successfully apply the associated configuration. In this case, the WTRU may disable the configuration of the associated serving cell, delete the configuration of the associated serving cell, disable the configuration for all serving cells in the SRAT, delete the configuration for all serving cells in the SRAT, inform the network that the configuration failed, and / or terminate the SRAT RRC instance or secondary RAT connection, none of which may affect the operation and / or configuration of the RRC connection for the PRAT.

[0086] With respect to the reconfiguration of the RRC connection, the WTRU may receive a radio resource reconfiguration message to add a configuration for the first LTE serving cell using the configured UL resources. The WTRU may then initiate a procedure to acquire UL timing synchronization (e.g., a random access procedure on the UL PRACH resources of the cell). In one embodiment, the WTRU may receive a handover command, which may include a configuration with at least one LTE serving cell using the configured UL resources. In this embodiment, in addition to initiating access to the HSPA target cell, the WTRU may also initiate a procedure to acquire UL timing synchronization (e.g., a random access procedure on the UL PRACH resources of the LTE target cell).

[0087] With regard to RLM, the WTRU may perform RLM for configured serving cells of the SRAT. In one embodiment, the WTRU may determine that it is experiencing RLF, for example, according to criteria for RLF of serving cells of the corresponding RAT. If the WTRU determines that it is experiencing RLF (DL or UL) for a serving cell of the first RAT, it may delete the configuration for all serving cells of the first RAT, turn off the radio front-end for the first RAT, and / or inform the network of the RLF status of the associated serving cell. In one embodiment, the RRC instance of the first RAT may inform the RRC instance of the second RAT of the UL RLF status.

[0088] With respect to state transitions and associated procedures, an RRC state change in a first RRC instance can trigger a state change and / or procedure in a second RRC instance. For example, a state transition in a first RRC instance can trigger a state transition in a second RRC instance, release of the RRC connection in the second RRC instance, and / or the WTRU can turn off the radio front end for the second RAT corresponding to the second RRC instance. In one embodiment, an RRC state transition from CELL_DCH to any other state for an HSPA RRC instance can trigger the LTE RRC instance to perform a state transition to RRC_IDLE, release the RRC LTE connection, and / or turn off the LTE front end. For example, if HSPA is a PRAT, LTE can be a SRAT, and no UL resources may be configured for the LTE RAT. In another embodiment, an RRC state transition to idle mode in the first RAT may trigger a state transition to idle mode for the RRC instance of each configured SRAT, or alternatively, may trigger, for example, releasing the RRC connection and / or turning off the front end of each configured SRAT. If HSPA is the PRAT, LTE may be the SRAT and only the HSPA RRC instance may perform the cell reselection procedure.

[0089] As another example, a state transition in the second RRC instance may not be allowed depending on the state of the first RRC instance. In one embodiment, an RRC state may not be allowed in the RRC instance for SRAT based on the current state of another RRC instance. In particular, if the LTE RRC instance is in RRC_CONNECTED state, the WTRU cannot transition to CELL-FACH or CELL_PCH state for the HSPA RRC instance.

[0090] As another example, the operational state of the second RRC instance may follow the state of the first RRC instance. In one embodiment, if the state of the RRC instance of the LTE PRAT is RRC_CONNECTED, the initial state of the RRC instance of the HSPA SRAT may be CELL_DCH.

[0091] With respect to transitioning back to idle mode, a transition to RRC idle for an RRC connection that is the WTRU's PRAT may trigger the release of other RRC connections and / or a transition to RRC IDLE for another RRC instance (e.g., all RATs, or only those RATs for which the WTRU should be in IDLE mode when not connected to a network). The RRC instance for the PRAT may notify another RRC instance for the SRAT of the state change to IDLE. The RRC instance for the SRAT may then transition to IDLE mode, delete the dedicated configuration for the SRAT, revert to the default configuration, and / or perform procedures to activate and / or turn off the transceiver module and / or any features of the SRAT.

[0092] Regarding actions upon PUCCH / SRS release request, the PRAT LTE RRC instance can receive an indication to release the PUCCH / SRS dedicated resources from lower layers (e.g., LTE MAC). This can occur, for example, when the maximum number of scheduling request (SR) transmissions on the configured PUCCH resources for the SR is reached or when the timing alignment timer (TAT) expires. When the TAT expires, the WTRU no longer has a valid timing advance and is no longer synchronized for UL transmissions. In this case, the RRC instance of the PRAT can inform the RRC instance of the SRAT of the loss of UL synchronization in the PRAT.

[0093] For embodiments using a single RRC connection for all configured RATs (e.g., those described above with respect to Figures 3, 4, 5, and 6), the WTRU may receive RRC messages and configuration parameters for the SRAT, for example, via SRAT IEs piggybacked in the RRC PDU of the RAT. In this embodiment, the WTRU may multiplex and / or demultiplex the RAT-specific IEs into the RRC PDU of the single RRC connection and identify the IEs using an explicit identifier in the RRC PDU (e.g., RRC state machine or SRAT identification).

[0094] In one embodiment, the RRC message of the PRAT may include an SRAT Container IE. The SRAT Container IE may include information about the SRAT that can be processed according to the RRC of the SRAT. For example, if the PRAT is LTE, an HSPA SRAT can be established by including an ultra-Secondarycell-Container IE. In one embodiment, the presence of this IE can trigger the start of the secondary RAT.

[0095] If more than one SRAT can be established, an SRAT Type IE and an SRAT Message Container IE can be used. The SRAT Message Container IE can carry a message specified in another standard indicated by the SRAT Type IE. This container can carry the information and radio parameters required for the SRATs to be configured.

[0096] For example, the WTRU may be configured such that each group of cells configured for a given RAT is associated with the identity of that RAT. When the WTRU receives an RRC PDU, it may determine which RAT the IE is associated with and, for example, process the RRC PDU according to the applicable RAT. Similarly, the WTRU may transmit an RRC PDU that includes one or more information elements therein. If at most two RATs are supported, this may be determined implicitly by the presence of the IE itself in the PDU.

[0097] For embodiments using a separate RRC instance for each configured RAT (e.g., the embodiments described above with respect to Figures 5, 6, 7, and 8), the WTRU may receive configuration parameters for the SRAT by, for example, multiplexing RRC PDUs for the PRAT and SRAT using different SRB identifiers (SRB_IDs). In one embodiment, the WTRU may multiplex and / or demultiplex RRC PDUs on the data path and identify the RRC connection and / or state machine to which the RRC message is applicable based on the radio bearer identity used for transmission of the RRC PDU.

[0098] For example, the WTRU may be configured such that one or more SRBs are associated with control signaling for a particular RAT, e.g., based on the SRB_ID. When the WTRU receives an RRC PDU, it may determine which radio bearer the PDU is associated with and, e.g., if the WTRU is configured with a RAT-specific security context, apply the appropriate security context for authentication (if necessary) and deciphering, and / or process the RRC PDU using the RRC state machine applicable to the associated RAT. Similarly, the WTRU may transmit RRC PDUs using its association with the applicable RRC state machine.

[0099] In one embodiment, after security activation and association with a given priority, the SRBs applicable to the SRAT may be configured. For example, the WTRU may configure such that the SRBs applicable to, for example, a subset or type of HSPA RRC PDUs have the same (or alternatively lower) priority as SRB1 for transport of HSPA RRC PDUs over the LTE MAC. For example, the WTRU may configure such that the logical channels applicable to, for example, a subset or type of LTE RRC PDUs are mapped to specific priorities in the multiplexing function of the MAC-ehs.

[0100] For embodiments using a single RRC instance for all configured RATs (e.g., the embodiments described above with respect to FIGS. 3 and 4), if the WTRU receives a configuration that adds at least one serving cell for the SRAT, it may perform radio resource management using one or more of the examples described below. In such embodiments, the WTRU may have an established RRC connection (e.g., 306 of FIG. 3) with the PRAT.

[0101] In one embodiment, if security (e.g., for the PRAT) is activated, the WTRU may add a serving cell for the SRAT, in which case it may apply the same configuration to integrity protection and ciphering for the access stratum, if applicable (e.g., if multiple data paths are used).

[0102] In one embodiment, the WTRU may receive an RRC message to add, modify, or delete at least a portion of the configuration for at least one serving cell of the SRAT. The WTRU may not successfully apply the relevant configuration, in which case it may disable the configuration for the relevant serving cell, delete the configuration for the relevant serving cell, disable the configuration for all serving cells of the SRAT, delete the configuration for all serving cells of the SRAT, turn off the radio front-end for the SRAT, inform the network of the configuration failure, and / or terminate the SRAT RRC instance for the SRAT RRC connection. In particular, failure to apply the configuration for the SRAT may not affect the operation and / or configuration of the RRC connection for the PRAT. If the RRC procedure applicable to the SRAT fails to complete successfully, the WTRU may abort the procedure and revert to the state before the WTRU initiated the procedure for the associated SRAT.

[0103] If LTE is the PRAT, the RRC instance may perform radio resource management for the SRAT according to any of the following embodiments. In one embodiment, WTRU operation for the PRAT may follow typical procedures for the associated RAT. In one embodiment, the WTRU may perform RLM for a configured serving cell of the LTE PRAT, e.g., for the PCell. The WTRU may determine that it is experiencing an UL RLF on the PCell of the LTE PRAT according to the criteria for RLF of the serving cell of the corresponding RAT. If the WTRU determines that it is experiencing an RLF (DL or UL) for the PCell of the LTE PRAT, it may perform an RRC state transition from RRC_CONNECTED to RRC_IDLE, in which case it may delete the configuration for all serving cells of the HSPA SRAT and / or turn off the radio front-end for the HSPA SRAT.

[0104] The WTRU may also perform RLM for configured serving cells of the HSPA SRAT. The WTRU may determine that it is experiencing an UL RLF on the primary serving cell according to the criteria for RLF of serving cells of the corresponding RAT. If the WTRU determines an UL RLF for a serving cell of the HSPA SRAT, the WTRU may disable the configuration of the associated serving cell, delete the configuration of the associated serving cell, disable the random access configuration of the associated serving cell, delete the random access configuration of the associated serving cell, disable the configurations for all serving cells of the HSPA SRAT, delete the configurations for all serving cells of the HSPA SRAT, turn off the radio front-end for the HSPA SRAT, inform the network of the UL RLF status for the associated serving cell, consider the secondary RAT serving cell as deactivated, and / or terminate the SRAT RRC instance of the SRAT RRC connection.

[0105] In one embodiment, the WTRU may determine that it is experiencing a DL RLF according to the criteria for RLF of the serving cell of the corresponding RAT. If the WTRU determines a DL RLF for a serving cell of an HSPA SRAT, the WTRU may disable the configuration of the associated serving cell, delete the configuration of the associated serving cell, disable the configurations for all serving cells of the HSPA SRAT, delete the configurations for all serving cells of the HSPA SRAT, turn off the radio front end for the HSPA SRAT, and / or inform the network of the DL RLF status for the associated serving cell.

[0106] The WTRU may perform an RRC state transition from LTE RRC_CONNECTED to LTE RRC_IDLE, in which case the WTRU may disable configurations for all serving cells of the SRAT, delete configurations for all serving cells of the SRAT, turn off the radio front end for the SRAT, and / or terminate the secondary RAT RRC instance or the SRAT RRC connection.

[0107] The PRAT LTE RRC instance may receive an indication from lower layers (e.g., LTE MAC) to release the PUCCH / SRS dedicated resources. This may occur, for example, when the maximum number of SR transmissions on the configured PUCCH resources for SR is reached or when the TAT expires. When the TAT expires, the WTRU no longer has a valid timing advance and is no longer synchronized for UL transmissions. In this case, the WTRU may disable configurations for all serving cells for the SRAT, delete configurations for all serving cells for the SRAT, turn off the radio front-end for the SRAT, and / or terminate the SRAT RRC instance or the SRAT RRC connection.

[0108] If HSPA is the PRAT, the RRC instance may perform radio resource management for the SRAT according to any of the following embodiments. In addition, the WTRU operation for the PRAT may follow typical procedures for the associated RAT.

[0109] In one embodiment, the WTRU may receive a radio resource reconfiguration message to add a configuration for a first LTE serving cell using the configured UL resources and then initiate a procedure to acquire UL timing synchronization (e.g., a random access procedure on the UL PRACH resources of the cell). In one embodiment, the WTRU may receive a handover command that may include a configuration for at least one LTE serving cell using the configured UL resources. In addition to the initial access to the HSPA target cell, the WTRU may also initiate a procedure to acquire UL timing synchronization (e.g., a random access procedure on the UL PRACH resources of the LTE target cell).

[0110] In one embodiment, the WTRU may perform RLM for one or more of the configured serving cells of the PRAT, particularly for the primary serving cell of the HSPA PRAT. The WTRU may determine that it is experiencing RLF on the primary serving cell, for example, according to criteria for RLF of the serving cell of the corresponding RAT. If it determines an UL RLF for the primary serving cell of the HSPA PRAT, the RRC instance for the HSPA PRAT may receive a first out-of-sync indication from the physical layer and may refrain from performing UL transmissions. If at least one serving cell of the LTE SRAT is configured to use UL resources and can transmit UL feedback information on the serving cell, the WTRU may proceed with any transmissions on the LTE SRAT.

[0111] If the WTRU determines that it is RLF (DL and / or UL) for the primary serving cell of the HSPA PRAT, it may perform an RRC state transition from CELL_DCH (and / or to CELL_FACH), in which case it may delete configurations for all serving cells for the LTE SRAT, turn off the radio front-end for the LTE SRAT, and / or consider the LTE SRAT as being deactivated by command.

[0112] In one embodiment, the WTRU may perform RLM for a configured serving cell of the LTE SRAT. The WTRU may determine that it is experiencing an UL RLF on a serving cell of the LTE SRAT, particularly on the PCell, according to the criteria for RLF of the serving cell of the corresponding RAT. If it determines an UL RLF for a serving cell of the LTE SRAT, the WTRU may disable the configuration of the associated serving cell, delete the configuration of the associated serving cell, disable the random access configuration of the associated serving cell, delete the random access configuration of the associated serving cell, disable the configuration for all serving cells of the LTE SRAT, delete the configuration for all serving cells of the LTE SRAT, turn off the radio front-end for the LTE SRAT, inform the network of the UL RLF status for the associated serving cell, and / or terminate the SRAT RRC instance or the SRAT RRC connection.

[0113] In one embodiment, the WTRU may determine that it is experiencing a DL RLF according to the criteria for the RLF of the serving cell of the corresponding RAT. If it determines a DL RLF for a serving cell of an LTE SRAT, the WTRU may disable the configuration of the associated serving cell, delete the configuration of the associated serving cell, disable the configurations for all serving cells of the LTE SRAT, delete the configurations for all serving cells of the LTE SRAT, turn off the radio front-end for the LTE SRAT, inform the network of the DL RLF status for the associated serving cell, and / or terminate the SRAT RRC instance or the SRAT RRC connection.

[0114] In one embodiment, the WTRU may perform an RRC state transition from a connected state (e.g., CELL_DCH, CELL_PCH, or URA_PCH) to an idle mode, in which case the WTRU may disable configurations for all serving cells for the LTE SRAT, delete configurations for all serving cells for the LTE SRAT, and / or turn off the radio front end for the LTE SRAT.

[0115] Embodiment

[0116] 1. A method of performing wireless communications in a wireless transmit / receive unit (WTRU) configured for multi-radio access technology (RAT) operation, the method including the WTRU wirelessly communicating information on a first operating frequency in accordance with a first RAT.

[0117] 2. The method of embodiment 1, further comprising the WTRU wirelessly communicating information on a second operating frequency according to a second RAT.

[0118] 3. The method of embodiment 1 or 2, wherein the first RAT is one of Long Term Evolution (LTE) and High Speed ​​Packet Access (HSPA), and the second RAT is one of HSPA, LTE, and WiFi.

[0119] 4. The method of any one of embodiments 1 to 3, further comprising the WTRU establishing a radio resource control (RRC) connection in the first RAT using the RRC instance.

[0120] 5. The method of embodiment 4, further comprising the WTRU receiving a configuration for at least one serving cell of the second RAT over an RRC connection.

[0121] 6. The method of embodiment 5, further comprising the WTRU configuring radio resources for the second RAT using the RRC instance.

[0122] 7. The method of any one of embodiments 1 to 6, wherein if the WTRU performs an RRC state transition from LTE RRC_CONNECTED to LTE RRC_IDLE on the first RAT, the WTRU performs at least one of: disabling configurations for all serving cells of the second RAT; deleting configurations for all serving cells of the second RAT; and turning off the radio front end for the second RAT.

[0123] 8. The method of any one of embodiments 1-7, further comprising the step of: the WTRU transmitting and receiving an RRC protocol data unit (PDU) of a type corresponding to a first RAT, wherein the RRC PDU of the type corresponding to the first RAT includes at least one information element (IE) corresponding to a second RAT.

[0124] 9. The method of any one of embodiments 1-8, further comprising the WTRU establishing a radio resource control (RRC) connection in the first RAT using the first RRC instance.

[0125] 10. The method of embodiment 9, further comprising the WTRU receiving a configuration for at least one serving cell of the second RAT over an RRC connection.

[0126] 11. The method of embodiment 9 or 10, further comprising the WTRU configuring radio resources for the second RAT using the second RRC instance.

[0127] 12. The method of any one of embodiments 9 to 11, further comprising the step of: the WTRU sending and receiving PDUs over an RRC connection, each PDU having a signaling radio bearer identifier (SRB_ID) corresponding to one of the first RRC instance and the second RRC instance.

[0128] 13. The method of any one of embodiments 9 to 12, wherein if the WTRU performs an RRC state transition from LTE RRC_CONNECTED to LTE RRC_IDLE on the first RAT, the WTRU performs at least one of: disabling configurations for all serving cells of the second RAT; deleting configurations for all serving cells of the second RAT; turning off the radio front-end for the second RAT; and terminating the second RRC instance.

[0129] 14. The method of any one of embodiments 1-13, further comprising the WTRU establishing a first radio resource control (RRC) connection in the first RAT using the first RRC instance.

[0130] 15. The method of embodiment 14, further comprising the WTRU establishing a second RRC connection in the second RAT using the second RRC instance.

[0131] 16. The method of embodiment 14 or 15, further comprising the WTRU adding a serving cell for the second RRC connection in the second RAT in response to security being activated for the first RAT.

[0132] 17. The method of embodiment 14 or 15, further comprising the step of: the WTRU performing radio link monitoring (RLM) on a configured serving cell of a first RAT, wherein the first RAT is LTE.

[0133] 18. The method of embodiment 17, further comprising the WTRU determining whether a configured serving cell of the first RAT is experiencing a radio link failure (RLF).

[0134] 19. The method of embodiment 17 or 18, further comprising the step of: if the WTRU determines that a configured serving cell of the first RAT is experiencing RLF, performing at least one of deleting configurations for all serving cells of the second RAT and turning off the radio front end for the second RAT, wherein the second RAT is HSPA.

[0135] 20. The method of embodiment 14 or 15, further comprising the WTRU configuring mobility management for the second RRC connection based on the first RRC connection.

[0136] 21. A wireless transmit / receive unit (WTRU) configured for multi-radio access technology (RAT) operation, the WTRU comprising a transceiver configured to wirelessly communicate information on a first operating frequency in accordance with a first RAT.

[0137] 22. The WTRU of embodiment 21, wherein the transceiver is further configured to wirelessly communicate information on a second operating frequency according to a second RAT.

[0138] 23. The WTRU of embodiment 21 or 22, wherein the first RAT is one of Long Term Evolution (LTE) and High Speed ​​Packet Access (HSPA), and the second RAT is one of HSPA, LTE, and WiFi.

[0139] 24. The WTRU of embodiment 21 or 22, further comprising a processor configured to establish a radio resource control (RRC) connection in the first RAT using the RRC instance.

[0140] 25. The WTRU of embodiment 24, wherein the transceiver is further configured to receive a configuration for at least one serving cell of a second RAT over an RRC connection.

[0141] 26. The WTRU of embodiment 24 or 25, wherein the processor is further configured to configure radio resources for the second RAT using the RRC instance.

[0142] 27. The WTRU of any one of embodiments 24-26, wherein the transceiver is further configured to transmit and receive an RRC protocol data unit (PDU) of a type corresponding to the first RAT, and the RRC PDU of the type corresponding to the first RAT includes at least one information element (IE) corresponding to the second RAT.

[0143] 28. The WTRU of any one of embodiments 21-27, further comprising: a processor configured to establish a radio resource control (RRC) connection in the first RAT using the first RRC instance.

[0144] 29. The WTRU of embodiment 28, wherein the transceiver is further configured to receive a configuration for at least one serving cell of a second RAT over an RRC connection.

[0145] 30. The WTRU of embodiment 28 or 29, wherein the processor is further configured to configure radio resources for the second RAT using the second RRC instance.

[0146] 31. The WTRU of any one of embodiments 28 to 30, wherein the transceiver is further configured to transmit and receive PDUs over an RRC connection, each PDU having a signaling radio bearer identifier (SRB_ID) corresponding to one of the first RRC instance and the second RRC instance.

[0147] 32. The WTRU of any one of embodiments 28 to 30, wherein the processor is further configured to, if performing an RRC state transition from LTE RRC_CONNECTED to LTE RRC_IDLE on the first RAT, perform at least one of: disabling configurations for all serving cells of the second RAT; deleting configurations for all serving cells of the second RAT; turning off a radio front-end for the second RAT; and terminating the second RRC instance.

[0148] 33. The WTRU of any one of embodiments 21-32, further comprising: a processor configured to establish a first radio resource control (RRC) connection in a first RAT using a first RRC instance.

[0149] 34. The WTRU of embodiment 33, wherein the processor is further configured to establish a second RRC connection in a second RAT using a second RRC instance.

[0150] 35. The WTRU of embodiment 33 or 34, wherein the processor is further configured to add a serving cell for a second RRC connection in the second RAT in response to security being activated for the first RAT.

[0151] 36. The WTRU of any one of embodiments 33-35, wherein the processor is further configured to perform radio link monitoring (RLM) for a configured serving cell of the first RAT.

[0152] 37. The WTRU of embodiment 36, wherein the first RAT is LTE.

[0153] 38. The WTRU of any one of embodiments 33-37, wherein the processor is further configured to determine whether a configured serving cell of the first RAT is experiencing an uplink (UL) radio link failure (RLF).

[0154] 39. The WTRU of any one of embodiments 33 to 37, wherein the processor is further configured to perform at least one of deleting configurations for all serving cells of the second RAT and turning off a radio front end for the second RAT if the processor determines that a configured serving cell of the first RAT is experiencing an UL RLF, and the second RAT is HSPA.

[0155] 40. The WTRU of any one of embodiments 33-39, wherein the processor is further configured to configure mobility management for the second RRC connection based on the first RRC connection.

[0156] While features and elements have been described above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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 conjunction with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: A transceiver; a processor; The processor and the transceiver receiving a first radio resource control connection (first RRC connection) using a first radio access technology (first RAT) on a primary cell of the first RAT, the first RRC message including configuration information for a second RRC connection on a secondary cell of the second RAT; transmitting radio resource configuration information associated with the second RRC connection on the secondary cell of the second RAT; receiving notification of a state transition to idle in the first RAT; In response to the received notification, release the second RRC connection on the secondary cell of the second RAT. A WTRU configured as follows:

2. The WTRU of claim 1 , wherein the processor and the transceiver are further configured to transmit and receive data over the primary cell of the first RAT.

3. The WTRU of claim 1 , wherein the first RRC message is an RRC reconfiguration message.

4. The WTRU of claim 1 , wherein the configuration information indicates to the WTRU to establish the second RRC connection on the secondary cell of the second RAT.

5. The WTRU of claim 1 , wherein the configuration information indicates adding the secondary cell for the second RAT.

6. The WTRU of claim 1 , wherein the configuration information includes information for establishing a radio bearer for the second RAT.

7. The WTRU of claim 1 , wherein the first RRC message includes the radio resource configuration information associated with the second RRC connection.

8. 2. The WTRU of claim 1, wherein the first RRC connection on the primary cell of the first RAT uses a first RRC instance, and the second RRC connection on the secondary cell of the second RAT uses a second RRC instance.

9. The WTRU of claim 1 , wherein data transmission using the first RAT uses at least a first carrier and data transmission using the second RAT uses at least a second carrier.

10. The WTRU of claim 1 , wherein the first RRC message further includes configuration information for the first RRC connection on the primary cell of the first RAT.

11. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving, using a first radio resource control connection (first RRC connection) on a primary cell of a first radio access technology (first RAT), a first RRC message including configuration information for a second RRC connection on a secondary cell of a second RAT; transmitting, on the secondary cell of the second RAT, radio resource configuration information associated with the second RRC connection; receiving notification of a state transition to idle in the first RAT; in response to the received notification, releasing the second RRC connection on the secondary cell of the second RAT; A method for providing the above.

12. transmitting and receiving data on the primary cell of the first RAT; The method of claim 11 further comprising:

13. The method of claim 11 , wherein the first RRC message is an RRC reconfiguration message.

14. 12. The method of claim 11, wherein the configuration information indicates to the WTRU to establish the second RRC connection on the secondary cell of the second RAT.

15. The method of claim 11 , wherein the configuration information indicates adding the secondary cell for the second RAT.

16. The method of claim 11 , wherein the configuration information includes information for establishing a radio bearer for the second RAT.

17. 12. The method of claim 11, wherein the first RRC message includes the radio resource configuration information associated with the second RRC connection.

18. 12. The method of claim 11, wherein the first RRC connection on the primary cell of the first RAT uses a first RRC instance, and the second RRC connection on the secondary cell of the second RAT uses a second RRC instance.

19. 12. The method of claim 11, wherein data transmission using the first RAT uses at least a first carrier and data transmission using the second RAT uses at least a second carrier.

20. 12. The method of claim 11, wherein the first RRC message further includes configuration information for the first RRC connection on the primary cell of the first RAT.

Citation Information

Patent Citations

  • Architecture Providing Multi-System Carrier Aggregation

    US20110134831A1