Method and apparatus for supporting communications via relay nodes

Abstract

To disclose a method and device for supporting communication through a relay node.SOLUTION: A relay node can receive a WTRU buffer status report (BSR) from a plurality of wireless transmission / reception unit (WTRU) undergoing a service by the relay node. The WTRU BSR shows an uplink buffer status in the WTRU. Next, the relay node can transfer the WTRU BSR to a donor evolved node B (DeNB). The relay node can send a relay node BSR to the DeNB. The relay node BSR shows a relay node uplink buffer status and / or a relay node downlink buffer status in the relay node. The relay node can send a radio resource control (RRC) message to the DeNB to request a radio resource reconfiguration.SELECTED DRAWING: Figure 3

Description

[Technical Field]

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

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 61 / 320,644, filed April 2, 2010, U.S. Provisional Patent Application No. 61 / 320,535, filed April 2, 2010, and U.S. Provisional Patent Application No. 61 / 373,555, filed August 13, 2010, the contents of which are incorporated herein by reference. [Background technology]

[0003] In a wireless communication system, an eNodeB (eNB) allocates air interface resources to a wireless transmit / receive unit (WTRU) for data transmission and reception. The eNB allocates resources and related parameters (e.g., modulation and coding scheme) for the WTRU's transmission and reception such that data-related quality of service (QoS) requirements (e.g., delay, packet error, and loss rate) for the WTRU are met while maintaining fairness to other WTRUs and maximizing capacity (i.e., the number of WTRUs the eNB can serve).

[0004] The WTRU may provide a WTRU buffer status report (BSR) to the serving eNB, which tells the eNB the amount of available uplink data stored in the WTRU uplink buffer that is ready for transmission and retransmission. The BSR is used for QoS-aware packet scheduling in evolved UMTS terrestrial radio access network (E-UTRAN).

[0005] Radio bearers (RBs) can be assigned quality of service (QoS) parameters by the network. The QoS parameters define service attributes such as type of service, delay tolerance, and data error and loss tolerance. A WTRU that knows the required QoS of its RBs can make intelligent decisions on how to prioritize the RBs in terms of which data to select for transmission when resources are allocated. The eNB can use this information to allocate resources to WTRUs and prioritize transmissions such that the performance and throughput requirements of each individual WTRU are met as closely as possible.

[0006] QoS can be defined using QoS class identifiers (QCIs). Table 1 shows QCI characteristics, including resource type, priority, packet delay budget, and packet error and loss rate. Table 2 shows the mapping of traffic classes to QCIs.

[0007] [Table 1]

[0008] [Table 2] Summary of the Invention [Problem to be solved by the invention]

[0009] A method and apparatus for supporting communications via relay nodes is provided. [Means for solving the problem]

[0010] A method and apparatus are disclosed for supporting communication via a relay node. The relay node can receive WTRU buffer status reports (BSRs) from multiple wireless transmit / receive units (WTRUs) served by the relay node. The WTRU BSRs indicate uplink buffer status at the WTRUs. The relay node can then forward the WTRU BSRs to a donor evolved Node B (DeNB).

[0011] The relay node may send a relay node BSR to the DeNB. The relay node BSR indicates the relay node uplink buffer status and / or the relay node downlink buffer status at the relay node. The relay node uplink buffer status is generated based on the sum of the uplink buffer accumulation for active WTRU radio bearers (RBs) of one or more WTRUs or for active WTRU RBs belonging to one or more reporting groups, and the relay node downlink buffer status is generated based on the sum of the downlink buffer accumulation for active WTRU RBs of one or more WTRUs or for active WTRU RBs belonging to one or more reporting groups. The reporting groups may be organized per WTRU or per quality of service (QoS) associated with the WTRU DRBs. The relay node BSR may be triggered periodically, based on the occurrence of a configured trigger event, or based on a combination of a periodic timer and the occurrence of a configured trigger event.

[0012] The relay node may send a radio resource control (RRC) message to the DeNB to request radio resource reconfiguration. For example, the relay node may send an RRC message to the DeNB conditional on a handover request acknowledgement message being received from the DeNB, data transfer to the DeNB being completed, an end marker being received, and / or a WTRU context release message being received.

[0013] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Effects of the Invention]

[0014] A method and apparatus for supporting communications via relay nodes is provided. [Brief explanation of the drawings]

[0015] [Figure 1A] FIG. 1 is a diagram of an exemplary communication system for implementing one or more disclosed embodiments. [Figure 1B] 1B is a system diagram of an example WTRU that may be used in the communication system of FIG. 1A. [Figure 1C] 1B is a system diagram of an example radio access network and an example core network that can be used in the communication system shown in FIG. 1A. [Figure 2] FIG. 1 illustrates an exemplary system including an RN. [Figure 3] FIG. 10 illustrates reporting of a WTRU BSR to a donor eNB (DeNB). [Figure 4] FIG. 1 is a signaling diagram of an exemplary handover procedure. [Figure 5] 1 is a flow diagram of an example process for combining event-triggered and periodic BSR reporting in one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 can enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 can employ 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), etc.

[0017] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, WTRUs 102a, 102b, 102c, and 102d may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, etc.

[0018] The communications system 100 may also include a base station 114a and a base station 114b. Each base station 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the core network 106, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted 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.

[0019] 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), or a relay node. 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 also 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 transceiver for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

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

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

[0022] 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 enable the radio interface 116 to be established using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0023] 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), GSM EDGE (GERAN), or the like.

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

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

[0026] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs that may employ the same RAT as the RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may have multi-mode capabilities. That is, the WTRUs 102a, 102b, 102c, 102d may have 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 employ a cellular-based radio technology, and a base station 114b, which may employ an IEEE 802.2 radio technology.

[0028] 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 subcombination of the foregoing elements while remaining consistent with an embodiment.

[0029] 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, etc. 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 depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0030] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, 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 understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0031] 1B depicts the transmit / receive element 122 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ 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.

[0032] 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. Thus, the transceiver 120 may comprise multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0033] 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, etc. 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).

[0034] 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 providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

[0036] The processor 118 may also 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, etc.

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

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

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

[0040] 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 foregoing elements is depicted as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0041] The MME 142 may be connected to each eNB 140a, 140b, 140c 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, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM or WCDMA.

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

[0043] 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.

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

[0045] 2 shows an exemplary system including WTRUs 102, 103, an eNB 140, an RN 150, and a core network 106. The RN 150 is introduced between the eNB 140 (referred to as a donor eNB (DeNB)) and the WTRU 102. The RN 150 is connected to the DeNB 140 via a wireless link. In the downlink, data is transmitted from the DeNB 140 to the RN 150 and then to the WTRU 102, and in the uplink, data is transmitted from the WTRU 102 to the RN 150 and then to the DeNB 140. The DeNB 140 provides the RN 150 with a link to the core network 106. To R8 and R9 WTRUs, the RN cells appear as normal R8 and R9 cells under the eNB. The RN 150 is used as a tool to improve coverage and cell-edge throughput.

[0046] The RN WTRU 102 is a WTRU that has an RN as its serving cell. The macro WTRU 103 is a WTRU that has an eNB (including a DeNB) as its serving cell. The Uu interface is the radio interface between the RN WTRU 102 and an RN cell, or between the macro WTRU 103 and an eNB 140. The Uu interface between the RN WTRU 102 and the RN 150 is referred to as the RN Uu, or simply the Uu interface, and the Uu interface between the macro WTRU 103 and the eNB 140 is referred to as the macro Uu interface. The Un interface is the radio interface between the RN 150 and its DeNB 140. For simplicity, the terms "RN WTRU" and "RN Uu" may be used hereinafter.

[0047] A Uu RB or WTRU RB (including both DRB and SRB) is an RB configured for service between the WTRUs 102, 103. A Un RB or RN RB (including both DRB and SRB) is an RB configured for radio bearers via the Un between the DeNB 140 and the RN 150. A RN Radio Network Temporary Identity (RNTI) is an identifier allocated to the RN 150 by the DeNB 140.

[0048] WTRU UL RB data destined for the network is transmitted by the WTRU 102 in a MAC PDU over Uu to the RN 150, and then transmitted by the RN 150 in a MAC PDU over Un to the DeNB 140. The DeNB 140 forwards this data to the network 106. DL transmission occurs in reverse.

[0049] The RN 150 may be an in-band relay node (referred to as a "Type 1" RN). A Type 1 RN controls cells, but each cell appears to the WTRU as a separate cell distinct from the donor cell (the cell controlled by the DeNB). The RN cell may have its own physical cell ID, and the RN may transmit its own synchronization channel, reference symbols, etc. In the context of single-cell operation, the WTRU may receive scheduling information and hybrid automatic repeat request (HARQ) feedback directly from the RN and may send the WTRU's control channel to the RN.

[0050] For a Type 1 RN, the eNB-RN link (Un) shares the same carrier frequency with the RN-WTRU link (RN Uu). Depending on the RN implementation, an in-band RN may or may not be able to support simultaneous transmission on its Uu link and reception on its Un link, and vice versa, due to interference of its transmission on its reception. For RNs that do not support simultaneous transmission and reception, time division multiplexing between the Un interface and the RN Uu interface can be used to avoid contention.

[0051] The DeNB configures and reconfigures radio resources for the RNs at the cell level or individually for a particular RN. For example, the DeNB configures Un subframes in Un for communication between the DeNB and the RN. For example, the DeNB may transmit to the RN on the Un during periods configured as multimedia broadcast over single frequency network (MBSFN) subframes on the RN Uu link. MBSFN subframes are subframes that the WTRU understands to be reserved for multimedia broadcast multicast service (MBMS) transmissions, and therefore the WTRU does not expect the RN to transmit data unless it is specifically informed of MBMS transmissions in these subframes. The RN does not use these subframes for MBMS, but can transmit and receive to and from the DeNB without the need to transmit to the WTRU.

[0052] If the Un configuration does not change at the cell level, the DeNB may send dedicated radio resource control (RRC) signaling, or any equivalent signaling or message, to specific RN(s). The RRC signaling or equivalent signaling or message may specify parameters for the reconfiguration, such as the downlink Un subframe mask or new Un subframe allocation pattern, the uplink Un subframe allocation, the subframe offset between Un and Uu, and the activation time. If an activation time is specified, the RN may maintain its current operation with the DeNB over the Un interface before the activation time, and may transmit and receive over the Un interface according to the reconfiguration at the activation time.

[0053] If the RN needs to reconfigure its Uu configuration as a result of any Un changes (this can be included in the RN Uu System Information Block (SIB)), the RN can turn on the system information change indicator in the paging message over the RN Uu, update the system information in the SIB as needed, and publish the new system information at the SIB modification period boundary.

[0054] The WTRU may provide a WTRU BSR to the RN indicating the amount of available uplink data stored in the WTRU uplink buffer that is ready to be transmitted and retransmitted. The buffer status may be reported as an index into a table that provides a buffer size range. Depending on the number of logical channels that have data available for transmission and the size of the padding space (if the BSR is triggered by MAC PDU padding), the BSR may be formatted and transmitted in three ways: a truncated BSR, a short BSR, and a long BSR.

[0055] The abbreviated BSR is a single LCG BSR containing the buffer status of the LCG with the highest priority logical channel. The abbreviated LCG is used when there are multiple LCGs with available data but not enough room in the MAC PDU to send BSRs for all of them. The short BSR is a single LCG BSR containing the buffer status of one LCG. The short BSR is used when there is only one LCG with available data to send. The long BSR is a 4LCG BSR containing the buffer status of four LCGs. If there is no data for an LCG, the buffer size value for that LCG is reported with index 0.

[0056] The basic channel- and bearer-related unit for the BSR is the logical channel group (LCG). An LCG contains one or more logical channels from the WTRU that have been assigned by the eNB in ​​a logical channel configuration. This logical channel grouping mechanism in BSR reporting limits the reporting load while maintaining some reporting granularity. A WTRU data radio bearer (DRB) is associated with a WTRU logical channel and is accompanied by a logical channel identification, logical channel configuration, and other attributes (such as evolved packet system (EPS) identification, radio bearer (RB) identification, packet data convergence protocol (PDCP), and radio link control (RLC) configuration information). Four LCGs (values ​​0-3) can be used for WTRU bearers and logical channels. If a logical channel is not assigned to an LCG, this logical channel UL data does not need to be included in the WTRU BSR. A WTRU signaling radio bearer (SRB) is assigned to LCG=0 by default.

[0057] The RN reports various types of status to the DeNB. For example, the RN can report buffer status and other traffic load conditions to the DeNB to help the DeNB make resource allocations to the RN or cell. The buffer status information can be sent via the MAC CE. Details of buffer status reporting are described later.

[0058] The RN may send a PDCP Status PDU to reflect the Un downlink reception status of received PDCP PDUs. The status granularity may depend on how the RN Un PDCP instance is configured. The RN Un PDCP instance may be configured per RN DRB per WTRU radio bearer or on either a per QoS or per WTRU basis. The PDCP Status PDU may be used to report the current accumulated uplink PDCP SDUs per UL bearer in the WTRU, per UL QoS bearer, or per UL WTRU in the RN. The PDCP status report may be a useful indicator when a WTRU handover occurs.

[0059] The RN can send RRC message(s) to the DeNB to indicate changing situations or conditions in the RN and trigger or assist the DeNB to adjust Un resource allocation or configuration (which may affect the RN Uu interface configuration). The RRC message(s) can carry one or more measurement report(s). The measurements may include traffic status during the RN's DL Uu, buffer status, measured aggregate data rate, link quality (e.g., acknowledgment / negative acknowledgment (ACK / NACK) rate), conditions during the DL Uu when resources are over- or under-utilized, etc. New RRC messages or new information elements (IEs) can also be defined for reporting.

[0060] Reporting may be periodic or trigger-based. The timer(s), threshold(s), and amount of reported measurements may be configured, for example, by RRC signaling. The DeNB may request immediate reporting. The RN may initiate a reconfiguration request and may include the reported values ​​in the reconfiguration request message to support the request.

[0061] 4 is a signaling diagram of an exemplary handover procedure. The RN configures WTRU measurements (402). The WTRU sends measurement reports to the RN according to the configuration (404). The RN makes a handover decision based on the measurement reports (406). The RN sends a handover request to the DeNB, passing the necessary information to prepare the handover (408). The DeNB reads the target cell ID from the handover request message, finds the target eNB or RN corresponding to the target cell ID, and forwards the handover request message to the target eNB or RN (410).

[0062] The target eNB / RN performs admission control (412). The target eNB / RN prepares for handover and sends a handover request acknowledgement message to the RN via the DeNB (414, 416). The handover request acknowledgement message includes a transparent container to be sent to the WTRU as an RRC message to perform the handover. This container includes a new cell radio network temporary identity (C-RNTI), a target eNB security algorithm identifier for the selected security algorithm, a dedicated random access channel (RACH) preamble, etc.

[0063] The RN sends an RRC message (e.g., an RRC Connection Reconfiguration message including mobility control information) to the WTRU to perform the handover (418). After receiving the RRC Connection Reconfiguration message, the WTRU disassociates from the old cell and performs synchronization and initial access procedures with the new cell (420). As soon as the RN receives the handover request acknowledgment or as soon as handover command transmission is initiated in the downlink, data transfer from the RN to the target eNB / RN can begin (422). Once the WTRU has successfully accessed the target cell, the WTRU confirms the handover by sending an RRC Connection Reconfiguration Complete message to the target eNB / RN (424). The target eNB / RN can now begin transmitting and receiving data to and from the WTRU and the serving gateway (426).

[0064] The target eNB / RN sends a path switch message to the mobility management entity (MME) to inform it that the WTRU has changed cells (428). The MME sends a user plane update request message to the serving gateway (430). The serving gateway switches the downlink data path to the target side (432), sends one or more "end marker" packets to the RN on the old path, and may then release any user plane / TNL resources to the RN (434). To aid in the reordering function in the target eNB / RN, the serving gateway can send one or more "end marker" packets on the old path to the WTRU immediately after switching the path. Upon receiving the "end marker" packets, the RN forwards the end marker packets to the target eNB / RN (436). When the target eNB / RN detects the end marker, it initiates (438) any processing necessary to maintain in-order delivery of user data forwarded over the X2 interface and user data received from the Serving GW over S1 as a result of the path switch.

[0065] The serving gateway sends a user plane update response message to the MME (440). The MME acknowledges the path switch message with a path switch acknowledgement message (442). The target eNB / RN notifies the RN of the success of the handover by sending a WTRU context release message to the RN, triggering the release of resources by the RN (444). Upon receiving the WTRU context release message, the RN can release radio and C-plane related resources associated with the UE context (446).

[0066] When a WTRU is to be handed over to a different eNB or RN, a data forwarding path may be established or widened over the Un interface between the RN and DeNB to forward WTRU data present in the RN to the DeNB and beyond. After the WTRU completes handover, the forwarding path over the Un interface may be removed or narrowed. The RN may send an RRC indication message to the DeNB when it receives a handover request acknowledgement message from the DeNB for a WTRU handing over from this RN to a different eNB or RN, or when it receives a handover request acknowledgement message from the DeNB such that the resulting aggregate Un traffic is now likely to exceed a value that is the sum of the currently configured bandwidth and a predefined or configured threshold.

[0067] The RN may send an RRC indication message to the DeNB when it has finished transferring data for the connected WTRU to the DeNB, or when it has received an end marker message or similar indication from the network, or when it has received a WTRU context release message from the network.

[0068] To reduce the signaling load and Un reconfiguration processing burden, the RN may send an RRC indication message for WTRU handover if the forwarding path bandwidth to be added or removed significantly impacts the Un capabilities configured for the RN beyond a predefined or configured threshold. The threshold may be configured as a data byte count or a percentage of the total bandwidth for the RN over the Un interface.

[0069] When the RN experiences a certain amount of data backlog or a certain amount of data underflow in the Un uplink for a certain period of time, or when the aggregated WTRU UL data backlog (e.g., detected from the WTRU BSR) exceeds or falls below a threshold, the RN may send an RRC indication message to the DeNB to request an Un resource reconfiguration.

[0070] For such reporting, a parameter (V) for a data volume change value and / or a parameter (T) for a time value can be defined. The parameter T can be used as the minimum time that the data backlog or underflow or bandwidth volume change can be above or below a threshold before an RRC indication message can be sent. The parameter T can be used as the minimum interval between the last Un(re)configuration message (e.g., RRCConnectionReconfiguration) of the DeNB and a new RRC indication message. The parameter V can be used as a threshold for the data backlog / underflow or for the bandwidth requirement change threshold.

[0071] In addition to providing normal voice and data services to the WTRU, the RN may also provide other user applications and services to the WTRU. Setup or reconfiguration of these applications may require the DeNB, unlike normal radio bearer processing, so that the DeNB may know that the Un interface may be reconfigured. In this case, the RN may indicate resource requirements to the DeNB. For example, if the RN provides Multimedia Broadcast Multicast Service (MBMS) services to the WTRU, the RN may indicate to the DeNB a request for downlink Uu subframe reconfiguration and / or a request for Un bandwidth and subframe configuration change by sending an RRC indication message when MBMS service(s) in the RN cell start and stop or when the configuration changes (when activating or deactivating some MBMS services).

[0072] The RN may send RRC indication messages to the DeNB for other applications that may change their Uu / Un configuration or bandwidth requirements, but for which the DeNB is not involved in starting, stopping, and / or changing. The RN may send RRC indication messages to the DeNB when a WTRU application has changed QoS requirements (e.g., the normal QoS requirements have changed to require low jitter or low latency, such that the QoS requirements cannot be guaranteed with the current Un subframe allocation).

[0073] Both the RN and the DeNB monitor the channel quality. In the Un uplink, the DeNB can learn the RN transmission quality through Hybrid Automatic Repeat Request (HARQ) reception, and the DeNB can learn its Un downlink transmission quality through the RN's feedback on the Channel Quality Indicator (CQI), Rank Indicator (RI), or Precoding Matrix Indicator (PMI). The DeNB can adjust the relevant Un parameters without additional information from the RN.

[0074] The DeNB itself does not know the RN-Uu link quality. In-band Type 1 relaying can adjust the allocation of RN-Uu configurations if there are many WTRUs over an unstable RN-Uu interface. This RN-Uu configuration adjustment may affect the Un configuration. In this case, the RN can send an RRC indication message requesting any RN-Uu configuration change if this change affects the configuration on the Un interface.

[0075] When some of the system information parameter values ​​change, the RN operation over the Un and / or Uu may also change. In this case, the DeNB may adjust some of the Un operation parameters or RN settings. If the DeNB does not reconfigure the Un, the RN may send an RRC indication message to the DeNB to request such a reconfiguration. For example, this may occur when changes occur in the following DeNB system information parameters: downlink bandwidth change, which affects the RN use of Un frequency resources; maximum transmit power limit change, which affects the WTRU power headroom; uplink bandwidth and / or uplink carrier frequency change, which affects the RN uplink operation; and MBSFN subframe configuration list, which affects the Un subframe allocation.

[0076] When an RN transitions from a connected state to an idle state, the RN may notify the DeNB of its intended detach, release, or shutdown action via an RRC indication message, allowing the DeNB to release Un resources allocated to the RN, as well as other connections the RN has with various network nodes. An RN may leave the connected state when the RN is shut down by a local Operation, Maintenance, and Administration (OAM) (e.g., when the RN receives a DETACH-ACCEPT or signaling-connection-release message from the core network), when the RN is commanded to detach or disconnect by a core network mobility management entity (MME) (e.g., when the RN replies to the network with a DETACH-ACCEPT message), or when the RN has an operational problem (e.g., when the RN detects a security violation or an unrecoverable error condition for ciphering or integrity protection).

[0077] When the RN has many connected WTRUs and Uu interface resources are limited or the radio link quality is poor, it may accumulate UL data at the WTRU side and buffer Uu DL data at the RN side. The DeNB may not know the data accumulation status of the WTRU UL buffers and the RN DL buffers. In one embodiment, the RN may send an indication to the DeNB when the total WTRU UL buffers exceed a threshold (detected from the WTRU BSR reported to the RN) or when the total RN DL buffers exceed a threshold, indicating to the DeNB that the Un interface needs to be reconfigured to leave more resources for the Uu interface. The RN may send an RRC indication message to the DeNB when it wants to adjust the Uu interface configuration.

[0078] The RRC indication message may include a reason indicating the purpose of the RRC indication message. The reason may be a related Un or Uu resource, such as a resource addition request for Un or Uu, a resource reduction request for Un or Uu, or a resource release request. The RRC indication message may also include other reasons or sub-reasons, including MBMS resource reconfiguration and handover resource reconfiguration. The RRC indication message may include an uplink bandwidth request (add or reduce) and quantity indication, an uplink Uu subframe change request (e.g., add, reduce, shift), and / or an uplink power change request.

[0079] In the above embodiment, the use of the RRC indication message is an example, and alternatively, any other message(s) or information element may be used in the new or existing message(s).

[0080] Below, an embodiment for reporting BSR is disclosed.

[0081] In one embodiment, the RN may generate buffer status reports (BSRs) for the RN DRBs and send these reports to the DeNB. The RN receives UL RBs from the WTRU and maps them to UL RN DRBs. Uplink data accumulated in the RN uplink buffers may be organized as RN BSR contents and reported to the DeNB. The buffer status report may include an actual count of data (e.g., a byte count) and / or a value representing this data count (such as an index into a look-up table) and / or a value representing a range within which this count falls. Other traffic volume related information may also be reported as a separate item or in conjunction with the byte count or equivalent.

[0082] The RN uplink buffers can be organized based on how WTRU RBs are mapped to RN DRBs. The RN DRBs may be organized per WTRU, such that the WTRU's RBs map to one RN DRB (multiple WTRU RBs may map to one RN DRB). Alternatively, the RN DRBs may be organized per QoS, such that the RBs of all or a subset of WTRUs with a given QoS map to one RN DRB (multiple QoSs may map to one RN DRB). Alternatively, the RN DRBs may be organized per RN, such that the WTRU DRBs map to a single RN DRB.

[0083] The RN BSR may contain the buffer status of a single RN DRB. The RN BSR may contain the total uplink buffer accumulation (or an indication of the total or range) of active WTRU RBs that are mapped to one RN DRB. The RN DRB may be identified by an RN DRB ID (or equivalent).

[0084] Alternatively, the RN BSR may contain the buffer status of a single RN DRB reporting group. The RN BSR may contain the sum (or an indication of the sum or range) of uplink buffer accumulation of active WTRU RBs that are mapped to one or more RN DRBs that belong to one RN DRB reporting group. The RN DRB reporting group may be identified by a RN DRB reporting group ID (or equivalent).

[0085] Alternatively, the RN BSR may include buffer status for multiple RN DRB reporting groups. Each buffer status is the sum (or an indication of a sum or range) of uplink buffer accumulation for active WTRU RBs that map to one or more RN DRBs belonging to one RN DRB reporting group. The report may include the RN DRB reporting group ID (or equivalent) for each RN DRB reporting group in the report. Alternatively, the report may include the buffer status for each RN DRB reporting group in a pre-defined order (e.g., this order may be signaled to the RN or fixed in a standard) so that the RN DRB reporting group ID can be omitted. If there is a set of pre-defined orders (e.g., based on signaling to the RN or defined in a standard), the report can use one of these orders and indicate in the report which order is used, and the reporting group ID can be omitted.

[0086] Alternatively, the RN BSR may include a combination of buffer status of one or more individual RN DRBs, individual buffer status of one or more RN DRB reporting groups, and / or the sum of buffer status from one or more RN DRB reporting groups.

[0087] If RN DRBs are organized per WTRU, the RN BSR may include the sum (or an indication of the sum or range) of uplink buffer accumulation of active RBs from one WTRU that are mapped to one RN-DRB.

[0088] Alternatively, the RN BSR may include the sum (or an indication of the sum or range) of uplink buffer accumulations of active RBs from one or more WTRUs that are mapped to one or more RN DRBs that belong to a reporting WTRU group, where these RN DRBs and / or associated WTRU RBs are assigned the same reporting WTRU group identifier.

[0089] Alternatively, the RN BSR may include buffer statuses for several reporting WTRU groups (one buffer status per reporting WTRU group), where each buffer status is the sum (or an indication of the sum or range) of the uplink buffer accumulation of active RBs from one or more RN WTRUs that are mapped to one or more RN DRBs that belong to the reporting WTRU group. The report may include a reporting WTRU group identifier (or equivalent) for each reporting WTRU group in the report. Alternatively, the report may include the buffer status for each reporting WTRU group in a predetermined order (e.g., this order may be signaled to the RN or configured in a standard), so that the reporting WTRU group identifier can be omitted. Alternatively, if there is a set of predetermined orders (e.g., based on signaling to the RN or defined in a standard), the report may use one of these orders and indicate in the report which order is used, and the reporting WTRU group identifier may be omitted.

[0090] Alternatively, the RN BSR may include a combination of the buffer status of one or more individual RN DRBs, and / or the individual buffer status of one or more reporting WTRU groups, and / or the sum of the buffer status from one or more reporting WTRU groups.

[0091] If the RN DRBs are organized by QoS (e.g., by DRB priority or QCI value), the RN BSR may include the sum (or an indication of the sum or range) of the uplink buffer accumulation of active WTRU RBs with one or more QoSs mapped to one RN-DRB.

[0092] Alternatively, the RN BSR may include the sum (or an indication of the sum or range) of uplink buffer accumulations of active WTRU RBs with one or more QoSs that are mapped to one or more RN-DRBs that belong to the reporting QoS group. These RN DRBs and / or associated WTRU RBs may be assigned the same reporting QoS group identifier.

[0093] Alternatively, the RN BSR may include a buffer status for each of several reporting QoS groups (one buffer status per reporting QoS group), where each buffer status is the sum (or an indication of a sum or range) of the uplink buffer accumulation of active WTRU RBs having one or more QoSs mapped to one or more RN DRBs belonging to the reporting QoS group. The report may include a reporting QoS group identifier (or equivalent) for each reporting QoS group in the report. Alternatively, the report may include the buffer status for each reporting QoS group in a predetermined order (e.g., this order may be signaled to the RN or fixed in a standard) so that the reporting QoS group identifier can be omitted. Alternatively, if there is a set of predetermined orders (e.g., based on signaling to the RN or defined in a standard), the report may use one of these orders and indicate in the report which order is used, and the reporting QoS group identifier can be omitted.

[0094] Alternatively, the RN BSR may include a combination of the buffer status of one or more individual RN DRBs, and / or the individual buffer status of one or more reporting QoS groups, and / or the sum of the buffer status from one or more reporting QoS groups.

[0095] The uplink buffer status may be included in the RN BSR alone or together with other aspects of the status related to buffers or traffic.

[0096] In another embodiment, the RN can report RN downlink buffer status to the DeNB. Downlink data buffered in the RN can be reported to the DeNB to support DeNB management of radio resources. In some types of relaying (e.g., half-duplex type 1 relaying, where the Uu and Un interfaces operate in the same frequency band), transmission on the Un causes interference to reception on the Uu, and vice versa. In such cases, resources on the Uu and Un can be allocated to reduce such interference. If the DeNB understands the needs of the relaying Uu, it can take this into account when allocating resources on the Un.

[0097] The DL buffer status in the RN may indicate an overflow or underflow situation. The report may include a reason (e.g., insufficient Uu bandwidth or a Uu transmission problem). The DL status report may indicate an overflow with a high Uu transmission NACK rate. This may indicate that the downlink transmission is operating under bad interference or insufficient radio coverage, and that flow control to the WTRU radio bearer can be performed on the DeNB, on the RN, or both. The DL status report may indicate an overflow with a low Uu transmission NACK rate. This may indicate a Uu resource scheduling problem or a Uu bandwidth shortage problem. The DeNB can use this information to adjust the Un configuration of the RN, which may allow the RN to configure and / or use more DL Uu resources. The DL status report may indicate an underflow with a low Uu transmission NACK rate. This may indicate over-resource scheduling or over-DL Uu bandwidth allocation. The DeNB can use this information to adjust the Un configuration of the RN, for example, to reduce the allocation to this RN's Un to use resources for other RNs or the macro WTRU.

[0098] The RN downlink data buffer status may be included in the RN BSR or in a separate RN report to the DeNB, such as a Un Subframe Configuration Report.

[0099] The RN DL buffer status may include the total downlink buffered data in the RN (including control plane and / or user plane data). The RN DL buffer status may include the sum of downlink buffer accumulation for active WTRU RBs of one or more WTRUs, or for active WTRU RBs belonging to one or more reporting WTRU groups. The grouping of WTRUs into downlink reporting WTRU groups may be similar to or assigned differently from uplink reporting WTRU groups. The RN DL buffer status may include the sum of downlink buffer accumulation (or an indication of the sum or range) for active WTRU RBs associated with one or more QoS data streams, or for active WTRU RBs associated with one or more QoS groups. The downlink reporting QoS grouping configuration may be similar to or assigned differently from the uplink reporting QoS groups. The RN DL buffer status may include any combination of the above.

[0100] The downlink buffer status may indicate the actual count (eg, byte count), a value representing this count (such as an index in a look-up table), or a value representing a range within which this count falls.

[0101] The RN DL buffer status may be transmitted in one or more of the following embodiments: The RN downlink buffer status report may be transmitted together with the RN uplink buffer status report. The RN DL buffer status may be reported alone when explicitly configured, when there is no buffered uplink data, or when the status of the buffered uplink data does not trigger a BSR (e.g., based on a threshold). The RN downlink buffer status may be transmitted periodically or in response to an explicit request from the DeNB. When the BSR is reported via the MAC CE, the MAC BSR CE may be identified by the logical channel identification (LCID) in the MAC header. When the downlink buffer status is reported alone or together with the uplink BSR, a new LCID or equivalent may be used for the DL BSR or mixed UL / DL BSR report. The LCID in the MAC CE of the downlink buffer status report may be defined similarly to the uplink BSR LCID.

[0102] A DL BSR report may be triggered based on a comparison of the RN Uu DL buffer buildup and the RN Un DL buffer buildup. A DL RN BSR report may be triggered if the RN Un DL buffer buildup is greater or less than the RN Uu DL buffer buildup by a threshold (configured or pre-determined).

[0103] In another embodiment, the RN may report a WTRU buffer status report to the DeNB. Figure 3 shows reporting of a WTRU BSR to the DeNB. The RN receives WTRU BSRs from multiple WTRUs served by the RN (302). The WTRU BSR indicates uplink buffer status at the WTRU, which reflects uplink data accumulation for the RN Uu interface. The RN then forwards the WTRU BSR to the DeNB (304).

[0104] This information can be used to support DeNB management of radio resources. In some types of relaying (e.g., half-duplex type 1 relaying, where the Uu and Un interfaces operate in the same frequency band), transmission on Un causes interference to reception on Uu, and vice versa. In such cases, resources on Uu and Un can be allocated to reduce such interference. If the DeNB understands the needs of the RN Uu, it can take this into account when allocating resources on Un.

[0105] The WTRU BSR may be relayed to the DeNB on a per RN WTRU basis. The RN may sum up the LCG loads of the WTRUs. Other information (such as the current Uu UL resource allocation status or allocated subframes) may also be provided from the RN to the DeNB, along with the Uu UL NACK rate, to serve as an indication, for example, regarding the Uu link transmission and Uu UL bandwidth allocation conditions.

[0106] The RN may report to the DeNB for each WTRU: buffer overflow with a high NACK rate, which may indicate poor transmission conditions; buffer overflow with a low NACK rate, which may indicate Uu bandwidth limitation (if the RN determines so); buffer underflow with a low NACK rate, which may indicate Uu bandwidth over-allocation. These indications may be derived by the RN from individual WTRU BSRs and other information. These indications may be sent to the DeNB as part of the RN BSR or in a special report to the DeNB (e.g., a report for Un reconfiguration).

[0107] WTRU BSR reports may be grouped in one or more of the following ways: The BSRs of the WTRUs reporting a BSR may be summed; Alternatively, the BSRs of a particular set of WTRUs may be summed; Alternatively, the WTRU BSRs may be reported individually; Alternatively, the BSRs for a particular LCG value (e.g., LCG=0) from the WTRUs reporting a BSR may be aggregated; Alternatively, the BSRs for each of the four LCGs may be aggregated separately, resulting in a total of four from the WTRUs reporting a BSR. When the WTRU BSRs are grouped and an aggregated BSR for the group is reported, the number of WTRUs in the group may also be reported.

[0108] The reported buffer status in each case can be the actual count (e.g., byte count), a value representing this count (such as an index in a lookup table), or a value representing a range within which this count falls.

[0109] The RN may include individual and / or aggregated WTRU BSRs in the RN BSR separately or together with other buffer status report content, or these WTRU BSRs may be in separate reports. When reporting the WTRU BSR to the DeNB, the RN may include the Uu subframe configuration to the DeNB.

[0110] In another embodiment, the RN may include a satisfaction indicator in the RN BSR (or another report) that indicates whether the RN is satisfied with its resource allocations with respect to the current traffic load and the RN's transmit and receive operations. The satisfaction indicator may indicate the degree of satisfaction.

[0111] When determining the satisfaction indicator value, the RN may take into account Un uplink resources and traffic load (e.g., uplink load for allocated Un uplink resources, e.g., as indicated by the RN UL BS, RN Un uplink power headroom, RN transmit NACK rate), Un downlink transmission and load (e.g., RN Un downlink receive NACK rate, and / or RN CQI detection conditions), Uu uplink resources and load (e.g., RN WTRU BSR, RN WTRU power headroom report (PHR), RN WTRU SRS measurements, RN Uu resource allocation), or Uu downlink resources, load, and transmission (RN DL buffer status, RN DL transmit NACK rate, RN WTRU-CQI report), etc.

[0112] The satisfaction indicator may be included in the RN BSR or other report and may be sent periodic or when specifically requested by the DeNB. The satisfaction indicator may be a single bit or multiple bits. The satisfaction indicator may be defined as a table of conditions / status including some or all or more of the parameters discussed above. The indicator may be an index value into the satisfaction indicator table. There may be multiple satisfaction indicators to indicate satisfaction status related to different sets of criteria.

[0113] In the following, embodiments for grouping RN BSR reports are disclosed. As disclosed above, RN DBRs can be grouped into multiple reporting groups, and the buffer accumulation status of each reporting group can be reported to the DeNB. BSR reports can be grouped per QoS and per WTRU.

[0114] If the RN DRBs are organized per QoS, a reporting QoS group ID can be assigned to each RN DRB via dedicated signaling by the DeNB, e.g., at RN DRB establishment time. If the RN DRBs are organized per WTRU, a reporting WTRU group ID can be assigned to each RN DRB via dedicated signaling by the DeNB, e.g., at RN DRB establishment time. The assignment of RN DRBs to reporting groups can be reassigned or revoked. RN DRBs with a revoked reporting group ID can be treated as if the reporting group ID was not assigned.

[0115] An RN DRB may not be assigned to a reporting group. In this case, the RN may report the RN DRB BSR alone or in conjunction with the BSRs of other assigned reporting group(s). Individual RN DRB BSR reports may also be triggered independently.

[0116] In one embodiment, RN-DRBs are organized based on QoS, and RN DRBs may be assigned to reporting QoS groups based on the QoS requirements of the RN DRBs. For example, QoS may be defined based on QCI or traffic class. RN DRBs may be grouped into reporting QoS groups based on traffic class. In this case, the reporting QoS groups may correspond to conversational, streaming, interactive, and background traffic classes. RN DRBs may be assigned to reporting QoS groups based on these characteristics.

[0117] Alternatively, RN DRBs can be grouped based on QCI. In this case, up to nine QoS groups can be defined. Some QCIs can be combined together, such as QCI8 and QCI9. RN DRBs with the same QCI value (or multiple same QCI values, if several QCI values ​​are combined into one group) can be assigned to a given reporting QoS group.

[0118] Alternatively, RN DRBs may be grouped based on the QCI for their resource type, where RN DRBs with QCI QoS values ​​corresponding to resource type guaranteed bit rate (GBR) may be assigned to one reporting QoS group, and RN DRBs with QCI values ​​corresponding to resource type non-GBR may be assigned to another reporting QoS group.

[0119] Alternatively, the RN DRBs may be grouped based on the QCI, by their packet delay budget, or by their packet error or loss rate, or by a combination of some of these with resource type and priority. For example, the RN DRBs may be grouped based on the QCI resource type and their delay budget attributes, with exemplary groupings being resource type GBR with a delay budget of 150 milliseconds or less, resource type GBR with a delay budget of 300 milliseconds, resource type non-GBR with a delay budget of 100 milliseconds, and resource type non-GBR with a delay budget of 300 milliseconds. In another example, the RN DRBs may be grouped based on resource type GBR with various packet error or loss rates, or resource type non-GBR with various delay budgets.

[0120] Alternatively, RN DRBs may be grouped based on allocation and retention priority (ARP) characteristics (i.e., ARP priority, ARP preemption capability, or ARP preemption vulnerability, either individually or in combination with some or all of these).

[0121] Alternatively, RN DRBs can be grouped based on their QCI characteristics along with their ARP characteristics in various combinations, for example, resource type GBRs with ARP preemption capability="yes" and ARP preemption vulnerability="no" in one reporting group, resource type GBRs with ARP preemption capability="no" and ARP preemption vulnerability="no" in another reporting group, and the rest with various delay budgets in another group.

[0122] Alternatively, RN DRBs can be grouped based on their QoS parameters, which are defined by priority values ​​assigned to logical channels, which are used by logical channel prioritization at the MAC layer.

[0123] When the RN BSR is triggered, the RN sums up the available data in the buffers (uplink, or uplink + downlink) assigned to the reporting group(s) and returns the assigned reporting group ID and the actual or transformed size. Indication The BSR record can be formatted to include the total buffered data (for one group or for each group) and the converted size Indication can be a value (such as an index into a lookup table) that represents the buffer size or a range of buffer sizes within which the buffer size falls.

[0124] In another embodiment, the RN DRBs are organized per WTRU, and the RN DRBs may be assigned to reporting WTRU groups based on the characteristics of the WTRU(s) mapped to it. The RN DRBs are assigned to reporting WTRU groups based on the WTRU's current QoS category (Q UE ) into reporting WTRU groups.

[0125] In one embodiment, the WTRU current QoS category Q UEmay be determined by the data radio bearer with the highest required or prioritized QoS on the WTRU (i.e., Q UE =WTRU RB's highest Q val ). Q val Q is a value that reflects or is redefined from the QoS assignment or association of the data radio bearer by the network. val Q can be a QCI value in a QCI table, or a priority value in a QCI table, or can be defined as an aggregation of these and other factors in a table, taking into account RN operating characteristics. val and Q UE Q val or Q UE The lower the value, the higher the QoS requirement or priority it may imply. For example, suppose a WTRU currently has three active (i.e., not suspended) data radio bearers, which have been assigned or associated with QCI values ​​by the network as their QoS allocation / classification, and thus Q val With values ​​2, 4, and 7, the WTRU current QoS category may be 2. In this embodiment, the highest prioritized WTRU DRB (and therefore WTRU or RN DRB) reporting activity on the RN may be recognized and biased in some way to appropriately support subsequent resource scheduling efforts made by the DeNB with respect to the highest prioritized WTRU DRB and WTRU.

[0126] In another embodiment, the WTRU current QoS category Q UE can be determined by the combination of data radio bearer QoS on the WTRU (or multiple WTRUs) that are mapped to the RN DRB. For example, Q of an active WTRU DRB valThe sum of the values ​​may be used to take into account the RBs with higher priority QCIs as well as the number of active DRBs for the WTRU (i.e., WTRUs with more active DRBs may get a higher QoS category). For example, if the WTRU QoS category value Q UE can be determined as follows: Q UE =(Q val-1 +Q val-2 +...+Q val-m +defQ val-m+1 +...+defQ val-w ) / w formula (1) In the above equation, Q val-1 ,Q val-2 ...Q val-m is the normalized / transformed Q of m active DRBs val value, w is the maximum number of WTRU DRBs allowed (e.g., 8), and defQ val is the value for the remaining inactive DRBs among the m maximum WTRU DRBs, where defQ val The values ​​are normalized / transformed maximum Q values ​​from the QCI table. val is equal to a value (e.g., 9). For example, Q val A WTRU with two active DRBs, with values ​​2 and 3, val may have a lower WTRU QoS category value than another WTRU with three active DRBs, with values ​​2, 3 and 4, val A WTRU with two active DRBs, with values ​​2 and 3, val may have a higher WTRU QoS category value than a WTRU with two active DRBs, with values ​​3 and 4, etc. The resulting Q UE may require some rounding and mapping (eg, to a set of ranges) to get a reasonable set of groups for per-WTRU reporting WTRU grouping.

[0127] In another embodiment, the WTRU current QoS category Q UEcan be determined by a weighted combination of Qval on the WTRU. Different scaling factors can be applied to the Qval values ​​in equation (1) according to their priority, allowing more highly prioritized Qval values ​​to be counted more in the combination. For example, the WTRU QoS category value Q UE can be determined as follows: Q UE =(u1Q val-1 +u2Q val-2 +...+u m Q val-m +u w defQ val-m+1 +...+u w defQ val-w ) / w formula (2) In the above equation, Q val-1 ,Q val-2 ,...,Q val-m is the normalized / transformed Q of m active DRBs val are the values ​​u1,u2,...,u m Q val It is a multiplier for the value.

[0128] Magnification u x may be predetermined by definition (e.g., u x =[1.0,1.1,1.2,1.3...,1.9,2.0]). Alternatively, the scaling factor is Q val The lower the value, the x It may be determined by default rules to have a small value (e.g., the Q assigned to a GBR data radio bearer). val For values, u x Q can be 1.0 and Q can be assigned to non-GBR data radio bearers val For values, u x (The scaling factor can be 1.3.) Alternatively, the scaling factor can be determined by the network.

[0129] Alternatively, Q in Eq. (2) UE is the magnification u as follows: x (multiple possible values) can also be taken into account for normalization. QUE =(u1Q val-1 +u2Q val-2 +...+u m Q val-m +u w defQ val-m+1 +...+u w defQ val-w ) / U Equation (3) In the above equation, U = sum (u1, u2, ..., u m ) The resulting Q UE may require some rounding and mapping (eg, to a set of ranges) to get a reasonable set of groups for per-WTRU reporting WTRU grouping.

[0130] In this embodiment, the higher prioritized Q val The highest prioritized Q val and the number of active DRBs in the WTRU. UE A controlled balance can be achieved with respect to the final result.

[0131] In another embodiment, the WTRU current QoS category Q UE can be determined by the current aggregated prioritized bit rate (PBR) of the active DRBs on the WTRU. In terms of using the WTRU QoS category to report WTRU group assignment, the larger the aggregated bit rate, the larger the WTRU QoS category value. One example of an aggregated bit rate is summing the PBRs of the WTRU's active DRBs.

[0132] When an RN BSR is triggered, the RN may sum up the available data in the buffers (uplink, or uplink+downlink) assigned to the reporting WTRU group (or each of multiple reporting WTRU groups) and format a BSR record that includes the assigned reporting WTRU group ID(s) and the total buffered data (for a group or groups) either actual or transformed size indication. The transformed size indication may be a value (such as an index into a lookup table) that represents the buffer size or a range within which the buffer size falls.

[0133] WTRU control plane traffic that does not terminate in the RN can be grouped into one reporting group. There may be several control plane bearers over the Un for control signaling between the DeNB and the RN. These control channels include at least the S1-AP from the MME / Serving Gateway (S-GW), the X2-AP to each potential target eNB, and the RRC protocol between the DeNB and the RN. These channels can be grouped together as one RN SRB or multiple RN SRBs. In either case, they can be grouped into one reporting group for buffer status reporting and other reports.

[0134] If the RN DRB is organized per RN, one DRB is configured, in which case some of its component streams or sub-data streams (corresponding to the WTRU DRB or some other aggregation scheme) can be grouped for BSR reporting purposes for better reporting granularity in addition to total reporting of all accumulated data in the RN.

[0135] Reporting can be configured for the RN as a general configuration, or can be configured or ordered individually for sub-streams in a per RN DRB configuration by the DeNB. BSR reporting groups can be organized per WTRU or per WTRU group(s). In this case, individual buffer status for one or more WTRUs or a sum for one or more reporting WTRU groups can be reported. Grouping can be performed in a similar manner as disclosed above. BSR reporting groups can be organized per QoS or per QoS group(s). In this case, individual or aggregated data buffer accumulation status for one or more QoS or QoS groups can be reported. Grouping can be performed in a similar manner as disclosed above.

[0136] In the following, embodiments for triggering an RN BSR report are disclosed. It can be noted that these embodiments can be used independently, together, or as a subpart of another embodiment. The embodiments for triggering an RN BSR can be applied to any type of RN BSR disclosed above.

[0137] In one embodiment, the RN may be configured with trigger events such that an RN BSR is generated and sent by the RN upon the occurrence of certain events, including, but not limited to, buffer accumulation exceeding a threshold, buffer accumulation falling below a threshold, expiration of a timer that may be restarted by other triggers (such as a command from the DeNB or buffer accumulation rising above or falling below a threshold), etc.

[0138] In another embodiment, the DeNB can explicitly trigger the RN for an RN BSR. For example, if the configured BSR trigger does not occur frequently enough or if the DeNB needs some immediate BSR before reconfiguring the cell, the DeNB can trigger a BSR for specific RN(s). When the DeNB triggers an RN BSR report, the DeNB can specify the required status type in the report (e.g., whether the report may include an uplink BSR, a downlink BSR, or both, or a WTRU BSR, or a satisfaction indicator, or a combination thereof) and / or the reporting group (such as which DRB group (per WTRU or per QoS), which SRB group, or a combination thereof). The response from the RN can be sent via an RRC message or a MAC message.

[0139] In another embodiment, the RN may be configured with a periodic timer to send BSR reports periodically, so that when the periodic timer expires, an RN BSR is generated and sent regardless of the amount of data in the corresponding buffer. Periodic RN BSR reporting can be activated if a special flag indicates activation (such as a periodic reporting flag provided to the RN in a message from the DeNB). The RN can send periodic BSR reports if threshold-related parameters are not configured for event-triggered reporting. If a specific period is not specified, default values ​​can be used.

[0140] In another embodiment, the event trigger can be configured in conjunction with a periodic timer. For example, a threshold related to buffer accumulation volume (e.g., a byte count or byte count range) can be used in conjunction with the periodic timer. The threshold can be a low buffer accumulation mark and / or a high buffer accumulation mark. The buffer accumulation count can be considered normal when it is between the low and high marks. If the buffer accumulation is lower than the low mark, this may mean that the RN load has somehow reduced or contracted. On the other hand, if the buffer accumulation count is higher than the high mark, this may mean that the link conditions are poor or that there are insufficient resources allocated to transmit the load.

[0141] 5 is a flow diagram of an example process 500 that combines event-triggered and periodic BSR reporting in one embodiment. In this embodiment, the RN reports BSR(s) based on buffer accumulation, i.e., based on a comparison with one or more thresholds (e.g., low and / or high marks). When one or more of the thresholds are crossed, the RN reports BSRs periodically based on a configured periodic timer. When buffer accumulation is normal (e.g., between the low and high marks), the RN can stop sending periodic reports for one or more reporting periods for the RN. Each report may be for one or more RN-DRBs or one or more reporting groups, or may be for one or more WTRU RBs based on configuration and / or buffer accumulation.

[0142] When the periodic timer expires (502), the RN evaluates (504) the buffer accumulation status (all, or one or more explicitly configured or default sets) (e.g., using one or more preconfigured buffer accumulation marks). The periodic timer is initially set to its original configured value. If the buffer accumulation is determined to be normal (i.e., between the low and high marks) during this period, the RN further determines (506) whether the buffer accumulation status has changed normally during this period (or whether the buffer accumulation status has remained normal for the last predetermined number (m) of periods).

[0143] If the buffer accumulation status changed to normal during this period (or the buffer status has remained normal for the last m periods), the RN reports a BSR 508. If the buffer accumulation status did not change to normal during this period (or the buffer accumulation status has remained normal for more than the last m periods), the RN need not report a BSR, and the periodic timer can be reset to N times its originally configured value, and process 500 returns to step 502 to wait for the periodic timer to expire.

[0144] If the buffer accumulation is below the low mark, the RN reports a BSR (510). The RN may report a BSR for the reporting group or RN DRB that triggered the BSR. Alternatively, the RN may report a BSR for the default reporting group(s) or RN DRB(s) in addition to the BSR for the triggering RN DRB or reporting group. The RN may reset the periodic timer to its original configured value if it has changed (512), and the process returns to step 502.

[0145] If the buffer accumulation is higher than the high mark, the RN reports a BSR (514). The RN can report a BSR for the reporting group or RN DRB that triggers the BSR. Alternatively, the RN can report the triggered BSR, the triggered BSR and the default BSR, or all BSRs. The RN can reset the periodic timer to its originally configured value if it has changed (516).

[0146] The next time the periodic timer expires, the RN evaluates the buffer accumulation status (all, or one or more specifically configured or default sets) 518. If the buffer accumulation is determined to be above the high mark in step 520, the RN reports 522 the triggered BSRs, the triggered BSRs and the default BSR, or all BSRs, and process 500 returns to step 518.

[0147] If in step 520 it is determined that the buffer accumulation is not above the high mark, the RN may report (524) the BSR(s) (e.g., the previous BSR triggered by rising above the high mark, the new BSR triggered by falling below the low mark, the default BSR(s), all, etc.) and the process returns to step 502 (or returns to step 518 if the buffer accumulation has been below the high mark for a predetermined time (which may be defined by the standard or configured by the DeNB or any network entity), or returns to step 502 if not).

[0148] The thresholds (e.g., high and / or low marks) used for event-triggered reporting or for a combination of periodic and event-triggered reporting may be fixed. Alternatively, the thresholds may be semi-statically configured by the network. Alternatively, the thresholds may be calculated by the RN, e.g., dynamically in response to rising and falling aggregate throughput values ​​of a BSR reporting unit. For example, the thresholds may be related to the aggregate GBR or AMBR from each of the component radio bearers of a basic BSR reporting unit, as appropriate, or to the bucket size (obtained by multiplying the prioritized bit rate by the buffer size duration) of that component radio bearer of the basic BSR reporting unit.

[0149] For RN BSR reporting, a time-to-trigger value can be configured so that the BSR is triggered when the threshold is crossed and maintained for a time period equal to or greater than the time-to-trigger value.

[0150] In one embodiment, an RN BSR can be piggybacked into a MAC PDU if there is space available in the MAC PDU. A periodic timer can be employed to trigger the piggybacked RN BSR generation. The piggybacked RN BSR may be triggered based on the availability of at least some predetermined size of unfilled space in the MAC PDU. The predetermined size can be defined to hold a certain minimum RN BSR, or several or categories or combinations of RN BSRs, and other related traffic information (such as uplink RN SRB reports, or high priority uplink BSRs, or uplink BSRs and downlink BSRs).

[0151] The piggybacked RN BSR may have a buffer accumulation threshold, so that a BSR is generated, for example, when the buffer accumulation is lower than the low mark and / or higher than the high mark. The threshold may have a looser value to generate a piggybacked RN BSR (e.g., the piggybacked BSR trigger threshold may have a low mark and a lower high mark that are higher by an offset (which may be a default value in the standard or may be signaled by the DeNB or a network entity).

[0152] The piggyback RN BSR trigger time may be the time close to the next periodic timer, as follows: Trigger time ≥ previous report time + (periodic timer value) / 2 Equation (4) Trigger time ≥ (previous report time + periodic timer value) - T offset Formula (5) In the above equation, T offset may be a default value defined in the standard or may be signaled by the DeNB or any network entity.

[0153] A piggyback RN BSR can be generated if there is space and the timing is correct, or if there is space and a threshold event is triggered, or if there is space and the timer has recently passed a predefined tolerance. If a piggyback RN BSR is sent, the periodic timer can be restarted. If the timer expires and there is no piggyback space, the RN can wait until there is a grant or there are subframe resources available for a full RN BSR, or it can initiate an uplink grant request action (defined for the RN).

[0154] Embodiment 1. A method for supporting communication via relay nodes.

[0155] 2. The method of embodiment 1, comprising: a relay node receiving WTRU BSRs from a plurality of WTRUs served by the relay node, the WTRU BSRs indicating uplink buffer status at the WTRUs.

[0156] 3. The method of embodiment 2, comprising the relay node sending the WTRU BSR to the DeNB.

[0157] 4. The method of any one of embodiments 2-3, further comprising the relay node sending a relay node BSR to the DeNB, the relay node BSR indicating a relay node uplink buffer status and / or a relay node downlink buffer status at the relay node.

[0158] 5. The method of embodiment 4, wherein the relay node uplink buffer status is generated based on a sum of uplink buffer accumulations for active WTRU radio bearers (RBs) of one or more WTRUs, or for active WTRU RBs belonging to one or more reporting groups.

[0159] 6. The method of any one of embodiments 4-5, wherein the relay node downlink buffer status is generated based on a sum of downlink buffer accumulations for active WTRU RBs of one or more WTRUs or for active WTRU RBs belonging to one or more reporting groups.

[0160] 7. The method of any one of embodiments 5-6, wherein the reporting groups are organized per WTRU or per QoS associated with the WTRU DRB.

[0161] 8. A method according to any one of embodiments 4 to 7, wherein the relay node BSR is triggered periodically, triggered based on the occurrence of a configured trigger event, or triggered based on a combination of a periodic timer and the occurrence of a configured trigger event.

[0162] 9. The method of any one of embodiments 2-8, wherein the WTRU BSR is reported to the DeNB individually or several WTRU BSRs are aggregated in groups.

[0163] 10. The method of any one of embodiments 2-8, further comprising sending a satisfaction indicator indicating whether the relay node is satisfied with its resource allocation.

[0164] 11. A method for supporting communication via relay nodes.

[0165] 12. The method of embodiment 11, comprising the relay node sending an RRC message to the DeNB to request radio resource configuration or reconfiguration, conditional on a handover request acknowledgement message being received from the DeNB in ​​response to a request for handover of the WTRU from the relay node to the handover target.

[0166] 13. The method of any one of embodiments 11-12, comprising, conditional on data transfer to the DeNB being completed for the WTRU, the relay node sending an RRC message to the DeNB to request radio resource configuration or reconfiguration.

[0167] 14. The method of any one of embodiments 11-13, comprising, on condition that an end marker is received, the relay node sending an RRC message to the DeNB to request radio resource configuration or reconfiguration.

[0168] 15. The method of any one of embodiments 11-14, comprising, on condition that a WTRU context release message is received, the relay node sending an RRC message to the DeNB to request radio resource configuration or reconfiguration.

[0169] 16. The method of any one of embodiments 11-15, comprising the relay node sending an RRC message to the DeNB indicating a need for configuration or reconfiguration, if the WTRU application changes quality of service requirements.

[0170] 17. The method of any one of embodiments 11-16, comprising the relay node sending an RRC message to the DeNB to indicate a need for configuration or reconfiguration, provided that the adjustment to the WTRU-relay node interface affects the relay node-DeNB interface configuration.

[0171] 18. The method of any one of embodiments 11-17, comprising, upon a condition that the relay node transitions from a connected state to an idle state, the relay node sending an RRC message to the DeNB to indicate a need for configuration or reconfiguration.

[0172] 19. The method of any one of embodiments 11-18, comprising the relay node sending an RRC message to the DeNB indicating a need for configuration or reconfiguration, if some of the system information parameter values ​​change.

[0173] 20. The method of any one of embodiments 11-19, comprising the relay node sending an RRC message to the DeNB indicating a need for configuration or reconfiguration, conditional on the total WTRU uplink buffers exceeding a threshold.

[0174] 21. The method of any one of embodiments 11-20, comprising the relay node sending an RRC message to the DeNB indicating a need for configuration or reconfiguration, on condition that the total relay node downlink buffers exceed a threshold.

[0175] 22. The method of any one of embodiments 11-21, comprising, if a WTRU-relay node interface needs to be reconfigured, the relay node sending an RRC message to the DeNB to indicate the need for configuration or reconfiguration.

[0176] 23. A relay node comprising a transceiver and a processor configured to receive WTRU BSRs from a plurality of WTRUs served by the relay node.

[0177] 24. The relay node of embodiment 23, wherein a processor is configured to send a WTRU BSR to the DeNB, the WTRU BSR indicating an uplink buffer status at the WTRU.

[0178] 25. A relay node as in any one of embodiments 23-24, wherein a processor is configured to generate and send a relay node BSR to the DeNB.

[0179] 26. The relay node of embodiment 25, wherein the relay node BSR indicates a relay node uplink buffer status and / or a relay node downlink buffer status at the relay node.

[0180] 27. The relay node of embodiment 26, wherein the processor is configured to generate a relay node uplink buffer status based on a sum of uplink buffer accumulations for active WTRU RBs of one or more WTRUs or for active WTRU RBs belonging to one or more reporting groups.

[0181] 28. The relay node in any one of 26-27, wherein the processor is configured to generate a relay node downlink buffer status based on a sum of downlink buffer accumulations for active WTRU RBs of one or more WTRUs or for active WTRU RBs belonging to one or more reporting groups.

[0182] 29. The relay node of any one of embodiments 27-28, wherein reporting groups are organized per WTRU or per QoS associated with a WTRU DRB.

[0183] 30. A relay node according to any one of embodiments 25 to 29, wherein the relay node BSR is triggered periodically, triggered based on the occurrence of a configured trigger event, or triggered based on a combination of a periodic timer and the occurrence of a configured trigger event.

[0184] 31. The relay node of any one of embodiments 23-30, wherein the WTRU BSRs are reported to the DeNB individually or several WTRU BSRs are aggregated in groups.

[0185] 32. A relay node as in any one of embodiments 23-31, wherein the processor is configured to send a satisfaction indicator indicating whether the relay node is satisfied with its resource allocation.

[0186] 33. A relay node comprising a transceiver and a processor configured to send an RRC message to a DeNB to request radio resource configuration or reconfiguration, conditional on a handover request acknowledgement message being received from the DeNB in ​​response to a request for handover of a WTRU from the relay node to a handover target.

[0187] 34. The relay node of embodiment 33, wherein the processor is configured to send an RRC message to the DeNB to request radio resource configuration or reconfiguration, conditional on data transfer to the DeNB being completed for the WTRU.

[0188] 35. The relay node of any one of embodiments 33-34, wherein the processor is configured to send an RRC message to the DeNB to request radio resource configuration or reconfiguration, on condition that an end marker is received.

[0189] 36. The relay node of any one of embodiments 33-35, wherein the processor is configured to send an RRC message to the DeNB to request radio resource configuration or reconfiguration, conditional on the WTRU context release message being received.

[0190] 37. The relay node of any one of embodiments 33-36, wherein the processor is configured to send an RRC message to the DeNB to indicate a need for configuration or reconfiguration, conditional on the WTRU application changing quality of service requirements.

[0191] 38. The relay node of any one of embodiments 33-37, wherein the processor is configured to send an RRC message to the DeNB to indicate a need for configuration or reconfiguration, provided that the adjustment to the WTRU-relay node interface affects the relay node-DeNB interface configuration.

[0192] 39. The relay node of any one of embodiments 33-38, wherein the processor is configured to, upon a condition that the relay node transitions from a connected state to an idle state, send an RRC message to the DeNB to indicate a need for configuration or reconfiguration.

[0193] 40. The relay node of any one of embodiments 33-39, wherein the processor is configured to send an RRC message to the DeNB to indicate a need for configuration or reconfiguration, conditional on some of the system information parameter values ​​changing.

[0194] 41. The relay node of any one of embodiments 33-40, wherein the processor is configured to send an RRC message to the DeNB to indicate a need for configuration or reconfiguration, conditional on the total WTRU uplink buffers exceeding a threshold.

[0195] 42. The relay node of any one of embodiments 33-41, wherein the processor is configured to send an RRC message to the DeNB to indicate a need for configuration or reconfiguration, conditional on the total relay node downlink buffers exceeding a threshold.

[0196] 43. The relay node of any one of embodiments 33-42, wherein the processor is configured to, on the condition that the WTRU-relay node interface needs to be reconfigured, send an RRC message to the DeNB to indicate the need for configuration or reconfiguration.

[0197] While features and elements have been described above in specific embodiments, one skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, 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, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer can be implemented using a processor in association with software. [Industrial Applicability]

[0198] The present invention can be generally applied to wireless communication systems. [Explanation of symbols]

[0199] 100 Wireless Communication System 102a to 102d Radio Transmit / Receive Unit (WTRU) 104 RAN 106 Core Network 108 PSTN 110 Internet 112 other networks 114a, 114b base station 118 processors 120 Transmitter / Receiver

Claims

1. 1. A method for use in a wireless node, comprising: combining and transmitting a first buffer status report (first BSR) with a second BSR in a single medium access control (MAC) protocol data unit (PDU) to a first base station, the first BSR being associated with first data for transmission from at least one wireless transmit / receive unit (WTRU) to the wireless node, and the second BSR being associated with second data for transmission from the wireless node to the first base station; receiving at least a portion of the first data from the at least one WTRU; transmitting at least a portion of the second data to the first base station; A method for providing the above.

2. The method of claim 1 , wherein the steps of transmitting the first BSR and the second BSR are based on a priority associated with the first BSR and a priority associated with the second BSR.

3. 10. The method of claim 1, further comprising receiving a third BSR from the at least one WTRU, wherein the first BSR is transmitted based on the third BSR.

4. The method of claim 3 , wherein the third BSR is associated with the first data.

5. The method of claim 1 , wherein the wireless node is a second base station.

6. The method of claim 1 , wherein the first base station is a donor base station.

7. A wireless node, A transmitter / receiver, a processor operatively coupled to the transceiver; Equipped with the transceiver and the processor are configured to combine and transmit a first buffer status report (first BSR) with a second BSR in a single medium access control (MAC) protocol data unit (PDU) to a first base station, the first BSR being associated with first data for transmission from at least one wireless transmit / receive unit (WTRU) to the wireless node, and the second BSR being associated with second data for transmission from the wireless node to the first base station; the transceiver is configured to receive at least a portion of the first data from the at least one WTRU; the transceiver and the processor are configured to transmit at least a portion of the second data to the first base station. Wireless node.

8. 8. The wireless node of claim 7, wherein transmitting the first BSR and the second BSR is based on a priority associated with the first BSR and a priority associated with the second BSR.

9. 8. The wireless node of claim 7, wherein the transceiver is further configured to receive a third BSR from the at least one WTRU, and wherein the first BSR is transmitted based on the third BSR.

10. The wireless node of claim 9 , wherein the third BSR is associated with the first data.

11. The wireless node of claim 7 , wherein the wireless node is a second base station.

12. The wireless node of claim 7 , wherein the first base station is a donor base station.

13. a first base station, A transmitter / receiver, a processor operatively coupled to the transceiver; Equipped with the transceiver is configured to receive, in a single Medium Access Control (MAC) Protocol Data Unit (PDU), a first buffer status report (first BSR) combined with a second BSR from a wireless node, the first BSR being associated with first data for transmission from at least one wireless transmit / receive unit (WTRU) to the wireless node, and the second BSR being associated with second data for transmission from the wireless node to the first base station; the transceiver configured to receive at least a portion of the second data from the wireless node; A first base station.

14. The first base station of claim 13, wherein the wireless node is a second base station.

15. The first base station of claim 13 , wherein the first base station is a donor base station.

16. 1. A method for use in a first base station, comprising: receiving a first buffer status report (first BSR) combined with a second BSR from a wireless node in a single medium access control (MAC) protocol data unit (PDU), the first BSR being associated with first data for transmission from at least one wireless transmit / receive unit (WTRU) to the wireless node, and the second BSR being associated with second data for transmission from the wireless node to the first base station; receiving at least a portion of the second data from the wireless node; A method for providing the above.

17. 17. The method of claim 16, wherein the wireless node is a second base station.

18. The method of claim 16 , wherein the first base station is a donor base station.

Images