Data division among plural sites

Abstract

To divide data in a wireless communication network.SOLUTION: In order to improve bandwidth when UE is at a cell edge, data may be divided for so that the data are transmitted to a user apparatus by using a plurality of base stations, or in order to improve a handover, the data may be divided so that the data are transmitted to the plurality of base stations by the user apparatus. Data division may be executed in a packet data convergence protocol layer, a radio link control layer, or a media access control layer in the user apparatus or each base station. In order to reduce an X2 interface load or X2 interface delay carrier aggregation, the data may also be divided in place in a network node such as a serving gateway.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present invention relates to the operation of user equipment in 3GPP.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 61 / 303,769, filed February 12, 2010, and U.S. Provisional Patent Application No. 61 / 304,377, filed February 12, 2010, both of which are incorporated herein by reference. [Background technology]

[0003] To support higher data rates and spectral efficiency, the 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) system has been introduced in 3GPP R8 (Release 8), which may be referred to herein as LTE R8 or R8-LTE. In LTE, uplink transmission is performed using SC-FDMA (Single Carrier Frequency Division Multiple Access). In particular, the SC-FDMA used in the LTE uplink is based on DFT-S-OFDM (Discrete Fourier Transform Spread Orthogonal Frequency Division Multiplexing) technology. As used herein, the terms SC-FDMA and DFT-S-OFDM are used interchangeably.

[0004] In LTE, a WTRU (wireless transmit / receive unit), also called a UE (user equipment), transmits on the uplink using a limited contiguous set of assigned subcarriers in an FDMA (frequency division multiple access) configuration. For example, if the overall OFDM (orthogonal frequency division multiplexing) signal bandwidth or OFDM system bandwidth in the uplink consists of useful subcarriers numbered from 1 to 100, a given first WTRU may be assigned to transmit on subcarriers 1-12, a second WTRU may be assigned to transmit on subcarriers 13-24, and so on. Different WTRUs may each transmit into a subset of the available transmission bandwidth, while an eNodeB (evolved Node-B) serving these WTRUs may receive a composite uplink signal over the entire transmission bandwidth.

[0005] LTE Advanced (which includes LTE Release 10 (R10), also referred to herein as LTE-A, LTE R10, or R10-LTE, and may further include future releases such as Release 11) is an extension of the LTE standard that provides a fully compliant 4G upgrade path for LTE and 3G networks. In LTE-A, carrier aggregation is supported and, unlike in LTE, multiple carriers can be assigned to the uplink, downlink, or both the uplink and downlink. Summary of the Invention [Problem to be solved by the invention]

[0006] In both LTE and LTE-A, UEs, and therefore users, may experience service degradation at cell edges. Throughput, quality of service (QoS), and other factors may be affected by interference from other cells when a UE is operated at the edge of a cell. What is needed in the art is a method and system that leverages the capabilities of LTE-A to address issues related to UE operation at the edge of a cell. [Means for solving the problem]

[0007] A method and system for splitting data in a wireless communication network is disclosed. Data can be split to use multiple base stations for transmission to a user equipment or can be split by the user equipment for transmission to multiple base stations. In an embodiment, data splitting can be performed at the Packet Data Convergence Protocol (PDCP) layer. In an embodiment, data can be split at the Radio Link Control (RLC) layer. In an embodiment, data can be split at the Medium Access Control (MAC) layer. In each of these embodiments, data can be split on the user equipment and / or on the base station. In an embodiment, data can be split at the user plane instead, such as at a serving gateway. The above and further aspects of the present disclosure are described in more detail below.

[0008] The following detailed description of the disclosed embodiments will be better understood when read in conjunction with the accompanying drawings, in which: For purposes of illustration, there are shown exemplary embodiments, but the subject matter is not limited to the particular elements or devices disclosed. [Brief description of the drawings]

[0009] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more embodiments disclosed may be implemented. [Figure 1B] 1B is a system diagram illustrating an example WTRU (wireless transmit / receive unit) that may be used within the communications system illustrated in FIG. 1A. [Figure 1C] A system diagram illustrating an example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A. [Diagram 2] FIG. 1 illustrates a non-limiting example network and component carrier configuration. [Diagram 3] FIG. 2 illustrates another non-limiting exemplary network and component carrier configuration. [Figure 4] FIG. 2 illustrates a non-limiting example downlink data flow and system configuration. [Diagram 5] FIG. 2 illustrates a non-limiting example uplink data flow and system configuration. [Figure 6] FIG. 2 illustrates a non-limiting exemplary method for splitting data. [Figure 7] FIG. 2 illustrates a non-limiting example uplink data flow and system configuration. [Figure 8] FIG. 2 illustrates a non-limiting exemplary method for splitting data. [Figure 9] FIG. 2 illustrates a non-limiting example downlink data flow and system configuration. [Figure 10] FIG. 2 illustrates a non-limiting example downlink data flow and system configuration. [Figure 11] FIG. 2 illustrates a non-limiting example uplink data flow and system configuration. [Figure 12] FIG. 2 illustrates a non-limiting example downlink data flow and system configuration. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] 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 sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), FDMA (Frequency Division Multiple Access), OFDMA (Orthogonal FDMA), SC-FDMA (Single Carrier FDMA), etc.

[0011] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be recognized that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the 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 UEs (user equipment), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, PDAs (personal digital assistants), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and the like.

[0012] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the core network 106, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base station transceiver station (BTS), a Node-B, an eNodeB, a Home NodeB, a Home eNodeB, a site controller, an AP (Access Point), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0013] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The 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 for each sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

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

[0015] More specifically, as previously mentioned, the communication system 100 may be a multiple access system and may further use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as UTRA (Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access), which may establish the air interface 116 using WCDMA (Wideband CDMA). WCDMA may include communication protocols such as HSPA (High Speed ​​Packet Access) and / or HSPA+ (Evolved HSPA). HSPA may include HSDPA (High Speed ​​Downlink Packet Access) and / or HSUPA (High Speed ​​Uplink Packet Access).

[0016] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as E-UTRA (Evolved UMTS Terrestrial Radio Access), which may establish the air interface 116 using LTE (Long Term Evolution) and / or LTE-A (LTE Advanced).

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

[0018] The base station 114b of FIG. 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity within a localized area, such as an office, a home, a vehicle, a campus, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. As such, the base station 114 b may not be required to access the Internet 110 via the core network 106 .

[0019] The RAN 104 may be in communication with a core network 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or core network 106 may be in direct or indirect communication with other RANs using the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) that uses GSM radio technology.

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

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

[0022] 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 GPS (Global Positioning System) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0023] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be incorporated together in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or 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.

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

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

[0027] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., an LCD (liquid crystal display) display unit or an OLED (organic light emitting diode) display unit) and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, 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 a RAM (random access memory), a ROM (read only memory), a hard disk, or any other type of memory storage device. The removable memory 132 may include a SIM (Subscriber Identity Module) card, a memory stick, a SD (Secure Digital) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory located physically remote from the WTRU 102, such as a server or home computer (not shown).

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

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

[0030] The processor 118 can be further 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 telephone 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.

[0031] 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As mentioned 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 106.

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

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

[0034] 1C may include a Mobility Management Gateway (MME) 142, a Serving Gateway 144, and a Packet Data Network (PDN) Gateway 146. Although each of the above elements is shown as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

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

[0039] The LTE DL (downlink) transmission scheme may be based on OFDMA air interface. For the LTE UL (uplink) direction, a SC (single carrier) transmission based on DFT-S-OFDMA (DFT spread OFDMA) may be used. In the R8 LTE DL direction, the UE may be assigned by the eNodeB to receive the UE's data at any position across the entire LTE transmission bandwidth (e.g., an OFDMA scheme may be used). The LTE DL may have an unused DC offset subcarrier in the center of the spectrum. In the R8 LTE UL direction, the R8 LTE system may be based on DTF-S-OFDMA transmission or SC-FDMA transmission.

[0040] In the DL direction, a UE can receive the UE's signal at any location across the frequency domain of the entire LTE transmission bandwidth, while in the UL direction, the UE can transmit on a limited (or only limited), but in some embodiments contiguous, set of assigned subcarriers in an FDMA (Frequency Division Multiple Access) configuration. This configuration may be referred to as SC (Single Carrier) FDMA. In some embodiments, if the overall OFDM signal bandwidth or OFDM system bandwidth in the UL consists of useful subcarriers numbered from 1 to 100, a given first UE can be assigned to transmit its signal on subcarriers 1-12, a given second UE can be assigned to transmit on subcarriers 13-24, and so on. An eNodeB can simultaneously receive composite UL signals from one or multiple UEs across the entire transmission bandwidth, but each UE can transmit (or only transmit) within a subset of the available transmission bandwidth. Thus, DFT-S-OFDM in the UL can be viewed as a conventional form of OFDM transmission with the additional constraint that the time-frequency resources assigned to a UE must consist of a set of contiguous subcarriers in frequency. In the UL, there may be no DC subcarrier at all. In one mode of operation, frequency hopping can be applied to the UL transmission by the UE.

[0041] LTE-A can support the CA (Carrier Aggregation) feature and the flexible bandwidth configuration feature. This can allow the DL and UL transmission bandwidth to exceed 20 MHz (e.g., as in R8 LTE). For example, transmission bandwidths from 40 MHz to 100 MHz can be supported. In LTE R10, CCs (Component Carriers) can enable this spectrum aggregation feature. In an embodiment, an aggregated spectrum of up to 100 MHz with a maximum bandwidth of 20 MHz for each CC can be configured, thus at least 5 CCs. In LTE-A, different CCs can have different coverage.

[0042] In some embodiments utilizing multiple CCs, different cells may use different sets of CCs to prevent or mitigate multi-carrier interference. Such cells may have different ranges and may have effective frequency reuse patterns greater than one, as shown in FIG.

[0043] Carrier aggregation using multiple CCs may concern UEs in RRC CONNECTED state. Idle UEs may access the network via a single UL and DL carrier pair (e.g., using FDD (Frequency Division Duplex)). In LTE-A embodiments, carrier aggregation at one serving eNodeB may be supported. This configuration may reduce the CA cell handover option to assignment of target candidate CCs after handover or before handover. Assigning target candidates after handover may increase user plane delay, therefore assignment before handover may result in better performance and may require additional X2 interface messages for measurement information exchange between target and source eNodeBs.

[0044] When a UE is located at a cell edge, it may be difficult to provide a uniform user experience (e.g., throughput, QoS, etc.) because the performance at the cell edge may be limited by interference from other cells. In an embodiment, CCs may be used to mitigate this cell edge problem if the UE is within a good coverage area of ​​a CC at a given time. In an embodiment, overlapping CCs for different cell edges may be created by coordinating neighboring eNodeBs (cell sites) to vary the transmit power of each CC for varying distances to the cell edge, as shown in FIG. 3.

[0045] 3, UE 350 may be at location 310 and may be communicating with eNodeB 361 via CC 320 (371a) and may be communicating with eNodeB 361 via CC 330 (372a). When UE 350 moves to a new location 311 where CC 330 may be used for eNodeB 362 but CC 320 remains within the cell boundary of eNodeB 361, UE 350 may still communicate with eNodeB 361 via CC 320 (371b), but now may communicate with eNodeB 362 via CC 330 (372b). This may allow UE 350 to remain near the cell center by handing over to different CCs at different locations while the network maintains a frequency reuse factor of unity. In this scenario, fully capable base stations, each capable of supporting the UE on all CCs (including base stations with and without associated RRHs (Radio Heads)), may be used if the UE is able to receive on a set of CCs, each of which may be transmitted from a different site.

[0046] It should be noted that although eNodeB 361 and eNodeB 362 are referred to as eNodeBs, these network elements may be any other type of device and / or network element capable of performing the functions described herein. For example, eNodeB 361 and / or eNodeB 362 may be a remote radio head (RRH), a sector antenna, any type of base station, or any combination of these or any other network elements. Any such device or network element may be configured to perform any of the functions described herein as being performed by a base station, eNodeB, gateway, node, or any other network element, and all such embodiments are contemplated as being within the scope of the present disclosure.

[0047] In some LTE R10 implementations, support for multiple CCs for carrier aggregation may be limited to one serving eNodeB. This may prevent a UE from maintaining a data connection using one CC for different eNodeBs. In a scenario where a UE moves to a location where there is coverage overlap for CCs on two different eNodeBs, as shown in Figure 3, a network RRM (Radio Resource Management) entity may determine whether to handover to another cell site instead of taking full advantage of the data throughput increase by using multiple CCs from different sites. To take full advantage of the available bandwidth on each CC, the corresponding data stream may be routed to and from the associated eNodeB.

[0048] Each data stream has associated resources (bandwidth and buffers) that are used to support transmission and reception. The aggregate bandwidth for each CC may be known by a network planner, but the instantaneous bandwidth available to a UE on a CC is typically a dynamic decision of the eNodeB scheduler. The decision of how much data to send to each CC may have a direct impact on the resource requirements of each cooperating site. In an embodiment, a cooperating eNodeB may, for example, feed back information about its available resources to a serving eNodeB, which may determine whether and how to perform data splitting, and may be configured to receive a complete (e.g., split ratio or unsplit) data flow.

[0049] In an embodiment, data throughput of SAE (Service Architecture Evolution) bearers from an eNodeB to a UE may be increased by coordinating splitting of data streams to multiple sites in a RAN (Radio Access Network). Data splitting may be performed at any layer of the RAN stack, including the PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control) layers, or in any combination, or using any of the means disclosed herein. Data splitting may also be performed in the user plane. Systems and methods for performing such data splitting are disclosed in more detail herein.

[0050] Uplink and downlink data may be split across multiple eNodeBs and other sites (e.g., RRHs) in the RAN. For DL ​​data splitting, the eNodeB may split the incoming data stream into N streams corresponding to the number of cooperating CCs. The data splitting may be based on bandwidth availability reported by the cooperating CCs, buffer status reported by the buffering entity, and / or data rates from bearer QoS requirements. The eNodeB may also support an iterative procedure to determine how the data should be split, such as a load-dependent mechanism. This mechanism may use an algorithm based on the instantaneous buffer status, another indication of the buffer status (e.g., average), and / or the bandwidth of existing entities on the peer eNodeB. The flow control mechanism may buffer data that has not yet been acknowledged to recover unrecoverable transmission errors on any of the cooperating CCs, and / or buffer data received from the data splitting entity and transmit the data based on bandwidth availability.

[0051] In DL data splitting, the eNodeB may also support the ability to dynamically add or remove cooperating CCs without tearing down the SAE bearers. The eNodeB may also support load monitoring of the transmission paths to provide periodic and / or event triggered measurement reports on the current buffer status and to provide periodic and / or event triggered measurement reports on bandwidth utilization.

[0052] In DL data splitting, the UE may buffer received data and may also perform reordering of data received from different links to ensure that the data is provided to higher layers in the order in which it was sent. This functionality may be used when layers above the entity generally do not have the capability to perform such reordering (e.g., do not have the capability to perform such reordering in the normal course of operation). The UE may also support in-order delivery and may configure the affected layers to set up data paths corresponding to data stream splitting.

[0053] In DL data splitting, the X2 interface (e.g., tunneling) may support several functions. The X2 AP (X2 Application Protocol) may provide configuration and control of the data splitting entities and may be responsible for providing measurement and / or bandwidth monitoring reports, as well as configuration setup, modification, and / or release of entities. The X2 Data Transport Protocol or X2 Data Tunneling Protocol may connect the data splitting entities between the serving eNodeB and the cooperating eNodeB to provide data transmission and / or reception between the connected eNodeBs and / or transfer data control messages (e.g., reset messages, buffer status, bandwidth monitoring reports, etc.) between the two connected entities. The X2 Data Transport Protocol or X2 Data Tunneling Protocol may also support flow control exchanges via the X2 AP or through in-band signaling via the tunneling protocol.

[0054] In UL data splitting, the UE may split the incoming data stream into N streams corresponding to the number of cooperating CCs. The data splitting may be based on the bandwidth availability scheduled by the cooperating CCs, the buffer status reported from the buffering entity, and / or the data rate from the bearer QoS requirements. The UE may support a load-dependent flow control mechanism using an algorithm based on the instantaneous or other indicative buffer status, and / or the UL bandwidth scheduled by the eNodeB. The flow control mechanism may buffer data that has not yet been acknowledged to recover unrecoverable transmission errors on any of the cooperating CCs, and / or buffer data received from the data splitting entity and transmit the data based on the bandwidth availability.

[0055] In UL data splitting, the UE may also support the configuration of dynamically adding or removing cooperating CCs without tearing down the SAE bearers. The UE may also support load monitoring of the transmission paths to provide periodic and / or event triggered measurement reports on the current buffer status to the data splitting entity and / or to provide periodic and / or event triggered measurement reports on the bandwidth utilization.

[0056] In UL data splitting, an eNodeB may be configured to schedule bandwidth to UEs (with or without cooperating eNodeB synchronization) and buffer received data, and also perform reordering of data received from different links to ensure that the data is provided to higher layers in the order in which it was sent. This reordering function may be used when layers above the entity generally do not have the capability to perform such reordering (e.g., do not have the capability to perform such reordering in the normal course of operation). The eNodeB may also support in-order delivery and to configure the affected layers to set up data paths corresponding to data stream splitting.

[0057] In UL data splitting, the X2 interface (e.g., tunneling) may support several functions: The X2 application protocol may provide configuration, control the data splitting entities, and may be responsible for sending measurement and / or bandwidth reports, and / or providing configuration for the setup, modification, and / or release of entities. The tunneling protocol may connect the data splitting entities between the serving and cooperating eNodeBs to provide the transmission of data between the connected eNodeBs and / or to transfer data control messages (e.g., reset messages, measurement reports, etc.) between the two connected entities.

[0058] In one embodiment, data segmentation may be performed at the PDCP layer. An interworking function (PDCP IWF) may be used in the source eNodeB to forward the compressed IP packets (PDCP PDUs) to the PDCP IWF in the cooperating eNodeB before forwarding to the RLC layer for transmission buffering. The PDCP IWF may provide support for multiple radio bearers per SAE bearer.

[0059] 4 illustrates an example DL data flow and system configuration that may be used in a data splitting embodiment that performs data splitting at the PDCP layer. A UE 401 may be in a location that allows the UE 401 to communicate with both an eNodeB 410 and an eNodeB 420. An IP packet 405 may be received at an eNodeB 410 and may have the UE 401 as a destination for the IP packet 405. The IP packet 405 may be transmitted to the eNodeB 410 via an SAE bearer 402, which may include radio bearers 403a and 403b. A PDCP IWF 450 may facilitate splitting the data between the eNodeB 410 and the eNodeB 420, in part, using an eNodeB-to-eNodeB tunnel 440.

[0060] IP header compression may be performed in the header compression modules 411a and 411b to reduce the number of bits that need to be transmitted over the radio interface. Robust header compression may be used in any mode (e.g., U-mode (Unidirectional mode), O-mode (Two-way Optimistic mode), and R-mode (Two-way Reliable mode)). O-mode and R-mode may utilize a feedback channel for error recovery. Since compression uses previous frame information, the header compression process performed by the header compression modules 411a and 411b may be performed before data segmentation with feedback process is performed in one entity (e.g., in only one entity).

[0061] Encryption and integrity protection of the transmitted data may be performed in encryption modules 412a and 412b. Although the eNodeB-to-eNodeB tunnel 440 transmits portions of PDCP PDUs as split data stream subflows to the cooperating eNodeBs 420, they may be transmitted after encryption to avoid having to signal and maintain multiple HFNs (hyperframe numbers) and PDCP SNs (sequence numbers).

[0062] The data may be split in the PDCP e-NodeB multiplexer 413, and the split data for the e-NodeB 420 may be sent to the e-NodeB 420 via the e-NodeB tunnel 440. Data to be sent from the e-NodeB 410 may be provided to the RLC buffers 414a and 414b, multiplexed at the MAC layer by the MAC multiplexer 415, modulated at the physical layer by the PHY modulation and coding module 417, coded, and finally sent to the UE 401 via the CC 471. Data to be sent from the e-NodeB 420 may be provided to the RLC buffers 424a and 424b, multiplexed at the MAC layer by the MAC multiplexer 425, modulated at the physical layer by the PHY modulation and coding module 427, coded, and finally sent to the UE 401 via the CC 472. The eNodeB 410 and the eNodeB 420 may each have a MAC scheduler 416 and 426 that receives channel status data 419 and 429 (e.g., downlink channel quality information) from the UE 401 and further receives data from the RLC buffer and coordinates the transmission of data using a MAC multiplexer and a PHY modulation and coding module.

[0063] There may be one PDCP entity per radio bearer configured for the mobile terminal. To support data segmentation, a scheduler (e.g. based on a simple round-robin distribution of received PDCP packets to active sites or some segmentation algorithm using buffer status feedback or transmission rate feedback from the destination eNodeB 420) may be used to forward PDCP PDUs (e.g. including a portion of IP packet 405) to another site (e.g. eNodeB 420) for transmission over another CC. This configuration results in two or more (in some embodiments depending on the number of sites transmitting together) data streams (e.g. PDCP / RLC / MAC) being set up per radio bearer (e.g. one per participating CC plus N for the UE, where N is the total number of participating CCs). A scheduler present on the PDCP / RLC interface may be responsible for scheduling data transfer to different sites including the main serving site and the cooperating sites for further processing in the RLC layer.

[0064] In the PDCP IWF 450, a flow mechanism may be used to avoid data loss when congested or limited PHY (physical layer) bandwidth in the cooperating CCs causes buffer overflow. The flow mechanism may be feedback via a tunneling protocol that provides data buffer status (e.g., RLC buffer occupancy) and / or instantaneous bandwidth information or some other indication of bandwidth for the cooperating CCs.

[0065] The corresponding UL data split in the PDCP layer shown in FIG. 5 utilizes the same module layout as in the DL case, but reverses the data path direction. Note that for any of the functions performed as shown in FIG. 4, the inverse function can be performed by the same module and / or entity in FIG. 5, or such inverse function can be performed by a different module or entity. For example, the MAC multiplexers in the eNodeBs 410 and 420 can perform the demultiplexing on the UL signal. Both the DL and UL can be configured with one PDCP entity per participating CC. In FIG. 5, the data merger can be performed in the eNodeB 410 by the merger entity of the PDCP inter-eNodeB multiplexer 413. In an embodiment, the physical layer HARQ ACK / NACK can be handled independently of the transmitting cell.

[0066] 5, data to be transmitted from the UE 401 may be provided by PDCP IWF data splitting (not shown) to RLC buffers 434a and 434b configured on the UE 401, multiplexed at the MAC layer by MAC multiplexer 435, modulated at the physical layer by PHY modulation-coding module 437, encoded and split, and finally transmitted to the eNodeB 410 via CC 473 and to the eNodeB 420 via CC 474. Again, the eNodeB 410 and the eNodeB 420 may have MAC schedulers 416 and 426, respectively, that receive channel status data 419 and 429 (e.g., uplink channel quality information) from the UE 401.

[0067] At the receiving side (UE 401 in FIG. 4 or eNodeB in FIG. 5), a data merger can be performed to re-merge the data splitting, and in embodiments where the connection is configured for "RLC-in-order delivery", a merger entity can perform this task instead of the RLC entity since separate RLC entities may be receiving partial PDCP data streams. The data merger can have access to a buffer that can be used to store out-of-order delivery due to different transmission path delays on the Iu (air interface). In FIG. 4, the data merger can be performed at the UE 401 by the merger entity 407. Data splitting at the PDCP layer can have a small impact on the established system architecture, requiring limited changes to PDCP. This configuration can also minimize configuration changes and allow independent PDCP PDU delivery from separate routes / sites (e.g., eNodeB, RRH, NodeB, etc.).

[0068] In implementations without data splitting (or with limited data splitting), seamless handover can be ensured by the RAN using data replication during preparation before or during HO. A data route (tunneling forwarding data streams) between source and target eNodeB can be established before the UE is commanded to HO. After successful HO, the source eNodeB can forward PDCP Packet Transmission Status (PDCP SN) to the target eNodeB to synchronize the transmission status so that no packets are lost.

[0069] In a data splitting embodiment, the corresponding HO procedure may be performed in several ways. Note that the HO command may be modified to handle multiple CCs. In an embodiment where the handover is performed between serving and / or cooperating CCs, a handover similar to a conventional handover may be performed. The CC cooperation configuration may need to be updated to maintain the cooperation structure, and furthermore, if the handover destination cannot support the required quality of service, the cooperation structure may need to be reorganized. Seamless data transmission may be ensured with PDCP SN synchronization. In an embodiment where the handover is performed between cooperating CCs, a subset of the conventional handover procedure may be performed, where tunneling may be established between the source and target cooperating eNodeBs. Data transfer may be handled by a new tunneling protocol or by reusing the existing GPRS tunneling protocol between the eNodeBs (in an embodiment, with some modifications). Further modifications may be performed to the handover preparation information (eg, X2 signaling) and handover commands (eg, over-the-air RRC peer messages) to indicate that the serving CC has not changed.

[0070] The X2 interface may support inter-eNodeB RESOURCE (e.g., cell capacity) STATUS REQUEST and inter-eNodeB RESOURCE UPDATE. Cell capacity may be given in terms of UL / DL GBR (guaranteed bit rate) / non-GBR / total PRB (physical resource block) usage percentage and UL / DL S1 TNL (transport network layer) load (e.g., low / medium / high / overloaded) or via a new IE that may indicate the number of PDCP PDUs that may be waiting in the RLC transmit buffer. For the purpose of estimating available bandwidth on cooperating CCs, this may be sufficient for PDCP level data partitioning and to optimize the partitioning scheduler algorithm.

[0071] To establish coordinated data splitting between sites between CCs, the X2 interface can be handled in several ways. The initial establishment can be treated as a partial handover, in which case a handover preparation information message can be used. In an embodiment, it may not be necessary to create a new X2 signaling protocol for this purpose. In an embodiment, a new X2 signaling message can be created in which the source eNodeB requests the target eNodeB to allocate resources (e.g., PDCP / RLC / MAC) to support coordinated transmission. Such a message can carry enough information to support some minimum data rate and QoS. It should be noted that the architectures and configurations shown in Figures 4 and 5 can be used in any embodiment disclosed herein, including embodiments that perform data splitting other than at the PDCP layer.

[0072] In an embodiment, data segmentation may be performed at the RLC layer. In such an embodiment, an AM (acknowledged mode) mode bearer may be configured, although the disclosure described herein may be implemented with other mode bearers. Data segmentation may be achieved by splitting a single stream of data received from a higher layer into multiple streams of data. Each stream of split data may be referred to herein as a flow. Each flow may be similar to an RLC entity, as currently defined in 3GPP standard documents. Each flow may be input to a device (e.g., eNodeB) as an SDU (service data unit) with a sequence number, and may be output from the device as a stream of SDUs. Within the device, the SDUs may be subdivided into PDUs (protocol data units) and may be reassembled on the peer node.

[0073] Further functions performed at the RLC layer on the transmitting entity may include a data splitting entity responsible for splitting the data into one or more flows. Each transmit flow is functionally equivalent to the current version of RLC. The data splitting entity can ensure that all SDUs it receives from higher layers are buffered, even if some of those SDUs are sent to the eNodeB on a CC, so that data can be retransmitted, for example, if there is a transmission failure on the radio or if there is some other problem between one of the CCs and the UE.

[0074] On the receiving entity, the flows are similar to the current RLC functionality, except that the flow entities may not handle reordering of the SDUs. This functionality may be performed by a data merge entity, which may receive input from one or more flows and may further buffer and reorder the SDUs before sending them to higher layers.

[0075] FIG. 6 illustrates a method 600 of performing UL data segmentation at the RLC layer. At block 605, an RLC entity on the UE may receive an SDU from PDCP. At block 610, a determination is made as to whether data segmentation is configured. Without data segmentation, at block 615, RLC may update the MAC layer with buffer information and await a data request from the MAC. If data segmentation is configured, at block 620, the data may be provided to a data segmentation entity present on the UE. At block 625, the data segmentation entity may segment the data into multiple flows (although each flow may behave like an RLC AM entity in itself). The decision of how the data should be segmented may be based on multiple factors, including available bandwidth on each CC based on input from the MAC, and the current buffer status on each flow. Once the data is segmented into flows for each CC, at block 630, buffer occupancy information for the MAC may be updated, and the MAC entity may determine the scheduling of the data for transmission over the air. The MAC scheduler may be modified to accommodate the concept of multiple flows.

[0076] At block 635, a MAC scheduler entity may select data from each flow and may forward the selected data to the PHY for transmission over Iu (air interface) to the destination eNodeB. Upon receipt of data on each flow at the eNodeB, appropriate control messages are exchanged at block 640 between the UE and the eNodeB on the same flow to acknowledge the data or to request retransmission. Note that once the PDUs are assembled into SDUs, all flows may be sent to the primary eNodeB that has a connection to the EPC (Enhanced Packet Core Network) for a given UE. Because these flows behave independently, any RLC control information (retransmission requests, resets, etc.) may be handled by the appropriate entity handling the given flow. Because the correct entity is handling the control information, latency in handling retransmission requests may be reduced.

[0077] The RLC entity on the primary eNodeB that receives flows from other RLC entities provides the data to a merging function or entity, which is responsible for merging the received data and ensuring that the data is in sequence before being provided to the PDCP.

[0078] 7 illustrates an example data flow and architecture that may be used according to an embodiment in which RLC layer data splitting is performed. A UE 730 may receive data at a PDCP layer 739 and provide the data to an RLC layer 737. At the RLC layer 737, a data splitting entity 736 splits the data into flows 731 and 732 that are provided to a MAC 735. Once the data splitting entity 736 has split the data into separate flows, it may keep track of the RLC SDUs. The MAC 735 may provide separate portions of the data (as flows 731 and 732) to a PHY 734 that may transmit the separate portions of the data to the eNodeB 710 and the eNodeB 720 over different CCs.

[0079] The eNodeB 720 may receive data at the PHY 724 and provide the data to the MAC 725, which provides the data of flow 732 to the RLC 727. The RLC 727 may then provide the flow data to the eNodeB 710 via the tunnel 740. At the eNodeB 710, the data flow 731 may be received at the PHY 714, which may provide the data flow 731 to the MAC 715, which provides the data of flow 731 to the RLC 717. The data merging entity 718 of the RLC 717 may then merge the data flows into properly ordered SDUs and provide the resulting data to the PDCP 719, which may transmit the data to the network as IP packets. The data merging entity 718 may keep track of the RLC SDUs. X2 signaling 750 may be used to exchange control information between eNodeB 710 and eNodeB 720.

[0080] FIG. 8 illustrates a method 800 of performing DL data segmentation at the RLC layer. At block 805, an RLC entity on an eNodeB entity that has a context with the EPC for a given UE receives data destined for that UE. In a normal mode where no CC is involved, this may result in a change in the total buffer occupancy for that channel. At block 810, the RLC entity on the eNodeB may determine whether data segmentation is configured. If so, at block 820, the RLC entity may check with the data segmentation entity to determine whether the SDU should be transmitted to a peer eNodeB or is available for local transmission. If data segmentation is not configured, processing the received data may proceed as normal at block 815.

[0081] At block 820, the data partitioning entity may determine whether the data should be sent to the peer RLC based on various factors, which may include available bandwidth at the peer entity, the current buffer status of the peer entity, etc. Because instantaneous buffer status on the X2 interface may not be available, the algorithm that determines the data partitioning may determine the partitioning based on expected data rates or a prediction based on the last reported measurement and the time since the last reported measurement.

[0082] If the data is to be sent on a local flow (i.e., directly from the eNodeB to the destination UE), the buffer occupancy information may be provided to the MAC to be updated in block 825, and the RLC may send the data to the MAC layer when requested in block 830. The data may be sent to the UE in block 835.

[0083] If the data is to be sent to a different eNodeB, the data may be sent to the peer eNodeB via the eNodeBe NodeB tunnel in block 840. The receiving RLC on the peer eNodeB may behave similarly as if it received the data from a higher layer. The difference is that the RLC transmission status feedback (e.g., RLC buffer status, and information about SDUs is not sent) is forwarded by the cooperating RLC entity to the RLC data splitting entity on the source eNodeB. This may enable the data splitting entity to send the failed packet over another available CC and to keep the buffer status up to date for seamless handover.

[0084] The RLC entity on each CC can update the buffer occupancy information that it provides to the MAC layer. The MAC entity can schedule data transmissions based on data availability and bandwidth availability. On the UE side, upon receiving data from the MAC, a reassembly function can be performed for each flow independently as per the current RLC standard. If there is RLC control information that needs to be transmitted, the MAC on the UE side can be informed of the flow for which the data should be transmitted. Once the SDUs are formed, they are provided to a data merging function that is responsible for reordering the SDUs (if the data merging function is configured to do so). The SDUs can be ordered before being sent from the RLC to the PDCP layer. The reordering can be done based on sequence numbers added to the SDUs or based on sequence numbers provided by the PDCP.

[0085] FIG. 9 illustrates an example data flow and architecture that may be used according to an embodiment in which RLC layer data splitting is performed. An eNodeB 910 may receive an IP packet 990 at a PDCP layer 919 and provide the data to an RLC layer 917. At the RLC layer 917, a data splitting entity 918 may split the data into flows 931 and 932. The data splitting entity 918 may determine that flow 932 should be sent to a peer eNodeB, whereas flow 931 should be sent locally (i.e., directly to the UE 930). The data splitting entity 918 may provide flow 931 to the MAC 915 (e.g., upon request, after updating buffer occupancy information). The data splitting entity 918 may keep track of the RLC SDUs once the data splitting entity 918 splits the data into separate flows. The MAC 915 may provide data regarding the flow 931 to the PHY 914, which may transmit the flow 931 to the UE 930 via the first CC.

[0086] The eNodeB flow 910 may provide a flow 932 to the eNodeB 920 via the tunnel 940. The RLC layer 927 may provide the flow 932 to the MAC 925 (e.g., upon a request after updating buffer occupancy information). The MAC 925 may provide data for the flow 932 to the PHY 924, which may transmit the flow 932 to the UE 930 via a second CC. X2 signaling 950 may be used to exchange control information between the eNodeB 910 and the eNodeB 920.

[0087] At the UE 930, data flows 931 and 932 may be received by a PHY 934, which may provide the data flows 931 and 932 to a MAC 935, which provides the data of flows 931 and 932 to an RLC 937. A data merging entity 936 of the RLC 937 then merges the data flows into properly ordered SDUs and provides the resulting data to the PDCP 939, which may transmit the data as IP packets to the network. A data merging entity 938 may keep track of the RLC SDUs.

[0088] For RLC layer data splitting embodiments, the handover operation may be performed using any means or methods disclosed herein, including those disclosed with respect to PDCP layer data splitting.

[0089] In an embodiment, data splitting may be performed at the MAC layer. A MAC IWF may be configured on the source eNodeB to forward RLC packets (e.g., PDUs) to a MAC IWF configured on a cooperating eNodeB that may provide transmission buffering. Note that MAC layer data splitting may be applied to HSPA (High Speed ​​Packet Access) configurations as well as LTE and LTE-A configurations as described herein. In HSPA configurations, a serving eNodeB in LTE-A may be equivalent to a serving RNC (Radio Network Controller) in HSPA, and a cooperating eNodeB in LTE-A may be equivalent to a NodeB or RNC in HSPA.

[0090] FIG. 10 illustrates an example DL data flow and architecture that may be used according to an embodiment in which MAC layer data splitting is performed. The eNodeB 1010 may receive IP packets 1090 at PDCP 1019a and 1019b, which may perform PDCP encoding and further provide data to RLC buffer layers 1017a and 1017b. The RLC buffers 1017a and 1017b may provide data to the MAC 1015, which may include a multiplexing entity 1019 that may determine an appropriate data split and split the data into at least two parts. The multiplexing entity 1019 may take into account available bandwidth with respect to the peer eNodeB and may forward the RLC PDUs in performing data multiplexing. Data determined to be sent using the peer eNodeB may be provided by the forwarding entity 1018 to the eNodeB 1020 via the inter-eNodeB tunnel 1040. Data determined to be transmitted locally (i.e., directly from the eNodeB 1010 to the UE 1030) may be provided to the HARQ 1016, which may perform any HARQ (Hybrid ARQ) functions and may forward the data to the PHY 1014 for transmission (1061) to the UE 1030 using the first CC.

[0091] When the eNodeB 1020 receives data for the UE 1030 from the eNodeB 1010 via the eNodeB-to-NodeB tunnel 1040, it may buffer such data in an eNodeB-to-NodeB buffer 1028. The buffer 1028 may provide the data to a MAC 1025 for multiplexing by a multiplexing entity 1029 and for the HARQ function performed by a HARQ entity 1026. This data may be provided to the PHY 1024 to be transmitted (1062) to the UE 1030 using the second CC.

[0092] The MAC scheduler 1012 on the serving eNodeB 1010 may use the reported (e.g., estimated or predetermined guaranteed or average transmission, etc.) supporting data rate from the cooperating eNodeB 1020 as a criterion in the payload selection algorithm to request that RLC PDUs be forwarded to the cooperating inter-site CC for transmission.

[0093] A MAC scheduler 1022 in a cooperating eNodeB 1020 may periodically report to the serving eNodeB 1010 the data rates (e.g., estimated, predetermined, or calculated guaranteed or average transmissions) that may be supported on the eNodeB 1020 and update the supported rates while a connection exists between the two eNodeBs. This, and other control information, may be exchanged between the eNodeBs via an X2 signaling interface 1050. In an embodiment, an X2 interface per cell radio resource status may be required, but radio resource status updates providing DL / UL GBR / non-GBR / total PRB may be optional. PRB status may also be used as an alternative scheduling input if such information is available.

[0094] It is also possible for the MAC scheduler 1022 in the cooperating eNodeB 1020 to perform standard payload selection for the cooperating CC as fixed size PDUs using the available RLC PDU buffers in the inter-eNodeB buffer 1028, or resized by multiplexing 1029 to fit the available radio resources. The RLC PDU size selection can be performed by the serving eNodeB MAC scheduler 1012 to accommodate the reported supported data rate or a guaranteed rate.

[0095] The MAC eNodeB-to-eNodeB data forwarding entity 1018 on the eNodeB 1010 may be a passive relay unit capable of sending MAC data to a PHY for processing and / or to the eNodeB 1020 via a tunnel 1040 .

[0096] The MAC eNodeB-to-eNodeB buffer 1028 at the cooperating eNodeB 1020 can act as a temporary "parking" area on the cooperating eNodeB 1020 to accommodate variable latency that can result from data tunneling over the X2 interface.

[0097] The inter-site tunnel 1040 may be a data pipe that transports RLC PDUs from the serving eNodeB 1010 to the cooperating eNodeBs 1020. There may be one tunnel per cooperating eNodeB.

[0098] The configurations and data flows described herein in connection with FIG. 10 and MAC layer data splitting may be implemented with only minor impact on the system architecture and with changes limited to the MAC layer. Such changes may be minimal and may be configuration changes that may be identical to or have minor differences from those required to support Coordinated Multipoint Transmission (CoMP) procedures. In an embodiment, some of the CoMP procedures may be reused with some modifications. In an embodiment, air interface resource reservation for participating sites may be used to reduce X2 interface delay. RLC SDU or in-order delivery may require that all relevant RLC PDUs are correctly received before RLC can send an RLC PDU to higher layers. Note that RLC PDUs may be transmitted over two different physical layer interfaces, each of which may have a different latency than the other. Thus, there may be a requirement for the receiving RLC entity to buffer further input data. Cooperative CCs may need to transmit RLC PDUs within the higher layer retransmission timer limits.

[0099] The corresponding data flow and architecture of UL MAC layer data splitting, using the same devices and entities as described with respect to Figure 10, is shown in Figure 11. The functionality shown in Figure 11 may be mostly or completely compatible with existing LTE and / or LTE-A signaling structures, but may also include configuration extensions for multiple CCs and corresponding scheduling from the network. The corresponding network requirements to forward successfully received MAC PDUs to the RLC on the serving eNodeB may be the same as those required to introduce CoMP procedures.

[0100] In FIG. 11 , data may be received at RLC buffers 1037a and 1037b on the UE 1030 and provided to a MAC multiplexing entity 1039 that may determine data partitioning and provide the data to the PHY 1034 for transmission on separate CCs 1063 and 1064 to the eNodeBs 1010 and 1020, respectively. Priority handling data may be used by the MAC multiplexing entity 1039. Such data may be exchanged between the priority handling entity 1032 and the MAC schedulers 1012 and 1022. Upon receiving data directly from the UE 1030, the PHY 1014 of the eNodeB 1010 may provide the data to the MAC 1015, which may perform HARQ functions and provide the data to the multiplexing entity 1019. The multiplexing entity 1019 may demultiplex the data with data received from the eNodeB 1020 via the tunnel 1040. Upon receiving data directly from the UE 1030, the PHY 1024 of the eNodeB 1020 may provide the data to the MAC 1025, which may perform HARQ functions and provide the data to the multiplexing entity 1029, which may demultiplex the data and provide it to the eNodeB 1010 via the tunnel 1040. After demultiplexing, the data may be provided to RLC buffers 1017a and 1017b, PDCP decoders 1019a and 1019b, and then transmitted to the network as IP packets 1091. Buffer statuses 1073 and 1074 may be provided by the UE 1030 to the MAC schedulers 1012 and 1022, respectively.

[0101] In a MAC layer data splitting embodiment, the basic handover features supported by LTE R8 can support the handovers described herein with the addition of configurations supporting reorganizing and / or maintaining the coordination structure, and support for partial handovers on the X2 signaling interface. Partial handovers of the serving CC or coordinated CCs can use the establishment of additional data paths between eNodeBs. There may be no need for data copying since MAC packets lost during path establishment or path re-establishment can be handled autonomously with RLC level retransmissions (for coordinated CC handovers since the RLC is always on the serving CC and may not have moved) or PDCP retransmissions (for serving handovers since the PDCP transmission status is forwarded to the target cell). It is possible for the X2 handover signal interface to encapsulate the handover preparation information defined by the RRC layer. Thus, the signaling problem of communicating partial handovers can be addressed by modifying the RRC handover messages to provide the context of the coordination structure in the handover preparation information.

[0102] In an embodiment, user plane data splitting may be implemented in an exemplary system. In a system using any combination of PDCP layer, RLC layer, MAC layer, or serving gateway data splitting, or any of the above and / or any other means disclosed herein, for an efficient data splitting decision, the serving eNodeB may need to take into account available resources and local scheduling information from the remote eNodeB. In a RAN data splitting embodiment, a dedicated "interworking function" may be used to buffer downlink frames to mitigate the delay introduced by the X2 link. The serving eNodeB may take into account the X2 delay and reduce the X2 latency by initiating S-GW (Serving Gateway) data splitting instead of RAN data splitting. Upon determining that data splitting should be used, the serving eNodeB may send a control signal to the serving gateway instructing the serving gateway to start splitting the data.

[0103] In an embodiment, the user plane load on the X2 interface may be reduced by building a framework that allows data splitting to be done at the serving gateway and by extending LTE R8 handover to allow carrier-specific handover. To implement such an embodiment, a message sequence may be used that allows the serving eNodeB to inform the serving gateway of a carrier-specific handover decision and further allows the serving gateway to split the UE traffic in a carrier-specific manner. In an embodiment that implements carrier-specific handover, eNodeB-MME messaging may be extended to support handover notification of a list of affected RABs (Radio Access Bearers) and to request that the MME support a carrier-specific PATH_SWITCH_REQUEST message.

[0104] For example, in an embodiment shown in FIG. 3, where the UE 350 may be connected to two eNodeBs when at location 311, appropriate RRC signaling may be required to support a split RRC connection. In some embodiments, an eNodeB UE context may be established once the transition to active state is completed for the UE or after handover resource allocation during handover preparation is completed at the target eNodeB. The eNodeB UE context may be a block of information in the eNodeB related to one active UE. This block of information may include necessary information required to maintain E-UTRAN services towards the active UE. UE status information, security information, UE capability information, and an ID of the logical S1 connection related to the UE may be included in the eNodeB UE context.

[0105] In an embodiment, user plane data splitting may be performed in the serving gateway shown in FIG. 12. An IP packet 405 may be received at a PDN (Packet Data Network) Gateway 1210 and sent to a serving gateway 1220. The serving gateway 1220 may split the data and send a portion of the data to the eNodeB 1230 via S1 bearer 1251 and another portion of the data to the eNodeB 1240 via S1 bearer 1252. The eNodeBs 1230 and 1240 may then send the data to the UE 1270 via radio bearers. Unacknowledged PDCP SDUs 1261 and 1262 may be forwarded between eNodeBs to allow lossless handover. Data splitting of bearers associated with individual CCs in the serving gateway may be enabled based on input from the eNodeBs and / or load balancing algorithms running on the serving gateway. A single component carrier may be associated with a HARQ entity. Multiple logical channels can be transparently mapped to different component carriers.

[0106] When a CC is handed over from one eNodeB (source) to another eNodeB (target), the source eNodeB can inform the MME associated with the Serving Gateway (directly or via the target eNodeB) of the radio bearers that were carried on the component carriers. This can be achieved by creating a message to be sent from the source eNodeB to the MME associated with the Serving Gateway or by extending the Path Switch Request message.

[0107] A Path Switch message can be exchanged between the eNodeB and the MME requesting a switch of the downlink GTP (GPRS Tunneling Protocol) towards a new GTP tunnel endpoint. The Path Switch message can carry the E-RABs to be switched in a Downlink List IE (Information Element), which can be a list of all E-RABs (EUTRAN RABs) that need to be switched from the source eNodeB to the target eNodeB. If the E-RABs to be switched in the Downlink List IE in the PATH SWICH REQUEST message may not include all E-RABs that were previously included in the UE context, the MME can consider the not included E-RABs as implicitly released by the eNodeB.

[0108] To support carrier-specific handover, the Path Switch Request (or an alternative message) may carry a list of RABs that need to be switched, but the MME and Serving Gateway may continue to forward the remaining traffic to the source eNodeB as before.

[0109] The eNodeB can decide how to request data splitting in the S-GW (Serving Gateway). In an embodiment, the eNodeB can request data splitting at the RAB level, in which case the path switch message can include a list of all RABs that need to be split. If the eNodeB does not want to split data at the RAB level, the eNodeB can send an indicator with the percentage of traffic that should be redirected to the new eNodeB. In an embodiment, a "RABs to keep" list can be used to avoid potential compatibility or interpretation issues with older equipment. The serving eNodeB can also implement a routing algorithm to determine the optimal RAB / RB mapping based on AS information that may not be available to the MME. An optional IE carrying a routing suggestion may be included in the "PATH SWITCH REQUEST" if the MME / S-GW decides to adopt data splitting routing as suggested by the eNodeB or an alternative data splitting routing. Some potential active inputs to the data split routing decision may include RB / RAB split allocation (mapping of RAB / RB to specific eNodeB MAC addresses), data split percentage, and other inputs.

[0110] Partial data from a radio bearer may be sent on a component carrier and this may be indicated by a special indicator that allows the serving gateway the option to split the traffic to mirror a similar configuration. This special indicator may be a one-time event or a periodic notification from the serving eNodeB to the S-GW / MME to change the split ratio based on channel quality measurements.

[0111] It is possible that the MME / S-GW implements some routing intelligence that is used to make data flow splitting decisions based on status inputs provided by the eNodeBs. Such inputs may include available eNodeB (e.g., PDCP) buffers, average transmission latency (e.g., on the UE or per specific RAB / RB), supportable traffic load distribution (e.g., % load per eNodeB), and others.

[0112] Note that packets sent from the S-GW may be IP traffic encapsulated in GTP tunnels, and furthermore, for a single E-RAB ID, it may be possible to request the creation of two GTP tunnels, one terminating at the source eNodeB and one terminating at the target eNodeB. This may differ from some implementations that prescribe one-to-one RAB to radio bearer mapping.

[0113] In an embodiment, the UE may have one RRC connection to the network with one special cell that provides security and NAS information. Referring back to Figure 3, at power-up, the UE 350 at location 311 is associated with an RRC connection to eNodeB 361 and established component carrier sets CC 320 and CC 330B. Thus, the UE 350 may associate with a serving cell (or special cell) in eNodeB 361 and may obtain security and NAS mobility information from eNodeB 361 until a serving cell handover occurs.

[0114] To support mobility in a coordinated component carrier deployment where CC 330 is the serving cell, the movement of UE 350 to location 311 may cause an RRC connection handover signaled using RRC connection reconfiguration and may cause a MAC / RLC layer reset to take into account the new security parameters. In an embodiment where CC 330 is not the serving cell, UE 350 may maintain its RRC connection to eNodeB 361 as UE 350 moves from location 310 to location 311. Security procedures may require additional mechanisms for handover, as described below.

[0115] Once the transition to active state for the UE is complete or after completion of handover resource allocation during handover preparation at the target eNodeB, the eNodeB UE context may be established. In an embodiment, the handover procedure is performed using the {K eNB* It is possible to trigger the target eNodeB and the UE to generate new keys for the encryption and encryption algorithms, derived from the {K,NCC} pair. The target eNodeB uses this tuple to generate a new K eNB It is possible to generate K UPenc Key (K eNB ) may be used for protection of user plane traffic with a specific encryption algorithm.

[0116] In an embodiment where the UE 350 of Figure 3 maintains an RRC connection with the source eNodeB 361 as it moves, for example, from location 310 to location 311, the PDCP entity running in the target eNodeB 362 may need to continue to use the same key as the source eNodeB 361. This may allow the UE to receive PDCP entities from different eNodeBs simultaneously. These keys may be exchanged in the handover command in the handover preparation phase of the handover from the source eNodeB to the target eNodeB. In an embodiment, this information may be conveyed during the initial context setup from the S-GW.

[0117] In an embodiment, uplink reports including power headroom, buffer status reports, and channel quality reports may be available at the target eNodeB and may be forwarded from the source eNodeB to the target eNodeB via X2-AP, or the UE may send the reports separately to the two eNodeBs. To provide backward compatibility, the UE may send reports on the serving cell to the "serving eNodeB". However, this may cause a delay in the availability of inputs for the scheduler at the target eNodeB, which may result in suboptimal scheduling decisions in some implementations.

[0118] To properly support handover in LTE-A with carrier aggregation, per-carrier UE measurements and reporting over aggregated downlink carriers may need to be defined, including carrier-specific RSRP and / or RSRQ. LTE R8 mechanisms may not support intra-frequency measurements, since measurements may be based on serving cells. For example, an eNodeB may own three carriers F1, F2, and F3, and may be using F1 and F2, with F1 being the serving cell. If the signal quality of F3 is better than F2, it may be desirable to have a measurement scheme that handles this situation so that the UE can report this situation. In some implementations, carrier-specific measurements, including measurements from non-serving cells, may be desired.

[0119] Although the features and elements are described above in certain combinations, those skilled in the art will recognize that each feature or element can be used alone or in any combination with the other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, ROM (read-only memory), RAM (random access memory), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and DVDs (digital versatile disks). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal device, base station, RNC, or any host computer. [Explanation of symbols]

[0120] 102, 102a-102d WTRU 104 RAN 106 Core Network 108 PSTN 110 Internet 112 Other Networks 114a, 114b base station 118 processors 120 Transceiver 122 Antenna

Claims

1. 1. A method implemented in a base station, comprising: receiving an Internet Protocol packet (IP packet) including data, the IP packet being associated with a wireless transmit / receive unit (WTRU); determining that a first portion of the data is to be transmitted to at least one cooperating network element for transmission to the WTRU; determining that a second portion of the data is to be transmitted by a base station to the WTRU; transmitting the first portion of the data to the at least one cooperating network element; transmitting the second portion of the data to the WTRU; Equipped with The method, wherein the base station includes a first scheduling entity, a first multiplexer, and a first modulation and coding module, and the first scheduling entity, together with the first multiplexer and the first modulation and coding module, coordinates transmission of the second portion of the data to the WTRU.

2. 2. The method of claim 1, wherein determining that the first portion of the data is to be transmitted to the at least one cooperating network element for transmission to the WTRU is performed in accordance with a Packet Data Convergence Protocol (PDCP) configured by a PDCP entity at the base station.

3. 2. The method of claim 1, wherein determining that the first portion of the data is to be transmitted to the at least one cooperating network element for transmission to the WTRU is performed by a Radio Link Control (RLC) entity configured at the base station.

4. 2. The method of claim 1, wherein determining that the first portion of the data is to be transmitted to the at least one cooperating network element for transmission to the WTRU is performed by a medium access control (MAC) entity configured at the base station.

5. The method of claim 1 , wherein the at least one cooperating network element includes any of another base station, a remote radio head (RRH), or a sector antenna.

6. 10. The method of claim 1, wherein the base station determines the first portion of the data to be transmitted to at least one cooperating network element using an iterative procedure and associated control information.

7. 2. The method of claim 1 , wherein the second portion of the data is transmitted from the base station to the WTRU using a first component carrier, and the first portion of the data is transmitted from the at least one cooperating network element to the WTRU using a second component carrier.

8. 1. A method implemented in a base station, comprising: receiving a first stream of data including Internet Protocol packets (IP packets), the IP packets associated with a wireless transmit / receive unit (WTRU); splitting the first stream of data into a second stream of data and a third stream of data, the second stream of data intended for transmission to the WTRU via at least one cooperating network element, and the third stream of data intended for transmission by the base station to the WTRU; transmitting, from the base station, the second stream of data to the at least one cooperating network element; transmitting the third stream of data to the WTRU while transmitting the second stream of data to the at least one cooperating network element; Equipped with The method, wherein the base station includes a first scheduling entity, a first multiplexer, and a first modulation and coding module, and the first scheduling entity, together with the first multiplexer and the first modulation and coding module, coordinates transmission of the third stream of the data to the WTRU.

9. The method of claim 8 , wherein the splitting is performed in accordance with a Packet Data Convergence Protocol (PDCP) configured by the base station.

10. The method of claim 8, wherein the splitting is performed by a Radio Link Control (RLC) entity configured in the base station.

11. The method of claim 8 , wherein the dividing is performed by a medium access control (MAC) entity configured in the base station.

12. The method of claim 8 , wherein the at least one cooperating network element includes any of another base station, a remote radio head (RRH), or a sector antenna.

13. A base station comprising a circuit including a transmitter, a receiver, a processor, and a memory, receiving an Internet Protocol packet (IP packet) including data, the IP packet being associated with a wireless transmit / receive unit (WTRU); determining that a first portion of the data is to be transmitted to at least one cooperating network element for transmission to the WTRU; determining, by a base station, that a second portion of the data is to be transmitted to the WTRU; transmitting the first portion of the data to the at least one cooperating network element; Transmitting the second portion of the data to the WTRU. It is configured as follows: The base station includes a first scheduling entity, a first multiplexer, and a first modulation and coding module, the first scheduling entity together with the first multiplexer and the first modulation and coding module coordinating transmission of the second portion of the data to the WTRU.

14. 14. The base station of claim 13, configured to determine that the first portion of the data is to be transmitted to the at least one cooperating network element in accordance with a Packet Data Convergence Protocol (PDCP) configured by a PDCP entity at the base station.

15. 14. The base station of claim 13, further configured to determine, by a radio link control (RLC) entity, that the first portion of the data is to be transmitted to the at least one cooperating network element.

16. 14. The base station of claim 13, further configured to determine, by a media access control (MAC) entity, that the first portion of the data is to be transmitted to the at least one cooperating network element.

17. The base station of claim 13 , wherein the at least one cooperating network element includes either another base station, a remote radio head (RRH), or a sector antenna.

18. 14. The base station of claim 13, wherein the base station is further configured to determine the first portion of the data to be transmitted to at least one cooperating network element using an iterative procedure and associated control information.

19. 14. The base station of claim 13, wherein the second portion of the data is transmitted from the base station to the WTRU using a first component carrier, and the first portion of the data is transmitted from the at least one cooperating network element to the WTRU using a second component carrier.

Images