Operation with multiple schedulers in a wireless system

Abstract

To provide systems and methods for a WTRU to operate using multiple schedulers.SOLUTION: A WTRU may exchange data with a network over more than one data path. Each data path may use a radio interface connected to a different network node and each node may be associated with an independent scheduler. For example, the WTRU may establish an RRC connection between the WTRU and the network. The RRC connection may establish a first radio interface between the WTRU and a first serving site of the network and a second radio interface between the WTRU and a second serving site of the network. The RRC connection may be established between the WTRU and an MeNB and a control function may be established between the WTRU and an SCeNB. The WTRU may receive data from the network over the first radio interface or the second radio interface.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to wireless communications. [Background technology]

[0002] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 61 / 692,548, filed August 23, 2012, U.S. Provisional Patent Application No. 61 / 726,448, filed November 14, 2012, U.S. Provisional Patent Application No. 61 / 753,323, filed January 16, 2013, U.S. Provisional Patent Application No. 61 / 753,334, filed January 16, 2013, U.S. Provisional Patent Application No. 61 / 821,071, filed May 8, 2013, U.S. Provisional Patent Application No. 61 / 821,186, filed May 8, 2013, and U.S. Provisional Patent Application No. 61 / 863,311, filed August 7, 2013, the contents of which are incorporated herein by reference in their entireties.

[0003] Wireless communication systems are widely deployed to provide various types of communication content such as voice, data, etc. These systems may be multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, etc.). Examples of such multiple-access systems may include Code Division Multiple Access (CDMA) systems, Wideband Code Division Multiple Access (WCDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, etc.

[0004] These multiple access technologies are being adopted to provide a common protocol that allows various wireless devices to communicate at city, national, regional, and even global levels. An example of an emerging telecommunications standard is LTE. LTE is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by 3GPP. LTE is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving service, utilizing new spectrum, and better integrating with other open standards that use OFDMA on the downlink (DL), SC-FDMA on the uplink (UL), and multiple-input multiple-output (MIMO) antenna technology. Summary of the Invention

[0005] Systems and methods are disclosed for a wireless transmit / receive unit (WTRU) to operate in a wireless communication system that utilizes multiple schedulers. For example, in some multiple-scheduler systems, the schedulers may lack a low-latency communication interface for coordinating scheduling operations associated with the same WTRU. Because the WTRU may exchange data with the network through more than one data path, each data path may use an air interface connected to a different network node, and each node may be associated with an independent scheduler. For example, the WTRU may establish a radio resource control (RRC) connection between the WTRU and the network. The RRC connection may establish a first air interface between the WTRU and a first serving site of the network and a second air interface between the WTRU and a second serving site of the network. The first serving site may be a macro eNodeB (MeNB), and the second serving site may be a small cell eNodeB (SCeNB). The RRC connection may be established between the WTRU and the MeNB, and control functions may be established between the WTRU and the SCeNB. The WTRU may receive data from the network over the first radio interface or the second radio interface.

[0006] As an example, methods and systems are described for a WTRU operating using multiple independently scheduled layers. For example, the WTRU may establish a radio resource control (RRC) connection with a first serving site. The WTRU may receive a reconfiguration message from the first serving site. The reconfiguration message may include a configuration for the WTRU to connect to one or more cells associated with a second serving site. The reconfiguration message may indicate at least one radio bearer (RB) to be used by the WTRU at the second serving site. The WTRU may determine to activate a connection to the second serving site. Based on the determination to activate a connection to the second serving site, the WTRU may monitor at least one control channel of one or more cells associated with the second serving site. For example, the reconfiguration message may be an RRC connection reconfiguration message, and the at least one RB may be a new RB established for use in the second serving site. In an example, the reconfiguration message may be an RRC connection reconfiguration message including a mobility control information element, and at least one RB may be an RB previously mapped to a first serving site, and the RRC connection reconfiguration message may trigger the WTRU to begin associating the RB previously mapped to the first serving site with a second serving site.

[0007] In an example, the reconfiguration message may include multiple radio resource management (RRM) configurations for a given cell associated with the second serving site. Upon activating a connection to the second serving site, the WTRU may apply a default RRM configuration of the multiple RRM configurations. The WTRU may receive one or more of physical layer signaling or Layer 2 signaling. The one or more of the physical layer signaling or Layer 2 signaling may indicate another RRM configuration of the multiple RRM configurations that the WTRU should apply in the given cell of the second serving site. The WTRU may then apply the other RRM configuration when connected to the given cell of the second serving site. For example, the one or more of the physical layer signaling or Layer 2 signaling may include one or more of a physical downlink control channel (PDCCH) transmission or a medium access control (MAC) control element (CE). The WTRU may determine which of multiple RRM configurations to apply based on an index received in one or more of the physical layer signaling or Layer 2 signaling. At least one RRM configuration of the multiple RRM configurations may include one or more of a physical layer configuration, a configuration for reporting a channel quality indication (CQI) (hereinafter, a channel quality indication reporting configuration), or a MAC configuration.

[0008] In an example, the control plane may be distributed across serving sites, coordinated among serving sites, and / or aggregated at one or more serving sites. For example, a network RRC entity associated with both a first serving site and a second serving site may be located at the second serving site. One or more signaling radio bearers terminated at the RRC entity at the first serving site may be transmitted to the WTRU via the second serving site. For example, one or more signaling radio bearers terminated at the RRC entity at the first serving site that are transmitted to the WTRU via the second serving site may be associated with control information for managing radio resources between the WTRU and the second serving site. The WTRU may perform one or more measurements of at least one or more cells associated with the second serving site. The WTRU may report the one or more measurements to the first serving site.

[0009] The WTRU may handle security for transmissions associated with the first serving site and / or the second serving site in a semi-coordinated and / or independent manner. For example, the first serving site and the second serving site may each be associated with an independent Packet Data Convergence Protocol (PDCP) instance for the WTRU. The WTRU may be configured to utilize the same security key to encrypt PDCP packets to be transmitted to either the first PDCP instance associated with the first serving site or the second PDCP instance associated with the second serving site. For example, the WTRU may be configured to use different BEARER parameters for each of the first PDCP instance associated with the first serving site and the second PDCP instance associated with the second serving site. For example, the respective BEARER parameters used to encrypt transmissions to the second PDCP entity at the second serving site may be determined based on the identity of the layer associated with the second serving site.

[0010] The WTRU may implement two or more sets of protocol stacks for the control plane and / or the data plane. For example, the WTRU may include a first medium access control (MAC) instance configured to access a cell associated with a first serving site and a second MAC instance configured to access a cell associated with a second serving site. The WTRU may configure data associated with at least one logical channel using either the first MAC instance or the second MAC instance. The WTRU may be configured to deactivate at least one bearer associated with the first serving site based on activating a connection to the second serving site. The WTRU may be configured to measure at least one cell associated with the second serving site and determine to autonomously activate at least one cell based on the measurements. The RRC reconfiguration message may include pre-configuration for the at least one cell, and the WTRU may be configured to autonomously activate the at least one cell using a random access channel (RACH) procedure.

[0011] An RRC connection for the WTRU may establish one or more SRBs between the WTRU and the network, such that each of the established SRBs may be assigned to at least one of the first and second radio interfaces. A received / transmitted RRC PDU may be associated with one of the one or more SRBs. An RRC PDU may be received over either the first or second radio interface, regardless of its associated SRB. The RRC connection may be controlled by the network. The WTRU may send an indication to the network that the WTRU supports multi-scheduling operations. [Brief explanation of the drawings]

[0012] [Figure 1A]FIG. 1 is a diagram of an example communications system in which one or more 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 may be used within the communication system shown in FIG. 1A. [Figure 1D] 1B is a system diagram of another example radio access network and another example core network that may be used within the communication system shown in FIG. 1A. [Figure 1E] 1B is a system diagram of another example radio access network and another example core network that may be used within the communication system shown in FIG. 1A. [Figure 2A] FIG. 1 illustrates an exemplary reference architecture that may implement a multi-scheduler architecture. [Figure 2B] FIG. 1 illustrates another exemplary reference architecture in which the multi-scheduler architecture may be implemented. [Figure 3] FIG. 1 illustrates an exemplary implementation of an aggregated control plane. [Figure 4] FIG. 1 illustrates another exemplary implementation of an aggregated control plane. [Figure 5] A diagram showing an example control plane protocol stack for SRB exchanged over a data path including an MeNB when an RRC instance is terminated at an MeNB on the network side. [Figure 6] FIG. 10 illustrates an exemplary control plane protocol stack for an SRB, exchanged via a data path including an SCeNB when an RRC instance is terminated at an MeNB on the network side. [Figure 7]FIG. 1 illustrates an example control plane protocol stack for a coordinated control plane in which a first RRC instance is terminated at a first serving site and a second RRC instance is terminated at a second serving site. [Figure 8] FIG. 10 illustrates an exemplary control plane protocol stack for an SRB exchanged over a data path including a first serving site when an RRC instance is terminated at the first serving site on the network side. [Figure 9] FIG. 10 illustrates an exemplary control plane protocol stack for an SRB exchanged over a data path including a second serving site when an RRC instance is terminated at the second serving site on the network side. [Figure 10] FIG. 1 illustrates an example control plane protocol stack for a distributed control plane where an RRC instance is terminated at a first serving site. [Figure 11] 1 illustrates an example of a control plane protocol stack with a distributed approach for RRC instances SR0, SR1, and SR2 terminated at a first serving site. [Figure 12] FIG. 10 illustrates an example control plane protocol stack with a distributed approach for an SRB associated with a second serving site. [Figure 13] FIG. 10 illustrates an exemplary protocol stack that may be used for the user plane data path when the data path is split above the PDCP layer in the network. [Figure 14] FIG. 1 illustrates an exemplary protocol stack in which an SRB may be associated with a single SAP and the data path is split above the PDCP layer in a network using an aggregated control plane. [Figure 15] FIG. 10 illustrates an example of a split data path above the PDCP layer for the user plane where multiple DRB SAPs are utilized. [Figure 16]FIG. 1 illustrates an example protocol stack in which an SRB may be associated with multiple SAPs and the data path is split above the PDCP layer in a network using an aggregated control plane. [Figure 17] FIG. 10 is a diagram illustrating an example of a user plane protocol stack. [Figure 18] FIG. 10 is a diagram illustrating an example of a user plane protocol stack. [Figure 19] FIG. 1 illustrates an example control plane protocol stack for a data path split over RLC, where PDCP PDUs may be forwarded over multiple data paths. [Figure 20] A diagram showing an example of a data path associated with a secondary layer when data division occurs below the PDCP layer (e.g., above the RLC layer). [Figure 21] FIG. 1 illustrates an exemplary control plane protocol stack that may be utilized when the data path is split above the MAC layer. [Figure 22] FIG. 1 illustrates an exemplary user plane protocol stack that may be utilized when the data path is split above the MAC layer. [Figure 23] FIG. 1 illustrates an exemplary Layer 2 structure for uplink multi-site operation that may implement a separated UL transmission scheme. [Figure 24] FIG. 1 illustrates an exemplary Layer 2 architecture for uplink multi-site operation in which a split RLC transmission scheme is utilized. [Figure 25] FIG. 1 illustrates an example Layer 2 structure in which data for a given logical channel may be mapped to multiple transport channels, and a transport channel may be associated with multiple different serving sites. [Figure 26] FIG. 1 illustrates an example of a Layer 2 structure for downlink multi-site operation that may be used for a separated DL transmission scheme. [Figure 27]FIG. 1 illustrates an example of a Layer 2 architecture for downlink multi-site operation that may be used for a split RLC DL transmission scheme. [Figure 28] FIG. 1 illustrates an example Layer 2 structure in which downlink data for a given logical channel may be mapped to multiple transport channels, and the transport channels may be associated with different serving sites. DETAILED DESCRIPTION OF THE INVENTION

[0013] A detailed description of illustrative embodiments will now be described with reference to various drawings. While this description provides detailed examples of possible implementations, it should be noted that the details are intended to be exemplary and are not intended to limit the scope of the present application in any way.

[0014] 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, broadcasts, etc. to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the 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), single-carrier FDMA (SC-FDMA), and the like.

[0015] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 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, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, and the like.

[0016] 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 / 107 / 109, 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, and the like. While the base stations 114a, 114b are each illustrated 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.

[0017] The base station 114a may be part of the RAN 103 / 104 / 105, 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, which may also be 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, i.e., one transceiver 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.

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

[0019] 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, and 102c in the RANs 103 / 104 / 105 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 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).

[0020] 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 115 / 116 / 117 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0021] 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), and the like.

[0022] 1A may be a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as, for example, a business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 (e.g., 802.11ac, 802.11af, and the like) 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 a picocell or a femtocell utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0023] The RANs 103 / 104 / 105 may be in communication with the core networks 106 / 107 / 109, 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 networks 106 / 107 / 109 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 RANs 103 / 104 / 105 and / or the core networks 106 / 107 / 109 may be in direct or indirect communication with other RANs that utilize the same RAT as the RANs 103 / 104 / 105 or a different RAT. For example, in addition to being connected to RAN 103 / 104 / 105, which may utilize E-UTRA radio technology, core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that utilizes GSM radio technology.

[0024] The core networks 106 / 107 / 109 may also serve as gateways 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 worldwide 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 networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may utilize the same RAT as the RANs 103 / 104 / 105 or a different RAT.

[0025] 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, which may utilize cellular-based radio technology, and a base station 114b, which may utilize IEEE 802.11 radio technology.

[0026] 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. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b and / or the nodes they may represent, such as, but not limited to, a base transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and a proxy node, among others, may include some or all of the elements illustrated in FIG. 1B and described herein.

[0027] 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 association 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, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality 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 illustrates 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.

[0028] 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 115 / 116 / 117. 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 appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0029] 1B 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 115 / 116 / 117.

[0030] The transceiver 120 may be configured to modulate signals to be 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, for example.

[0031] 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 access 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, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as memory on a server or home computer (not shown).

[0032] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to 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 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.

[0033] 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 115 / 116 / 117 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location determination implementation while remaining consistent with an embodiment.

[0034] 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 electronic 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, and the like.

[0035] 1C is a system diagram of the RAN 103 and the core network 106, according to an embodiment. As mentioned above, the RAN 103 can communicate with the WTRUs 102a, 102b, and 102c over the air interface 115 utilizing UTRA radio technology. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0036] As shown in FIG. 1C , Node-Bs 140a and 140b may be in communication with RNC 142a. Additionally, Node-B 140c may be in communication with RNC 142b. Node-Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b may be in communication with each other via an Iur interface. Each of RNCs 142a and 142b may be configured to control its respective Node-B 140a, 140b, and 140c to which it is connected. Additionally, each of RNCs 142a and 142b may be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0037] 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is illustrated as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the operator of the core network.

[0038] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and MGW 144 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 fixed-line communication devices.

[0039] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 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.

[0040] As mentioned above, the core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0041] 1D is a system diagram of the RAN 104 and the core network 107, according to an embodiment. As discussed above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also be in communication with the core network 107.

[0042] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c 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 eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0043] Each of the eNode-Bs 160a, 160b, 160c 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, and the like. As shown in FIG. 1D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0044] 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is illustrated as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the operator of the core network.

[0045] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial connection of the WTRUs 102a, 102b, 102c, and the like. The MME 162 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.

[0046] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during handovers between eNodeBs, 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.

[0047] The serving gateway 164 may also be connected to a PDN gateway 166, 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.

[0048] The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional fixed-line communication devices. For example, the core network 107 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 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0049] 1E is a system diagram of the RAN 105 and the core network 109, according to an embodiment. The RAN 105 may be an access service network (ASN) that communicates with the WTRUs 102a, 102b, 102c over an air interface 117 utilizing IEEE 802.16 radio technology. As discussed further below, communication links between different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0050] 1E, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions such as triggering handoffs, establishing tunnels, radio resource management, traffic classification, enforcing quality of service (QoS) policies, and the like. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for calling, caching subscriber profiles, routing to the core network 109, and the like.

[0051] The air interface 117 between the WTRUs 102a, 102b, and 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Additionally, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and 102c and the core network 109 may be defined as an R2 reference point that may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0052] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handover and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c, and the ASN gateway 182 may be defined as an R6 reference point that may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0053] 1E, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which may include protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is illustrated as part of the core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the operator of the core network.

[0054] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and user service support. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional fixed-line communication devices. Additionally, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0055] 1E, it will be understood that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0056] Systems and methods are disclosed for utilizing multi-node scheduling, which allows a WTRU to exchange data over a wireless communications network using more than one data path. For example, transmit / receive points of different air interfaces may be associated with each of the data paths (e.g., each data path may use a radio interface associated with a different network node). Different transmit / receive points associated with different data paths may independently schedule WTRU transmissions over their respective data paths. In other words, a first scheduler may schedule transmissions to / from the WTRU over the first data path, and a second scheduler may schedule transmissions to / from the WTRU over the second data path. Although different transmit / receive points in a network may be in communication with each other, the data links between the different transmit / receive points may be associated with relatively high latency. Therefore, it may be difficult or impractical for different transmit / receive points to schedule transmissions over data paths in a coordinated manner. Thus, each transmit / receive point may independently schedule the WTRU to transmit and / or receive over its respective transmit path. Such a transmitting / receiving point may be called a serving site.

[0057] Examples described herein may be described with respect to examples implemented in an evolved universal terrestrial radio access network (E-UTRAN). However, the methods and systems disclosed herein may be applicable to other network architectures and / or may be used by other network nodes. Data transmitted to (or received from) a serving site for a WTRU may be provided to (or passed from) a core network (e.g., a serving gateway (S-GW)). The serving site may support one or more Layer 2 protocols (e.g., MAC, RLC, and / or PDCP) for a given radio bearer.

[0058] For example, the WTRU may establish a radio resource control (RRC) connection between the WTRU and a wireless communications network. The RRC connection may establish or configure a first radio interface between the WTRU and a first node of the network and a second radio interface between the WTRU and a second node of the network. The first node may be a macro eNodeB (MeNB), and the second node may be a small cell eNodeB (SCeNB). In an example, the RRC connection may be established between the WTRU and the MeNB, and control functions may be established between the WTRU and the SCeNB. The WTRU may receive data from the network over the first radio interface and / or the second radio interface. Although the examples described herein may be described with respect to operation utilizing a first data path (e.g., which may also be referred to as a first layer, primary data path, primary layer, etc.) and a second data path (e.g., which may also be referred to as a second layer, secondary data path, secondary layer, etc.) associated with an MeNB, the methods and systems described herein may be equally applicable to other independently scheduled network transmit / receive points (e.g., more than two independently scheduled eNBs, more than two independently scheduled NBs, more than two independently scheduled RAN access nodes, etc.).

[0059] The systems and methods described herein may be applicable to one or more multi-scheduler frameworks, where different network nodes serve as transmit / receive points for different data paths. The use of multiple data paths may be facilitated by decoupling the relationship between bearers, radio bearers, and / or the like. For example, when a multi-scheduler framework is utilized, an evolved packet service (EPS) bearer may be associated with multiple radio bearers. When multi-scheduler operation is utilized, the WTRU may be configured to exchange control signaling and / or user plane data over one or more data paths.

[0060] A data path may be defined based on the identity of one or more service access points (SAPs) used to transmit data associated with the data path, based on the identity of one or more network interfaces or nodes used to transmit data associated with the data path, based on one or more radio interfaces (e.g., X2, X2bis, X2', Uu, etc.) used to transmit data associated with the data path, and / or the like. Additionally, a data path may be defined based on a communications protocol stack (e.g., including one or more of a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, a Physical (PHY) layer, etc.) that may be used to define a processing sequence for forwarding information associated with the data path. Information or data transmitted over a data path may include one or more of control plane data (e.g., Non-Access Stratum (NAS) signaling, RRC signaling, etc.) and / or user plane data (e.g., IP packets, etc.). A data path may be scheduled independently of other data paths.

[0061] For example, in LTE Release 11, data transfer may be performed through a single data path between the WTRU and the network. In the control plane, there may be a direct mapping between SRBs and logical channels (LCHs) on a single Uu interface (e.g., the interface between the WTRU and the eNB). For the user plane, there may be a direct mapping between EPS bearers, data radio bearers (DRBs), and logical channels (LCHs) on the same Uu interface.

[0062] However, in the presence of multiple independent schedulers, the WTRU may be configured to utilize more than one data path, for example, each data path may be established between the WTRU and a network node using a different Uu interface. A data path may also be referred to as a layer. For example, the WTRU may be configured to transmit and / or receive data on multiple layers, with each layer associated with a different data path. Each layer may be scheduled independently of the other layers. Each layer may be associated with a different air interface for the WTRU. Each layer may be associated with a serving site that serves as a transmission and / or reception point for a data path within the network.

[0063] To support transmissions on multiple layers, multiple MAC instances may be established in the WTRU. For example, the WTRU may be configured with multiple MAC instances, each associated with a corresponding set of physical layer parameters and / or layer-specific radio bearers. By way of example, the WTRU may be configured with a set of primary layer information (e.g., associated with a macro layer / MeNB / macro serving site) and one or more sets of secondary layer information (e.g., associated with a small cell layer / SCeNB / small cell serving site). The WTRU may be configured with one or more serving cells for each layer. For example, the WTRU may perform carrier aggregation in each of the layers so that transmission and / or reception from multiple cells in a given layer can occur.

[0064] For example, a WTRU may be configured to operate with one or more serving sites (e.g., also referred to as serving eNBs) in the downlink and / or uplink. Each serving site may be associated with one or more serving cells. For example, a WTRU may operate using a single serving cell (e.g., component carrier) at a first serving site (e.g., MeNB) and may operate using multiple serving cells (e.g., multiple component carriers) at a second serving site (e.g., SCeNB). Thus, a serving site may be associated with multiple serving cells. Each serving cell at a given serving site may be configured for operation on a corresponding component carrier (CC). A serving site may support one or more CCs. Because each CC within a serving site may operate using a different frequency range from other CCs at the serving site, each of the serving cells associated with a given serving site may transmit using a different CC. However, serving cells from different serving sites may transmit using the same CC. Thus, a serving cell may be associated with the same CC but with different serving sites. A WTRU may be configured with a maximum number of serving sites (e.g., 1, 2, 3, 4, etc.) on which it may operate. An indication of the maximum number of serving sites that the WTRU may be allowed to utilize may be signaled by the WTRU to the network as part of the WTRU's capability information and / or may be determined by the network based on the WTRU's class of operation.

[0065] A serving site may be associated with one or more transport channels. For example, in the uplink, a WTRU may be configured to deliver data to the physical layer using a transport channel (e.g., an UL-SCH) associated with a serving cell associated with a particular serving site. In an example, each transport channel may be specific to a given serving site / layer, but a transport channel may be associated with multiple serving cells and / or component carriers within that serving site. For example, a UL-SCH may be associated with a particular serving site (e.g., a serving site associated with a data path including an MeNB) and one or more component carriers associated with that serving site (e.g., multiple component carriers associated with the MeNB). A transport block to be delivered to that serving site may be given data associated with a transport channel mapped to that serving site. In the downlink, a WTRU may be configured to receive data at the physical layer and deliver the data to a transport channel (e.g., a DL-SCH) associated with a serving cell associated with a particular serving site. For example, a DL-SCH may be associated with a particular serving site (e.g., a serving site associated with a data path that includes the SCeNB) and one or more component carriers associated with that serving site (e.g., multiple component carriers associated with the SCeNB). A transport block received at the physical layer may be mapped to a transport channel associated with the serving site from which the transport block is received. A given serving site may be associated with zero, one, or more than one UL-SCH and zero, one, or more than one DL-SCH.

[0066] Each serving site may be associated with a corresponding MAC instance in the WTRU. A WTRU may be configured with multiple MAC instances. Each MAC instance may be associated with a particular serving site. Terms such as serving site, layer, data path, and MAC instance may be used interchangeably herein. Each MAC instance may be associated with one or more configured serving cells and may support one or more CCs. Each UL-SCH and / or DL-SCH may be associated with a given MAC instance (e.g., one-to-one correspondence between transport channels and MAC instances).

[0067] A MAC instance may be configured with a primary cell (PCell). For each serving site (and / or MAC instance), one of its associated serving cells may support at least a subset of the functionality supported by the primary serving cell (PCell) in a legacy (e.g., single-site) system. For example, one or more of the serving cells of a given MAC instance may support PUCCH transmission, which may be utilized to transmit scheduling requests, HARQ feedback, CSI feedback, and / or the like, for the UL-SCH and / or DL-SCH mapped to the corresponding serving site. A serving cell configured to receive uplink control information (UCI) associated with a transport channel of a serving site may be referred to as a "site Pcell" and / or a "MAC primary cell." Each MAC instance may be configured with one Pcell and zero or more Scells. Furthermore, the Pcell of a primary MAC instance (e.g., a MAC instance associated with an MeNB) may have additional functionality specific to that MAC instance. A serving site may be associated with a data path. A serving site may correspond to a single data path.

[0068] RRC may be utilized to configure multiple MAC instances. For example, when RRC configures a MAC instance for operation, the WTRU may determine whether a received configuration or parameter is associated with a given MAC instance based on an explicit indication included in a field of an information element (IE) containing configuration information. In an example, if multiple configurations are received, the WTRU may implicitly determine that each configuration applies to a respective MAC instance. For example, if multiple radioResourceConfigDedicated IEs are received in an RRC connection setup / modification message, the WTRU may determine that a first radioResourceConfigDedicated IE is associated with a first MAC instance and a second radioResourceConfigDedicated IE is associated with a second MAC instance. In an example, a different type of IE may be defined to configure a secondary MAC instance (e.g., radioResourceConfigDedicatedSecondaryMACInstance IE). The WTRU may determine that a received configuration / IE applies to a secondary MAC instance based on the type of the received IE. The WTRU may determine that a received configuration / IE applies to a secondary MAC instance based on the presence of an access stratum (AS) configuration in an IE (e.g., similar to the mobilityControl IE). For example, if certain AS configuration information is present in the received configuration information, the WTRU may determine that the configuration applies to a secondary MAC instance. If AS configuration information is not present in the received configuration information, the WTRU may determine that the configuration applies to a primary MAC instance. The WTRU may determine to which MAC instance a given configuration is applicable based on the identity of the SRB over which the configuration message is received (e.g., SRB3 may indicate configuration information for a secondary MAC instance), for example, if such an SRB was previously configured for the WTRU.If the individual RRC instances / entities are associated with different serving sites, the WTRU may determine to which MAC instance the configuration applies based on the RRC entity from which the configuration was received.

[0069] The different layers utilized by the WTRU may be associated with different types of radio access nodes and / or different types of cells. For example, the primary layer may be associated with a macro cell served by an MeNB, and the secondary layer may be associated with a small cell served by an SCeNB. The network configuration may be transparent to the WTRU. Although examples may be described in which schedulers associated with different layers are implemented in different RAN nodes (e.g., different eNBs), the systems and methods described herein may be applicable to configurations in which multiple schedulers are implemented in a single RAN node.

[0070] 2A is a system diagram illustrating an example network architecture that may provide multiple layers for a WTRU to transmit / receive. For example, the MeNB 202 may provide a first layer of wireless coverage (e.g., a macro layer) to the WTRU. The SCeNB 204 and / or the SCeNB 206 may provide additional layers of wireless coverage (e.g., a second layer, a third layer, etc.) to the WTRU. The SCeNB 204 and / or the SCeNBs may provide one or more layers of “small cell” coverage for the WTRU. One or more SCeNBs may be logically grouped to form a cluster of SCeNBs, which may be referred to as a cluster. For example, the SCeNB 204 and the SCeNB 206 may be included in a cluster.

[0071] The MeNB 202 may communicate with one or more of the SCeNB 204 and / or the SCeNB 206 via a logical communication interface that may be referred to as an X2bis interface. The MeNB 202 may communicate with a cluster of one or more SCeNBs using the X2bis interface. An SCeNB in ​​a cluster configuration may communicate with other SCeNBs in the cluster and / or with a central controller (e.g., a cluster controller, a small cell gateway (SCGW), etc.). For example, the SCGW may terminate S1-U for bearers associated with the corresponding small cell layer. The X2bis interface may be an extension of the X2 interface (e.g., an interface used by an eNB to communicate with other eNBs), may be the same as the X2 interface, and / or X2bis may be a separate logical interface (e.g., in addition to the X2 interface). The X2bis interface may be a wired interface and / or a wireless interface. In examples, the X2bis interface may be implemented over a communication medium with relatively high latency (e.g., and / or a communication medium in which relatively low latency may not be guaranteed), making it substantially difficult to implement coordinated scheduling between, for example, the MeNB and the SCeNB.

[0072] 2B is a system diagram illustrating another example network architecture that can provide multiple layers of WTRUs for transmission / reception. As shown in FIG. 2B, an MeNB can communicate with another MeNB via an X2' interface and with an SCeNB via an X2bis interface. The X2' interface may be an extension of the X2 interface, may be the same as the X2 interface, and / or may be a separate logical interface (e.g., in addition to the X2 interface).

[0073] With multi-scheduling, a WTRU can establish a connection such that data can be exchanged using one or more data paths, each path may use an air interface (e.g., Uu) associated with a different network node (e.g., MeNB or SCeNodeB). The air interfaces for the different data paths may be independently scheduled by the respective network node (e.g., MeNB or SCeNodeB).

[0074] A first RRC connection may be established between the WTRU and the MeNB. The first RRC connection may establish signaling radio bearers SRB0, SRB1, and SRB2. For example, this connection may be established according to LTE Release 11 principles. During RRC connection establishment of the first RRC connection, the WTRU may indicate whether it supports operation according to the multi-scheduler principle. For example, the WTRU may indicate whether it supports multi-scheduled / multi-layered operation when indicating the WTRU's operation class and / or otherwise indicating the WTRU's capabilities.

[0075] When a WTRU operates according to the multi-scheduler principle, the control plane may be extended to support multi-layer operation. For example, a control plane associated with a WTRU that operates utilizing multiple layers may be implemented using an aggregated control plane / entity, a coordinated control plane / entity, and / or a distributed control plane / entity.

[0076] For example, from the network perspective, an aggregated control plane / entity may be characterized by a single terminating RRC instance (e.g., MeNB, another network node / entity, etc.) augmented by control functions between the terminating node in the network and the SCeNB. In an example, when utilizing an aggregated control plane, for example, if the terminating instance of the RRC connection is logically separate from the MeNB, the control functions may be established between the terminating node of the RRC instance and the MeNB. From the WTRU perspective, an aggregated control plane / entity may be characterized by a single RRC entity. The WTRU may also implement one or more extensions to control aspects of the multi-scheduler (e.g., one or more SRBs) specific to a subset of configured serving cells / layers (e.g., those corresponding to the SCeNBs).

[0077] From the network perspective, a coordinated control plane / entity may be characterized by multiple terminating RRC instances (e.g., a first terminating instance in a first network node such as an MeNB, a second terminating instance in a second network node such as an SCeNB), which may be augmented by control functions implemented between corresponding terminating nodes. Each of the RRC instances may implement a corresponding set of SRBs and / or a corresponding set of control functions (e.g., connection establishment, mobility control and RRM, connection release, etc.). From the WTRU perspective, a coordinated control plane / entity may be characterized by multiple RRC entities. The WTRU may also implement one or more extensions to aspects of the control multi-scheduler (e.g., signaling received via the first RRC instance) that may trigger the establishment of a second RRC instance. Mobility control may be performed per layer. By way of example, mobility may be performed per layer when a cluster of SCeNBs is utilized. Mobility control per layer may include each RRC instance being configurable independently of one another.

[0078] From a network perspective, a distributed control plane / entity may be characterized by multiple terminating RRC instances (e.g., a first terminating instance in a first network node such as an MeNB and a second terminating instance in a second network node such as an SCeNB), which may be augmented by control functions between the terminating nodes (e.g., between an MeNB and an SCeNB). Each RRC instance may implement a different set of functions (e.g., an MeNB may support connection establishment, RLM mobility control, NAS transport, etc., while an SCeNB may lack support for one or more of those functions). Some RRC functions (e.g., management of radio resources for the applicable serving cell, e.g., using RRC connection reconfiguration) may be supported by each of the RRC instances. Mobility control may be performed layer-by-layer, e.g., in the case of a deployment with a cluster of SCeNBs, in which case mobility control may be supported by one or more RRC instances. From a WTRU perspective, a distributed control plane / entity may be characterized by a single RRC entity. The WTRU may also implement one or more extensions specific to the control of aspects of the multi-scheduler. For example, one or more SRBs may be specific to a subset of configured serving cells / layers (e.g., SRB0, SRB1, and SRB2 may be specific to control serving cells / layers corresponding to MeNBs, while SRB3 may be specific to serving cells / layers corresponding to SCeNBs). Some functions may be specific to an SRB (e.g., radio resource reconfiguration and / or mobility management), which may be applied per layer.

[0079] 3 shows an example implementation of a converged control plane. For example, the converged control plane may include a single terminating RRC instance on the network side (e.g., at a Radio Cloud Network Controller (RCNC) 302), a single RRC instance at the WTRU 304, and the use of X2bis control. For example, the WTRU 304 may establish a single RRC connection to the network. The RRC connection may be controlled by a converged network controller, such as the RCNC 302.

[0080] Within the network, an aggregated network controller at which an RRC instance terminates may be a separate logical network node (e.g., the RCNC 302) and / or may be implemented within a RAN node (e.g., an eNB). For example, the aggregated network controller may be implemented in the MeNB 306 and / or the SCeNB 308. The RCNC 302 may communicate over an X2bis interface (e.g., and / or some other interface) to configure the SCeNB 308. For example, the RCNC 302 may configure one or more security parameters, evolved packet core (EPS) bearers, radio resource management (RRM) functions, etc. for the SCeNB 308 over the X2bis interface. The RCNC 302 may send configuration parameters for the SCeNB 308 (e.g., WTRU configuration information for one or more of PHY, MAC, RLC, PDCP, RRC, etc. for one or more serving cells of the SCeNB) over the X2bis interface. At the WTRU 304, a single RRC instance and a single RRC connection may be used to implement the aggregated control plane.

[0081] When utilizing an aggregated control plane, information associated with one or more SRBs may be exchanged via multiple layers / data paths. For example, some data associated with the SRBs may be exchanged via a layer / data path including the MeNB 306, and other data associated with the SRBs may be exchanged via a layer / data path including the SCeNB 308. As shown in FIG. 3, an RRC PDU corresponding to an SRB(x) may be exchanged over a data path corresponding to a radio bearer (and / or logical channel (LCH)) of the MeNB and / or a radio bearer (and / or LCH) of the SCeNB. The RRC PDU corresponding to an SRB(x) may be included in a transport block associated with a first MAC instance associated with the macro layer and / or a second MAC instance associated with the small cell layer. The aggregated control plane may be implemented regardless of how Layer 2 protocols are divided between the RCNC and the MeNB / SCeNB.

[0082] In an example, a consolidated control plane may be implemented in which each SRB is associated with a given data path / layer. For example, FIG. 4 shows an example implementation of a consolidated control plane in which an SRB is associated with a single data path / layer. As shown in FIG. 4, the WTRU 404 may be configured to communicate RRC PDUs associated with a first SRB (e.g., SRB(0, 1, 2, or x)) to the RCNC 402 via a first data path / layer associated with a radio bearer (and / or LCH) of the MeNB 406, and to communicate RRC PDUs associated with a second SRB (e.g., SRB(y)) to the RCNC 402 via a second data path / layer associated with a radio bearer (and / or LCH) of the SCeNB 408. The RRC PDUs may be mapped to transport blocks associated with the appropriate LCH (e.g., the LCH of the MAC instance associated with the SRB). Here, each SRB in the aggregated control plane is associated with a given data path / layer and can be implemented regardless of how the Layer 2 protocols are split between the RCNC and the MeNB / SCeNB.

[0083] As can be appreciated, examples may include implementations in which some SRBs, e.g., SRB0, SRB1, and SRB2, may be mapped to a single data path (e.g., the data path associated with the MeNB), while other SRBs may be mapped to both data paths. In another example, all SRBs may be transmitted over a single layer. For example, there may be no SRBs associated with the data path / layer for the SCeNB.

[0084] In an example, the RCNC may be co-located with and / or implemented by the MeNB. Figure 5 shows an example control plane protocol stack for SRBs exchanged over a data path including the MeNB when the RRC instance is terminated at the MeNB on the network side. If the RCNC is co-located with and / or implemented by the MeNB, one or more of SRB0, SRB1, SRB2, and / or SRB3 may be exchanged over a data path including the MeNB. For example, the WTRU may establish an RRC connection with the MeNB, e.g., according to procedures in LTE Release 11. The MeNB may receive WTRU capability information from the WTRU that has indicated that the WTRU supports multi-scheduler / multi-layer operation. The MeNB may configure the WTRU to perform measurements on frequencies corresponding to the small cell layer (e.g., in-band measurements, inter-band measurements, etc.). The MeNB may receive measurement reports from the WTRU and determine which serving cells of the SCeNB may be suitable for offloading traffic to / from the WTRU. The MeNB may establish a data path for the WTRU including the SCeNB. The MeNB may establish a connection to a selected SCeNB to provide the SCeNB with context information of the WTRU. For example, the MeNB may configure the SCeNB with parameters for setting up one or more EPS bearers, such as QoS / QCI information for the WTRU, security parameters for ciphering and / or authentication, and / or the like. The MeNB may receive a response message from the SCeNB, which may include access stratum configuration (AS configuration) information for one or more serving cells of the SCeNB.

[0085] The MeNB may send an RRC Connection Reconfiguration message to the WTRU, which may include one or more AS configuration parameters received from the SCeNB, to configure the WTRU for access to one or more applicable cells of the SCeNB. The MeNB may receive a response from the WTRU indicating that it has received the configuration and / or successfully connected to the SCeNB. The MeNB may receive a confirmation from the SCeNB indicating that the WTRU has successfully accessed one or more serving cells of the SCeNB. The WTRU may access the SCeNB using random access and / or may exchange one or more RRC messages over an SRB established for exchanging control data over a data path that includes the SCeNB (e.g., SRB3). In an example, SRB3 may be an SRB established and / or dedicated to controlling the radio link between the WTRU and the SCeNB (e.g., and / or a RAN node associated with the secondary data path).

[0086] 6 shows an example control plane protocol stack for SRBs exchanged over a data path including an SCeNB when an RRC instance is terminated at an MeNB on the network side. As shown in FIG. 6, one or more SRBs (e.g., SRB(x), which may be SRB3) may be exchanged over a path including the SCeNB. The protocol stack for such a control plane may include PHY, MAC, and / or RLC layers terminated at the SCeNB, and PDCP and / or RRC layers terminated at the MeNB.

[0087] To establish a dual layer connection, the WTRU may first establish an RRC connection with the MeNB, for example, according to the procedures of LTE Release 11. When establishing the RRC connection, the WTRU may indicate that it supports multi-scheduler / multi-layer operation, for example, as part of the WTRU's capability information. The WTRU may receive measurement configuration information from the MeNB. The measurement configuration information may include measurement information (e.g., in-band measurements, inter-band measurements, etc.) for frequencies corresponding to the small cell layer. The WTRU may report measurements according to configured trigger criteria. The WTRU may receive an RRC connection reconfiguration message from the MeNB, where the RRC connection reconfiguration information may include AS configuration parameters for accessing one or more serving cells of the SCeNB. The WTRU may reconfigure at least a portion of its radio for operation on the indicated carrier frequency of the SCeNB. The WTRU may attempt to perform an initial access procedure to the serving cell of the SCeNB (e.g., receiving system information broadcast from the SCeNB). The WTRU may send an RRC message (e.g., an RRC Connection Reconfiguration Request) indicating a request to establish an SRB3 (e.g., using the same security context as for other SRBs), which may be exchanged over a data path including the SCeNB. The WTRU may receive a response over the SRB3 and / or receive an RRC Connection Reconfiguration message exchanged over the SRB3 (e.g., over a data path including the SCeNB) that configures one or more cells corresponding to the SRB3 connection. The WTRU may perform the reconfiguration and send an RRC Connection Reconfiguration Complete Response message.

[0088] In an example, SRB0, SRB1, and / or SRB2 may terminate in the RCNC / MeNB and in the WTRU and may be exchanged via a data path including the MeNB. For example, SRB0, SRB1, and / or SRB2 may be associated with the control plane protocol stack configuration shown in FIG. 5. In an example, SRB3 (and / or other supplemental SRBs) may terminate in the RCNC / MeNB and in the WTRU and may be exchanged via a data path including the SCeNB. For example, SRB3 may be associated with the control plane protocol stack configuration shown in FIG. 6. SRB3 may be used for radio resource reconfiguration (e.g., release) and / or small cell layer mobility configuration.

[0089] The coordinated control plane may be characterized by multiple terminating RRC instances in the network, one or more SRB sets, and / or X2bis exchanges of control data. For example, a WTRU may establish multiple RRC connections to the network. The RRC connections may be configured in a hierarchical manner.

[0090] For example, from the network perspective, both the MeNB and the SCeNB may be associated with respective RRC entities. The MeNB may use the X2bis interface (and / or some other interface) to configure the SCeNB with various parameters associated with the WTRU (e.g., with security information, EPS bearer information, QoS information, RRM information, etc.). The MeNB may instruct the WTRU to establish a secondary RRC connection to the SCeNB's serving cell. The SCeNB may establish the secondary RRC connection with the WTRU and may send an RRC connection reconfiguration message to the WTRU. The RRC connection reconfiguration message may include AS configurations for applicable cells of the SCeNB (e.g., WTRU configuration information for one or more of PHY, MAC, RLC, PDCP, RRC, etc., for one or more serving cells of the SCeNB).

[0091] From the WTRU's perspective, once the WTRU establishes an RRC connection with the MeNB, the WTRU may receive control signaling from the network indicating that the WTRU can establish a secondary RRC connection to the SCeNB. Such control signaling may be received in a dedicated manner using the established RRC connection with the MeNB. In an example, a paging message broadcast in the SCeNB's cell may indicate to the WTRU that it can establish a secondary RRC connection to the SCeNB. The paging may be transmitted from a cluster (or group) of SCeNBs. Before attempting to receive a paging message indicating that the WTRU can perform multi-layer operation using the SCeNB's cell, the WTRU may receive dedicated RRC signaling from the MeNB that configures a secondary RRC instance in the WTRU to perform IDLE mode mobility procedures for one or more cells of a given frequency band (e.g., corresponding to the frequency band utilized by the SCeNB). The RRC connection establishment procedure for the secondary RRC instance may include an indication that the connection being established is for a secondary connection.

[0092] 7 shows an example control plane protocol stack for a coordinated control plane in which a first RRC instance is terminated at an MeNB and a second RRC instance is terminated at an SCeNB. As shown in FIG. 7, a data path for a first RRC connection (e.g., a connection with an MeNB) may include radio bearers (and / or LCHs) mapped to the MeNB. For example, SRB0, SRB1, and / or SRB2 may be established via the first RRC connection associated with a data path including the MeNB. A data path for a second RRC connection (e.g., a connection with an SCeNB) may include radio bearers (and / or LCHs) mapped to the SCeNB. For example, instances SRB0, SRB1, and / or SRB2 associated with a second RRC connection (e.g., shown as SC-SRB0,1,2 in FIG. 7) may be established via the second RRC connection associated with a data path including the SCeNB.

[0093] The primary connection (e.g., the connection established with the MeNB) may be augmented to include an additional SRB (e.g., shown as SRB(x) in FIG. 7), which may be a bearer used to control some aspects of the secondary RRC connection (e.g., the connection associated with the SCeNB). For example, the additional SRB may be used to trigger a connection establishment procedure and / or to trigger a release procedure over a secondary data path / layer. RRC PDUs corresponding to the supplemental bearers may be exchanged over the data path corresponding to the radio bearers (and / or LCH) of the MeNB.

[0094] A secondary connection (e.g., a connection established with the SCeNB) may be augmented to include an additional SRB (e.g., SRB(y), not shown in FIG. 7), which may be a bearer used to transmit data associated with the primary RRC connection (e.g., a connection associated with the MeNB). For example, the supplemental SRB(y) (and / or a similar implementation for multiplexing RRC PDUs) may terminate at the SCeNB and be an SRB used to redirect and / or forward RRC PDUs to the primary RRC instance at the MeNB. For example, data for SRB0, SRB1, or SRB2 of the primary RRC instance may be transmitted via SRB(y) to the SCeNB, which may forward the data to the MeNB, e.g., via an X2bis interface.

[0095] 8 shows an example control plane protocol stack for SRBs exchanged over a data path including the MeNB when an RRC instance is terminated at the MeNB on the network side. In an example of coordination control plane operation, the MeNB may establish a primary RRC connection with the WTRU, e.g., according to LTE Release 11 procedures. The MeNB may receive WTRU capability information from the WTRU indicating that the WTRU supports multi-scheduler / multi-layer operation. The MeNB may configure the WTRU to perform measurements (e.g., in-band measurements, inter-band measurements, etc.) for frequencies corresponding to the small cell layer. The MeNB may receive measurement reports from the WTRU and determine which serving cells of the SCeNB may be suitable for offloading traffic to / from the WTRU.

[0096] 9 shows an example control plane protocol stack for SRBs exchanged over a data path including the SCeNB when an RRC instance is terminated at the SCeNB on the network side. The WTRU and / or MeNB may trigger the WTRU to establish a secondary RRC connection, e.g., a secondary connection terminated at the SCeNB. As an example, the MeNB may instruct the WTRU to establish a secondary RRC connection with the SCeNB using the primary RRC connection. In an example, the MeNB may initiate connection establishment with the SCeNB before the WTRU establishes a secondary RRC connection with the SCeNB in ​​question. For example, the MeNB may establish a data path and control connection to a selected SCeNB to transfer the WTRU's context (e.g., via X2bis). The MeNB may configure the SCeNB with parameters for setting up one or more EPS bearers, such as QoS / QCI information for the WTRU, security parameters for ciphering and / or authentication, and / or the like. The MeNB may receive a response message from the SCeNB, which may include AS configuration information (e.g., system information parameters, handover command parameters similar to those of the RRC connection reconfiguration with mobility control information elements) for one or more serving cells of the SCeNB. The MeNB may send an RRC connection reconfiguration message to the WTRU, which may include the AS configuration information (e.g., mobility control information elements) received from the SCeNB for the configuration of the applicable cells of the SCeNB.

[0097] In an example, the WTRU may establish a secondary RRC connection to the SCeNB, which may then initiate establishment of a connection to the MeNB (e.g., after establishment of the secondary RRC connection). For example, after establishing the secondary RRC connection with the WTRU, the SCeNB may request establishment of a data path and control connection to an associated MeNB to receive the WTRU's context information from the MeNB. A request for the WTRU's context may be sent by the SCeNB while the secondary connection is established by the WTRU (e.g., after / based on receiving an RRC connection request sent from the WTRU). For example, the MeNB may configure the SCeNB with parameters for setting up one or more EPS bearers, such as QoS / QCI information for the WTRU. The MeNB and SCeNB may utilize different security configurations for the same WTRU. The MeNB may receive a response message from the SCeNB indicating that the WTRU's context information has been received and / or that the secondary RRC connection has been successfully established. The MeNB may receive a connection complete response from the WTRU and / or a confirmation from the SCeNB, which may indicate that the WTRU has established a secondary connection to the SCeNB.

[0098] In an example of operation using a coordinated control plane, the WTRU may establish an RRC connection with the MeNB (e.g., according to the procedures of LTE Release 11). When establishing the RRC connection, the WTRU may indicate that it supports multi-scheduler / multi-layer operation, e.g., as part of the WTRU's capability information. The WTRU may receive measurement configuration information from the MeNB. The measurement configuration information may include measurement information (e.g., in-band measurements, inter-band measurements, etc.) for frequencies corresponding to the small cell layer. The WTRU may report measurements according to configured trigger criteria. The WTRU may receive an RRC connection reconfiguration message from the MeNB, where the RRC connection reconfiguration information may include AS configuration parameters for accessing one or more serving cells of the SCeNB. The WTRU may reconfigure at least a portion of its radio for operation on the indicated carrier frequency for the SCeNB. The WTRU may attempt to perform an initial access procedure to the serving cell of the SCeNB (e.g., receiving system information broadcast from the SCeNB). The WTRU may establish an RRC connection with the SCeNB, e.g., according to the procedures of LTE Release 11. The WTRU may send an RRC reconfiguration complete response to one or more of the MeNB and / or SCeNB upon successful establishment of the secondary RRC connection.

[0099] When a coordinated control plane is utilized, one or more independent SRBs may terminate at each of the RAN nodes (e.g., MeNB and SCeNB). In a primary RRC connection, a first set of SRBs (e.g., including a first instance of SRB0, a first instance of SRB1, and / or a first instance of SRB2) may terminate at the MeNB. In a secondary RRC connection, a first set of SRBs (e.g., including a first instance of SRB0, a first instance of SRB1, and / or a first instance of SRB2) may terminate at the SCeNB.

[0100] A distributed control plane may be characterized by a single terminating RRC instance on the network side, a single set of SRB0, SRB1, and / or SRB2, X2bis control between nodes of different layers, and the use of an SRB (e.g., SRB3) to exchange control data between layers.

[0101] For example, when utilizing a distributed control plane, the WTRU may establish a single RRC connection to the network via the MeNB. Although the RRC connection is established with the MeNB (e.g., macro layer), some RRC functions related to management of radio resources of the serving cell corresponding to the SCeNB may be performed or implemented by the SCeNB. If the SCeNB is a member of a cluster of SCeNBs, the SCeNB may perform some mobility-related functions. For example, if the SCeNB implements one or more RRC and / or RRM functions (e.g., a subset of RRC and / or RRM functions) for the serving cell associated with the SCeNB, the RRC connection established between the WTRU and the network may include one or more SRBs (e.g., SRB3) utilized to control the data path between the SCeNB and the WTRU.

[0102] On the network side, the MeNB may have an RRC entity that may be the termination point of an RRC connection. For example, SRB0, SRB1, and SRB2 may terminate in the WTRU and in the MeNB. The MeNB may use an X2bis interface (or similar) to configure the SCeNB for communication with the WTRU (e.g., security information, EPS bearer setup information, QoS / QCI information, etc.). The MeNB may instruct the WTRU to access the SCeNB's serving cell. The SCeNB may establish one or more supplemental SRBs (e.g., SRB3) to, for example, perform RRM functions for a serving cell associated with the SCeNB. Such supplemental SRBs may be used to facilitate some mobility-related functions in the SCeNB. The supplemental SRB (e.g., SRB3) may terminate in the WTRU and in the SCeNB, for example, even when the RRC connection is terminated at the MeNB rather than the SCeNB. The supplemental SRBs may be used for control signaling to reconfigure one or more serving cells corresponding to the SCeNB (e.g., WTRU configuration information for one or more of PHY, MAC, RLC, PDCP, etc. for one or more serving cells of the SCeNB).

[0103] From the WTRU's perspective, once the WTRU establishes an RRC connection with the MeNB, the WTRU may receive control signaling from the network indicating that the WTRU can establish a secondary RRC connection to the SCeNB. Such control signaling may be received in a dedicated manner using the established RRC connection with the MeNB. In an example, a paging message broadcast in the SCeNB's cell may indicate to the WTRU that it can establish a secondary RRC connection to the SCeNB. The paging may be transmitted from a cluster (or group) of SCeNBs. Before attempting to receive a paging message indicating that the WTRU can perform multi-layer operation using the SCeNB's cell, the WTRU may receive dedicated signaling from the MeNB that configures the WTRU to monitor the paging channel of an appropriate cell in a given frequency band of the SCeNB. The WTRU may access the SCeNB's cell using a random access procedure. The random access may be dedicated to using RACH parameters (e.g., a dedicated RACH preamble) received in dedicated control signaling transmitted from the MeNB. The WTRU may receive RRC signaling, for example via SRB3, to reconfigure the serving cell corresponding to the SCeNB.

[0104] FIG. 10 shows an example control plane protocol stack for a distributed control plane in which an RRC instance is terminated at an MeNB. As shown in FIG. 10, RRC PDUs corresponding to transmissions for a given SRB of an RRC connection may be exchanged over a data path corresponding to a radio bearer (and / or LCH) of the MeNB and / or a radio bearer (and / or LCH) of the SCeNB. For example, RRC PDUs corresponding to transmissions for SRBs 0, 1, and 2 may be exchanged over a data path corresponding to a radio bearer (and / or LCH) of the MeNB. This may be represented as SRBs 0, 1, 2 in FIG. 10. RRC PDUs corresponding to transmissions for a supplemental SRB (e.g., SRB 3) may be exchanged over a data path corresponding to a radio bearer (and / or LCH) of the SCeNB. This may be represented as SRB(x) in FIG. 10. The SCeNB may forward control data associated with SRB 3 to the MeNB over the X2bis interface. Thus, in an example for a distributed control plane architecture, some RRC-related functionality may be implemented by the SCeNB (e.g., related to SRB3) even though the RRC connection and / or SRB is not terminated at the small cell layer. Such a subset of RRC functionality is illustrated by the SCeNB including the SC-RRC layer of the protocol stack of FIG. 10 (e.g., representing the limited RRC functionality implemented in the small cell).

[0105] In an example of network-side functionality for a distributed control plane, the MeNB may establish an RRC connection with the WTRU, for example, according to LTE R11 procedures. Such an example may be shown in FIG. 11. FIG. 11 illustrates an example of a control plane protocol stack with a distributed approach for MeNB RRC SRB0, SRB1, and SRB2. The MeNB may receive the WTRU's capability for support for multi-scheduler operation as part of the connection establishment procedure. The MeNB may configure the WTRU with measurements (e.g., intra-band or inter-band measurements) for frequencies corresponding to the small cell enhancement layers. The MeNB may receive measurement reports from the WTRU and determine which serving cells of the SCeNB may be suitable for offloading traffic to / from the WTRU. The MeNB may establish a data path and control connection to the SCeNB selected for the WTRU's context. The MeNB may configure the SCeNB with, for example, parameters for setting up one or more EPS bearers along with QoS / QCI information for the WTRU, and security parameters for ciphering and authentication. The MeNB may receive a response message from the SCeNB, which may include AS configuration for at least one serving cell of the SCeNB. The MeNB may send an RRC connection reconfiguration message to the WTRU, which may include configuration parameters received from the SCeNB for the configuration of the applicable cells of the SCeNB. The MeNB may receive a completion response from the WTRU or a confirmation from the SCeNB, which may indicate that the WTRU has accessed at least one serving cell of the SCeNB (e.g., successful random access and / or exchange of at least one RRC message over SRB3). The SRB3 may terminate at the SCeNB. For example, this may be shown in FIG. 12. FIG. 12 illustrates an example control plane protocol stack with a distributed approach for SRB3 of the SCeNB.

[0106] In an implementation, the WTRU may establish an RRC connection with the MeNB, for example, according to the procedures of LTE R11. For example, this may be shown in FIG. 11. The WTRU may include whether it supports multi-scheduler operation in its capabilities. The WTRU may receive a measurement configuration from the MeNB including measurements (e.g., intra-band or inter-band measurements) for frequencies corresponding to small cell enhancement layers. The WTRU may report the measurements according to the configured trigger criteria. The WTRU may receive an RRC connection reconfiguration message from the MeNB along with AS configuration parameters to access one or more serving cells of the SCeNB. The WTRU may reconfigure at least a portion of its radio for operation on the selected carrier frequency to perform initial access to the serving cell (e.g., receiving a system broadcast). The WTRU may include an initial RRC message, such as, but not limited to, a request to establish SRB3 terminating at the SCeNB. This may be done using the same security context as for other SRBs. For example, this may be shown in FIG. 12. The WTRU may receive a response on SRB3 and / or an RRC connection reconfiguration message on SRB3 that configures one or more cells corresponding to the SRB3 connection. The WTRU may perform the reconfiguration and send a completion response over SRB3 in response to the configuration request from the SCeNB. The WTRU may send a completion response over SRB1 or SRB2 to the MeNB in ​​response to a request to access the SCeNB.

[0107] SRB3 may terminate in the WTRU and in the SCeNB. Supplemental SRBs may be used once security is initiated. SRB3 may be used for RRM (e.g., configuration, reconfiguration) of the serving cell associated with the SCeNB and / or for mobility control in the small cell enhancement layer.

[0108] When multiple schedulers are utilized to transmit over multiple data paths, the mapping between DRB / SRB and the multiple data paths may vary depending on how the protocol stacks for transmitting the data are divided among different network nodes. For example, a first data path may be established from the WTRU to the network via the MeNB (e.g., macro layer), and additional data paths may be established from the WTRU to the network via one or more SCeNBs. One or more protocol stacks may be defined for the user plane and / or for the control plane to support multi-layer (e.g., multi-scheduler) transmission.

[0109] For example, the X2bis interface and / or some other interfaces between the MeNB and the SCeNB may be used to implement various protocol stack configurations that support multi-scheduler operation. For a given WTRU, a data path for the user plane and a data path for the control plane may be realized based at least in part on communications exchanged over the X2bis interface.

[0110] For example, multiple data paths for a given WTRU may be established such that the data paths are split within the network above the PDCP layer. Such an architecture may result in each of the MeNB and SCeNB including functionality corresponding to the PHY layer, MAC layer, RLC layer, and PDCP layer. The control plane may be implemented such that a PDCP entity associated with a given radio bearer (e.g., DRB and / or SRB) may be located in a network entity that transmits and / or receives control data. For example, a PDCP entity used to transmit control data via the SCeNB may be located in the SCeNB, and a PDCP entity used to transmit data via the MeNB may be located in the MeNB. In an example, user plane data and / or control plane data may be carried over radio bearers that may be mapped to a single data path (e.g., to a DRB / SRB with a single SAP). In another example, user plane data and / or control plane data may be carried over radio bearers that may be mapped to multiple data paths (e.g., to a DRB / SRB with multiple SAPs). Each PDCP entity (eg, a PDCP entity in the SCeNB, a PDCP entity in the MeNB) may include a security state machine for its respective data path.

[0111] In an example, multiple data paths split above the PDCP layer within a network may be implemented using one or more radio bearers associated with a single SAP in the network (e.g., MeNB or SCeNB). To support multi-scheduler operation, one or more DRBs and / or SRBs may be transferred between data paths (e.g., DRB / SRB mobility). For example, an SRB associated with an MeNB may be offloaded to an SCeNB. If a distributed control plane is utilized (e.g., there may be some RRC functions in both the MeNB and SCeNB), an SRB3 or some other SRB may be used to exchange mobility-related control information.

[0112] For example, if a given radio bearer is associated with a single SAP in the network, then in the user plane, an EPS radio access bearer (RAB) may be implemented using a single DRB SAP. For example, Figure 13 shows an example protocol stack that may be used for the user plane data paths (e.g., the WTRU-MeNB data path and the WTRU-SCeNB data path) when the data paths are split above the PDCP layer in the network.

[0113] In the control plane, NAS signaling and / or RRC signaling may be transmitted over a single SRB associated with a single SAP. Depending on whether a centralized, coordinated, and / or distributed control plane is utilized, the mapping of SRBs to data paths, SRB mobility, and / or protocol stack implementation for the control plane within the network may vary.

[0114] For example, a consolidated control plane may be implemented such that a single SRB SAP is utilized for NAS and / or RRC signaling. For example, RRC PDUs for SRB0, SRB1, and / or SRB2 may be generated by an RCNC entity that may be implemented in the MeNB. Additional extensions and / or additional information elements may be exchanged via the MeNB to manage the radio connection between the WTRU and the SCeNB (e.g., trigger secondary RRC connection establishment, mobility, and / or release). RRC PDUs for SRB0, SRB1, and / or SRB2 may be transmitted from the serving cell of the MeNB to the WTRU. In an example, RRC PDUs for SRB0, SRB1, and / or SRB2 may be exchanged via the RAN node with which the WTRU originally established an RRC connection (e.g., before initiating multi-scheduler / multi-layer operation). RRC PDUs corresponding to an SRB dedicated to the SCeNB (e.g., SRB3) may be exchanged in the serving cell of the SCeNB.

[0115] 14 shows an example protocol stack in which an SRB may be associated with a single SAP and data paths are split above the PDCP layer in a network using an aggregated control plane. For example, RRC PDUs for a given SRB may be transmitted over a single data path (e.g., SRB0, SRB1, and / or SRB2 on the data path associated with the MeNB and SRB3 on the data path associated with the SCeNB). Radio bearers for different data paths may be associated with different / separate PDCP entities. From the network perspective, the PDCP layer associated with the connection to the WTRU may be located in the MeNB and the SCeNB (e.g., not shown in FIG. 14), or may be located in the RCNC (e.g., as shown in FIG. 14). In an example, both the PDCP layer and the RLC layer on the network side may be located in the RCNC.

[0116] In an example, a coordinated control plane may be implemented such that a single SRB SAP is utilized for NAS and / or RRC signaling. For example, when an RRC connection uses a coordinated control plane, RRC PDUs for a given SRB (e.g., SRB0, SRB1, and / or SRB2) may be transmitted over a single data path, such as a data path associated with the MeNB. Other control data designed to trigger establishment, mobility, and / or release of a secondary RRC connection may also be exchanged via the single data path associated with the MeNB (e.g., via the serving cell of the MeNB). In an example, RRC PDUs for SRB0, SRB1, and / or SRB2 may be exchanged via the RAN node with which the WTRU originally established the RRC connection (e.g., before initiating multi-scheduler / multi-layer operation). For a coordinated control plane, RRC PDUs for SRB0, SRB1, and / or SRB2 may be generated by the SCeNB, and the SCeNB may exchange locally generated RRC PDUs via the SCeNB's serving cell. For example, for a given radio bearer, Figures 8 and 9 may show an example in which each corresponding radio bearer has a separate PDCP entity for each RRC instance that utilizes a coordinated control plane.

[0117] In an example, a distributed control plane may be implemented such that a single SRB SAP is utilized for NAS and / or RRC signaling. For example, when an RRC connection uses a distributed control plane, RRC PDUs for SRB0, SRB1, and / or SRB2 may be generated by an MeNB entity. Additional extensions and / or additional information elements may be exchanged via the MeNB to manage the radio connection between the WTRU and the SCeNB (e.g., trigger secondary RRC connection establishment, mobility, and / or release). RRC PDUs for SRB0, SRB1, and / or SRB2 may be transmitted from the serving cell of the MeNB to the WTRU. In an example, RRC PDUs for SRB0, SRB1, and / or SRB2 may be exchanged via the RAN node with which the WTRU originally established the RRC connection (e.g., before initiating multi-scheduler / multi-layer operation). RRC PDUs corresponding to an SRB dedicated to the SCeNB (e.g., SRB3) may be exchanged with the serving cell of the SCeNB. For example, the RRC PDU for SRB3 may be generated in the SCeNB and forwarded to the WTRU via the SCeNB's serving cell. Figure 10 may show an example where each corresponding radio bearer has a separate PDCP entity for each RRC instance utilizing a distributed control plane.

[0118] In an example, instead of or in addition to mapping a given radio bearer to a single SAP, a single RB may be mapped to multiple SAPs (e.g., through multiple logical channels). For example, in the user plane, an EPS RAB with multiple DRB SAPs may be used. Mapping a single EPS RAB through multiple E-UTRA DRBs may be implemented using various techniques, depending, for example, on whether the data is for the data plane or the control plane and / or whether a centralized, coordinated, or distributed control plane is utilized. For example, data for the user plane may be exchanged through one of multiple data paths. Data corresponding to a given EPS bearer may be mapped through one or more SAPs, where each SAP may correspond to a DRB and / or LCH of a different MAC instance. Figure 15 shows an example of a data path split above the PDCP layer for the user plane, in which multiple DRB SAPs are utilized. For example, IP packets for a given EPS bearer may be exchanged over either data path (e.g., a path associated with the MeNB or a path associated with the SCeNB).

[0119] When multiple radio bearer SAPs are utilized, in the control plane, NAS and / or RRC signaling may be transmitted through multiple SRB SAPs. For example, a single SRB may be mapped through multiple SAPs (e.g., through multiple logical channels). Data corresponding to a given SRB (e.g., one of the supplemental SRBs, such as SRB0, SRB1, SRB2, and / or SRB3) may be mapped through one or more SAPs, each of which may correspond to a different MAC instance and may be transmitted via a different RAN node (e.g., MeNB or SCeNB).

[0120] FIG. 16 shows an example protocol stack in which an SRB may be associated with multiple SAPs and data paths are split above the PDCP layer in the network using an aggregated control plane. For example, an RRC PDU for a given SRB may be transmitted over multiple data paths (e.g., a data path associated with the MeNB and / or a data path associated with the SCeNB). A given radio bearer may utilize the services of multiple PDCP entities (e.g., a PDCP entity in the SCeNB and a PDCP entity in the MeNB). From the network perspective, the PDCP layer associated with the connection to the WTRU may be located in the MeNB and in the SCeNB (e.g., as shown in FIG. 16), or may be located in the RCNC (e.g., not shown in FIG. 16). In an example, both the PDCP layer and the RLC layer on the network side may be located in the RCNC. From the network perspective, each SAP associated with a given radio bearer may correspond to a logical channel managed by a different scheduler. The WTRU may receive control data corresponding to a given SRB over different logical channels of different MAC instances.

[0121] In an example, a coordinated control plane may be implemented to enable a radio bearer (e.g., SRB) to use the services of multiple PDCP entities. For example, when an RRC connection uses a coordinated control plane, RRC PDUs for a given SRB (e.g., SRB0, SRB1, and / or SRB2) may be transmitted over multiple data paths. For example, multiplexing and / or demultiplexing of RRC PDUs associated with a given SRB of a first RRC entity and RRC PDUs associated with an SRB of a second RRC entity may be performed.

[0122] In an example, a distributed control plane may be implemented to allow a radio bearer (e.g., SRB) to use the services of multiple PDCP entities. For example, a radio bearer associated with an RRC entity in the MeNB may use the services of a PDCP entity located in the SCeNB. Figure 3 may show an example of a distributed control plane in which a given SRB may be mapped to multiple radio bearer SAPs.

[0123] In an example, rather than splitting the data path above the PDCP protocol stack in the network, the data path / layer utilized by the WTRU may be split above the RLC layer. Thus, the PDCP layer may be included in a single node in the network, and PDCP layer PDUs to be transmitted to the WTRU may be mapped to multiple RLC SAPs (e.g., over multiple logical channels). The PDCP layer may include the functionality of multiple PDCP entities. For example, a PDCP entity may be associated with a particular DRB and / or SRB allocated to the WTRU. Thus, if the WTRU is allocated multiple DRBs, there may be multiple PDCP entities (e.g., both in the WTRU and in the network) that process PDCP packets (e.g., SDUs and PDUs) corresponding to the DRBs / SRBs associated with a particular entity.

[0124] When multiple RLC instances are utilized in a network (e.g., a first RLC instance in the MeNB and a second RLC instance in the SCeNB), packets to / from a given PDCP entity may be mapped to one or more of the RLC instances at different transmission sites in various ways. For example, data associated with a given PDCP entity (e.g., user plane data associated with a given DRB) may be mapped such that the PDCP entity can forward associated PDCP PDUs through a single RLC SAP (e.g., using a direct mapping between the PDCP entity and the RLC entity in a given RLC instance). In another example, a PDCP entity (e.g., which may correspond to a given DRB) may be configured to forward associated PDCP PDUs using one or more of multiple RLC SAPs; e.g., data from the PDCP entity may be forwarded using a first RLC instance (e.g., in the MeNB) at some times and a second RLC instance (e.g., in the SCeNB) at other times. The PDCP entities used to transfer data within the network may or may not be co-located at the same node as the RLC entity used to transmit the data.

[0125] For example, in the user plane, a PDCP entity (e.g., in the network, in the WTRU, etc.) may be configured to transmit and / or receive data using multiple RLC SAPs. The use of multiple RLC SAPs may result in data for a given DRB being exchanged over multiple data paths, where the data paths branch below the PDCP layer in the network. A PDCP PDU corresponding to a given EPS bearer may be mapped over one or more RLC SAPs, where each SAP may correspond to an LCH of a different MAC instance. For example, Figures 17 and 18 show example protocol stacks that may be utilized to transport user plane data when the data paths are split below the PDCP layer in the network.

[0126] A PDCP entity may utilize multiple data paths (e.g., associated with different RLC instances located in different network entities) to forward control data (e.g., data for one or more SRBs). For example, data associated with a given PDCP entity (e.g., control plane data associated with a given SRB) may be mapped such that the PDCP entity can forward associated PDCP PDUs through a single RLC SAP (e.g., using a direct mapping between the PDCP entity and the RLC entity in a given RLC instance). In another example, a PDCP entity (e.g., which may correspond to a given SRB) may be configured to forward associated PDCP PDUs using one or more of multiple RLC SAPs, e.g., where data from the PDCP entity may be forwarded using a first RLC instance (e.g., in the MeNB) at some times and a second RLC instance (e.g., in the SCeNB) at other times. For example, a PDCP PDU associated with a given SRB (eg, SRB0, SRB1, SRB2, or one of the supplemental SRBs) may be mapped through one or more RLC SAPs.

[0127] FIG. 19 shows an example control plane protocol stack for a data path split over RLC, in which a PDCP PDU may be forwarded through multiple data paths. For example, as shown in FIG. 19, a PDCP PDU associated with SRB(x) may be forwarded via a data path associated with the MeNB (e.g., using an RLC entity located in the MeNB) and / or via a data path associated with the SCeNB (e.g., using an RLC entity located in the SCeNB). In an example, such a configuration may be utilized to implement a centralized control plane approach as described herein. The PDCP entity for a given SRB may be located in the MeNB. A first RLC entity utilized to transmit data for the PDCP entity may be co-located with the PDCP entity in the MeNB. A second RLC entity utilized to transmit data for the PDCP entity may be located in the SCeNB. FIG. 20 shows an example data path associated with the SCeNB when data splitting occurs below the PDCP layer (e.g., above the RLC layer).

[0128] In an example, a coordinated control plane may be implemented to enable a radio bearer (e.g., SRB) to use the services of multiple RLC entities. For example, when an RRC connection uses a coordinated control plane, RRC PDUs for a given SRB (e.g., SRB0, SRB1, and / or SRB2) may be transmitted over multiple data paths. For example, multiplexing and / or demultiplexing may be performed between RRC PDUs associated with a given SRB transferred via a first RLC entity and RRC PDUs associated with an SRB of a second RRC entity transferred via a second RLC entity.

[0129] In a distributed control plane, RRC PDUs associated with a PDCP entity located in the MeNB can utilize services provided by an RLC entity located in the SCeNB. For example, such an architecture can use methods similar to those described with respect to a distributed control plane when data splitting occurs above the PDCP layer (e.g., FIG. 16).

[0130] In an example, data path splitting may occur above the MAC layer (e.g., below the RLC layer). In such an architecture, the PDCP layer and the RLC layer in the network may be implemented in the same node in the network (e.g., in an MeNB). However, each data path may be associated with its own MAC instance, which is associated with one of multiple data paths. Figure 21 shows an example control plane protocol stack that may be utilized when data paths are split above the MAC layer. Figure 22 shows an example user plane protocol stack that may be utilized when data paths are split above the MAC layer.

[0131] To support a multi-scheduler architecture (e.g., transmission and / or reception via independently scheduled data paths transmitted via different serving sites), the Layer 2 structure in the uplink and / or downlink may be modified from the structure utilized for transmission / reception via a single data path. For example, at the WTRU, uplink data (e.g., RLC PDUs, MAC SDUs, etc.) from logical channels may be multiplexed into transport blocks delivered to one of the configured transport channels (e.g., UL-SCH) associated with the serving site or MAC instance. Figure 23 shows an exemplary Layer 2 structure for uplink multi-site operation (e.g., utilizing a separated UL). Data associated with a particular radio bearer (e.g., PDCP PDU) may be mapped to a single logical channel by an RLC instance. The mapping of data from a radio bearer to a single RLC instance may be referred to as a separated UL transmission scheme. When a separated UL transmission scheme is utilized, a given radio bearer may be mapped to a given logical channel associated with one of the MAC instances. Although data may be transmitted to the network over multiple transport channels (e.g., there may be a UL-SCH transport channel for each component carrier of a MAC instance), data mapped to a given logical channel may be transported to the network over the same MAC instance if a separate UL transmission scheme is utilized. As an example, a separate UL transmission scheme may be used for user plane data transfer when a single radio bearer SAP (e.g., a single RLC SAP) is utilized with a protocol stack that is split above the PDCP layer, although a separate UL transmission scheme may also be used in other architectures.

[0132] Data from a particular radio bearer (e.g., a PDCP PDU) may be mapped to more than one logical channel and / or to multiple sub-logical channels. Data from a radio bearer split among multiple logical channels may be processed by different RLC instances (e.g., where each RLC instance is associated with and / or located at a different transmitting / receiving site in the network). For example, multiple RLC instances may be configured to segment and / or retransmit data associated with a given radio bearer. Each RLC instance may be associated with a different logical channel or sub-logical channel for the radio bearer. Because separate RLC instances may be utilized to process data associated with a single radio bearer, such a scheme may be referred to as a split RLC UL transmission scheme. Figure 24 shows an example Layer 2 structure for uplink multi-site operation in which a split RLC transmission scheme is utilized. At the WTRU, data from a logical channel associated with a given RLC instance may be associated with a specific MAC instance. Although data may be transmitted to the network via multiple transport channels (e.g., there may be a UL-SCH transport channel for each component carrier of a MAC instance), data mapped to a given logical channel may be transported to the network via the same MAC instance. As an example, a split RLC UL transmission scheme may be used to transmit user plane data when multiple SAPs are utilized with a split protocol stack above the RLC layer, although a split RLC UL transmission scheme may also be used in other architectures.

[0133] In an example, at a WTRU, uplink data associated with a given logical channel may be multiplexed into transport blocks associated with transport channels for multiple serving sites. For example, uplink data from a particular logical channel may be allowed to be multiplexed into a transport block delivered to a transport channel associated with any of the serving sites (e.g., any transmitting / receiving point in the network). Figure 25 shows an example Layer 2 structure in which data for a given logical channel may be mapped to multiple transport channels, and the transport channels may be associated with different serving sites. The mapping of data from a logical channel to transport channels associated with different transmitting / receiving sites in the network may be referred to as a pooled UL transmission scheme. When a pooled UL transmission scheme is used, uplink data (e.g., RLC SDUs) from a given radio bearer may be delivered to one of multiple logical channels configured for the radio bearer. Multiple MAC instances and / or multiple corresponding logical channels may be configured for use by a bearer (e.g., as defined in the bearer configuration). As an example, a pooled UL transmission scheme may be used for user plane data transfer when any MAC PDU can be used to transport any RLC PDU. For example, the pooled UL transmission scheme may be applied to architectures where the transmission path is split above the MAC layer, but the pooled UL transmission scheme may also be utilized in other architectures.

[0134] On the network side, the MAC SDUs may be demultiplexed from the transport blocks decoded at the serving site associated with the UL-SCH used for transmission. The MAC SDUs may be processed by an RLC entity at the serving site and / or relayed to a second site (e.g., a primary serving site) for processing by an RLC entity at the second site. When a pooled UL is utilized, one or more serving sites may relay the data (e.g., MAC SDUs) to the serving site where the RLC entity configured to process data associated with the logical channel in question is located.

[0135] Figure 26 shows an example of a Layer 2 structure for downlink multi-site operation that may be used for a separated DL transmission scheme. On the network side, downlink data from logical channels may be multiplexed into transport blocks that are delivered to one of the configured transport channels (e.g., DL-SCH) associated with a serving site or MAC instance. On the WTRU side, downlink data associated with a given logical channel may be demultiplexed from the transport blocks received over one of a set of transport channels (e.g., DL-SCH) associated with a particular serving site or MAC instance. The mapping of data from a radio bearer to a single RLC instance may be referred to as a separated DL transmission scheme. When a separated DL transmission scheme is utilized, a given radio bearer may be mapped to a given logical channel associated with one of the MAC instances. Although data may be transmitted to the WTRU over multiple transport channels (e.g., there may be a DL-SCH transport channel for each component carrier of a MAC instance), data mapped to a given logical channel may be transported to the WTRU over the same MAC instance when a separated DL transmission scheme is utilized.

[0136] Figure 27 shows an example of a Layer 2 structure for downlink multi-site operation that may be used for a split RLC DL transmission scheme. Data from a particular radio bearer (e.g., a PDCP PDU) may be mapped to more than one logical channel and / or to multiple sub-logical channels. Data from a radio bearer split among multiple logical channels may be processed by different RLC instances (e.g., each RLC instance associated with and / or located at a different transmitting / receiving site in the network). For example, multiple RLC instances may be configured to segment and / or retransmit data associated with a given radio bearer. Each RLC instance may be associated with a different logical channel or sub-logical channel for the radio bearer. Because separate RLC instances may be utilized to process data associated with a single radio bearer, such a scheme may be referred to as a split RLC DL transmission scheme. In the network, data from a logical channel associated with a given RLC instance may be associated with a specific MAC instance. Although data may be transmitted to the WTRU via multiple transport channels (e.g., there may be a DL-SCH transport channel for each component carrier of a MAC instance), data mapped to a given logical channel may be transported to the WTRU via the same MAC instance.

[0137] In an example, in a network, downlink data associated with a given logical channel may be multiplexed into transport blocks associated with transport channels for multiple serving sites. For example, downlink data from a particular logical channel may be allowed to be multiplexed into a transport block delivered to a transport channel associated with any of the serving sites (e.g., any transmitting / receiving point in the network). Figure 28 shows an example Layer 2 structure in which downlink data for a given logical channel may be mapped to multiple transport channels, and the transport channels may be associated with different serving sites. The mapping of downlink data from a logical channel to transport channels associated with different transmitting / receiving sites in the network may be referred to as a pooled DL transmission scheme. When a pooled DL transmission scheme is used, downlink data (e.g., RLC SDUs) from a given radio bearer may be delivered to one of multiple logical channels configured for the radio bearer. Multiple MAC instances and / or multiple corresponding logical channels may be configured for use by a bearer (e.g., as defined in the bearer configuration). As an example, a pooled DL transmission scheme may be used for user plane data transfer where any MAC PDU may be used to transport any RLC PDU.

[0138] When one or more bidirectional logical channels (e.g., a dedicated control channel (DCCH) and / or a bidirectional dedicated traffic channel (DTCH)) are utilized, various combinations of uplink and downlink transmission schemes may be utilized. For example, for a given logical channel, a separated DL transmission scheme and a pooled UL transmission scheme may be used. In an example, the serving site associated with a logical channel in the DL may be different from the serving site associated with the logical channel in the UL. For example, for a given logical channel, a separated DL transmission scheme and a separated UL transmission scheme may be used. An RLC entity on the network side may be operating at a first serving site in the network, and the DL-SCH may be transmitted from the first serving site. However, although there may be no RLC entity at a second serving site, the UL MAC SDUs may still be transmitted to and decoded at the second serving site. The UL MAC SDUs transmitted to the second serving site may be relayed to the first site for processing by the RLC entity. If a first serving site includes an RLC entity (e.g., and / or the DL-SCH is transmitted from the first serving site), but the UL MAC SDU may still be transmitted to a second serving site (e.g., the second serving site lacks an RLC entity and forwards the UL MAC SDU to the second serving site after decoding), such a scheme may be referred to as a "decoupled UL / DL." In an example, a decoupled DL transmission scheme and a decoupled UL transmission scheme may be used for one or more bidirectional logical channels. For example, a serving site corresponding to a DL transmission site for a logical channel and a serving site corresponding to a UL reception point for the bidirectional logical channel may be the same serving site, and an RLC entity can operate at this serving site without relaying the MAC SDU to another serving site.

[0139] Higher layers (e.g., RRC) may be used to configure the uplink and / or downlink transmission scheme to be utilized for a given transmission site and / or for a given logical channel. For example, when a WTRU receives RRC signaling configuring a given logical channel, the RRC signaling may indicate whether a pooled transmission scheme (e.g., UL and / or DL) or a separated transmission scheme (e.g., UL and / or DL) should be used for the logical channel. For example, if a separated DL transmission scheme and / or a separated UL transmission scheme is utilized, the RRC signaling may indicate a mapping indicating to which of one or more serving sites the logical channel should be transmitted and / or from which of one or more serving sites the logical channel should be received. In an example, the mapping of logical channels to serving sites may be predetermined for one or more logical channels, and the WTRU may implicitly know which serving site a logical channel is associated with without receiving an explicit mapping. For example, a logical control channel (e.g., DCCH) may be mapped to a transport channel associated with a primary serving site, and a logical traffic channel (e.g., DTCH) may be mapped to a transport channel associated with a secondary serving site.

[0140] When a separated DL transmission scheme and / or a separated UL transmission scheme is utilized, RRC signaling may be used to configure the mapping between the logical channels and the associated serving sites. For example, the RRC signaling used to configure the logical channels for use by the WTRU may include an indication of the logical channel identity and the serving site identity (e.g., and / or MAC instance identity) so that the WTRU knows which serving site to use for the logical channel. In an example, rather than or in addition to using the serving site identity (e.g., and / or MAC instance identity), the RRC signaling used to configure the logical channels may specify the mapping by including the logical channel identity and the serving cell identity (e.g., where the serving cell is associated with one of the serving sites). Multiple logical channels may be configured together to be associated with a serving site. For example, a group of logical channels may be specified by the logical channel group identity and the serving site identity (and / or the serving cell identity). In an example, the WTRU may be able to implicitly determine which serving site a given logical channel is associated with based on the logical channel identity for that logical channel, e.g., some logical channel identities may be associated with a primary serving site and other logical channel identities may be associated with a secondary serving site.

[0141] In an example, a subset of logical channels from which data may be multiplexed into transport blocks of one or more transport channels associated with a particular serving site (e.g., and / or MAC instance) may be referred to as a "logical channel scheduling group" for the serving site or MAC instance. From the above Layer 2 structure, the UL (and / or DL) logical channel scheduling groups of different serving sites may be independent of each other (e.g., processing at higher layers does not overlap), for example, when a separated UL transmission scheme (e.g., and / or separated DL transmission scheme) is used. Similarly, when a split RLC UL transmission scheme (e.g., and / or split RLC DL transmission scheme) is utilized, the processing paths above Layer 2 may be independent of each other.

[0142] An example use case for a secondary serving site may be for offloading DL data transmissions. For example, a WTRU may initially connect to a primary serving site (which may correspond to an MeNB, for example) but receive a reconfiguration from the primary serving site that reconfigures one or more radio bearers (e.g., and / or logical channels) to be transmitted to and / or received from the secondary serving site. As an example, one or more downlink data channels may be reconfigured to be received via the secondary serving site. Such a scheme may eliminate the need for the primary serving site to transmit as much data to the WTRU, for example, during periods when the WTRU can be better served by one or more small cells. Because small cells may serve fewer WTRUs than WTRUs served in a macrocell, offloading DL data transmissions to small cells may save network resources while still maintaining a desired level of service to the WTRU. In an example, downlink data to be delivered to a WTRU may be received by an MeNB and forwarded or relayed to an SCeNB for delivery to the WTRU. Examples are described herein for processing downlink data when the downlink data is relayed by a primary serving site (e.g., an MeNB) to a secondary serving site (e.g., an SCeNB) for delivery to a WTRU.

[0143] How DL data to be delivered to the WTRU is processed by the network and / or the WTRU may depend on the location of the RLC entity associated with the DL data in the network. For example, the RLC entity processing downlink data for a radio bearer may be operating at a secondary serving site (e.g., at the SCeNB). If the RLC entity is located at the secondary serving site, the RLC entity in the network may generate an RLC PDU and its segments, whose size may be adapted to the transport block size applicable to the current radio conditions. The corresponding logical channel associated with the generated RLC PDU may be mapped to the DL-SCH from the secondary serving site, for example, using a separated DL transmission scheme.

[0144] For a bidirectional logical channel, if the RLC entity on the network side is located at the secondary serving site, the DL transmission associated with the bidirectional logical channel may be transmitted from the secondary serving site, and one or more options for transmitting UL data associated with the bidirectional logical channel may be used by the WTRU. For example, the UL data for the bidirectional logical channel may be mapped to the UL-SCH associated with the secondary serving site (e.g., a separated UL transmission scheme for the secondary serving site). When the UL data is transmitted by the WTRU to the secondary serving site, the same RLC entity on the network side can process both uplink and downlink data for the bidirectional logical channel. The PDCP entity used to process uplink and / or downlink data for the bidirectional logical channel may also operate at the secondary serving site.

[0145] In an example, UL data for a bidirectional logical channel may be mapped to a UL-SCH associated with a primary serving site (e.g., a separated UL transmission scheme for the primary serving site). In another example, UL data for a bidirectional logical channel may be mapped to a UL-SCH associated with either a primary serving site and / or a secondary serving site (e.g., a pooled UL transmission scheme).

[0146] For example, UL data for a bidirectional logical channel may be mapped to a UL-SCH associated with the primary serving site, e.g., when no UL transmission to the secondary serving site is performed by the WTRU. However, the RLC entity on the network side may still be located at the secondary serving site even when no UL transmission is performed to the secondary serving site. When UL data for a bidirectional logical channel is mapped to a UL-SCH associated with the primary serving site, RLC PDUs demultiplexed from uplink transport blocks decoded at the primary serving site may be relayed by the primary serving site to the secondary serving site for processing by the RLC entity at the secondary serving site.

[0147] In an example, RLC PDUs transmitted by a WTRU associated with a bidirectional logical channel whose DL data is transmitted via a secondary serving site may be demultiplexed from an uplink transport block that may be received by and decoded at the primary serving site. These RLC PDUs may be processed by an RLC receiving entity operating at the primary serving site. The RLC receiving entity at the primary serving site may provide control information (e.g., through a network interface such as X2bis) to an RLC entity handling the same logical channel at the secondary serving site. For example, an RLC entity at the primary serving site that receives RLC PDUs from the WTRU may send information regarding the identities / sequence numbers of successfully received and / or unreceived RLC PDUs to an RLC entity at the secondary serving site to enable the RLC entity at the secondary serving site to generate status reports and other control information and provide them to a peer RLC entity at the WTRU (e.g., via downlink transmission). In an example, RLC PDUs demultiplexed from an uplink transport block received at and decoded by a secondary serving site may be relayed to an RLC receiving entity at the primary serving site without processing by an RLC entity at the secondary serving site. RLC PDUs received in the UL by the secondary serving site may be forwarded to an RLC instance at the primary serving site for processing when a pooled transmission scheme is utilized.

[0148] In an example, a WTRU may transmit RLC control PDUs in the uplink to a secondary serving site, while RLC data PDUs may be transmitted to the primary serving site. For example, RLC control PDUs generated by an RLC entity in the WTRU may be multiplexed into transport blocks delivered on a transport channel associated with the secondary serving site, while RLC data PDUs may be multiplexed into transport blocks delivered on a transport channel associated with the primary serving site. In an example, a given bidirectional logical channel may be divided into two bidirectional sub-logical channels. A first sub-logical channel of the bidirectional logical channel may be associated with RLC data PDUs sent by the WTRU to a first serving site (e.g., the primary serving site) and RLC control PDUs received from the primary serving site. A second sub-logical channel of the bidirectional logical channel may be associated with RLC data PDUs received by the WTRU from a second serving site (e.g., the secondary serving site) and RLC control PDUs sent to the secondary serving site.

[0149] In an example, the RLC entity may be located at the primary serving site. For example, RLC PDUs to be transmitted in the downlink to the WTRU may be transferred from the RLC entity at the primary serving site to the secondary serving site using a network interface (e.g., X2bis). For example, a MAC entity at the secondary serving site may receive the RLC PDUs from the RLC entity at the primary serving site and transmit the RLC PDUs to the WTRU through one or more cells of the secondary serving site. The RLC entity located at the primary serving site may correspond to a single RLC entity configured to generate RLC PDUs associated with the primary and / or secondary serving site. In an example, because downlink data transmitted to the WTRU may be transmitted via the secondary serving site, the RLC entity located at the primary serving site is configured to provide any RLC PDUs to be delivered to the WTRU to the secondary serving site for transmission.

[0150] The primary serving site may generate RLC PDUs to be delivered via the secondary serving site, and an RLC entity located at the primary serving site may not be aware of the near-real-time channel conditions experienced at the secondary serving site at the time of generation of the RLC PDU, and some segmentation and / or other scheduling decisions may be performed at the secondary serving site after it receives the RLC PDU to be delivered to the WTRU from the primary serving site. For example, an RLC entity located at a node different from the node making scheduling decisions for delivering the RLC entity's data (e.g., the RLC entity is located at the primary serving site, but the MAC instance performing the scheduling is located at the secondary serving site) may generate one or more RLC PDUs that are not properly sized under the transport block size allocated by the MAC instance performing the scheduling. For example, an RLC PDU generated by an RLC instance at the primary serving site may not fit into the transport block size allocated by the MAC instance at the secondary serving site. In order to avoid delayed transmission of an RLC PDU until the scheduler allocates a transport block that can accommodate such an RLC PDU (which may be difficult under current channel conditions, for example), techniques may be defined to avoid situations in which transmission may be delayed and / or in which some segmentation and / or limited RLC functions may be performed at a secondary serving site even if the RLC entity is located at the primary serving site.

[0151] For example, to avoid generating relatively large RLC PDUs that may be delayed when they reach a MAC instance at a secondary serving site, an RLC entity at a primary serving site may be constrained from generating RLC PDUs larger than the maximum RLC PDU size. By establishing a maximum RLC PDU for RLC PDUs generated at an RLC entity located at a different serving site than the MAC instance used to transmit data to the WTRU, the probability that the RLC PDU will not fit into the transport block size set by the MAC instance at the secondary serving site may be minimized. The maximum RLC PDU size for RLC PDUs transmitted by a serving site that does not include the RLC entity that generated the RLC PDU may be smaller than the maximum RLC PDU size for RLC PDUs transmitted from a serving site that includes the RLC entity. In an example, an RLC PDU transmitted from a serving site that includes the RLC entity that generated the RLC PDU may not be constrained with respect to the maximum RLC PDU size.

[0152] In an example, a secondary serving site may not include a complete RLC entity, but an RLC segmentation function may be located at the secondary serving site, e.g., on a MAC instance associated with a secondary serving cell. For example, an RLC entity in the primary serving site may be configured to initially generate RLC PDUs to be transmitted from one or more of the primary and / or secondary serving sites. The RLC entity at the primary serving site may be configured to perform the segmentation function for RLC PDUs transmitted through cells belonging to the primary serving site. However, the RLC entity at the primary serving site may be configured to refrain from segmenting RLC PDUs it generates that are to be transmitted through cells belonging to the secondary serving site. The RLC segmentation function for RLC PDUs transmitted via the secondary serving site may be located at the secondary serving site, e.g., even if the remaining RLC functions for processing those RLC PDUs are located at the primary serving site in the network. The secondary serving site may receive RLC PDUs generated by the primary serving site and segment RLC PDUs to be transmitted through a MAC instance associated with the secondary serving site. The segmentation of the RLC PDUs at the secondary serving site may be transparent to the RLC entity located at the primary serving site.

[0153] An RLC status PDU (e.g., an RLC control PDU containing an RLC status report) may be transmitted to an RLC entity at the primary serving site. In an example, when an RLC entity at the primary serving site receives an RLC status PDU for a segmented RLC PDU at a secondary serving site, the RLC status PDU may be forwarded to and / or processed by the secondary serving site. In an example, when an RLC entity receives an RLC status PDU that negatively acknowledges a segmented RLC PDU at a secondary serving site, the RLC entity may retransmit the entire original RLC PDU as long as a segment of the original RLC PDU is negatively acknowledged, even if some of the segments are positively acknowledged. In this way, the RLC status report may be processed at the primary serving site without any knowledge of segmentation at the secondary serving site.

[0154] In an example, a MAC instance (e.g., a MAC instance at a secondary serving site) transmitting an RLC PDU may be configured to support RLC PDU segmentation. For example, the RLC PDU may be generated by an RLC entity at the primary serving site and forwarded to a MAC instance of a cell at the secondary serving site. When an RLC PDU is received, the MAC instance may determine whether to perform RLC PDU segmentation based on, for example, whether there is available space in a scheduled transport block. The MAC instance may perform RLC PDU segmentation and concatenation. Additional segmentation information may be added to the MAC header because the receiving MAC instance can reassemble the RLC PDU segments generated by the MAC instance. For example, the segmentation information may provide an indication of whether the MAC PDU, including the header, includes a MAC SDU corresponding to a complete RLC PDU, a MAC SDU corresponding to the first segment of the RLC PDU, a MAC SDU corresponding to a middle segment of the RLC PDU, and / or a MAC SDU corresponding to the last or final segment of the RLC PDU. The MAC header may include a sequence number for each MAC PDU. The WTRU may reorder the MAC PDUs and reassemble the MAC SDUs based on, for example, a sequence number and / or additional segmentation information that indicates whether the MAC SDU corresponds to the first, middle, or last segment of a given RLC PDU. In an example, the MAC SDUs may be provided with a sequence number, and the MAC header may indicate the segment number of the given MAC SDU.

[0155] Upon receiving the MAC PDUs from the MAC instance of the secondary serving site, a MAC instance at the receiving entity (e.g., a WTRU) may reassemble the segmented MAC SDUs and forward the unsegmented MAC SDUs to the RLC entity. For example, based on the sequence numbers of the received MAC PDUs, the WTRU may reorder and / or disassemble the received MAC PDUs. If the segmentation entity indicates that the segmentation of the MAC SDUs was performed by the MAC entity, the WTRU may reassemble the segments contained in multiple MAC PDUs into a MAC SDU.

[0156] Because the RLC entity and the MAC entity may not be co-located in a given network node (e.g., the RLC entity may be at the primary serving site and the MAC entity may be located at the secondary serving site), and the network interface between the primary and secondary serving sites may be associated with relatively large delays, buffering and / or flow control may be implemented between the secondary and primary serving sites to ensure continuity of transmission. For example, flow control may be performed to enable a scheduler located at the secondary MAC instance to appropriately schedule resources for transmission of RLC data PDUs forwarded from the primary serving site. For example, the MAC instance at the secondary serving site may request information related to the transmission of one or more RLC PDUs from the RLC entity at the primary serving site. By way of example, the MAC instance may request one or more of an indication of the number of bits of data that the MAC instance is scheduling for transmission to the WTRU, an indication of the length of time it will take for the requested number of bits to be transmitted to the WTRU, an indication of the length of time it will take for a certain buffer size to be transmitted to the WTRU, an indication of the amount of radio resources available for transmission to the WTRU, an indication of the average data rate supported for transmission to the WTRU, and / or a request for polling of the primary serving site to determine whether there may be data available to be transmitted to the WTRU.

[0157] The RLC entity at the primary serving site may be configured to provide information regarding the amount of data, the type of data, and / or the characteristics of the data to be transmitted to the WTRU to a scheduler at the secondary serving site (e.g., located in a MAC instance at the secondary serving site). For example, the primary serving site may send information related to data buffered for transmission for the WTRU to a MAC instance at the secondary serving site (e.g., using a network interface). The primary serving site may provide an overall buffer status report for DL ​​data to be transmitted to the WTRU (e.g., data to be transmitted via either the primary or secondary serving site) to the MAC instance at the secondary site. The primary serving site may provide a buffer status report for DL ​​data to be transmitted to the WTRU, which is transmitted / mapped to the secondary serving site, to the MAC instance at the secondary site. The primary serving site may send a request to the MAC instance at the secondary site indicating that data should be transmitted through the cell of the secondary serving site. For example, the request may indicate the overall number of buffers to be transmitted through the secondary serving site and / or the desired bit rate.

[0158] MAC instances at different serving sites may implement different rules for handling and processing data transmissions, e.g., rules for performing logical channel multiplexing, power control, and UL PUSCH transmissions may differ depending on the site to be used.

[0159] As an example, radio link monitoring (RLM) may be performed by a MAC instance associated with a primary serving site (e.g., in a WTRU), while a MAC instance associated with a secondary site (e.g., in a WTRU) may refrain from performing RLM unless specifically configured to do so by the network. In an example, detecting an RLF on a primary MAC instance may lead to re-establishment of an RRC connection, while detecting an RLF on a secondary MAC instance may not lead to re-establishment of an RRC connection. In an example, a MAC reset for a secondary MAC instance may not lead to a reset of another MAC instance (e.g., the primary MAC instance and / or another secondary MAC instance). A MAC reset for a secondary MAC instance may suspend DRBs associated only with the MAC instance being reset, while DRBs associated with the MAC instance being reset and also associated with another MAC instance may remain active because data may be transmitted via the other MAC instance during the reset procedure.

[0160] When using MAC instance-specific DRX (e.g., different MAC instances may apply different DRX configurations), the DRX state of the primary MAC may have precedence or priority over the DRX state of the secondary MAC. For example, if the WTRU is configured to refrain from performing uplink transmissions on two MAC instances simultaneously, a WTRU in a DRX active time on the primary MAC instance may imply that the WTRU should be in a DRX inactive state on the secondary MAC instance. In an example, when SR is triggered based on data becoming available for a given RB (e.g., DRB, SRB, etc.), the WTRU may perform an SR transmission using the MAC instance corresponding to the RB in question. In an example, when SR is triggered based on data becoming available for a given DRB, the WTRU may perform an SR transmission using the MAC instance corresponding to the DRB in question, but if SR is triggered based on data to be transmitted for an SRB, the SR procedure may be performed on the primary MAC instance (e.g., even when the SRB is associated with a secondary MAC instance such as SRB3).

[0161] In an example, MAC instances associated with each serving site may operate relatively independently of one another. For example, multiple MAC instances (or entities) may be defined, with each MAC instance using a transport channel associated with a single serving site. Each MAC instance may use an independent MAC configuration, e.g., an independent set of parameters, state variables, timers, HARQ entities, etc. Independent per-site MAC operations may apply to operations including one or more of: random access procedures, maintaining uplink time alignment (e.g., each MAC instance may maintain a unique active time, DRX-related timers, DRX-related parameters, TAT timers, etc.), Scell ​​activation / deactivation (e.g., each MAC instance may have a Pcell and / or one or more Scells), DL-SCH data transfer, UL-SCH data transfer (e.g., scheduling requests, buffer status reporting, power headroom reporting, logical channel prioritization, etc.), discontinuous reception (DRX) operations, MAC reconfiguration procedures, MAC reset procedures, semi-persistent scheduling, and / or the like.

[0162] As an example, a MAC instance at a given serving site may be configured to perform buffer status reporting (BSR). Different procedures for buffer status reporting may be applied based on the Layer 2 architecture / transmission scheme employed, for example, in the uplink.

[0163] By way of example, BSR reports may be performed independently by different MAC instances. For example, multiple BSR procedures may operate independently and / or simultaneously, where a given BSR procedure may correspond to a given serving site (e.g., and / or MAC instance). A BSR procedure associated with a given MAC instance may operate on / be associated with the logical channel scheduling group of the serving site / MAC instance. A BSR report generated as part of a BSR procedure associated with a given MAC instance may be included in a MAC control element included in a transport block for the transport channel associated with the serving site / MAC instance. A BSR report for a given MAC instance may be generated based on information related to the transmission / reception of the MAC instance in question (e.g., allocated UL resources, UR grant, transmission / reception of MAC PDUs, information considered in the decision applicable to generating a padding BSR, revocation of a triggered BSR, BSR value, etc.), but not based on information related to the transmission of other MAC instances. BSR parameters, such as the BSR retransmission timer (e.g., retxBSR-Timer) and / or the periodic BSR timer (e.g., periodicBSR-Timer), may have different values ​​depending on the serving site or MAC instance with which the BSR parameters are associated. Independent BSR reporting may be utilized for one or more UL transmission schemes / Layer 2 structures. For example, independent BSR reporting may be utilized when separate UL retransmission schemes / Layer 2 structures are used. In this way, different scheduling entities on the network side may be made aware of the buffer status with respect to the logical channel scheduling groups for their corresponding serving site / MAC instance.

[0164] In an example, a common BSR report may be performed across multiple MAC instances. For example, a single combined BSR procedure may operate across multiple serving sites and / or logical channels. The combined BSR procedure may provide each scheduler with information related to transmissions at the serving site associated with the scheduler and / or information related to transmissions at other serving sites utilized by the WTRU.

[0165] For example, whenever a BSR is triggered, a BSR may be transmitted for each serving site. A BSR for a given serving site may be transmitted over a transport channel associated with the serving site. A BSR for a serving site may include information generated based on uplink data to be transmitted to that serving site. If no data is available for transmission from the logical channel scheduling group associated with the serving site, a BSR may not be transmitted to one or more serving sites even if the BSR is triggered. A padding BSR may be transmitted for one or more serving sites, for example, if the number of padding bits in one of the transport blocks for that serving site is sufficient. The content of the BSR transmitted for the serving site may be determined based on data from the serving site's corresponding logical channel scheduling group. If data from a given logical channel is multiplexed onto transport blocks for more than one serving site, the BSR may reflect the state after MAC PDUs are generated for different serving sites (e.g., to prevent the WTRU from appearing to have more available data than actually to be transmitted by reporting data in multiple BSRs to multiple sites).

[0166] The data considered by the WTRU as available for transmission for purposes of generating a BSR may include one or more of RLC SDUs, RLC data PDUs, segments of RLC data PDUs, and / or RLC status PDUs associated with the logical channel scheduling group of the MAC instance for which a BSR is being generated. PDCP SDUs and / or PDCP PDUs may not be considered for BSR generation. By considering RLC SDUs, RLC data PDUs, and / or RLC status PDUs associated with the logical channel scheduling group of the MAC instance for which a BSR is being generated as available for transmission, BSR status reporting may be effectively implemented in a segmented RLC transmission scheme / Layer 2 structure.

[0167] In an example, data considered available for transmission for purposes of BSR generation may include some or all PDCP SDUs and / or PDCP PDUs, e.g., PDCP SDUs and / or PDCP PDUs that may be considered available per Release 11 procedures. When a portion of PDCP SDUs and / or PDCP PDUs is considered available, that portion may correspond to a ratio provided by a higher layer. That portion may correspond to the greater of a "resource utilization ratio" of a serving site (or MAC instance) and a minimum value. The "resource utilization ratio" may correspond to the ratio of UL resources allocated in a given period for transport channels associated with the corresponding serving site / MAC instance to the sum of all UL resources allocated in the same period for transport channels associated with all serving sites / MAC instances. In an example, PDCP SDUs and / or PDCP PDUs may be considered available for transmission in a BSR generation procedure if the PDCP SDUs and / or PDCP PDUs are associated with the particular serving site / MAC instance for which the transmission is being generated. PDCP SDUs and / or PDCP PDUs associated with other sites (e.g., sites not associated with the BSR being generated) may not be counted as available for transmission in the calculation of another serving site's BSR.

[0168] The data considered available for transmission may include a portion of the total amount of data considered available for transmission for logical channels in a given logical channel scheduling group. When a portion of PDCP SDUs and / or PDCP PDUs is considered available, the portion may correspond to a ratio provided by a higher layer. The portion may correspond to the greater of the "resource utilization ratio" of the serving site (or MAC instance) or a minimum value.

[0169] A WTRU may be configured with one or more sets of resources for transmitting a scheduling request (SR) to the network. In multi-layer operation, the WTRU may be allocated resources for performing SR on multiple layers (e.g., a first resource may be available in a primary layer and a second resource may be available in a secondary layer). An example of a resource that may be used to transmit an SR to the network may be a PRACH configuration for a random access scheduling request (RA-SR). Another example of a resource that may be used to transmit an SR may be a received physical uplink control channel (PUCCH) configuration received by the WTRU (e.g., via RRC signaling) that allocates dedicated physical uplink control channel (PUCCH) resources (e.g., dedicated SR (D-SR) resources) to a given WTRU for transmitting a scheduling request. The PUCCH configuration may define a periodic allocation of PUCCH physical resources that the WTRU may use to transmit an SR on a given layer. In an example, the WTRU may select resources to use to perform SR based on one or more characteristics of the data to be transmitted. For example, an example of a data characteristic that may be used to select an appropriate resource for transmitting an SR may include an identity of a bearer (e.g., DRB, SRB, etc.) associated with the data to be transmitted. Another example of a data characteristic that may be used to select an appropriate resource for transmitting an SR may include an association of a given bearer with a particular layer (e.g., primary layer, secondary layer, etc.).

[0170] As an example, a WTRU may be configured with a PRACH configuration for a PCell in the primary layer. The WTRU may also be configured with a PRACH configuration for a serving cell in the secondary layer. Furthermore, the WTRU may be configured with dedicated resources for transmitting SR on a PUCCH in one or more layers, for example, in a serving cell in the secondary layer. The WTRU may be configured with a first DRB and / or a first SRB, which may be associated with the primary layer. The WTRU may be configured with a second DRB and / or a second SRB, which may be associated with the secondary layer. When new data becomes available for transmission on one or more of the RBs configured for the WTRU and an SR is triggered, the WTRU may select resources to use to perform the SR procedure based on the layer associated with the RB that triggered the request. For example, if SR is triggered from data on the first SRB, the WTRU may perform RA-SR on the PCell in the primary layer. If SR is triggered from data associated with the second DRB, the WTRU may perform D-SR and / or RA-SR on the serving cell in the secondary layer.

[0171] In an example, the WTRU may be configured to perform an SR procedure on a PCell of the primary layer following a failure of the SR procedure on the secondary layer. For example, when transmitting an SR on the primary layer for an RB associated with the secondary layer, the WTRU may transmit an indication of data available for both RBs associated with the secondary layer (e.g., that triggered the SR) and any data available for transmission associated with the RBs mapped to the primary layer in the BSR. In an example, the WTRU may reassociate one or more RBs associated with the secondary layer to the primary layer based on the failure of the SR on the secondary layer.

[0172] In an example, how the WTRU handles an SR failure may be based on which layer included the SR resources used for the failed SR procedure (e.g., primary layer, secondary layer, etc.) and / or the type of SR resources used for the failed SR procedure (e.g., RA-SR, D-SR, etc.). For example, when the WTRU determines that the D-SR procedure failed using PUCCH resources of a cell in the secondary layer, the WTRU may be configured to initiate an RA-SR procedure in a cell in the secondary layer. For example, the cell used for RA-SR in the secondary layer may be the same cell as that used for the failed D-SR procedure, or may be a different cell in the secondary layer (e.g., the WTRU may first try the same cell and then a different cell in the secondary layer). If the WTRU determines that the RA-SR also fails in the secondary layer, the WTRU may then initiate an SR procedure on the PCell in the primary layer. The SR on the PCell in the primary layer may be performed according to the SR configuration for the WTRU on the PCell. For example, if the WTRU is configured with dedicated PUCCH resources for transmitting SR on the PCell, the D-SR procedure may be performed. If the WTRU is not configured with dedicated PUCCH resources for SR on the PCell, the WTRU may initiate an RA-SR procedure. If the SR procedure on the primary layer PCell fails, the WTRU may attempt to re-establish an RRC connection with the primary layer PCell. In another example, if any SR procedure (e.g., D-SR or RA-SR) fails on the secondary layer, the WTRU may attempt to perform an SR procedure on the primary layer PCell (e.g., rather than first attempting to perform a different type of SR procedure on the secondary layer).

[0173] In an example, a WTRU may be configured to perform an SR procedure (e.g., an RA-SR procedure) in a primary layer based on data that triggered an SR associated with an RB in a secondary layer. For example, the RA-SR procedure in the primary layer may be used for SR for data associated with an RB in the secondary layer. The WTRU may indicate in the RA-SR procedure that data is associated with an RB mapped to a secondary layer. In an example, the WTRU may initiate a mobility procedure based on a failure of SR in the secondary layer. For example, if an SR procedure fails in the secondary layer, the WTRU may be configured to perform a reassociation procedure (e.g., an RRC reconfiguration procedure) for one or more radio bearers that moves RBs associated with the layer in which the SR failed to a different layer (e.g., the primary layer). In an example, the WTRU may determine that a UL RLF occurred in a given layer when a RACH using a PRACH resource of the layer in question (e.g., due to an SR procedure) fails. For example, for a failure of SR corresponding to the secondary layer, the WTRU may initiate mobility-related procedures for bearers in a different layer (e.g., the primary layer).

[0174] The WTRU may utilize different procedures for maintaining timing alignment of different layers. For example, the timing alignment (TA) procedure utilized in a given cell (e.g., PCell) may be based on which layer the TA procedure is associated with. For example, the WTRU may perform various actions related to timing alignment in a first cell in a first layer (e.g., PCell of a primary layer) based on detecting one or more conditions associated with a second cell in a secondary layer (e.g., a cell in the secondary layer). For example, a failure of SR in the secondary layer may trigger one or more actions related to TA in the primary layer.

[0175] By way of example, the WTRU may consider a timing alignment timer (TAT) associated with a given layer (e.g., some or all applicable TATs, e.g., in the case where multiple TA groups are configured) to have expired upon detecting a D-SR failure and / or an RA-SR failure in that layer. For example, the WTRU may consider the TAT of a PCell of a secondary layer to have expired based on determining that an SR procedure failed using resources of the PCell of the secondary layer.

[0176] In an example, expiration of a TAT in a first cell of a first layer (e.g., or a trigger that causes the WTRU to consider the TAT as expired) may trigger an enhanced SR / BSR to be transmitted in another cell associated with a different layer. For example, when the WTRU determines that a TAT associated with one or more cells (e.g., PCells) of a secondary layer has expired and / or is considered expired (e.g., based on an SR failure), the WTRU may transmit a BSR to a cell of the primary layer (e.g., a PCell of the primary layer). For example, a BSR transmitted over the primary layer may include information regarding any data for RBs associated with the secondary layer to be transmitted in addition to any data associated with the RBs of the primary layer to be transmitted.

[0177] In an example, expiration of a TAT (e.g., or a trigger that causes the WTRU to consider the TAT as expired) may trigger mobility of the RB to another layer and / or discontinuation of the RB. For example, the WTRU may reassociate one or more RBs associated with a layer that includes a cell in which the TAT has expired (e.g., or the TAT has been deemed expired) with a different cell in a different layer (e.g., to the primary layer). In an example, association of the RB may be performed when all TATs applicable to the secondary layer have expired or are deemed expired. In such a case, if a TAT has expired in a first cell in the secondary layer but that TAT in a second cell has not yet expired, the WTRU may refrain from performing mobility of the RB to another layer until the TAT of the second cell has expired or is deemed expired. If the RB is reassociated with a different layer, once one or more TATs have started or are running in the secondary layer, the WTRU may reconfigure the transferred RB to be reassociated with the secondary layer. In an example, suspension of an RB may be performed by the WTRU when all TATs applicable to the secondary layer have expired or are deemed to have expired. In such a case, if a TAT has expired in a first cell of the secondary layer but the TAT of a second cell has not yet expired, the WTRU may refrain from suspending the RB. If the WTRU suspends an RB based on the expiration of all TATs associated with a given layer, the WTRU may consider the RB in question to be active if the WTRU determines that at least one TAT applicable to the secondary layer has started and / or is currently running.

[0178] In an example, expiration of a TAT (e.g., or a trigger that causes the WTRU to consider the TAT as expired) may trigger deactivation of a MAC instance / layer associated with the expired TAT. For example, if the WTRU determines that a TAT associated with one or more cells (e.g., PCells) of a secondary layer has expired or is considered expired, the WTRU may deactivate some or all cells of the MAC instance in question. In an example, expiration of a TAT (e.g., a trigger that causes the WTRU to consider the TAT as expired) may trigger the WTRU to suspend one or more layer-specific radio bearers. For example, if the WTRU determines that a TAT associated with one or more cells (e.g., PCells) of a secondary layer has expired or is considered expired, the WTRU may suspend one or more radio bearers associated with the layer in question. In an example, expiration of the TAT (e.g., or a trigger that causes the WTRU to consider the TAT as expired) may trigger the WTRU to perform a mobility procedure to transfer / reassociate one or more layer-specific bearers to a different layer. For example, if the WTRU determines that a TAT associated with one or more cells (e.g., PCells) of a secondary layer has expired or is considered expired, the WTRU may initiate a mobility procedure to reconfigure the radio bearers to be reassociated with a different layer (e.g., the primary layer).

[0179] In an example, expiration of the TAT (e.g., or a trigger that causes the WTRU to consider the TAT as expired) may trigger a switch of the active MAC instance / layer. For example, if the WTRU determines that a TAT associated with one or more cells (e.g., PCells) of the secondary layer has expired or is considered to have expired, the WTRU may initiate a procedure to activate one or more cells (e.g., PCells) of the primary MAC instance, e.g., if the primary MAC instance has been deactivated.

[0180] Dynamic radio resource management (RRM) control based on Layer 1 (e.g., PHY layer) and / or Layer 2 (e.g., MAC, RRC, etc.) may be performed to coordinate multi-layer RRM. For example, the control and allocation of physical layer resources for each layer can be complex and may depend on the type of control plane architecture employed (e.g., distributed control plane, coordinated control plane, aggregated control plane, etc.). For example, a WTRU may be configured with dual connectivity such that SRBs are terminated at a single layer (e.g., primary layer) and / or one or more layers may not have SRBs terminated at the serving site for the layer. In such cases, configuration information and other control data to support RRM may be determined for a layer (e.g., secondary layer / SCeNB layer) by one or more of the RCNC (e.g., which may be located in the MeNB), the serving site of another layer (e.g., the MeNB), and / or the serving site of the layer in question (e.g., SCeNB). The configuration information may be provided over one or more interfaces between layers (e.g., X2bis) to the appropriate network node where the SRB terminates. For example, the WTRU may be configured such that the SRB terminates at the MeNB, but control information for the SRB may be provided to another serving site (e.g., SCeNB).

[0181] However, in some situations, inter-layer communication / interface latency can be an issue for RRM. For example, RRM and / or reconfiguration at the secondary layer (e.g., associated with the SCeNB) can be complicated by the fact that the interface between the macro layer serving site (e.g., the MeNB) where the SRBs may be terminated and the secondary layer serving site (e.g., the SCeNB) can be associated with relatively high latency and / or can result in relatively large delays. Reducing the latency of MAC instance reconfiguration and layer PHY configuration while still providing scheduler flexibility (e.g., with respect to resource allocation) can be related to several scheduling functions, such as one or more of transmission time interval (TTI) bundling, PUCCH allocation for D-SR, CQI reporting, hybrid automatic repeat request (HARQ) feedback (e.g., including HARQ formats), sounding reference signal (SRS) resource allocation, configuration reference signals, etc. For example, parameters included in one or more IEs, such as sps-Config, mac-MainConfig (e.g., including ttiBundling, drx-Config, etc.), physicalConfigDedicated (e.g., including pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP, etc.), may be time-sensitive, and delays in signaling and / or configuring such parameters may be problematic.

[0182] As an example, synchronization of reconfiguration moments (e.g., the time at which a new configuration being applied should start) may be difficult to achieve in a multi-layer setting, e.g., when intra-network communications between serving sites are associated with high latency and the control plane (e.g., and / or a particular SRB) is terminated at one of the layers. For example, when a WTRU receives an RRC reconfiguration message that reconfigures one or more aspects of a connection at a secondary layer (e.g., associated with an SCeNB), timing and / or synchronization between a scheduler at the secondary layer and a MAC instance associated with the secondary layer at the WTRU may be difficult. For example, the WTRU may be configured to determine a fixed point in time from which the new configuration is assumed to be valid.

[0183] Timing and synchronization can also be an issue on the network side, for example, when the network is attempting to reallocate resources from one WTRU to another, as the network may need to determine the first possible instance when such resources may then be available for allocation to a given WTRU. For example, the network may attempt to determine when resources may be available at a given WTRU for purposes of deactivating TTI bundling, releasing PUCCH resources for D-SR, allocating CQI reporting instances, receiving HARQ feedback (e.g., including HARQ formats), determining when to apply a new DRX configuration, releasing SRS resources, modifying reference signals, and / or the like. For example, the network may attempt to determine when the WTRU can and / or will start applying one or more parameters included in IEs such as sps-Config, mac-MainConfig (e.g., including ttiBundling, drx-Config, etc.), physicalConfigDedicated (e.g., including pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP, etc.) The timing of activation and deactivation of semi-persistent scheduling (SPS) resources may be controlled using PHY layer control signaling (e.g., may be activated and deactivated via PDCCH commands).

[0184] For example, the WTRU and one or more serving sites may be configured to establish one or more pre-configurations for sets of parameters, an index may be assigned to each pre-configured set of parameters, and explicit control signaling and / or implicit rules may be utilized to switch the active configuration (e.g., activate and / or deactivate a given set of parameters). For example, the WTRU and / or serving sites of different layers may utilize localized, flexible, and / or dynamic management of physical layer resources for a given layer and / or scheduler (e.g., for the SCeNB) without having to introduce and / or utilize an RRC component with SRB termination at the layer for which the configuration is established (e.g., a secondary layer with the SCeNB serving site).

[0185] For example, rather than or in addition to relying on RRC signaling to configure static parameters for RRM (e.g., which may be used for a layer where one or more SRBs are terminated at an RRC component at the serving site), a scheduler for a given layer (e.g., in the SCeNB) may thereby pre-configure various RRM configurations (e.g., via RRC signaling or the like) and signal which pre-configured allocation to use (e.g., based on implicit rules, based on trigger events, via PHY or MAC signaling, etc.).

[0186] Various techniques may be used to configure multiple sets of RRM parameters. As used herein, the term RRM parameters may refer to one or more of parameters related to TTI bundling, D-SR, DRX, PUCCH allocation for SR, CQI reporting, HARQ feedback (e.g., including HARQ formats), SRS resource allocation, configuration reference signals, other PHY layer parameters, and / or the like. For example, RRM parameters may include one or more items of information that may be included in IEs such as sps-Config, mac-MainConfig (e.g., including ttiBundling, drx-Config, etc.), physicalConfigDedicated (e.g., including pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP, etc.). Additionally, various subsets of RRM parameters / configurations may be processed and / or treated independently / separately. For example, a set of SPS parameters may be pre-configured separately from a set of physical layer configuration parameters. Similarly, a set of DRX parameters may be treated separately from a set of CQI reporting parameters. Parameters related to one or more different control functions may be grouped into a pre-configuration group (e.g., DRX parameters may be grouped with TTI parameters, CQI reporting parameters may be grouped with D-SR configuration parameters, etc.). As used herein, the term RRM parameters may be used to refer to one or more parameters described above (or similar), singly or in various combinations. The term RRM configuration may refer to a group of one or more RRM parameters that may be grouped for pre-configuration and / or activated together.

[0187] For example, the WTRU may receive RRC signaling (e.g., an RRC connection reconfiguration message) configuring one or more sets of RRM parameters. The WTRU may receive a configuration with one or more indexed sets of parameters. For example, the WTRU may be pre-configured with one or more sets of physical layer configuration parameters (e.g., physicalConfigDedicated) and / or one or more sets of MAC configuration parameters (e.g., mac-MainConfig). For example, each configuration may be grouped as a separate item (e.g., defaultConfig and zero or more alternativeConfig). In an example, each received configuration may be associated with an index value, which may be assigned when the configuration is received and / or may be implicitly determined. For example, each configuration value may be provided in order with increasing index numbers (e.g., the first configuration in the message has index 0, the second configuration has index 1, etc.). One or more of the configurations may be default configurations. For example, a received reconfiguration message may explicitly indicate which received set of parameters (e.g., configuration) is considered to be the default configuration, and / or the initial configuration, and / or the configuration assigned index 0, and / or the initial configuration applied in the cell may be considered to be the default configuration. The received RRM configuration may be specific to a cell or may be common across multiple cells. The received RRM configuration may be specific to a layer or may be common across multiple layers. Upon receiving multiple sets of parameters (e.g., multiple sets of RRM configurations), the WTRU may complete the reconfiguration by applying the parameters corresponding to the default set.

[0188] As an example, a WTRU may receive a configuration with sets of parameters grouped as one or more virtual cells. For example, the WTRU may receive one or more sets of RRM parameters, e.g., one or more sets of physical layer configurations. The configurations may be received such that they correspond to virtual cells. Virtual cells may be associated with similar configurations as conventional cells, but the configurations may be dynamically activated and / or deactivated. For example, the WTRU may receive multiple virtual cell configurations (e.g., multiple sets of RRM parameters, each set corresponding to a different virtual cell) for a given sCellIndex, a given physCellId, a given dl-CarrierFreq, and / or the like. The received virtual cell configurations may correspond to multiple possible configurations that may be applied in a given cell. In an example, each virtual cell configuration and / or each set of RRM parameters may be assigned a virtualCellId for identification purposes. The identifier (e.g., virtualCellId) may be explicitly signaled and / or implicitly determined. For example, each virtual cell configuration may be provided in order with increasing identification numbers (e.g., the first configuration in the message has virtualCellId0, the second configuration has virtualCellId1, etc.). One or more of the virtual cell configurations may be default configurations. For example, the received reconfiguration message may explicitly indicate which received virtual cell configuration is considered to be the default configuration and / or the first configuration and / or the configuration assigned virtualCellId0, and / or the first virtual cell configuration applied in the cell may be considered to be the default configuration. The virtual cell configuration may be specific to a cell or common across multiple cells. The virtual cell configuration may be specific to a layer or common across multiple layers. Upon receiving the virtual cell configuration, the WTRU may complete the reconfiguration by applying parameters corresponding to the default virtual cell configuration.

[0189] Control signaling may be used to activate RRM configurations and / or virtual cell configurations, deactivate RRM configurations and / or virtual cell configurations, modify RRM configurations and / or virtual cell configurations, remove RRM configurations and / or virtual cell configurations, and / or the like. For example, the control signaling may be applicable to one or more cells in a layer (e.g., possibly a group or subset of cells in a layer), a particular type of cell in a layer (e.g., a PCell, SCell, etc.), a timing alignment group (TAG), etc.

[0190] For example, physical layer signaling may be used to activate an RRM configuration and / or virtual cell configuration, deactivate an RRM configuration and / or virtual cell configuration, change an RRM configuration and / or virtual cell configuration, remove an RRM configuration and / or virtual cell configuration, and / or the like. By way of example, physical layer signaling used for layer activation, PCell activation, SCell activation, etc. may include an indication of the appropriate RRM configuration and / or virtual cell configuration to be applied. In an example, separate physical layer signaling may be used to indicate which RRM configuration and / or virtual cell configuration should be applied in a cell, in a layer including the cell, in another cell in the layer including the cell, in another layer, in another cell in another layer, in a TAG, and / or the like.

[0191] For example, when configured with multiple RRM configurations and / or multiple virtual cell configurations for a given cell, a given group of cells, a given layer, etc., the WTRU may receive control signaling, e.g., on the PDCCH and / or enhanced PDCCH (ePDCCH), to activate the given RRM configuration and / or virtual cell configuration. For example, the WTRU may receive an index and / or virtualCellId corresponding to the given RRM configuration and / or virtual cell configuration in a downlink control information (DCI) field and / or via other physical layer signaling.

[0192] For example, a WTRU may receive a DCI that activates an RRM configuration and / or virtual cell configuration for one or more cells, and the WTRU may determine which RRM configuration and / or virtual cell configuration to apply based on one or more of: an explicit index and / or virtual cell identity indicated in the DCI; an identity of the search space in which the DCI was successfully decoded (e.g., each search space and / or portion of the search space may be implicitly mapped to a given index and / or virtual cell); a Radio Network Temporary Identifier (RNTI) used to decode the DCI (e.g., each RRM configuration and / or virtual cell configuration may be assigned an RNTI, and / or an implicit mapping may be assumed based on which RNTI is used); an identity of the first control channel element (CCE) associated with the DCI (or the last CCE, or some other CCE in the range used to decode the DCI) (e.g., the CCE may be implicitly mapped to the RRM configuration and / or virtual cell configuration); and / or the like.

[0193] The physical layer signaling may indicate the activation and / or deactivation of an RRM configuration and / or virtual cell configuration, for example, by including a corresponding index and / or virtual cell identification in the signaling format. If the WTRU is operating using a non-default RRM configuration and / or virtual cell configuration, the non-default RRM configuration and / or virtual cell configuration is deactivated and / or removed, and the WTRU may implicitly determine to use the default RRM configuration and / or virtual cell configuration for the layer in question (e.g., the configuration with index / virtualCellId0) unless a different RRM configuration and / or virtual cell configuration is explicitly indicated.

[0194] Feedback may be transmitted by the WTRU to confirm the reconfiguration. For example, the WTRU may transmit feedback to indicate successful completion of the reconfiguration and / or successful reception of physical layer signaling. For example, the WTRU may transmit a HARQ ACK / NACK for the received physical layer signaling used to activate and / or deactivate the RRM configuration and / or virtual cell configuration. For example, positive feedback (e.g., an ACK) may indicate successful reception of the physical layer signaling that changed the RRM configuration and / or virtual cell configuration. For example, the HARQ ACK / NACK feedback may be transmitted at a fixed time after successful reception of the control signaling. The ACK / NACK feedback may be transmitted using the RRM configuration and / or virtual cell configuration that was previously applicable at the time of reception of the physical layer signaling that changed the RRM configuration and / or virtual cell configuration (e.g., in subframe n) of the control signaling that changed the configuration. For example, if physical layer control signaling is received in subframe n, feedback may be transmitted in subframe n+4.

[0195] In an example, feedback for HARQ ACK / NACK for received physical layer signaling used to activate and / or deactivate an RRM configuration and / or virtual cell configuration may be transmitted using the RRM configuration and / or virtual cell configuration indicated in the physical layer control signaling. For example, ACK / NACK feedback may be transmitted using the new RRM configuration and / or virtual cell configuration in subframe n+(reconfigurationDelay). reconfigurationDelay may be configurable (e.g., may be indicated in the physical layer activation signaling and / or may be preconfigured by a set of RRM / virtual cell configurations) or may be equivalent to some fixed processing delay (e.g., 15 ms). In an example, the physical layer signaling used to activate and / or deactivate an RRM configuration and / or virtual cell configuration may indicate specific resources for transmission of ACK / NACK feedback. In an example, the WTRU may send first feedback indicating whether physical layer signaling used to activate and / or deactivate the RRM configuration and / or virtual cell configuration was successfully received (e.g., using methods described herein), and second feedback to indicate successful completion of the reconfiguration as indicated by the control signaling (e.g., using methods described herein). In an example, confirmation of successful reconfiguration to the new RRM configuration and / or virtual cell configuration may be performed by transmitting a random access preamble. For example, once the WTRU successfully applies the new RRM configuration and / or virtual cell configuration, the WTRU may initiate a RACH procedure. msg3 may include a MAC CE indicating the activated RRM configuration and / or virtual cell configuration.

[0196] Layer 2 signaling, such as MAC signaling, may be used to activate RRM configurations and / or virtual cell configurations, deactivate RRM configurations and / or virtual cell configurations, change RRM configurations and / or virtual cell configurations, remove RRM configurations and / or virtual cell configurations, and / or the like. For example, MAC signaling used for layer activation, PCell activation, SCell activation, etc. may also include an indication of the appropriate RRM configuration and / or virtual cell configuration to be applied.

[0197] For example, the WTRU may receive a MAC Control Element (CE) that activates a given RRM configuration and / or virtual cell configuration. For example, the WTRU may receive an index and / or virtualCellId corresponding to the given RRM configuration and / or virtual cell configuration in a field of the MAC CE. In an example, the MAC CE used to activate the given RRM configuration and / or virtual cell configuration may include a bitmap, where each bit of the bitmap may correspond to the given RRM configuration and / or virtual cell configuration. For example, the first bit of the bitmap may correspond to an index / virtual cell identity of 0, the second bit of the bitmap may correspond to an index / virtual cell identity of 1, and so on. A 1 may indicate that the corresponding RRM configuration and / or virtual cell configuration is activated, and a 0 may indicate that the corresponding RRM configuration and / or virtual cell configuration is deactivated (or vice versa).

[0198] In an example, a WTRU may receive a MAC activation / deactivation CE to activate and / or deactivate a layer, to activate and / or deactivate a cell in a layer, to activate and / or deactivate a group of cells in a layer, etc. The MAC activation / deactivation CE may include an explicit index and / or virtualCellId corresponding to a given RRM configuration and / or virtual cell configuration for the activated cell, group of cells, and / or layer. Bitmaps as described herein may also be used.

[0199] In an example, a WTRU may receive a MAC RRMConfig CE for a particular cell, group of cells, and / or layer. The MAC RRMConfig CE may include an explicit index and / or virtualCellId corresponding to a given RRM configuration and / or virtual cell configuration for the configured cell, group of cells, and / or layer. Bitmaps as described herein may also be used.

[0200] Regardless of the signaling method used, if the WTRU is operating using a non-default RRM configuration and / or virtual cell configuration, the non-default RRM configuration and / or virtual cell configuration may be deactivated and / or removed (e.g., via MAC signaling) and the WTRU may implicitly decide to use the default RRM configuration and / or virtual cell configuration for the cell / group of the cell / layer in question (e.g., the configuration with index / virtualCellId0) unless a different RRM configuration and / or virtual cell configuration is explicitly indicated.

[0201] Feedback may be sent by the WTRU to confirm the reconfiguration received via MAC signaling. For example, the WTRU may send feedback to indicate successful completion of the reconfiguration and / or that the MAC CE was successfully received. By way of example, the feedback may be included in the MAC CE and / or PUCCH (e.g., a fixed time after the transmission of the HARQ ACK for the transport block in which the L2 / MAC signaling was received). In an example, confirmation of successful reconfiguration for the new RRM configuration and / or virtual cell configuration may be performed by transmitting a random access preamble. For example, once the WTRU successfully applies the new RRM configuration and / or virtual cell configuration, the WTRU may initiate a RACH procedure. msg3 may include a MAC CE indicating the activated RRM configuration and / or virtual cell configuration.

[0202] Implicit rules may be used to activate RRM configurations and / or virtual cell configurations, deactivate RRM configurations and / or virtual cell configurations, change RRM configurations and / or virtual cell configurations, remove RRM configurations and / or virtual cell configurations, and / or the like. For example, when pre-configured with multiple RRM configurations and / or virtual cell configurations for a given cell, group of cells, layer, etc., the WTRU may determine events or triggers that may activate and / or deactivate RRM configurations and / or virtual cell configurations.

[0203] For example, the WTRU may receive control signaling (e.g., CE for MAC activation / deactivation) that activates a cell, group of cells, layer, etc. that is pre-configured for use by the WTRU. The WTRU may implicitly determine that a default RRM configuration and / or virtual cell configuration for the cell, group of cells, layer, etc. in question should apply, in the absence of explicit signaling to the contrary.

[0204] The WTRU may be configured to maintain a validity timer for an active RRM configuration and / or virtual cell configuration (e.g., for a non-default RRM configuration and / or virtual cell configuration). For example, the WTRU may start a validity timer for a given RRM configuration and / or virtual cell configuration upon receiving activation of the RRM configuration and / or virtual cell configuration and / or upon receiving explicit control signaling activating the RRM configuration and / or virtual cell configuration. The WTRU may deactivate an RRM configuration and / or virtual cell configuration for a given cell, group of cells, layer, etc. upon expiration of the validity timer for such RRM configuration and / or virtual cell configuration. In an example, there may be no validity timer for a default configuration. The validity timer may be restarted upon receiving signaling reactivating the RRM configuration and / or virtual cell configuration.

[0205] In an example, expiration of a TAT for a cell, a group of cells, a layer, etc. may deactivate and / or remove an RRM configuration and / or virtual cell configuration. For example, a WTRU may be configured to deactivate an RRM configuration and / or virtual cell configuration for a given cell, a group of cells, a layer, etc. upon expiration of the applicable TAT. In an example, expiration of a TAT may cause the WTRU to deactivate a non-default RRM configuration and / or virtual cell configuration, but may not cause the default RRM configuration and / or virtual cell configuration to be deactivated.

[0206] The WTRU may deactivate the RRM configuration and / or virtual cell configuration for a given cell, group of cells, layer, etc. upon detecting a radio link failure condition for the cell, group of cells, layer, etc. In an example, detection of a radio link failure may cause the WTRU to deactivate a non-default RRM configuration and / or virtual cell configuration, but may not deactivate a default RRM configuration and / or virtual cell configuration.

[0207] Upon determining that the problematic cell, group of cells, layer, etc. is in DRX (e.g., long DRX) and that z DRX periods have elapsed, the WTRU may deactivate the RRM configuration and / or virtual cell configuration for the given cell, group of cells, layer, etc., where x may be an aspect of the configuration. In an example, determining that the problematic cell, group of cells, layer, etc. is in DRX (e.g., long DRX) and that z DRX periods have elapsed may cause the WTRU to deactivate a non-default RRM configuration and / or virtual cell configuration, but not the default RRM configuration and / or virtual cell configuration.

[0208] The WTRU may deactivate the RRM configuration and / or virtual cell configuration for a given cell, group of cells, layer, etc. when it deactivates (e.g., implicitly and / or explicitly) a problematic cell, group of cells, layer, etc. (e.g., when it deactivates the problematic cell or layer). In an example, deactivation of a problematic cell, group of cells, layer, etc. may cause the WTRU to deactivate a non-default RRM configuration and / or virtual cell configuration, but may not cause the default RRM configuration and / or virtual cell configuration.

[0209] The WTRU may revert to the default RRM configuration and / or virtual cell configuration upon implicitly and / or explicitly deactivating the non-default RRM configuration and / or virtual cell configuration (e.g., unless some other RRM configuration and / or virtual cell configuration is explicitly indicated). The UE may use control signaling (e.g., RRC messages, MAC CE indicating an active configuration) to indicate that the WTRU lacks a valid configuration and / or indicates that a different configuration is currently being used (e.g., the default configuration).

[0210] The timing of completion of reconfiguration to different RRM configurations and / or virtual cell configurations may be specified. For example, the WTRU may attempt to complete the reconfiguration within x subframes. The value x may be fixed (e.g., 15 ms processing time) and / or may be configured as part of the RRM configuration and / or virtual cell configuration. In an example, a delay may be determined starting from subframe n at which applicable control signaling (e.g., L1 / L2 signaling) activating the RRM configuration and / or virtual cell configuration is received. In an example, a delay may be determined starting from the time feedback for the applicable control signaling (e.g., L1 / L2 signaling) is transmitted. In an example, a delay may be determined starting from the time a confirmation of successful reconfiguration is transmitted.

[0211] In some cases, during the period [n, n+x], the WTRU may not receive the PDCCH and / or ePDCCH. In an example, the WTRU may start using the new RRM configuration and / or virtual cell configuration as soon as it is able to reconfigure its transceiver, may start receiving the PDCCH and / or ePDCCH, and / or may perform uplink transmissions using the configuration applicable at the moment of reception of the control signaling in question. In an example, the WTRU may be allowed to start using the new RRM configuration and / or virtual cell configuration after transmission of an acknowledgment of reception of the control signaling (e.g., in subframe n+4).

[0212] In an example, one or more of the methods described herein may be combined to provide flexible RRM control by a scheduler in a node without SRB termination. For example, a WTRU may receive an RRC connection reconfiguration message. The RRC connection reconfiguration message may be associated with / transmitted via an SRB terminated at an RRC entity in the MeNB. The RRC connection reconfiguration message may add, modify, remove, etc., one or more cells associated with the secondary layer (e.g., a serving site for the secondary layer may be an SCeNB). The reconfiguration message may include multiple RRM configurations and / or virtual cell configurations for one or more cells being added and / or modified in the secondary layer (e.g., and possibly for removed cells). The various RRM configurations and / or virtual cell configurations may be indexed, and / or one or more RRM parameters within the RRM configurations and / or virtual cell configurations may be indexed. One of the RRM configurations and / or virtual cell configurations may be considered the default configuration, and / or one or more RRM parameters in the RRM configuration and / or virtual cell configuration may be considered the default parameter value. The first configured RRM configuration and / or virtual cell configuration may be considered the default configuration, and / or the first configured RRM parameter may be considered the default parameter. The default RRM configuration and / or virtual cell configuration and / or default RRM parameters may be explicitly indicated, for example, by associating them with index 0 and / or by listing them first. A virtual cell is used to group aspects of configurations. For example, multiple serving cell configurations may be provided for a given carrier frequency.

[0213] The WTRU may receive Layer 1 (e.g., PHY) and / or Layer 2 (e.g., MAC) signaling (e.g., DCI on the PDCCH, MAC CE, etc.) that may indicate one or more RRM configurations and / or virtual cell configurations to apply and / or an index for one or more RRM parameters to apply. The WTRU may acknowledge receipt in subframe n of such control signaling (e.g., possibly including an indication of the configuration index in the feedback) by transmitting a HARQ ACK on the PUCCH according to the current RRM configuration and / or virtual cell configuration (e.g., in subframe n+4). Reception of such control signaling (e.g., with the configuration index) by the WTRU may activate the corresponding RRM configuration and / or virtual cell configuration (e.g., and / or its RRM parameters). The WTRU may resume decoding the PDCCH and / or ePDCCH after a given time (e.g., fixed and / or signaled) from receipt of the problematic signaling (e.g., at subframe n+4, subframe n+15, etc.) In an example, activation / deactivation of virtual cells may be used as a method of grouping.

[0214] From the network perspective, the SCeNB may provide the MeNB with some configuration values ​​for one or more RRM configurations and / or virtual cell configurations. The SCeNB may indicate an indexing method to be used. For example, such configurations may be transferred over an interface (e.g., a modified X2 such as X2bis) between the SCeNB and the MeNB. The SCeNB may prepare an RRC connection reconfiguration message with the RRM configurations and / or virtual cell configurations and send the RRC connection reconfiguration message to the MeNB to be forwarded to the WTRU. A scheduler in a MAC instance associated with the secondary layer can then dynamically switch configuration values ​​for one or more RRM aspects using L1 signaling and / or L2 signaling.

[0215] When a WTRU is configured to operate utilizing multiple layers or serving sites associated with different schedulers, a radio bearer may be exclusively associated with a single MAC instance and / or multiple MAC instances. One or more serving cells associated with a given layer / MAC instance may fail due to, for example, poor radio link conditions, reconfiguration failure, mobility failure, radio link failure, and / or other reasons. In addition, a WTRU configured with one or more serving cells associated with a given layer / MAC instance may be handed over to a different set of serving cells that may be associated with different network entities (e.g., logical entities such as cells or physical entities such as eNBs). Methods are described for addressing radio link loss across one or more serving sites / MAC instances and / or for addressing mobility in a serving site-specific manner (e.g., applied to the set of serving cells associated with a particular layer / MAC instance). Methods and systems for efficient management of MAC instances are disclosed to ensure service continuity during mobility events. For example, methods and systems are described for performing a mobility event when one or more radio bearers (eg, SRBs and / or DRBs) are associated with the layer / MAC on which the mobility event is being performed.

[0216] As an example, a WTRU may establish a connection to a first eNB. For example, the first eNB may be an MeNB. The connection to the first eNB may be considered a primary layer, and / or the first eNB may be considered a first serving site and / or a primary serving site. As part of an exchange of WTRU capabilities during an initial RRC connection procedure with the first serving site, the WTRU may provide a first set of WTRU capabilities for establishing a connection to the first serving site, e.g., according to a Release 11 connection procedure. Additionally, as part of the initial connection procedure to the first site, the WTRU may provide a second set of WTRU capabilities, which may be associated with connection information supported by the WTRU for establishing a connection to a second layer or serving site. The MeNB and another eNB (e.g., an SCeNB) may subsequently coordinate to configure the WTRU to access multiple serving sites according to their respective capabilities, e.g., using multiple MAC instances.

[0217] In an example, when establishing a connection to a first eNB (e.g., an MeNB associated with the primary layer / first serving site), the WTRU may include an indication of whether the WTRU supports dual connectivity, e.g., as part of the WTRU's capability information. If the WTRU indicates that dual connectivity is supported, the WTRU may include the associated WTRU's capabilities for accessing the secondary serving site when establishing a connection with the first serving site. Upon successfully connecting to the first serving site, the WTRU may provide the SCeNB with a second set of its capabilities, e.g., when initially establishing a connection to the SCeNB. The MeNB and SCeNB may subsequently configure a connection for the WTRU to each of the serving sites using their respective parameters in accordance with the capability information provided by the WTRU.

[0218] After establishing a connection (e.g., an RRC connection) to a primary serving site, for example, using Release 11 procedures, initial configuration of the secondary layer may be in various manners. For example, a WTRU connected to a first eNB (e.g., an MeNB, primary layer, first serving site, connection via a first MAC instance, etc.) may be configured to operate with one or more cells from a second eNB (e.g., an SCeNB, secondary layer, second serving site, connection via a second MAC instance, etc.). For example, the WTRU may receive control plane signaling (e.g., RRC signaling) such that a second set of cells may be configured to form the secondary layer for configuration of the WTRU. Configuration of the secondary layer may be performed using RRC signaling received using dedicated resources and / or dedicated RRC messages.

[0219] As an example, initial configuration of a connection for a secondary serving site may be performed using a reconfiguration procedure. The WTRU may perform the reconfiguration procedure with a primary layer, which may be used to establish a connection to the secondary serving site. Thus, signaling from the primary serving site may be used to configure the WTRU to operate using the secondary layer. The signaling to configure the secondary layer may be received, for example, over resources of the primary layer if an RRC connection associated with the primary layer is used to configure the secondary layer. An RRC connection reconfiguration procedure may be used. For example, the WTRU may perform an RRC connection reconfiguration procedure with the primary serving site that configures the WTRU to operate using the secondary serving site.

[0220] The initial configuration of the secondary serving cell may be a type of mobility event. For example, after establishing an RRC connection with the primary serving site, resources associated with the primary serving site may be used to perform a mobility procedure. During the mobility procedure, the WTRU may maintain its configuration, connection, and / or operation state for the primary serving site, but may add one or more serving cells of a secondary layer to its configuration. For example, an RRC connection reconfiguration procedure may be performed, during which a mobility control information element is sent to the WTRU (e.g., a handover command may be sent to the WTRU). Rather than the WTRU interpreting the handover command to mean that the WTRU should perform a handover from the primary serving site cell to some other cell, the handover command may configure one or more cells of the secondary serving site to be used in addition to the primary serving site cell. The handover command may include an indication that the handover command is not for triggering a handover of the WTRU from the primary serving site cell, but is for establishing a dual connection. The mobility-related signaling received on the primary layer resources may configure a primary cell (PCell) in the secondary layer at the target eNB (e.g., SCeNB). After establishing a connection with the secondary layer PCell, the WTRU may receive an RRC connection reconfiguration message from the target eNB (e.g., SCeNB) that adds an additional serving cell, such as an SCell associated with a secondary serving site.

[0221] The initial configuration of the secondary layer / serving site (e.g., as a reconfiguration of the primary serving site and / or a mobility event at the primary serving site) may include a reallocation of radio bearers. For example, when a connection reconfiguration procedure and / or a mobility procedure is performed by the primary serving site to establish a connection to the secondary serving site, one or more existing radio bearers (e.g., radio bearers previously associated with the primary serving site's transmissions) may be transferred to the secondary layer / serving site. The radio bearers may be transferred exclusively to the secondary serving site and / or may be transferred such that they are associated with both the primary and secondary serving sites.

[0222] Addition of the secondary layer may be performed once security is activated for the primary layer. For example, to add a PCell of a secondary serving site, the WTRU may wait until a security context associated with the WTRU connection to the primary serving site is activated. For example, configuration of the secondary serving site may be performed once access stratum (AS) security is activated and / or an SRB2 with at least one DRB is established / set up (e.g., and not interrupted) for a connection associated with the first eNB (e.g., primary layer).

[0223] In an example, a common security context may be utilized across multiple serving sites, and the bearer identity may be WTRU-specific. If the secondary layer implements a common security context with the primary layer or that of some other active serving site (e.g., for one or more of the control plane and / or user plane), configuration of the secondary layer may be performed using a common identity space for the bearer identity (e.g., srb-Identity and / or drb-Identity). For example, if one or more serving sites utilize the same bearer identity, a transmission scheme may be established such that none of the utilized bearer identities are used in multiple layers / serving sites with different PDCP entities. By doing so, the WTRU may avoid a situation in which different PDCP PDUs are transmitted using the same security key and the same sequence number (e.g., such a situation may lead to processing / identification difficulties at the PDCP layer in the WTRU).

[0224] In an example, separate security contexts may be utilized for different serving sites, and bearer identities may be layer-specific. For example, if separate security contexts matching the layers are utilized, a reconfiguration procedure (e.g., used to initially configure the secondary layer) may be performed while security is not active in the secondary layer. If the secondary layer implements separate security contexts (e.g., for one or more of the control plane and / or user plane), configuration of the secondary layer may be performed either when security has not yet started / activated (e.g., for the initial configuration of the secondary layer) and / or when it has failed (e.g., for a reconfiguration that moves one or more RBs to another layer). A layer-specific security mode command may be used to activate security in the secondary layer. For example, a security activation procedure may be performed and / or a security mode command may be sent for a given layer whenever the layer-specific Kenb is changed and / or when the NAS COUNT is changed.

[0225] Depending on the current load in the network and / or the amount of data to be transmitted to and / or from the WTRU, a WTRU may be configured with a primary layer and zero or more secondary layers. The WTRU may be configured with layer-specific measurement information and / or with cell-specific offsets to define the area of ​​the cell. The WTRU may be configured with measurement objects (e.g., measObj). This measurement object may be cell-specific and / or layer-specific. The measurement object may be associated with one or more other event configurations (e.g., eventConfiguration), for example, depending on the WTRU configuration. An event configuration may include one or more criteria that trigger one or more WTRU behaviors. For example, with respect to a measurement object, the WTRU may be configured with one or more event configurations (e.g., criteria) that establish conditions under which the WTRU is triggered to perform an action based on WTRU measurements associated with the measurement object. By way of example, the measurement object may establish measurements for serving cells of the primary and / or secondary serving site, and the event configuration may indicate one or more thresholds and / or offset amounts associated with the measurement object. If the measurement in question exceeds a configured threshold, falls below a configured threshold, exceeds a given offset value, etc., the WTRU may be triggered to perform an event associated with the event configuration. The initial configuration of the secondary cell may include one or more associations between measurement objects and one or more event configurations for the secondary serving site cell that establish the actions that the WTRU should take on the primary and / or secondary layer if the measurement meets specified criteria. The measurement objects may be associated with one or more event configurations using a measurement identity (measId) that is used by the network to refer to a given measurement object or configuration.

[0226] For example, a measurement object for a given layer may be configured for a given serving cell of the layer. An event configuration may establish an action to be performed by the WTRU based on the serving cell quality becoming better than a first threshold (e.g., a condition that may trigger a first behavior), the serving cell quality becoming worse than a second threshold (e.g., a condition that may terminate the first behavior and / or trigger a second behavior), etc. One or more measurement objects and one or more event configurations may be used to define a cell range extension (CRE) region. A CRE region may be established for a macro cell (e.g., associated with an MeNB) and one or more small cells (e.g., associated with one or more SCeNBs). A CRE region of an MeNB may be associated with a region in which the WTRU is within the coverage area of ​​the MeNB and also within the coverage of one or more small cells of the SCeNB. While the WTRU is in the CRE, traffic from the macro cell may be offloaded to one or more of the small cells. The CRE may be defined based on cell measurements at one or more layers. A WTRU may be configured to determine whether it is in a CRE based on measurements of one or more small cells while it is still connected to a macro cell (e.g., whether the serving cell quality is above a threshold, whether it is below a threshold, etc.). The WTRU's behavior may be defined based on one or more of whether the WTRU is within the coverage of the area of ​​the CRE, whether the WTRU detects that it has entered the area of ​​the CRE (e.g., from or towards the center of the cell), whether the WTRU detects that it has left the area of ​​the CRE (e.g., from or towards the center of the cell), and / or the like.

[0227] A condition detected in a first cell associated with a first serving site or layer may trigger the behavior of a WTRU at a secondary serving site or layer. For example, if a nearby cell in a different layer becomes better (e.g., by a specified offset) than the serving cell of the current layer, the WTRU may be triggered to perform a first function and / or to stop performing a second function. Similarly, if a nearby cell in a different layer becomes worse (e.g., by a specified offset) than the serving cell of the current layer, the WTRU may be triggered to perform a second function and / or to stop performing the first function.

[0228] A WTRU may be configured with one or more offset values ​​(e.g., values ​​by which a nearby cell may be above or below that of the current serving cell to trigger a behavior) and / or one or more absolute thresholds (e.g., a particular level at which a measurement triggers a given behavior). With respect to multi-layer operation, if certain criteria are met for measurements performed on a cell associated with a primary layer and / or a cell associated with a secondary layer, the WTRU may perform one or more actions related to a particular layer (e.g., start decoding control signaling in another cell / layer, activate a cell / layer, etc.). Thus, instead of (and / or in addition to) triggering a conventional measurement report, a given measurement may trigger other behaviors in other layers. For example, a WTRU configured with dual connectivity may be configured with measurements on a first layer and may be triggered to perform an action related to a serving cell on a secondary layer (e.g., measuring a cell on the secondary layer) based on certain criteria for measurements on the primary layer being met. For example, metrics may be established to indicate that the WTRU is within the range of the CRE but that the secondary cell quality is degrading (e.g., indicating that the WTRU is moving toward the edge of the small cell). Such metrics may be used to trigger the WTRU to send a request for re-establishment of at least one bearer configured for use in the secondary layer.

[0229] In an example, a WTRU may be configured to attempt to determine whether it is within the region of the CRE but the quality of a cell associated with a secondary layer is degrading. For example, measurements may be configured such that if the WTRU detects that the quality of a secondary serving cell has fallen below a threshold but is still within the region of the CRE (e.g., indicating the WTRU is moving toward the edge of the cell), the WTRU may be triggered to start receiving control signaling in a different cell. For example, the different cell may be associated with a different SCeNB for which the WTRU was pre-configured but not activated in the WTRU. The WTRU may begin attempting to receive control signaling (e.g., RRC signaling) in other cells to attempt to maintain session continuity during activation / deactivation of different layers. For example, measurements may indicate that the WTRU is moving toward the edge of the small cell, and the WTRU may be triggered to start receiving control signaling in the macro cell. Because a macro cell may have a larger coverage area than a small cell, a WTRU may be more likely to receive control signaling via a macro cell when moving to the cell edge of a small cell. The initiation of reception of control signaling in the macro cell may be performed in addition to and / or after the transmission of measurement reports to the network (e.g., through the current serving cell at the small cell layer).

[0230] A reconfiguration procedure may be utilized to configure one or more secondary cells for use. For example, an RRC connection reconfiguration procedure may be utilized by the WTRU to configure the secondary layer using control signaling exchanged with the primary layer. Configuration of a second set of cells associated with a secondary serving site and / or secondary MAC instance (e.g., referred to as the secondary layer) may be performed as part of the RRC connection reconfiguration procedure. For example, the control signaling used to establish configuration for one or more cells in the secondary layer may include an RRC connection reconfiguration message without a mobilityControlInfo information element (e.g., received via a cell of the primary layer). For example, the WTRU may receive an RRCConnectionReconfiguration message, e.g., via a transmission from a cell associated with the primary layer and / or over an SRB associated with the primary layer (e.g., in the case of initial configuration for the small cell layer). In an example, if a secondary layer is already established, an RRCConnectionReconfiguration message may be received in a transmission from a cell associated with the secondary layer and / or over an SRB associated with the secondary layer (e.g., reconfiguration of PHY / MAC parameters for the secondary layer, such as for adding, removing, reassociating, and / or moving one or more RBs from one layer to another).

[0231] In an example, rather than reusing the RRCConnectionReconfiguration message for configuring the secondary layer, a new RRC message may be established to configure the MAC instance associated with the secondary layer. For example, an RRCConnectionReconfigurationSecondaryLayer message may be defined to initially configure and / or reconfigure the secondary layer. When the RRCConnectionReconfiguration message is utilized, an indication indicating that the reconfiguration is being performed to configure / reconfigure the secondary layer rather than or in addition to the primary layer may be included in the message. Configuration information for the secondary layer may be applicable to a second group of cells served by a serving site (e.g., SCeNB) associated with the secondary layer. Cells of the secondary layer may be scheduled independently of cells of other layers. The configuration for the secondary layer may include configuration information for a PCell and zero or more SCells. In an example, cells of a given layer may be associated with the same Timing Advance Group.

[0232] Regardless of whether the reconfiguration message is used to initially configure the secondary layer and / or to reconfigure the secondary layer, the reconfiguration message may include one or more parameters that the WTRU can apply to operation in the secondary layer (e.g., the parameters may be in addition to existing parameters of such an RRC message). For example, an RRCConnectionReconfiguration message used to configure / reconfigure the secondary layer may include a dedicated radio resource configuration for one or more serving cells of the secondary layer (e.g., a radioResourceConfigDedicated IE for a cell of the secondary serving site). For example, the dedicated radio resource configuration may be for a PCell of the secondary layer. In an example, an RRCConnectionReconfiguration message used to configure / reconfigure the secondary layer may include an indication and / or a list of one or more secondary layers to be added (and / or modified) (e.g., an sLayerCellToAddModList IE that may identify the layer being added). In an example, an RRCConnectionReconfiguration message used to configure / reconfigure a secondary layer may include a list of one or more serving cells to add (and / or modify) corresponding to cells of the secondary layer (e.g., a pCellToAddModList indicating information for a PCell to add / modify and / or an sCellToAddModList for an SCell to add / modify). For example, for each layer indicated (e.g., via an sLayerCellToAddModList IE), a list of cells to add (e.g., via pCellToAddModList and / or sCellToAddModList) may be provided.

[0233] In an example, an RRCConnectionReconfiguration message used to configure / reconfigure a secondary layer may include one or more parameters for security key derivation. For example, the reconfiguration message may indicate whether new security keys for use with the secondary layer should be derived and / or an indication of the method to be used to derive the security keys. In an example, an RRCConnectionReconfiguration message used to configure / reconfigure a secondary layer may include an indication of layer identity (e.g., a layer-identity IE, a mac-instanceIdentity IE, etc.). The layer identity may be used to derive identity information for one or more SRBs of the secondary layer (e.g., for purposes of security inputs such as the BEARER parameter). For example, for a given SRB, the value provided by RRC to a lower layer to derive a 5-bit BEARER parameter used as input for ciphering and integrity protection may be the value of the corresponding srb-Identity+2×layer-identity, e.g., with the MSB padded with zeros. As an example, the primary layer may be assigned identity 0. The identity of the secondary layer may be implicitly derived based on the configuration sequence. In an example, the RRCConnectionReconfiguration message used to configure / reconfigure the secondary layer may include an indication of one or more associated RBs (e.g., one or more DRBs and / or SRBs) associated with the secondary layer. If a bearer may be split across different layers, the RRCConnectionReconfiguration message used to configure / reconfigure the secondary layer may include an identity of a service access point associated with the secondary layer (e.g., such an indication may also be provided even if the bearer is specific to a given layer).

[0234] Upon receiving the RRCConnectionReconfiguration message, the WTRU may perform various functions, e.g., based on the contents of the reconfiguration message. For example, the WTRU may add a first cell for the secondary layer, add additional cells to the secondary layer, remove cells from the secondary layer, etc. By way of example, if the reconfiguration message indicates the addition of one or more secondary layers and / or one or more cells of the secondary layer, the WTRU may perform an initial configuration of cells for the secondary layer. By way of example, if the cell to be added is the first cell to be configured and added for a given secondary layer, the WTRU may create a secondary MAC instance, e.g., using the mac-MainConfig IE provided in the radioResourceConfigDedicated that may be included in the reconfiguration message. The WTRU may associate the newly created secondary MAC instance with an identity. For example, an explicit indication of the identity may be provided in the reconfiguration message and / or may be created implicitly based on incrementing a counter of instantiated (e.g., configured) MAC instances. The WTRU may configure a physical layer associated with the secondary MAC instance (e.g., possibly using a separate transceiver chain). For example, parameters for the physical layer may be included in a radioResourceConfigDedicated IE included in the configuration applicable to the MAC instance (e.g., physicalConfigDedicated). The WTRU may implicitly consider the first cell configured for use in the newly created layer to be a PCell for the secondary layer. The WTRU may synchronize with the downlink of the configured cell for the newly added layer (e.g., if the cell is configured as a PCell for the layer in question). If the cell being added is not the first cell configured for the secondary layer, the WTRU may apply any configuration received for the cell to the existing MAC instance and may refrain from creating a new MAC instance.

[0235] A reconfiguration message may be used to remove or delete a cell from the secondary layer. For example, if the reconfiguration indicates that a cell should be removed, the WTRU may remove the indicated cell and update the configuration of the MAC instance. If the secondary MAC instance is configured with zero cells after completion of processing the reconfiguration message (e.g., each of the cells for the layer has been removed), the WTRU may remove the corresponding secondary MAC instance from its configuration.

[0236] In an example, the use of an RRC connection reconfiguration message without a mobilityControlInfo IE may be associated with modifying an existing connection for a secondary layer, rather than for the addition of a new layer (e.g., the use of a reconfiguration message without a mobilityControlInfo IE occurs when the WTRU is already configured for dual connectivity and one or more secondary layers are being modified). For example, if the WTRU has not previously received an initial configuration for a secondary layer in an RRC connection reconfiguration message that includes a mobilityControlInfo IE, the WTRU may decide to discard the RRC configuration included in the reconfiguration message without a mobilityControlInfo IE that is applicable to a layer that was not previously configured.

[0237] For example, the configuration of the secondary layer may be established based on an RRC connection reconfiguration procedure that includes a mobilityControlInfo IE. Configuration of a second set of cells and / or secondary MAC instances (e.g., the secondary layer) may be performed as part of the RRC connection reconfiguration procedure. An RRC connection reconfiguration message that includes a mobilityControlInfo information element may be referred to as a handover command. If the handover command is a type of signaling used to add a secondary layer (e.g., and an RRC connection reconfiguration message without a mobilityControlInfo IE is used to modify an existing layer configuration), upon receiving the handover command, the WTRU may perform one or more of the operations described herein to add the new layer (e.g., add a PCell to the new layer, create a secondary MAC instance, associate the secondary MAC instance with an identity, configure the physical layer, synchronize with the PCell for the new layer, etc.). Additionally, if the handover command is a type of signaling used to add a secondary layer (e.g., and an RRC connection reconfiguration message without a mobilityControlInfo IE is used to modify an existing layer configuration), the handover command may include one or more of the configuration parameters described herein for adding a new layer (e.g., a dedicated radio resource configuration for the cell of the new layer, a list of one or more layers to add, a list of one or more serving cells for the layer, parameters for derivation of security keys, identity information for the layer, an indication of the associated RBs, etc.).

[0238] The WTRU may receive an indication that the reconfiguration procedure that includes the handover command is for adding a layer. The WTRU may maintain its configuration information for the currently configured serving cell if the handover command is adding a new layer. The indication that the handover command is being used to add a layer may explicitly indicate for which other layers the WTRU should maintain its current configuration.

[0239] If the WTRU fails to reconfigure the primary layer during the reconfiguration procedure, the WTRU may release and erase any configurations corresponding to both the primary layer and one or more secondary layers. The WTRU may perform reconfiguration failure handling via legacy procedures, for example, by reselecting a different cell, initiating a re-establishment procedure, moving to IDLE mode, and / or the like.

[0240] Upon successfully completing an RRC procedure initially used to initially configure a secondary layer and / or upon successfully completing an RRC procedure to reconfigure one or more secondary layers, the WTRU may autonomously trigger a RACH reconfiguration, monitor for RACH commands after the reconfiguration and after the activation time, and / or activate one or more cells via the RACH.

[0241] For example, the WTRU may be configured to autonomously trigger a RACH reconfiguration upon successfully adding and / or reconfiguring a secondary layer. The WTRU may initiate a RACH procedure for the secondary layer. In an example, the UE may receive an indication that a RACH procedure should be performed in a reconfiguration message for the layer. In an example, if the WTRU receives a reconfiguration message (e.g., from the MeNB) configuring a new layer using resources of the primary layer, the RACH procedure may be performed, but if the reconfiguration is performed over the secondary layer, the RACH procedure may not be performed. The RACH procedure may be performed using a dedicated PRACH configuration provided in the reconfiguration procedure (e.g., in a handover command or other reconfiguration message). In an example, the presence of the PRACH configuration in the reconfiguration message may be an indication that the WTRU should initiate a RACH procedure once the reconfiguration procedure is complete. The RACH procedure may be performed using uplink resources of the serving cell of the newly added or reconfigured secondary layer. The RACH procedure may be performed over the PCell of the secondary layer. The RACH procedure may be performed over the SCell of the secondary layer. Which cell of the newly added / reconfigured layer should be used for the RACH procedure may be indicated in the reconfiguration message. The TAT associated with the serving cell on which the RACH procedure should be performed may be considered as stopped or not running after the reconfiguration procedure.

[0242] In an example, the WTRU may monitor for RACH commands after a reconfiguration procedure and / or after an activation time for the secondary layer. For example, the WTRU may start monitoring for RACH commands on the PDCCH for a serving cell of the secondary layer upon completion of a reconfiguration procedure that adds and / or modifies the secondary layer. The WTRU may start monitoring the PDCCH after a configured and / or predefined activation time. The serving cell to be monitored for RACH commands may be a PCell of the newly created / reconfigured secondary layer and / or a SCell of the newly created / reconfigured secondary layer. Which cell of the newly added / reconfigured layer should be monitored for RACH commands may be indicated in the reconfiguration message. The TAT associated with the serving cell on which the RACH procedure is to be performed (e.g., through which the RACH command is received) may be stopped or considered not running after the reconfiguration procedure.

[0243] In an example, cells of a newly created / reconfigured layer may initially be considered deactivated. Upon layer activation, the WTRU may be configured to perform a RACH procedure for cells of the activated layer. For example, the WTRU may determine to associate a deactivated state with each cell of the newly added / reconfigured layer. In an example, the SCell of a layer may initially be deactivated, while the PCell of the layer may be considered activated upon receiving a configuration for the layer. Receipt of control signaling activating a cell of the newly added / reconfigured layer may trigger the WTRU to perform a RACH procedure for the cell of the newly added / reconfigured layer and / or start monitoring its PDCCH. For example, receipt of control signaling (e.g., from an MeNB) activating one or more cells of a secondary layer (e.g., received while all cells of the secondary layer are in a deactivated state) may trigger the WTRU to perform a RACH procedure for the cell of the activated layer and / or start monitoring the PDCCH for it.

[0244] The WTRU may be configured to transmit and / or receive RRC signaling from independent eNBs and / or independent RRC entities in the network. For example, according to LTE Release 11 procedures, when an RRC procedure is initiated, the WTRU may be allowed a maximum amount of time to complete the RRC procedure. For example, a typical value for the maximum length of time the WTRU may take to complete the RRC procedure may range from 15 ms to 20 ms, depending on the RRC procedure. RRC also supports sequential reception of RRC messages, for example, when an RRC message initiating a second RRC procedure is received while a first RRC procedure is ongoing and not yet completed. In such cases, the WTRU may process the RRC messages sequentially. When the WTRU has a connection to a single eNB, the network may ensure proper coordination of the RRC signaling so that the WTRU's processing and timing requirements are minimized.

[0245] When the same eNB transmits both messages, the eNB may be able to determine the overall delay for the combined RRC procedure. The delay may be determined independently of how many RRC messages the eNB transmits to the WTRU. In this situation, there can be no timing uncertainty at the eNB, and synchronization can be fully controlled by the eNB.

[0246] When dual connectivity is configured (e.g., a WTRU is connected to and / or attempts to connect to multiple layers), conflicts may occur if the eNBs are not fully coordinated. For example, a WTRU may receive control signaling from multiple eNBs, each initiating a respective RRC procedure. The received control signaling may be transmitted over different transmission paths (e.g., the Uu of the MeNB and the Uu of the SCeNB). For example, the path utilized to transmit an RRC message may depend on whether the signaling is applicable to the WTRU configuration for the MeNB or the SCeNB. In such a case, the WTRU may receive an RRC message that triggers a second RRC procedure (e.g., with the SCeNB), but there is a higher likelihood that the WTRU already has an RRC procedure in progress (e.g., with the MeNB) (or vice versa).

[0247] When a WTRU receives RRC messages from different eNBs (e.g., an SCeNB and an MeNB), it may be difficult for the second eNB to ensure synchronization and completion of the procedure with the WTRU. For example, it may be difficult to determine a delay before completion of the procedure because the WTRU may already be performing another RRC procedure initiated by the first eNB. The second eNB may not be aware of the other RRC procedures that the WTRU is performing. In addition, it may be difficult for the WTRU to perform RRC procedures in parallel (e.g., rather than sequentially) if, for example, there is a dependency (or interaction) between the two RRC procedures. For example, problems may arise with one or more of competing procedures, associated synchronization, timing uncertainty, additional delays, etc.

[0248] For example, there may be reception of conflicting RRC PDUs by the WTRU for different RRC procedures. In an example, the WTRU may be configured to prioritize one or more RRC procedures that may be associated with a first layer over another RRC procedure that may be associated with a second layer. For example, the WTRU may handle reception of multiple RRC PDUs in the same subframe (or within processing windows that may overlap) by associating a priority with each message. Priorities may be assigned according to a predefined rule, for example, to enable the WTRU to sequentially execute associated procedures in order of increasing priority. For example, the priority assigned to a given RRC procedure and / or a given RRC message may be based on the identity of the layer with which the RRC PDU is associated (e.g., a primary layer / MeNB may have a higher priority than a secondary layer / SCeNB), the identity of the SRB through which the WTRU receives the RRC PDU (e.g., SRB0, SRB1, SRB2 may have a higher priority than SRB3), the type of procedure with which the RRC PDU is associated (e.g., a mobility event such as a handover command may have a higher priority than a reconfiguration procedure), and / or the like.

[0249] In an example, in the event of reception of colliding RRC PDUs, the WTRU may be configured to prioritize RRC PDUs for synchronization based on delay requirements. For example, the WTRU may assign a lower priority to an RRC PDU associated with a procedure whose completion may trigger a RACH procedure. The timing of the procedure with the higher priority may be maintained, but the second procedure may still be executed without introducing timing uncertainty if a RACH procedure performed after completion of the lower priority RRC procedure can synchronize the WTRU and the network.

[0250] In an example, upon receiving an RRC PDU while another RRC procedure is in progress, the WTRU may be configured to prioritize one of the procedures and abort / cancel the other RRC procedure. For example, the WTRU may abort or abort an ongoing procedure based on receiving an RRC message determined to have a higher priority. For example, the WTRU may determine that two received RRC PDUs and / or an ongoing procedure and the received RRC PDU conflict, in which case the WTRU may initiate RRC procedure failure logic for the RRC PDU and / or the procedure with the lowest priority. In an example, the WTRU may abort a procedure whose completion would result in a RACH procedure in the event of such a conflict.

[0251] For example, two or more RRC PDUs may be received simultaneously or nearly simultaneously. By way of example, a WTRU may receive multiple RRC PDUs in the same subframe and / or within a certain length of time. A first RRC PDU may be associated with a procedure applicable to a first eNB / layer, and a second RRC PDU may be associated with a procedure applicable to a second eNB / layer. In the event of such a conflict, the WTRU may perform parallel processing of the RRC procedures, sequential processing of the RRC procedures, and / or may skip or perform a failure procedure for one or more of the RRC procedures.

[0252] For example, the WTRU may process both messages such that the RRC procedures may be performed in parallel. For example, the WTRU may determine to perform RRC procedures in parallel if the RRC procedures are independent of each other. For example, the WTRU may determine that both procedures reconfigure different RRC aspects (e.g., different parameters, different RBs, different MAC instances, different transceiver components, and / or independent combinations thereof) and that the reconfigurations do not conflict with each other. The WTRU may perform RRC procedures in parallel based on determining that both procedures are inherently independent (e.g., reconfiguration of measurement configuration and dedicated resources). For example, the WTRU may determine that the processing requirements (e.g., in terms of maximum delay) to complete the procedures are the same as if each procedure were performed separately. Otherwise, the WTRU may be configured to perform synchronization with the network (e.g., by performing a RACH procedure). For example, if a dual connectivity configuration results in timing uncertainty for both the MeNB and the SCeNB for RRC procedures, the WTRU may be configured to perform a RACH procedure for one or more RRC procedures that modify parameters of the WTRU's corresponding physical layer and / or for each of the reconfigured physical layers.

[0253] In an example, a WTRU may be configured to perform sequential processing of two or more RRC procedures. The WTRU may process received messages in order such that the RRC procedures are performed sequentially. For example, the WTRU may determine to perform the RRC procedures sequentially based on determining that both RRC procedures are independent of each other. The WTRU may determine which procedure to prioritize (e.g., perform first) based on one or more of an identity of an eNB associated with the RRC procedure, an identity of an SRB associated with the RRC procedure, a type of received RRC PDU, a type of RRC procedure, and / or the like.

[0254] For example, the WTRU may determine which RRC procedure to prioritize / perform first depending on the identity of the eNB (and / or layer / Uu interface) associated with the RRC procedure. For example, the WTRU may prioritize processing of RRC PDUs associated with the MeNB over those of the SCeNB.

[0255] For example, the WTRU may determine which RRC procedure to prioritize / perform first depending on the identity of the SRB associated with the procedure. For example, the WTRU may determine whether the SRB through which the RRC PDU is received is the same as or different from that of the RRC PDU that initiated the ongoing procedure. In an example, if the sets of SRBs used for the first eNB and the second eNB are different, some SRBs may be prioritized over others. For example, if the SRBs for a given WTRU share the same identity space across different layers / MAC instances, the WTRU may directly determine which procedure to prioritize based on the identity of the SRB for the procedure. Otherwise, if the SRBs for the first layer are different from those for the second layer, the WTRU may determine which RRC procedure to prioritize based on the association between the SRB identities and the eNBs (e.g., the WTRU may have SRBs 0, 1, and / or 2 for each eNB, and the priority may be based on the SRB identities first, or, if the SRB identities are the same, on the layer identities). For example, the WTRU may prioritize processing of RRC PDUs associated with SRBs 0, 1, and / or 2 over RRC PDUs associated with SRBs 3.

[0256] The WTRU may determine which RRC procedure to prioritize / perform first depending on the multiplexing method used for receiving RRC PDUs associated with WTRU configurations for different eNBs. For example, the WTRU may determine the priority associated with a given RRC procedure based on a feature that allows multiplexing of RRC PDUs (or information elements within a PDU) for configurations for different eNBs. For example, the identity of the Uu interface used for transport of the RRC PDU may be used to establish the priority. The RRC PDU format (e.g., an indication received in the RRC PDU and / or information elements of the type included in the RRC PDU) may be used to establish the RRC priority. The identity of the subframe in which the WTRU received the RRC PDU may be used to determine the priority for handling the RRC procedure (e.g., if the WTRU's downlink is time-multiplexed between eNBs).

[0257] The WTRU may determine which RRC procedure to prioritize / perform first depending on the type of RRC PDU received. For example, the WTRU may determine a priority associated with a given RRC PDU depending on whether the RRC PDU initiates a new RRC procedure or is a PDU for an ongoing procedure. The WTRU may be configured to prioritize RRC PDUs for an ongoing procedure over RRC PDUs that initiate a new RRC procedure. In an example, if RRC PDUs applicable to the WTRU configuration for any of the eNBs / layers may be received on either transport path (e.g., RRC PDUs for RRC procedures associated with different layers may be received on the same transport path), the ongoing procedure may be prioritized over a newly initiated procedure. For example, the WTRU may prioritize RRC PDUs associated with an ongoing procedure over RRC PDUs that initiate a new procedure.

[0258] The WTRU may determine which RRC procedure to prioritize / perform first depending on the type of procedure associated with the received RRC PDU. For example, the WTRU may determine a priority associated with an RRC PDU based on the type of RRC procedure with which the RRC PDU is associated. For example, the WTRU may prioritize an RRC PDU associated with a mobility event or a security event over an RRC PDU associated with a secondary layer reconfiguration.

[0259] The WTRU may be configured to omit and / or initiate a failure procedure for an RRC procedure that conflicts with another RRC procedure of higher priority. For example, the WTRU may determine that the second RRC PDU should be ignored and / or that the WTRU should proceed with failure logic for the RRC procedure associated with the second RRC PDU based on determining that another RRC procedure overrides and / or conflicts with the RRC procedure associated with the second RRC PDU and that the other RRC procedure has a higher priority than the RRC procedure associated with the second RRC PDU. For example, the WTRU may omit the RRC PDU or initiate failure logic for the RRC procedure associated with the RRC PDU based on determining that the procedures are interdependent. For example, the WTRU may receive an RRC reconfiguration message with a mobilityControlInfo IE (e.g., a handover command) that instructs the WTRU to remove a configuration associated with the SCeNB and to perform a handover to another cell for the RRC connection. The WTRU may also receive an RRC reconfiguration command (e.g., such as a physical layer configuration of the SCeNB) intended to reconfigure the SCeNB. In such a case, the WTRU may process and perform a mobility procedure (e.g., associated with a handover command) and determine that the reconfiguration procedure for the SCeNB is invalid. In an example, the WTRU may send a message indicating a failure to perform the second procedure, and the message may include an indication of the cause of the failure (e.g., "overridden by MeNB").

[0260] Similar priority-based rules may be applicable at the WTRU for WTRU-initiated RRC procedures. For example, when the WTRU determines that more than one RRC procedure should be triggered within a given period of time, the WTRU may utilize priority rules to determine how to handle contention for two or more WTRU-initiated RRC procedures.

[0261] In an example, a WTRU may be configured to receive one or more RRC PDUs for an RRC procedure while another RRC procedure is in progress. For example, the ongoing RRC procedure may be applicable to a first eNB / layer, and the received RRC PDU may be associated with a procedure applicable to a second eNB / layer. In such cases, similar rules may be defined for parallel processing of RRC procedures, performing sequential processing of RRC procedures, and / or omitting or performing failure procedures for one or more of the RRC procedures, as was the case when two or more RRC PDUs were received simultaneously or near simultaneously.

[0262] For example, the WTRU may process a received RRC PDU applicable to a configuration for the second eNB / layer such that the second RRC procedure is performed in parallel with the ongoing RRC procedure. For example, the WTRU may determine to perform RRC procedures in parallel if the RRC procedures are independent of each other. For example, the WTRU may determine that both procedures reconfigure different RRC aspects (e.g., different parameters, different RBs, different MAC instances, different transceiver components, and / or independent combinations thereof) and that the reconfigurations do not conflict with each other. The WTRU may perform RRC procedures in parallel based on determining that both procedures are inherently independent (e.g., reconfiguration of measurement configuration and dedicated resources). For example, the WTRU may determine that the processing requirements (e.g., in terms of maximum delay) to complete the procedures are the same as if each procedure were performed separately. Otherwise, the WTRU may be configured to perform synchronization with the network (e.g., by performing a RACH procedure). For example, if a dual connectivity configuration results in timing uncertainty for both the MeNB and the SCeNB for RRC procedures, the WTRU may be configured to perform a RACH procedure for one or more RRC procedures that modify parameters of the WTRU's corresponding physical layer and / or for each of the reconfigured physical layers.

[0263] In an example, the WTRU may be configured to process the second message once the ongoing procedure is completed, so that the RRC procedures are performed sequentially. For example, the WTRU may determine to perform the RRC procedures sequentially based on determining that both RRC procedures are independent of each other. In an example, the WTRU may determine that the ongoing procedure should be interrupted such that other RRC PDUs should be prioritized based on one or more of an identity of the eNB associated with the RRC procedure, an identity of the SRB associated with the RRC procedure, a type of RRC PDU received, a type of RRC procedure, and / or the like.

[0264] For example, the WTRU may determine which RRC procedure to prioritize / perform first depending on the identity of the eNB (and / or layer / Uu interface) associated with the RRC procedure. For example, the WTRU may prioritize procedures associated with the MeNB over those of the SCeNB. For example, the WTRU may choose to initiate a new procedure and abort (or abort, or complete with failure) the ongoing procedure if the new procedure is for the MeNB / primary layer and the ongoing procedure is for the SCeNB / secondary layer.

[0265] For example, the WTRU may determine which RRC procedure to prioritize / perform first depending on the identity of the SRB associated with the procedure. The WTRU may determine that the SRB for which the RRC PDU is received is of a higher priority than the RRC PDU that initiated the ongoing procedure. For example, the WTRU may prioritize processing of RRC PDUs associated with SRB0, SRB1, or SRB2 over an RRC procedure initiated from an RRC PDU associated with SRB3.

[0266] The WTRU may decide which RRC procedure to prioritize / perform first depending on the procedure associated with the received RRC PDU and the type of ongoing RRC procedure. For example, the WTRU may prioritize an RRC PDU associated with a mobility event or a security event over the completion of an ongoing procedure associated with a secondary layer reconfiguration.

[0267] The WTRU may be configured to omit and / or initiate failure procedures for an ongoing RRC procedure that conflicts with a received RRC PDU determined to have a higher priority. The WTRU may be configured to ignore an RRC PDU associated with a lower priority when an RRC procedure of a higher priority is in progress. For example, the WTRU may determine that the second RRC PDU should be ignored and / or proceed with failure logic for the RRC procedure associated with the second RRC PDU based on the WTRU determining that another RRC procedure overrides and / or conflicts with the RRC procedure associated with the second RRC PDU, and that the other RRC procedure has a higher priority than the RRC procedure associated with the second RRC PDU. For example, the WTRU may omit an RRC PDU or initiate failure logic for the RRC procedure associated with the RRC PDU based on determining that the procedures are interdependent. For example, the WTRU may have an ongoing mobility procedure based on receiving an RRC reconfiguration message with a mobilityControlInfo IE (e.g., a handover command) that instructs the WTRU to remove the configuration associated with the SCeNB and perform a handover to another cell for the RRC connection. In such a case, the WTRU may process and perform the mobility procedure (e.g., associated with the handover command) and determine that the reconfiguration procedure for the SCeNB is invalid. In an example, the WTRU may send a message indicating a failure to perform the second procedure, and the message may include an indication of the cause of the failure (e.g., "overridden by MeNB").

[0268] In an example, the WTRU may abort an ongoing RRC procedure if the ongoing procedure conflicts with an RRC PDU received for another layer and completion of the ongoing RRC procedure would result in a synchronization event with the eNB being challenged (e.g., completion of the RRC procedure would result in a RACH procedure).

[0269] The WTRU may be configured to perform one or more actions when reconfiguration for the secondary layer fails and / or when it determines to initiate a reconfiguration failure procedure (e.g., due to a conflict between multiple RRC procedures). The WTRU may determine that reconfiguration of a given layer failed based on one or more of: a failure to interpret and / or decode a reconfiguration message; a failure to successfully apply a configuration provided during the reconfiguration procedure; a failure to successfully perform random access using the new configuration; determining that the received configuration exceeds the capabilities of the WTRU (e.g., the received configuration cannot be applied based on the capabilities of the WTRU); detecting conflicting control plane signaling; detecting RLF; and / or the like. If the WTRU determines that it was unsuccessful in configuring one or more (or all) serving cells for the secondary layer and / or MAC instance, the WTRU may perform various actions. For example, if the WTRU determines that the RRC connection reconfiguration procedure failed, the WTRU may revert to a previous configuration for the secondary layer (e.g., if reconfiguration for the secondary layer and / or a single layer failed). In an example, the WTRU may return to the primary layer (e.g., if mobility for all secondary layers has failed) and stop utilizing configurations for the secondary layers. The WTRU may initiate an RRC connection re-establishment procedure in the primary layer, for example, to re-establish radio bearers (e.g., DRBs, possibly DRBs other than SRBs) associated with the secondary layer for which the reconfiguration failed. For example, the WTRU may perform the re-establishment procedure for all DRBs associated with the secondary layer for which the reconfiguration failure occurred and / or for the particular DRB of the secondary layer that was the subject of the failed reconfiguration procedure. As an example, the WTRU may send an indication to the network of why the reconfiguration failure occurred.For example, if the reconfiguration failure occurs because it conflicts with another RRC procedure (e.g., for another layer) being implemented by the WTRU, the WTRU may indicate that the conflict occurred by, for example, indicating the cause as "WTRU capabilities exceeded" or some similar / other cause. When the WTRU determines that the reconfiguration procedure for the secondary layer failed, it may initiate sending a measurement report to the macro layer. For example, the report may include one or more measurement results for the layer that failed to reconfigure. As an example, the WTRU may determine that the WTRU failed to configure the secondary layer if the WTRU failed to successfully apply a configuration for the PCell of the secondary layer. For example, the WTRU may determine whether it failed to successfully synchronize with the PCell and / or whether it failed to successfully perform random access on the PCell. Such a failure may cause the WTRU to consider the reconfiguration to be unsuccessful.

[0270] The WTRU may be configured to perform an RRC connection re-establishment procedure based on, for example, a failure to successfully reconfigure one or more layers. The following example may be used for an RRC connection (or secondary layer) re-establishment procedure. For example, the WTRU may determine that some or all serving cells of the secondary layer (e.g., PCells of the secondary layer) are experiencing radio link problems. The WTRU may detect a failure condition that may indicate that transmission for a DRB of the secondary layer will not be successful or will no longer be possible. For example, if a DRB is exclusively associated with the secondary layer and one or more cells of the secondary layer are experiencing radio link problems (e.g., RLF is declared), the WTRU may determine that it will be unable to communicate using the bearer. As an example, a re-establishment procedure may be performed for a DRB whose QoS can no longer be met, but not for a DRB whose QoS can still be met. RRC re-establishment may be performed for an SRB (e.g., SRB3). For example, a re-establishment procedure may be performed for an SRB associated with a secondary layer if the re-establishment procedure indicates that after completion of the procedure, the secondary layer will still be used for the RB in question. The re-establishment procedure may be when the primary layer (e.g., a PCell of the primary layer) is experiencing a radio link failure and / or when the secondary layer (e.g., a PCell of the secondary layer) is experiencing a radio link failure.

[0271] For example, the WTRU may determine that a re-establishment procedure should be performed for a given layer based on detecting one or more failure conditions. Examples of failure conditions may include one or more of a DL RLF, a UL RLF, a handover failure for a secondary layer, a security failure (e.g., integrity verification failure), an indication from a lower layer (e.g., MAC) that a configuration and / or re-configuration procedure failed, a re-configuration failure associated with a re-configuration of a secondary layer, and / or other failure situations. If a failure condition is detected for a given layer, the WTRU may attempt to initiate a re-establishment request in a cell of the layer that is not in the failure condition. For example, the re-establishment may be to a cell of a layer that is configured for use by the WTRU but may be in a deactivated / idle state. In an example, the WTRU may attempt to perform re-establishment in a configured active layer that is different from the layer in which the failure was detected. For example, if the cell used for the re-establishment procedure was previously inactive, the WTRU may first resume normal operation and / or activate the cell in question. For example, the inactive layer may be a primary layer cell (e.g., PCell). In an example, a re-establishment request may be initiated to a secondary layer cell.

[0272] For example, upon detecting a failure in a cell of a given layer (e.g., a secondary layer), the WTRU may initiate a re-establishment procedure, e.g., in a cell of the primary layer and / or a cell of a different secondary layer. The WTRU may suspend one or more DRBs associated with the layer for which re-establishment is being performed (e.g., a DRB associated with the failed secondary layer). In an example, the WTRU may release all cells of the layer for which re-establishment is being performed. The WTRU may reset (e.g., and / or destroy) the MAC instance corresponding to the layer for which re-establishment is being performed. For example, the WTRU may initiate transmission of an RRC message (e.g., an RRC connection re-establishment (or similar) message indicating "layer failure"), which may include an identification of the layer for which re-establishment is being performed (e.g., in the reestablishmentCause). If the re-establishment procedure is triggered based on an event configuration, the WTRU may include the measID and / or an indication of "degrading quality" and / or "sufficient quality." If the WTRU performs re-establishment via a deactivated / idle layer, the WTRU may include identification information, such as, for example, a WTRU identity and / or a context identity. For example, the identification information may be a value assigned to the WTRU at the layer on which the re-establishment is being performed and / or the configuration of the layer through which the re-establishment procedure is being performed. As an example, the identification information may be a C-RNTI assigned to the WTRU at the layer on which the re-establishment is being performed and / or the configuration of the layer through which the re-establishment procedure is being performed.

[0273] The WTRU may receive an RRC connection reconfiguration message. The reconfiguration message may reassociate one or more DRBs to a layer in which no failure condition was detected (e.g., to a primary layer). The WTRU may destroy and / or remove the configuration for the MAC instance corresponding to the failed layer. In an example, the reconfiguration message may reassociate the DRBs (e.g., and / or SRBs) of the failed layer to a new secondary layer and / or primary layer. The WTRU may reuse the MAC instance corresponding to the failed layer for the new secondary layer and / or may instantiate a new MAC instance for the newly configured secondary layer. Whether the primary layer or the secondary layer should be used for RB reassociation may be indicated using layer identification information included in the reconfiguration message.

[0274] If the WTRU is configured to perform a reconfiguration (e.g., based on performing a layer re-establishment, based on the occurrence of a mobility event, based on layer activation / deactivation, etc.), the WTRU may re-establish PDCP for the DRBs associated with the layer being reconfigured (and / or for the SRBs of the layer being reconfigured). For example, if the PDCP instance is WTRU-specific (e.g., in an architecture where the receive / transmit PDCP entities change upon a mobility event in the primary layer but do not change upon a mobility event associated with a secondary layer), the WTRU may re-establish PDCP by performing a subset of the PDCP re-establishment procedure that would be performed if the primary layer were to be re-established. For example, the WTRU may skip PDCP re-establishment, which means that the WTRU can continue with the header compression protocol without resetting it, can maintain security context, and / or can continue with ordering information unaffected. In an example, the WTRU, if configured, may send a PDCP status report in the uplink. The WTRU may re-establish the RLC for the problematic DRB (and / or SRB, if applicable).

[0275] Upon successful completion of the reconfiguration procedure based on the secondary layer failure, the WTRU may determine that the reestablishment of the DRB for the failed layer is successful. The WTRU may resume use of any suspended RBs for the failed layer, e.g., on a different layer as configured by the reconfiguration procedure. The WTRU may include a status report indicating user plane data that must still be successfully transmitted / received when it resumes the reconfigured DRB. The WTRU may perform a reestablishment request for the secondary layer DRB if it determines a failure of the uplink radio link. In an example, the reestablishment for the secondary layer DRB may be performed for the secondary layer PCell, but not for the secondary layer SCell.

[0276] Because different serving sites can access and serve the WTRU relatively independently of one another, the behavior of a WTRU in such an architecture may differ from the behavior of a WTRU in a single data path architecture. For example, a WTRU may connect to a first primary serving site (MeNB). The WTRU may establish an RRC connection with the primary serving site in a manner similar to Release 11. During the connection process, the WTRU may send an indication to the network indicating that the WTRU supports connections at multiple serving sites. Based on receiving the indication, the network may pre-configure the WTRU to access one or more secondary serving sites. For example, the primary serving site may send an RRC connection reconfiguration message to the WTRU. The RRC connection reconfiguration message may include an indication that the reconfiguration is for adding an additional MAC instance and / or an additional transmission layer.

[0277] The WTRU may store configuration information for one or more layers. However, even though the received configuration may be valid, the actual connection between the WTRU and the pre-configured serving site may be deactivated. The configuration information stored by the WTRU may be stored and / or remain valid until the WTRU receives a message removing, modifying, and / or releasing the configuration. In an example, the stored configuration information may be valid for a set period of time, and an indication of the period may be part of the configuration. The WTRU may consider the configuration information valid until a specified event occurs (e.g., until cell reselection occurs at the primary layer). For example, the stored configuration information may be considered valid until a mobility event occurs (e.g., the WTRU moves to a different PLMN, a different tracking area, etc.).

[0278] The configuration of the primary layer may be valid for a different period of time than the configuration of the secondary layer. For example, an event may trigger the WTRU to ignore the configuration of the secondary layer but not the configuration of the primary layer (or vice versa). The network may “pre-configure” or “prime” the WTRU with configuration information for one or more layers (e.g., a primary layer, a secondary layer, etc.) without activating the one or more layers. The network may then send signaling to the WTRU to indicate that the WTRU should activate one or more pre-configured layers. The WTRU may prioritize the configuration of a first layer over the configuration of a second layer. For example, the WTRU may prioritize the configuration of a primary layer (e.g., which may correspond to the macro layer and / or may be served by an MeNB) for functions such as connection re-establishment and / or mobility if another layer fails (e.g., a secondary layer).

[0279] The configuration information for multiple layers may configure the WTRU to utilize multiple MAC instances. Depending on the situation in which the WTRU is attempting to access different serving sites, the WTRU may be configured to maintain different numbers of activated serving sites at any given time instant. For example, the WTRU may have a single MAC instance (or layer) active at any given time. A configuration in which a single MAC instance (or layer) is active at any given time may be referred to as a single MAC connection. The WTRU may maintain a single active layer, for example, regardless of which layer provides the best connection at a given time instant. For example, the small cell layer may be used to achieve improved throughput and / or to offload traffic from the macro layer. If the small cell layer is used for macro layer offloading, the WTRU may deactivate the primary layer after activating and accessing the secondary layer.

[0280] For example, as described above, the WTRU may first connect to the macro layer. After receiving pre-configuration information for one or more possible secondary layers, the WTRU may activate the secondary layer and begin accessing the secondary serving site. The WTRU may then deactivate its connection to the primary serving site while maintaining its connection to the secondary serving site. In this way, the WTRU may be effectively offloaded from the macro layer while maintaining continuous service at the small cell layer.

[0281] In an example, when a primary layer is inactive and / or not used for transmitting and / or receiving data, the configuration / context for the primary layer may be stored in the WTRU, but the WTRU may refrain from utilizing the configuration / context for the primary layer for transmission. The configuration and / or configurations of the primary layer associated with the serving cell for the primary layer may be considered idle or deactivated, but may be saved in memory for subsequent reactivation and use. The WTRU may receive control signaling that deactivates one or more layers and / or activates one or more layers. In an example, deactivation of one layer may trigger the WTRU to activate a different layer.

[0282] During periods when the macro layer is deactivated, the WTRU may continue to monitor the serving site of the macro layer. For example, mobility-related procedures and / or a WTRU RRC connection may be associated with the WTRU's connection to the primary serving site. Transfer of offloaded data may be performed via one or more active secondary serving sites. To ensure that the WTRU is still able to access the macro serving site when the macro layer is reactivated (e.g., to perform mobility or other control procedures, to transmit and / or receive data, etc.), the WTRU may continue to measure the macro serving site (e.g., MeNB). The WTRU may perform monitoring based on one or more triggers. For example, a decision to perform measurements on the macro serving site (e.g., and / or on one or more other deactivated layers) may be based on one or more triggers. Triggers for performing such measurements are described in more detail below. Similarly, triggers for transmitting measurement reports including information related to quality measurements performed on the WTRU may be defined. The trigger for transmitting a measurement report may be the same as or different from the trigger for performing measurements. For purposes of explanation and brevity, examples of triggers for performing measurements and triggers for sending measurement reports may be described together herein. However, it is contemplated that various combinations of triggers may be used to trigger performing measurements and reporting the measurements. For example, a first trigger, such as the quality of an active layer serving cell falling below a threshold, may trigger the WTRU to perform measurements on a deactivated serving cell of another layer. A second trigger, such as the quality of another layer serving cell being above a threshold and / or better than the current serving cell of the active layer by a predetermined threshold, may cause the WTRU to report measurements of the deactivated layer serving site to the network (e.g., the active serving site).An active serving site can use the measurement information to instruct the WTRU to activate one or more deactivated layers. For example, the primary serving site can send MAC signaling (e.g., MAC CE) to the WTRU indicating that pre-configured deactivated secondary layers should be activated. The MAC signaling can indicate that one or more layers (e.g., currently activated primary layers) should be deactivated upon activation of other layers, and / or the WTRU can implicitly decide to deactivate active layers based on the activation of other layers.

[0283] Furthermore, rather than, or in addition to, layer activation and deactivation being triggered by explicit signaling from the network, one or more pre-configured layers may be autonomously activated and / or deactivated by the WTRU. For example, rather than, or in addition to, sending measurement reports of deactivated serving sites to the network, the WTRU may locally evaluate measurements to determine whether a deactivated layer should be activated and / or whether an activated layer should be deactivated. The WTRU may use similar criteria as the network to evaluate whether a layer should be activated or deactivated, and triggers for the WTRU's autonomous activation and / or deactivation may be similar to the triggers described for causing the WTRU to perform measurements or deactivated layers and / or send measurement reports to the network (e.g., active serving site). Thus, for purposes of explanation and brevity, triggers for causing the WTRU to autonomously activate and / or deactivate layers may be described in combination with triggers for the WTRU to perform measurements and / or send measurement reports. However, as can be appreciated, various combinations of such triggers can be implemented, such that a first set of triggers can cause the WTRU to perform measurements, a second set of triggers can cause the WTRU to report measurements, and a third set of triggers can cause the WTRU to autonomously activate and / or deactivate layers. The first, second, and / or third sets of triggers can each be different, partially overlapping, and / or fully overlapping (e.g., the trigger for performing measurements can be the same as the trigger for measurement reporting). Various combinations of triggers are described together herein and are within the contemplated scope of the present disclosure.

[0284] In an example, a WTRU may be configured to activate or use more than one MAC instance (or layer) at a given time. For example, a first MAC instance may be active and configured for transmission / reception over a primary layer, and a second MAC instance may be active and configured for transmission / reception over a secondary layer. Different MAC instances may be active simultaneously at some points in time, while a single MAC instance may be active at other points in time.

[0285] The WTRU may perform layer deactivation. For example, the WTRU may receive control signaling to deactivate a given cell of a given layer (e.g., a primary cell (PCell) in a layer, a secondary cell (SCell) in a layer, etc.), multiple cells of a given layer, and / or all cells of a given layer. The WTRU may be configured to perform carrier aggregation on different layers, for example, to enable the WTRU to transmit and / or receive data from multiple cells associated with a layer. However, unlike layered transmissions using multiple data paths, carrier aggregation may be characterized in that each of the transmissions transmitted from the aggregated cells / carriers may be scheduled by the same entity or may be scheduled by independent entities in a coordinated manner (e.g., there may be a low-latency communication interface between the scheduling entities). Due to transmissions over different layers or data paths, the independent scheduling entities may lack tight coordination and / or communicate over communication links whose latency makes it difficult and / or impractical to coordinate the scheduling of WTRUs across layers. A PCell may refer to a layer's primary cell, which may be the cell through which carrier aggregation for the layer is configured or established. Each layer may additionally utilize one or more SCells, which may be carrier aggregation cells / carriers associated with the layer. The PCell may be used to schedule transmissions on the SCells, and / or transmissions may be scheduled directly via the SCells. The WTRU may be configured to autonomously deactivate the PCell and / or SCell, for example, upon expiration of a timer after a period of scheduling inactivity for the cell in question.

[0286] Forming the RRC connection may establish one or more signaling radio bearers (SRBs) between the WTRU and the network; for example, each of the established SRBs may be assigned to one or more of the first or second radio interfaces. Control data received by the WTRU may be included in one or more RRC protocol data units (PDUs). The RRC PDUs may be associated with one of the one or more SRBs. In an example, an RRC PDU may be received over either the first or second radio interface regardless of the associated SRB. In another example, the RRC PDU may be received over an assigned radio interface associated with the corresponding SRB. The RRC connection may be controlled by the network. The network may include a radio cloud network controller (RCNC) that controls the RRC connection. The WTRU may send an indication to the network indicating that the WTRU supports multi-scheduling operations.

[0287] In an example, a WTRU may be configured to operate using one or more SRBs associated with an MeNB or cells served by an MeNB (e.g., which may be referred to as macro (SRB)), one or more SRBs associated with an SCeNB or cells served by an SCeNB (e.g., which may be referred to as sc(SRB)), one or more data radio bearers (DRBs) associated with an MeNB or cells served by an MeNB (e.g., which may be referred to as macro (DRB)), and one or more DRBs associated with an SCeNB or cells served by an SCeNB (e.g., which may be referred to as sc(DRB)). In an example, the WTRU may establish a macro (SRB) with the MeNB, and establish an sc(SRB) and an sc(DRB) with the SCeNB.

[0288] For example, a MAC instance in the WTRU may be configured and active for the secondary layer and may be used for both user plane (e.g., sc(DRB)) and control plane (e.g., sc(SRB)) data. In some situations, transmission and / or reception may frequently be performed using the SCeNB, so the secondary layer may be considered the primary layer for transmitting / receiving data and control plane data and / or performing physical layer procedures. Even when the majority of data transmissions are transmitted via the SCeNB, the WTRU may still have configured a MAC instance for the primary layer that may be used, for example, for control plane data (e.g., for traffic that may be transmitted via either layer, for traffic that may be transmitted only through the primary layer, etc.). In some situations, the MAC instance for the primary layer may be active at the same time as the MAC instance for the secondary layer, which may be referred to as a dual MAC connection. Because macros (SRBs) may be utilized for transmission of relatively high-importance control information, in some examples, the WTRU may be configured to refrain from deactivating the PCell of the primary layer (and / or the entire primary layer) to ensure that the macro (SRB) data is delivered in a timely manner. However, in other examples, because such control information may be deliverable over a secondary layer, during periods of inactivity, the primary layer may be deactivated and / or may operate according to IDLE mode principles to conserve power and network resources. The WTRU may be configured to periodically or intermittently monitor control channels (e.g., PDCCH for random access channel (RACH) commands, paging channel, etc.) when the secondary layer is active and / or even when the primary layer is deactivated.

[0289] In examples, the WTRU may be configured to exchange control plane data using the primary layer (e.g., via macro (SRB)) and user plane data via the secondary layer (e.g., via sc (DRB)). Such a situation may be, for example, when the WTRU is offloaded from the MeNB to the SCeNB for data forwarding. The MAC instance configured and active for the primary layer may remain active and may be used for transmission of control information. The MAC instance configured and active for the secondary layer may be used for forwarding user plane data. Because macro (SRB) may be utilized for transmission of relatively high-importance control information, in some examples, the WTRU may be configured to refrain from deactivating the PCell of the primary layer (and / or the entire primary layer) to ensure that the macro (SRB) data is delivered in a timely manner. However, in other examples, because such control information may be deliverable via the secondary layer, during periods of inactivity the primary layer may be deactivated and / or may operate according to IDLE mode principles to conserve power and network resources. The WTRU may be configured to periodically or intermittently monitor a control channel (e.g., PDCCH for random access channel (RACH) commands, paging channel, etc.) when the secondary layer is active and / or even when the primary layer is deactivated.

[0290] Regardless of how data and control information is transferred to the WTRU (e.g., via one or more of the primary and / or secondary layers), the WTRU may be configured to maintain or store configuration information for each of the layers / MAC instances even after deactivating the MAC instance. For example, the WTRU may be configured to store the configuration for the primary layer even after deactivation of the primary layer. In this way, the WTRU may be able to quickly return to the macro layer even if it is deactivated. Quickly returning to the macro layer can enable fast recovery from radio link failures (RLFs) in the secondary layer and can facilitate avoidance of radio link failures in handover situations between small cells.

[0291] RRC signaling may be utilized to configure the operation of the primary layer and / or the secondary layer. The layer configuration may include one or more of PHY configuration information, MAC configuration information, RLC configuration information, PDCP configuration information, radio bearer (RB) configuration information, cell radio network temporary identifier (C-RNTI) information, etc. The configuration information provided for the primary layer may include a complete set of configuration information (e.g., PHY configuration information, MAC configuration information, RLC configuration information, PDCP configuration information, RB configuration information, C-RNTI information, etc.) that enables the WTRU to perform transmission and reception procedures in the primary layer. In an example, the WTRU may also be configured with a subset of configuration information for transmission and reception in the secondary layer. For example, the WTRU may be configured with MAC configuration information, RLC configuration information, PDCP configuration information, and a subset of PHY layer resource / configuration information to be used in the secondary layer. Other configuration information, such as the remaining PHY layer resource / configuration information (e.g., PUCCH configuration information, etc.), may be included in a reconfiguration message sent to activate the secondary layer. In this way, the WTRU may be pre-configured with most of the configuration information for using the secondary layer, and some configuration information may be provided upon activation (e.g., to ensure that the configuration does not conflict with the current configuration utilized in the primary layer).

[0292] The configuration of the primary layer may include complete configuration information associated with the operation of both SRBs and DRBs on that layer, or may include a subset of the configurations (e.g., only SRBs), which may enable the WTRU to perform one or more of receiving data associated with SRBs, receiving RRC reconfiguration messages, performing handovers, and / or performing reconfiguration procedures.

[0293] The WTRU may be configured to implicitly decide to activate the secondary layer upon receiving the configuration for the secondary layer (and / or remaining configuration information, such as PHY information, that was not provided as part of the initial pre-configuration) and may begin using the secondary layer as the active layer. The WTRU may store the configuration for the primary layer upon activation of the secondary layer so that the primary layer may be reactivated at a later time. In another example, the WTRU may implicitly assume that the primary layer is the active layer (and store the context of the inactive layer in memory for later use) until the network explicitly indicates that another layer is the active layer. The context stored in the WTRU for the inactive layer may be considered valid until explicitly deleted by the network. The configuration information may be considered valid for a defined period of time. The configuration information for the secondary layer may be deleted upon changing to a different secondary layer and / or upon changing to the primary layer.

[0294] When operating using a secondary layer, the WTRU stores the context / configuration information of the primary layer and may consider the primary layer to be deactivated and / or in idle mode. In an example, rather than completely deactivating the primary layer, the WTRU may have a separate discontinuous reception (DRX) configuration to keep the context of the primary layer active. During the DRX period, the WTRU may periodically check (e.g., read the PDCCH) for a cell associated with the primary layer for transmission. The WTRU may monitor a deactivated layer during the active portion of a DRX cycle, even if it is actively monitoring / utilizing a different layer. The WTRU may also be provided with an explicit indication as to which layer is initially active when receiving RRC configuration information. Thus, the RRC connection reconfiguration information may include configuration information for multiple layers and may further indicate which of the layers is initially active. The WTRU may then store the configuration information for the inactive layers for later use while performing reception and transmission procedures using the configuration of the active layer.

[0295] One or more triggers may cause the WTRU to activate a primary layer, activate an inactive layer, and / or report quality information for one or more layers. For example, while the WTRU is operating with a secondary layer as the active layer, the WTRU may be triggered to use (or return to) the primary layer (e.g., for user plane and / or control plane transmission and / or reception) to receive an RRC reconfiguration message. For example, the RRC reconfiguration message may indicate that the WTRU should perform a handover, may be designed to help the WTRU avoid radio link failures, may facilitate performing a fast re-establishment to the primary layer, and / or the like. The switch to the primary layer may be temporary (e.g., the WTRU may return after receiving control plane data), and the WTRU may be configured to utilize the PCell of the primary layer to receive control plane data.

[0296] In an example, the WTRU may receive explicit dynamic signaling from the network that triggers the WTRU to switch layers, activate a given layer, and / or deactivate a given layer. For example, a PDCCH command and / or a MAC Control PDU (e.g., a MAC Control Element (CE)) may be used to indicate to the WTRU to switch layers, activate a layer, and / or deactivate a layer. As an example, the WTRU may receive a PDCCH command or a MAC Control PDU indicating that the WTRU should deactivate a currently active MAC instance (e.g., layer) and / or activate a different MAC instance / layer. The explicit activation indication may explicitly indicate which layer should be activated, or the WTRU may implicitly determine which layer should be activated.

[0297] Various implicit criteria may be used by the WTRU to decide to activate an inactive / idle layer (e.g., a primary layer), switch to an inactive / idle layer (e.g., a primary layer), and / or deactivate a given layer. For example, the WTRU may begin monitoring a previously inactive layer (e.g., begin reading or monitoring the PDCCH of the inactive layer using a stored C-RNTI for the inactive layer) based on detecting various criteria. In an example, the WTRU may start some processing / monitoring of the inactive layer based on detecting an implicit trigger, and the WTRU may be configured to refrain from switching to or fully activating the layer until an explicit instruction to do so is received from the network (e.g., via a PDCCH command or MAC control PDU).

[0298] For example, the downlink quality as observed by the WTRU may be used as an implicit criterion for deciding to start monitoring (e.g., partially monitor) inactive layers and / or report an indication of the downlink quality of the inactive layers to the network. Although the following criteria may be described to trigger the WTRU to send measurement reports for inactive layers, such triggers may also be used to trigger the WTRU to start monitoring inactive layers (e.g., monitoring the PDCCH of a cell in the inactive layers). In addition, such criteria may also be applicable to trigger the WTRU to activate and / or deactivate layers.

[0299] For example, the WTRU may monitor the downlink quality of one or more layers for which it has received configuration information but which are not currently active. There may be one or more triggers that cause the WTRU to perform measurements on cells associated with inactive layers (e.g., such triggers may also cause the WTRU to start monitoring cells for transmissions, activate and / or deactivate various cells, and / or the like). For example, the WTRU may be configured to perform measurements on cells associated with inactive layers any time a measurement report is triggered (e.g., for another layer / cell or for an inactive layer / cell). In an example, the WTRU may be configured to perform measurements on cells associated with inactive layers based on the occurrence of a defined event (e.g., a handover, an event indicated in the configuration, etc.).

[0300] The WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) when a measurement report is triggered on an active layer (e.g., a secondary layer) and the quality of the active layer falls below a predetermined threshold (e.g., indicating that the WTRU has lost coverage on the active layer). For example, the WTRU may determine that the quality of the active layer is deteriorating and / or that measurements should be performed on an inactive layer based on one or more of: a reference signal received power (RSRP) measurement of the active layer falling below a threshold; a reference signal received quality (RSRQ) measurement of the active layer falling below a threshold; a determined channel quality indicator (CQI) of a cell associated with the active layer falling below a threshold; a determined CQI for a serving cell of the active layer (e.g., of the serving cell for the SCeNB) falling below a threshold; a determined CQI for a non-serving cell of the active layer (e.g., some other cell associated with the SCeNB) rising above a threshold; and / or the WTRU starting a T301 timer (e.g., upon detecting deteriorating radio link conditions).

[0301] In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on a measurement report indicating that the best cell (e.g., the cell with the highest quality) on a currently active layer (e.g., a secondary layer) has changed. The WTRU may be configured to perform measurements on a cell associated with an inactive layer based on a measurement report indicating that the best cell (e.g., the cell with the highest quality) on a primary layer has changed. In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on a measurement report being triggered or transmitted and the active MAC instance being out of synchronization (e.g., upon the start of T310 and / or upon the start of T311). The WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on failure to receive a handover command within a predetermined period while the quality of the active layer is below a threshold.

[0302] In an example, a WTRU may be configured to perform measurements on a cell associated with a non-active layer (e.g., a primary layer) based on detecting an out-of-sync condition on the active layer and / or based on detecting a predetermined number of out-of-sync conditions on the active layer. The WTRU may be configured to perform measurements on a cell associated with a non-active layer (e.g., a primary layer) based on detecting an out-of-sync condition on the active layer for a period configured by the network and / or based on detecting an out-of-sync condition a given number of times within a predetermined window. In an example, a WTRU may be configured to perform measurements on a cell associated with a non-active layer (e.g., a primary layer) based on detecting one or more DL RLFs and / or UL RLFs on the active layer. In an example, a WTRU may be configured to perform measurements on a cell associated with a non-active layer (e.g., a primary layer) based on the WTRU losing timing alignment with the currently active layer (e.g., expiration of a timing alignment timer (TAT), e.g., when multiple timing advance groups are configured for the layer in question, the TAT of the PCell of the active layer expires). In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on detecting a scheduling request (SR) failure. For example, the WTRU may attempt to re-establish a connection on an inactive layer (e.g., a primary layer) before attempting to perform an RRC connection re-establishment procedure on a currently active layer. In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on the quality of the inactive layer being above a configured time period threshold.In an example, the WTRU may be configured to perform measurements on cells associated with a non-active layer based on the quality of the serving cell of the primary layer or the quality of the serving cell of the active layer being below a threshold and no other cell of the layer being above a threshold (e.g., the active layer is losing coverage).

[0303] In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., the primary layer) based on receiving a deactivation command for the active layer (e.g., this may be an implicit activation of the primary layer). In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., the primary layer) based on the WTRU receiving an RRC reconfiguration message (e.g., this message may deconfigure or deactivate the active layer). In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., the primary layer) based on an estimated rate of change of channel quality on the active layer (e.g., the secondary layer) being higher (and / or becoming higher) than a configured time period threshold. For example, the rate of change of the channel may be estimated by measuring a reference signal transmitted from the active (e.g., secondary) layer. Other measures of the rate of change of the channel may be based on the absolute value of the Doppler spread of the channel and / or the Doppler shift of the channel. The estimated rate of change of the channel may be proportional to (and based on) the inverse of the coherence time of the channel. In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on an estimated rate of change of attenuation-averaged path loss on a currently active (e.g., secondary) layer being higher (or becoming higher) than a configured time period threshold. For example, the rate of change of attenuation-averaged path loss may be estimated by subtracting the time-averaged received power level of a reference signal for a first time frame from that of a previous time frame. In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on receiving an indication from the RLC that a maximum number of retransmissions has been reached. In an example, a WTRU may be configured to perform measurements on a cell associated with an inactive layer (e.g., a primary layer) based on receiving an indication of a random access problem from the MAC.

[0304] The WTRU may begin monitoring the PDCCH associated with the primary layer or the inactive layer using the stored C-RNTI based on detecting one or more of the conditions used to trigger measurements of the inactive layer. However, in examples, the WTRU may refrain from switching to the inactive layer and / or performing a full activation of the inactive layer unless an explicit indication is received (e.g., via a PDCCH command and / or MAC Control PDU) indicating that switching or activation should be performed.

[0305] The WTRU may be configured with a measurement configuration used to determine parameters to use when performing measurements. For example, the measurement configuration may be common for all cells in a layer, common for all cells in a cluster (e.g., if clusters are utilized), configured separately for serving and non-serving cells per layer, and / or configured separately for each cell in a given layer. For example, the WTRU may be configured with corresponding zero-power channel state information reference signals (CSI-RS) for different cells / layers for CQI measurements. The WTRU may be configured with an averaging period so that measurements are performed and filtered over the averaging period. The WTRU may be configured with the identity of the node (e.g., MeNB, SCeNB, etc.) to which reports should be sent. The WTRU may be configured with a periodicity to use for reporting measurements and / or with one or more triggers for sending aperiodic reports (e.g., channel quality thresholds for triggering reports).

[0306] Layer-specific measurement configurations may be provided to the WTRU by the network. For example, the received configuration or configuration parameters may explicitly indicate to which layer the configuration is applicable. In an example, the measurement configuration may indicate cluster IDs to which the measurement configuration is applicable. The measurement configuration may include a list of cells for which the WTRU can perform measurement reporting in a given layer and / or which the WTRU can monitor. The measurement configuration may indicate a measurement periodicity to be used to measure cells in a layer based on activation and / or deactivation of another layer. For example, activation of a cell in a first layer may trigger more frequent measurements (e.g., a faster measurement periodicity) for nearby cells. The measurement configuration may include a list of whitelisted cells that are nearby cells for a configured small cell. In an example, when a small cell is activated (e.g., the small cell layer is activated), the WTRU may stop using the measurement periodicity measCycleSCell (e.g., the measurement periodicity normally used for SCell in a deactivated state) and may use a different (e.g., faster) measurement periodicity. In an example, activation of the first cell may trigger a scale down of measCycleSCell to a smaller value.

[0307] A WTRU may be configured to report measurement information for each cell, a subset of cells, and / or one or more clusters of cells that it is currently monitoring. For example, which cells to measure may be determined based on the cluster identity of the cell that triggered the report and / or the cell for which the measurement is being reported. For example, the WTRU may be configured with a blacklist / whitelist to determine which events trigger a measurement report for cells in a given cluster. For example, a measurement report may be triggered for cells in a first cluster if the triggering is based on criteria associated with cells of a different cluster (e.g., when measuring for inter-cluster mobility). In an example, the WTRU may be configured with the identity of the cluster such that if measurement is triggered for any cell in the cluster, the WTRU measures each of the cells in the cluster.

[0308] The WTRU may periodically and / or aperiodically (e.g., upon request of the network) send quality measurement reports based on detecting a trigger to measure inactive cells. The reports may be transmitted to a network node in the primary and / or secondary layer. For example, if the WTRU detects a trigger that may be used to trigger measurements of inactive layers / cells, the WTRU may transmit a measurement report to the network, and the measurement report may indicate what triggered the report. The measurement report may be transmitted periodically by the WTRU, for example, by configuring and setting a timer to be used to trigger transmission of periodic reports. The network may transmit a request for a measurement report. An aperiodic measurement request may be transmitted to the WTRU, for example, using one or more of a PDCCH command, a MAC control PDU, and / or an RRC measurement request. The aperiodic request may be received from a primary layer (e.g., associated with the MeNB) and / or a secondary layer (e.g., associated with the SCeNB). For example, the MeNB may request measurement reports for cells belonging to any layer (e.g., the primary layer and / or the secondary layer). As an example, the SCeNB may send a measurement request indicating that the WTRU should send a measurement report to the MeNB (e.g., via RRC). The SCeNB may send the request based on detecting a degradation in radio link quality (e.g., based on UL RL quality, a CQI report received for a secondary layer falling below a threshold, etc.). The request for the measurement report may be sent by using PHY, MAC, and / or RRC signaling. In an example, the request may be sent by the SCeNB, for example, by using MAC CE.

[0309] The WTRU may provide measurements and / or indications of cell / layer quality using one or more of an RRC message, a MAC control message, and / or a Layer 1 (PHY) message. For example, selected measurements may be sent through an RRC measurement report and / or as part of an RRC establishment / re-establishment request. A MAC control message (e.g., a MAC Control Element) may be used to transmit the measurements. For example, a MAC CE may be used to transmit measurement information for each reported cell along with the cell ID associated with the measurement (e.g., the measurement may be associated with the cell using SCellIndex). If Layer 1 (PHY) reporting is utilized, the report may be transmitted via the PUCCH.

[0310] For each reported layer / cell, the WTRU may send one or more of the RSRPs of all cells being reported, the RSRPs of cells on the reporting whitelist, and / or the RSRPs of cells in the defined cluster for which reporting is performed. In an example, for each reported layer / cell, the WTRU may send one or more of the RSRQs of all cells being reported, the RSRQs of cells on the reporting whitelist, and / or the RSRQs of cells in the defined cluster for which reporting is performed. The report may include one or more of the measured CQI value for the cell, the identity of the cell that triggered the report, a list of DRBs served by the layer experiencing the failure, and / or an in-sync / out-of-sync indication.

[0311] The WTRU may be configured and / or requested by the network to send measurement reports in various manners. For example, if the WTRU is configured to send a report over a primary layer and there is a failure on the primary layer, the report may be sent over another active layer. For example, the report may be sent to an active small cell, which may forward it to the MeNB using a backhaul link. In an example, the WTRU may be c...

Claims

1. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: establishing a radio resource control connection (RRC connection), the RRC connection being common between at least a first data path associated with a first group of one or more cells and a second data path associated with a second group of one or more cells, and a first signaling radio bearer (first SRB) being used to communicate RRC connection information over the first data path; receiving an RRC reconfiguration message including information indicating a configuration associated with a second SRB; determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied, wherein the at least a portion of the configuration associated with the second SRB cannot be successfully applied due to a security failure associated with the second SRB; reverting to a previous configuration associated with the SRB based on determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied; A method for providing the above.

2. transmitting an RRC message over the first SRB based on determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied, the RRC message including information indicating a cause of failure, the cause of failure being the security failure associated with the second SRB. The method of claim 1 , comprising:

3. sending a message over the first SRB indicating the security failure. The method of claim 1 , comprising:

4. determining said security failure using at least an integrity key; The method of claim 1 , comprising:

5. Initiating an RRC re-establishment procedure or an RRC failure notification procedure. The method of claim 1 further comprising:

6. 2. The method of claim 1, wherein the first SRB includes one of SRB0 and SRB1, and the second SRB includes SRB3.

7. The method of claim 1 , wherein a single RRC entity in the WTRU is configured to process each of the first SRB and the second SRB.

8. 2. The method of claim 1, wherein the first data path is used to communicate with a first type of radio access node associated with a first cell type, and the second data path is used to communicate with a second type of radio access node associated with a second cell type.

9. 2. The method of claim 1, wherein the step of receiving an RRC reconfiguration message including information indicating a configuration associated with the second SRB includes receiving the RRC reconfiguration message over the first SRB or the second SRB.

10. The method of any preceding claim, wherein the security failure comprises an integrity verification failure.

11. 1. A wireless transmit / receive unit (WTRU) comprising a circuit including a transmitter, a receiver, a processor, and a memory, the circuit comprising: establishing a radio resource control connection (RRC connection), the RRC connection being common between at least a first data path associated with a first group of one or more cells and a second data path associated with a second group of one or more cells, and a first signaling radio bearer (first SRB) being used to communicate RRC connection information via the first data path; receiving an RRC reconfiguration message including information indicating a configuration associated with the second SRB; determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied, wherein the at least a portion of the configuration associated with the second SRB cannot be successfully applied due to a security failure associated with the second SRB; and returning to a previous configuration associated with the SRB based on determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied. A WTRU configured as follows:

12. The circuit comprises: transmitting an RRC message over the first SRB based on determining that at least a portion of the configuration associated with the second SRB cannot be successfully applied, the RRC message including information indicating a cause of failure, the cause of failure being the security failure associated with the second SRB; The WTRU of claim 11 configured to:

13. The WTRU of claim 11 , wherein the circuitry is configured to transmit a message indicating the security failure over the first SRB.

14. The WTRU of claim 11 , wherein the circuitry is configured to determine the security failure using at least an integrity key.

15. The WTRU of claim 11 , wherein the circuitry is configured to initiate an RRC re-establishment procedure or an RRC failure notification procedure.

16. The WTRU of claim 11 , wherein the first SRB comprises one of SRB0 and SRB1, and the second SRB comprises SRB3.

17. The WTRU of claim 11 , wherein a single RRC entity in the WTRU is configured to process each of the first SRB and the second SRB.

18. 12. The WTRU of claim 11, wherein the first data path is used to communicate with a first type of radio access node associated with a first cell type, and the second data path is used to communicate with a second type of radio access node associated with a second cell type.

19. 12. The WTRU of claim 11, wherein the circuitry configured to receive an RRC reconfiguration message including information indicating a configuration associated with the second SRB comprises the circuitry configured to receive the RRC reconfiguration message via the first SRB or the second SRB.

20. The WTRU of any of claims 11 to 19, wherein the security failure comprises an integrity verification failure.

Images