U.S. patent application number 13/075961 was filed with the patent office on 2011-10-27 for method and apparatus for supporting communication via a relay node.
This patent application is currently assigned to INTERDIGITAL PATENT HOLDINGS, INC.. Invention is credited to Mihaela C. Beluri, Kai Liu, Janet A. Stern-Berkowitz, Nobuyuki Tamaki, Stephen E. Terry, Peter S. Wang.
Application Number | 20110261747 13/075961 |
Document ID | / |
Family ID | 44072712 |
Filed Date | 2011-10-27 |
United States Patent
Application |
20110261747 |
Kind Code |
A1 |
Wang; Peter S. ; et
al. |
October 27, 2011 |
METHOD AND APPARATUS FOR SUPPORTING COMMUNICATION VIA A RELAY
NODE
Abstract
A method and apparatus for supporting communication via a relay
node are disclosed. A relay node may receive wireless
transmit/receive unit (WTRU) buffer status reports (BSRs) from a
plurality of WTRUs that are served by the relay node. The WTRU BSRs
indicate uplink buffer status at the WTRUs. The relay node then may
forward the WTRU BSRs to a donor evolved Node B (DeNB). The relay
node may send a relay node BSR to the DeNB. The relay node BSR
indicates a relay node uplink buffer status and/or a relay node
downlink buffer status at the relay node. The relay node may send a
radio resource control (RRC) message to the DeNB for requesting
radio resource reconfiguration.
Inventors: |
Wang; Peter S.; (E.
Setauket, NY) ; Stern-Berkowitz; Janet A.; (Little
Neck, NY) ; Tamaki; Nobuyuki; (Manhasset, NY)
; Terry; Stephen E.; (Northport, NY) ; Beluri;
Mihaela C.; (Huntington, NY) ; Liu; Kai; (S.
Huntington, NY) |
Assignee: |
INTERDIGITAL PATENT HOLDINGS,
INC.
Wilmington
DE
|
Family ID: |
44072712 |
Appl. No.: |
13/075961 |
Filed: |
March 30, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61320644 |
Apr 2, 2010 |
|
|
|
61320535 |
Apr 2, 2010 |
|
|
|
61373555 |
Aug 13, 2010 |
|
|
|
Current U.S.
Class: |
370/315 |
Current CPC
Class: |
H04B 7/155 20130101;
H04W 40/22 20130101; H04W 72/1221 20130101; H04W 36/08 20130101;
H04W 72/0446 20130101; H04W 16/26 20130101; H04W 28/0278 20130101;
H04W 84/047 20130101 |
Class at
Publication: |
370/315 |
International
Class: |
H04B 7/14 20060101
H04B007/14 |
Claims
1. A method for supporting communication via a relay node, the
method comprising: a relay node receiving WTRU buffer status
reports (BSRs) from a plurality of wireless transmit/receive unit
(WTRUs) that are served by the relay node, wherein the WTRU BSRs
indicate uplink buffer status at the WTRUs; and the relay node
sending the WTRU BSRs to a donor evolved Node B (DeNB).
2. The method of claim 1 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.
3. The method of claim 2 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 active
WTRU RBs belonging to one or more reporting groups, and 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
active WTRU RBs belonging to one or more reporting groups.
4. The method of claim 3 wherein the reporting groups are organized
per-WTRU or per-quality of service (QoS) associated with a WTRU
DRB.
5. The method of claim 2 wherein the relay node BSR is triggered
either periodically, based on occurrence of a configured triggering
event, or based on combination of a periodic timer and occurrence
of a configured triggering event.
6. The method of claim 1 wherein the WTRU BSRs are reported to the
DeNB individually or some WTRU BSRs are aggregated on a
group-basis.
7. The method of claim 1 further comprising: sending a satisfaction
indicator indicating whether the relay node is satisfied or not
with its resource allocation.
8. A method for supporting communication via a relay node, the
method comprising: the relay node sending a radio resource control
(RRC) message to a donor eNode B (DeNB) for requesting radio
resource configuration or reconfiguration on a condition that a
handover request acknowledge message is received from the DeNB in
response to a request for handover for a wireless transmit/receive
unit (WTRU) from the relay node to a handover target, data
forwarding to the DeNB is completed for the WTRU, an end marker is
received, or a WTRU context release message is received.
9. The method of claim 8 further comprising: the relay node sending
an RRC message to the DeNB to indicate a need for configuration or
reconfiguration on a condition that a WTRU application changes
quality of service requirements, adjustment on a WTRU-relay node
interface affects a relay node-DeNB interface configuration, the
relay node transitions from a connected state to an idle state,
some of system information parameter values change, a total WTRU
uplink buffer exceeds a threshold, a total relay node downlink
buffer exceeds a threshold, and/or when a WTRU-relay node interface
needs to be reconfigured.
10. A relay node comprising: a transceiver; and a processor
configured to receive WTRU buffer status reports (BSRs) from a
plurality of wireless transmit/receive unit (WTRUs) that are served
by the relay node, and send the WTRU BSRs to a donor evolved Node B
(DeNB), wherein the WTRU BSRs indicate uplink buffer status at the
WTRUs.
11. The relay node of claim 10 wherein the processor is configured
to generate, and send, 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.
12. The relay node of claim 11 wherein the processor is configured
to generate the relay node uplink buffer status based on a sum of
uplink buffer accumulations for active WTRU radio bearers (RBs) of
one or more WTRUs, or active WTRU RBs belonging to one or more
reporting groups, and generate the relay node downlink buffer
status based on a sum of downlink buffer accumulations for active
WTRU RBs of one or more WTRUs, or active WTRU RBs belonging to one
or more reporting groups.
13. The relay node of claim 12 wherein the reporting groups are
organized per-WTRU or per-quality of service (QoS) associated with
a WTRU DRB.
14. The relay node of claim 11 wherein the relay node BSR is
triggered either periodically, based on occurrence of a configured
triggering event, or based on combination of a periodic timer and
occurrence of a configured triggering event.
15. The relay node of claim 10 wherein the WTRU BSRs are reported
to the DeNB individually or some WTRU BSRs are aggregated on a
group-basis.
16. The relay node of claim 10 wherein the processor is configured
to send a satisfaction indicator indicating whether the relay node
is satisfied or not with its resource allocation.
17. A relay node comprising: a transceiver; and a processor
configured to send a radio resource control (RRC) message to a
donor eNodeB (DeNB) for requesting radio resource configuration or
reconfiguration on a condition that a handover request acknowledge
message is received from the DeNB in response to a request for
handover for a wireless transmit/receive unit (WTRU) from the relay
node to a handover target, data forwarding to the DeNB is completed
for the WTRU, an end marker is received, or a WTRU context release
message is received.
18. The relay node of claim 17 wherein the processor is configured
to send an RRC message to the DeNB to indicate a need for
configuration or reconfiguration on a condition that a WTRU
application changes quality of service requirements, adjustment on
a WTRU-relay node interface affects a relay node-DeNB interface
configuration, the relay node transitions from a connected state to
an idle state, some of system information parameter values change,
a total WTRU uplink buffer exceeds a threshold, a total relay node
downlink buffer exceeds a threshold, and/or when a WTRU-relay node
interface needs to be reconfigured.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. provisional
application Nos. 61/320,644 filed Apr. 2, 2010, 61/320,535 filed
Apr. 2, 2010, and 61/373,555 filed Aug. 13, 2010 and, the contents
of which are hereby incorporated by reference herein.
BACKGROUND
[0002] In a wireless communication system, an eNodeB (eNB) assigns
air interface resources to wireless transmit/receive units (WTRUs)
for the transmission and reception of data. The eNB assigns
resources and the associated parameters, (e.g., modulation and
coding scheme), for transmission and reception of WTRUs so that the
quality of service (QoS) requirements, (e.g., delay, packet error
and loss rate, etc.), associated with the data for the WTRUs are
met while maintaining fairness to other WTRUs and maximizing
capacity, (i.e., the number of WTRUs it can serve).
[0003] WTRUs may provide the serving eNB with a WTRU buffer status
report (BSR) which tells the eNB the amount of available uplink
data stored in the WTRU uplink buffers that is ready for
transmission and retransmission. The BSR is used for QoS-aware
packet scheduling in the evolved UMTS terrestrial radio access
network (E-UTRAN).
[0004] Radio bearers (RBs) may be assigned quality of service (QoS)
parameters by the network. QoS parameters define service attributes
such as type of service, delay tolerance, and data error and loss
tolerance. A WTRU knowing the required QoS of its RBs may make
intelligent decisions on how to prioritize the RBs with respect to
which data to choose to transmit when resources are assigned. The
eNB may use this information to assign resources to WTRUs and
prioritize transmission such that each individual WTRU performance
and throughput requirements are as closely met as possible.
[0005] A QoS class identifier (QCI) may be used to define the QoS.
Table 1 shows QCI characteristics including a resource type, a
priority, a packet delay budget, and a packet error and loss rate.
Table 2 shows a mapping of the traffic classes to the QCIs.
TABLE-US-00001 TABLE 1 Packet Re- Packet Error source Delay Loss
QCI Type Priority Budget Rate Example Services 1 GBR 2 100 ms
10.sup.-2 Conversational voice 2 4 150 ms 10.sup.-3 Conversational
video (live streaming) 3 3 50 ms 10.sup.-3 Real time gaming 4 5 300
ms 10.sup.-6 Non-conversational video (buffered streaming) 5 Non- 1
100 ms 10.sup.-6 IMS signalling GBR 6 6 300 ms 10.sup.-6 Video
(Buffered Streaming),TCP- based (e.g., www, e-mail, chat, ftp, p2p
file sharing, progressive video, etc.) 7 7 100 ms 10.sup.-3 Voice,
Video (live streaming), interactive gaming 8 8 300 ms 10.sup.-6
Video (buffered streaming), TCP-based 9 9 (e.g., www, e-mail, chat,
ftp, p2p file sharing, progressive video, etc.)
TABLE-US-00002 TABLE 2 Traffic Source Traffic Handling Signalling
Statistics QCI Class Priority Indication Descriptor 1
Conversational N/A N/A Speech 2 Conversational N/A N/A Unknown 3
Conversational N/A N/A Unknown 4 Streaming N/A N/A Unknown 5
Interactive 1 Yes N/A 6 Interactive 1 No N/A 7 Interactive 2 No N/A
8 Interactive 3 No N/A 9 Background N/A N/A N/A
SUMMARY
[0006] A method and apparatus for supporting communication via a
relay node are disclosed. A relay node may receive wireless
transmit/receive unit (WTRU) buffer status reports (BSRs) from a
plurality of WTRUs that are served by the relay node. The WTRU BSRs
indicate uplink buffer status at the WTRUs. The relay node then may
forward the WTRU BSRs to a donor evolved Node B (DeNB).
[0007] The relay node may send a relay node BSR to the DeNB. The
relay node BSR indicates a relay node uplink buffer status and/or a
relay node downlink buffer status at the relay node. 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 active WTRU RBs belonging to one or more reporting
groups, and 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 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 a WTRU DRB. The relay
node BSR may be triggered either periodically, based on occurrence
of a configured triggering event, or based on combination of a
periodic timer and occurrence of a configured triggering event.
[0008] The relay node may send a radio resource control (RRC)
message to the DeNB for requesting radio resource reconfiguration.
For example, the relay node may send the RRC message to the DeNB on
a condition that the handover request acknowledge message is
received from the DeNB, data forwarding to the DeNB is completed,
the end marker is received, and/or the WTRU context release message
is received.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] A more detailed understanding may be had from the following
description, given by way of example in conjunction with the
accompanying drawings wherein:
[0010] FIG. 1A is a system diagram of an example communications
system in which one or more disclosed embodiments may be
implemented;
[0011] FIG. 1B is a system diagram of an example WTRU that may be
used within the communications system illustrated in FIG. 1A;
[0012] FIG. 1C is a system diagram of an example radio access
network and an example core network that may be used within the
communications system illustrated in FIG. 1A;
[0013] FIG. 2 shows an example system including an RN;
[0014] FIG. 3 shows reporting WTRU BSRs to the donor eNB
(DeNB);
[0015] FIG. 4 is a signaling diagram of an example handover
procedure; and
[0016] FIG. 5 is a flow diagram of an example process of combined
event-triggered and periodic BSR reporting in one embodiment.
DETAILED DESCRIPTION
[0017] FIG. 1A is a diagram of an example communications system 100
in which one or more disclosed embodiments may be implemented. The
communications system 100 may be a multiple access system that
provides content, such as voice, data, video, messaging, broadcast,
etc., to multiple wireless users. The communications system 100 may
enable multiple wireless users to access such content through the
sharing of system resources, including wireless bandwidth. For
example, the communications systems 100 may 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), and the like.
[0018] As shown in FIG. 1A, the communications system 100 may
include wireless transmit/receive units (WTRUs) 102a, 102b, 102c,
102d, a radio access network (RAN) 104, a core network 106, a
public switched telephone network (PSTN) 108, the Internet 110, and
other networks 112, though it will be appreciated that the
disclosed embodiments contemplate any number of WTRUs, base
stations, networks, and/or network elements. Each of the WTRUs
102a, 102b, 102c, 102d may be any type of device configured to
operate and/or communicate in a wireless environment. By way of
example, the WTRUs 102a, 102b, 102c, 102d may be configured to
transmit and/or receive wireless signals and may include user
equipment (WTRU), a mobile station, a fixed or mobile subscriber
unit, a pager, a cellular telephone, a personal digital assistant
(PDA), a smartphone, a laptop, a netbook, a personal computer, a
wireless sensor, consumer electronics, and the like.
[0019] The communications systems 100 may also include a base
station 114a and a base station 114b. Each of the base stations
114a, 114b may be any type of device configured to wirelessly
interface with at least one of the WTRUs 102a, 102b, 102c, 102d to
facilitate access to one or more communication networks, such as
the core network 106, the Internet 110, and/or the networks 112. By
way of example, the base stations 114a, 114b may be a base
transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a
Home eNode B, a site controller, an access point (AP), a wireless
router, and the like. While the base stations 114a, 114b are each
depicted as a single element, it will be appreciated that the base
stations 114a, 114b may include any number of interconnected base
stations and/or network elements.
[0020] The base station 114a may be part of the RAN 104, which may
also include other base stations and/or network elements (not
shown), such as a base station controller (BSC), a radio network
controller (RNC), relay nodes, etc. The base station 114a and/or
the base station 114b may be configured to transmit and/or receive
wireless signals within a particular geographic region, which may
be referred to as a cell (not shown). The cell may further be
divided into cell sectors. For example, the cell associated with
the base station 114a may be divided into three sectors. Thus, in
one embodiment, the base station 114a may include three
transceivers, i.e., one for each sector of the cell. In another
embodiment, the base station 114a may employ multiple-input
multiple output (MIMO) technology and, therefore, may utilize
multiple transceivers for each sector of the cell.
[0021] 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 communication 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).
[0022] More specifically, as noted 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,
and the like. For example, the base station 114a in the RAN 104 and
the WTRUs 102a, 102b, 102c may implement a radio technology such as
Universal Mobile Telecommunications System (UMTS) Terrestrial Radio
Access (UTRA), which may establish the air interface 116 using
wideband CDMA (WCDMA). WCDMA may include communication protocols
such as High-Speed Packet Access (HSPA) and/or Evolved HSPA
(HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA)
and/or High-Speed Uplink Packet Access (HSUPA).
[0023] In another embodiment, the base station 114a and the WTRUs
102a, 102b, 102c may implement a radio technology such as Evolved
UMTS Terrestrial Radio Access (E-UTRA), which may establish the air
interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced
(LTE-A).
[0024] In other embodiments, the base station 114a and the WTRUs
102a, 102b, 102c may implement radio technologies such as IEEE
802.16 (i.e., Worldwide Interoperability for Microwave Access
(WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard
2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856
(IS-856), Global System for Mobile communications (GSM), Enhanced
Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the
like.
[0025] The base station 114b in FIG. 1A may be a wireless router,
Home Node B, Home eNode B, or access point, for example, and may
utilize any suitable RAT for facilitating wireless connectivity in
a localized area, such as a place of business, a home, a vehicle, a
campus, and the like. In one embodiment, the base station 114b and
the WTRUs 102c, 102d may implement a radio technology such as IEEE
802.11 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.
Thus, the base station 114b may not be required to access the
Internet 110 via the core network 106.
[0026] The RAN 104 may be in communication with the core network
106, which may be any type of network configured to provide voice,
data, applications, 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, pre-paid calling,
Internet connectivity, video distribution, etc., and/or perform
high-level security functions, such as user authentication.
Although not shown in FIG. 1A, it will be appreciated that the RAN
104 and/or the core network 106 may be in direct or indirect
communication with other RANs that employ the same RAT as the RAN
104 or a different RAT. For example, in addition to being connected
to the RAN 104, which may be utilizing an E-UTRA radio technology,
the core network 106 may also be in communication with another RAN
(not shown) employing a GSM radio technology.
[0027] 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
circuit-switched telephone networks that provide 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 the transmission control
protocol (TCP), user datagram protocol (UDP) and the internet
protocol (IP) in the TCP/IP internet protocol suite. The networks
112 may include wired or wireless communications networks owned
and/or operated by other service providers. For example, the
networks 112 may include another core network connected to one or
more RANs, which may employ the same RAT as the RAN 104 or a
different RAT.
[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the
communications system 100 may include multi-mode capabilities,
i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple
transceivers for communicating with different wireless networks
over different wireless links. For example, the WTRU 102c shown in
FIG. 1A may be configured to communicate with the base station
114a, which may employ a cellular-based radio technology, and with
the base station 114b, which may employ an IEEE 802 radio
technology.
[0029] FIG. 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 106,
removable memory 132, a power source 134, a global positioning
system (GPS) chipset 136, and other peripherals 138. It will be
appreciated that the WTRU 102 may include any sub-combination of
the foregoing elements while remaining consistent with an
embodiment.
[0030] The processor 118 may be a general purpose processor, a
special purpose processor, a conventional processor, a digital
signal processor (DSP), a plurality of microprocessors, one or more
microprocessors in association with a DSP core, a controller, a
microcontroller, Application Specific Integrated Circuits (ASICs),
Field Programmable Gate Array (FPGAs) circuits, any other type of
integrated circuit (IC), a state machine, and the like. The
processor 118 may perform signal coding, data processing, power
control, input/output processing, and/or any other functionality
that enables the WTRU 102 to operate in a wireless environment. The
processor 118 may be coupled to the transceiver 120, which may be
coupled to the transmit/receive element 122. While FIG. 1B depicts
the processor 118 and the transceiver 120 as separate components,
it will be appreciated that the processor 118 and the transceiver
120 may be integrated together in an electronic package or
chip.
[0031] The transmit/receive element 122 may be configured to
transmit signals to, or receive signals from, a base station (e.g.,
the base station 114a) over the air interface 116. For example, in
one embodiment, the transmit/receive element 122 may be an antenna
configured to transmit and/or receive RF signals. In another
embodiment, the transmit/receive element 122 may be an
emitter/detector configured to transmit and/or receive IR, UV, or
visible light signals, for example. In yet another embodiment, the
transmit/receive element 122 may be configured to transmit and
receive both RF and light signals. It will be appreciated that the
transmit/receive element 122 may be configured to transmit and/or
receive any combination of wireless signals.
[0032] In addition, although the transmit/receive element 122 is
depicted in FIG. 1B 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.
[0033] The transceiver 120 may be configured to modulate the
signals that are to be transmitted by the transmit/receive element
122 and to demodulate the signals that are received by the
transmit/receive element 122. As noted above, the WTRU 102 may have
multi-mode capabilities. Thus, the transceiver 120 may include
multiple transceivers for enabling the WTRU 102 to communicate via
multiple RATs, such as UTRA and IEEE 802.11, for example.
[0034] The processor 118 of the WTRU 102 may be coupled to, and may
receive user input data from, the speaker/microphone 124, the
keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal
display (LCD) display unit or 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. In addition, the processor 118 may access information from,
and store data in, any type of suitable memory, such as the
non-removable memory 106 and/or the removable memory 132. The
non-removable memory 106 may include random-access memory (RAM),
read-only memory (ROM), a hard disk, or any other type of memory
storage device. The removable memory 132 may include a subscriber
identity module (SIM) card, a memory stick, a secure digital (SD)
memory card, and the like. In other embodiments, the processor 118
may access information from, and store data in, memory that is not
physically located on the WTRU 102, such as on a server or a home
computer (not shown).
[0035] The processor 118 may receive power from the power source
134, and may be configured to distribute and/or control the power
to the other components in the WTRU 102. The power source 134 may
be any suitable device for powering the WTRU 102. For example, the
power source 134 may include one or more dry cell batteries (e.g.,
nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride
(NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and
the like.
[0036] The processor 118 may also be coupled to the 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 in lieu of, the information from the GPS
chipset 136, the WTRU 102 may receive location information over the
air interface 116 from a base station (e.g., base stations 114a,
114b) and/or determine its location based on the timing of the
signals being received from two or more nearby base stations. It
will be appreciated that the WTRU 102 may acquire location
information by way of any suitable location-determination method
while remaining consistent with an embodiment.
[0037] The processor 118 may further be coupled to other
peripherals 138, which may include one or more software and/or
hardware modules that provide additional features, functionality
and/or wired or wireless connectivity. For example, the peripherals
138 may include an accelerometer, an e-compass, a satellite
transceiver, a digital camera (for photographs or video), a
universal serial bus (USB) port, a vibration device, a television
transceiver, a hands free headset, a Bluetooth.RTM. module, a
frequency modulated (FM) radio unit, a digital music player, a
media player, a video game player module, an Internet browser, and
the like.
[0038] FIG. 1C is a system diagram of the RAN 104 and the core
network 106 according to an embodiment. As noted above, the RAN 104
may employ an E-UTRA radio technology to communicate with the WTRUs
102a, 102b, 102c over the air interface 116. The RAN 104 may also
be in communication with the core network 106.
[0039] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it
will be appreciated that the RAN 104 may include any number of
eNode-Bs while remaining consistent with an embodiment. The
eNode-Bs 140a, 140b, 140c may each include one or more transceivers
for communicating with the WTRUs 102a, 102b, 102c over the air
interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may
implement MIMO technology. Thus, the eNode-B 140a, for example, may
use multiple antennas to transmit wireless signals to, and receive
wireless signals from, the WTRU 102a.
[0040] Each of the eNBs 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 in the uplink and/or downlink, and the like. As shown in FIG.
1C, the eNBs 140a, 140b, 140c may communicate with one another over
an X2 interface.
[0041] The core network 106 shown in FIG. 1C may include a mobility
management gateway (MME) 142, a serving gateway 144, and a packet
data network (PDN) gateway 146. While each of the foregoing
elements are depicted as part of the core network 106, it will be
appreciated that any one of these elements may be owned and/or
operated by an entity other than the core network operator.
[0042] The MME 142 may be connected to each of the eNBs 142a, 142b,
142c in the RAN 104 via an S1 interface and may serve as a control
node. For example, the MME 142 may be responsible for
authenticating users of the WTRUs 102a, 102b, 102c, bearer
activation/deactivation, selecting a particular serving gateway
during an initial attach of the WTRUs 102a, 102b, 102c, and the
like. 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.
[0043] The serving gateway 144 may be connected to each of the eNBs
140a, 140b, 140c in the RAN 104 via the S1 interface. The serving
gateway 144 may generally route and forward user data packets
to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may
also perform other functions, such as anchoring user planes during
inter-eNB handovers, triggering paging when downlink data is
available for the WTRUs 102a, 102b, 102c, managing and storing
contexts of the WTRUs 102a, 102b, 102c, and the like.
[0044] The serving gateway 144 may also be connected to the 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.
[0045] The core network 106 may facilitate communications with
other networks. For example, the core network 106 may provide the
WTRUs 102a, 102b, 102c with access to circuit-switched networks,
such as the PSTN 108, to facilitate communications between the
WTRUs 102a, 102b, 102c and traditional land-line communications
devices. For example, the core network 106 may include, or may
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 the networks 112, which
may include other wired or wireless networks that are owned and/or
operated by other service providers.
[0046] FIG. 2 shows an example 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 (called 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 a link to the core network 106 for the
RN 150. To R8 and R9 WTRUs, the RN cell looks like an regular R8
and R9 cell under an eNB. The RN 150 is used as a tool to improve
the coverage and to enhance cell-edge throughput.
[0047] An RN WTRU 102 is a WTRU that has an RN as its serving cell.
A macro WTRU 103 is a WTRU that has an eNB (including DeNB) as its
serving cell. A Uu interface is an air interface between the RN
WTRU 102 and the RN 150 or between the macro WTRU 103 and the eNB
140. The Uu interface between the RN WTRU 102 and the RN 150 will
be referred as RN Uu or simply Uu interface, and the Uu interface
between the macro WTRU 103 and the eNB 140 will be referred to as a
macro Uu interface. A Un interface is an air interface between the
RN 150 and its DeNB 140. Hereafter, the terminologies "RN WTRU" may
be referred to as "WTRU" and "RN Uu" may be referred to as "Uu" for
simplicity.
[0048] A Uu RB or WTRU RB (including both DRB and SRM) is an RB
configured for service to and from a WTRU 102, 103. A Un RB or RN
RB (including both DRB and SRB) is an RB configured for a radio
bearer over Un between the DeNB 140 and the RN 150. An RN radio
network temporary identity (RNTI) is an identifier allocated by the
DeNB 140 for the RN 150.
[0049] WTRU UL RB data destined for the network is transmitted by
the WTRU 102 in MAC PDUs over the Uu to the RN 150 and then
transmitted by the RN 150 in MAC PDUs over the Un to the DeNB 140.
The DeNB 140 forwards it to the network 106. The DL transmissions
occur in the reverse process.
[0050] The RN 150 may be an in-band relaying node, (called "Type 1"
RN). The Type 1 RN controls cells, each of which appears to a 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 channels,
reference symbols, etc. In the context of single cell operation,
the WTRUs may receive scheduling information and hybrid automatic
repeat request (HARQ) feedback directly from the RN and send its
control channels to the RN.
[0051] For the Type 1 RN, the eNB-RN link (Un) shares the same
carrier frequency with the RN-WTRU links (RN Uu). Depending on the
implementation of the RN, 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 into its reception. For RNs that does not support
simultaneous transmission and reception, time division multiplexing
of the Un and RN Uu interfaces may be used to avoid conflict.
[0052] The DeNB configures and reconfigures radio resources for RNs
at the cell level or individually for a specific RN. For example,
the DeNB configures the Un subframes in the Un for the
communication between the DeNB and the RN. For example, the DeNB
may transmit to the RN on the Un during the periods configured as
multimedia broadcast over single frequency network (MBSFN)
subframes on the RN Uu link. MBSFN subframes are subframes that
WTRUs understand to be reserved for multimedia broadcast multicast
services (MBMS) transmissions so the WTRUs do not expect the RN to
transmit data unless specifically told of MBMS transmissions in
these subframes. Rather than using these subframes for MBMS, the RN
may transmit and receive to and from the DeNB without having to
transmit to WTRUs.
[0053] If the Un configuration does not change at the cell level,
the DeNB may send a dedicated radio resource control (RRC)
signaling or any equivalent signaling or message to a specific
RN(s). The RRC signaling or equivalent signaling or message may
specify the parameters for reconfiguration, such as a downlink Un
subframe mask or a new Un subframe allocation pattern, the uplink
Un subframe allocation, the subframe offset between the Un and Uu,
an activation time, and the like. If the activation time is
specified, the RN may maintain the current operation with the DeNB
over the Un interface before the activation time, and at the
activation time, the RN may receive and transmit over the Un
interface in accordance with the reconfiguration.
[0054] If any Un changes result in the need for the RN to
reconfigure its Uu configuration, (which may be included in the RN
Uu system information block (SIB)), the RN may turn on the system
information change indicator in the paging messages over the RN Uu,
update the system information in the SIB as required, and publish
the new system information at the SIB modification period
boundary.
[0055] WTRUs may provide the RN with a WTRU BSR which indicates the
amount of available uplink data stored in the WTRU uplink buffers
that is ready for transmission and retransmission. The buffer
status may be reported as an index into a table which provides a
buffer size range. Depending on the number of logical channels
having data available for transmission and the size of the padding
space (in case the BSR is triggered by the MAC PDU padding), the
BSR may be formatted and transmitted one of three ways: truncated
BSR, short BSR, and long BSR.
[0056] A truncated BSR is a one LCG BSR which contains the buffer
status of the LCG with the highest priority logical channel. The
truncated LCG is used when there is more than one LCG with
available data but there is not enough room in the MAC PDU to
transmit a BSR for all. A short BSR is a one LCG BSR which contains
the buffer status of one LCG. A short BSR is used when there is
only one LCG with available data to transmit. A long BSR is a four
LCG BSR which contains the buffer status of the four (4) LCGs. If
there is no data for a LCG, the buffer size value for that LCG is
reported as index 0.
[0057] The basic channel and bearer-related unit for the BSR is a
logical channel group (LCG). An LCG includes one or more logical
channels from a WTRU assigned by the eNB at the logical channel
configuration. This logical channel grouping mechanism in BSR
reporting is to limit the reporting load while retaining some
reporting granularity. A WTRU data radio bearer (DRB) is associated
with a WTRU logical channel together with a logical channel
identity, a logical channel configuration, and other attributes
such as an evolved packet system (EPS) identity, a radio bearer
(RB) identity, packet data convergence protocol (PDCP) and radio
link control (RLC) configuration information. Four LCGs (values
0-3) may be used for the 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. WTRU signaling
radio bearers (SRBs) are by default assigned to LCG=0.
[0058] The RN reports various types of statuses to the DeNB. For
example, the RN may report buffer status and other traffic load
conditions to the DeNB to support the DeNB in making resource
allocations for the RN or the cell. The buffer status information
may be sent via a MAC CE. Details of buffer status reporting will
be explained below.
[0059] The RN may send a PDCP status PDU to reflect the Un downlink
reception status of the received PDCP PDUs. The status granularity
may depend on how the RN Un PDCP instances are configured. The RN
Un PDCP instances may be configured for each WTRU radio bearer, or
per RN DRB either per QoS-based or per WTRU-based. The PDCP status
PDU may be used to report the current accumulated uplink PDCP SDUs
per UL bearer in a WTRU, per UL QoS bearer, or per UL WTRU at the
RN. The PDCP status reports may be useful indicators when handover
of a WTRU occurs.
[0060] The RN may send an RRC message(s) to the DeNB to indicate
the changing situations or conditions in the RN to trigger or
assist the DeNB for adjusting the Un resource allocation or
configurations that may affect the RN Uu interface configurations.
The RRC message(s) may carry a report(s) of one or more
measurements. The measurements may include the traffic status in
the DL Uu of the RN, the buffer status, the measured aggregated
data rate, link quality, (e.g., positive acknowledgement/negative
acknowledgement (ACK/NACK) rate), conditions in DL Uu when
resources are over or under utilized, and the like. New RRC
messages or new information elements (IEs) may be defined for the
reporting.
[0061] The reporting may be periodic or trigger-based. A timer(s),
a threshold(s), and quantities for the reported measurements may be
configured, for example, by RRC signaling. The DeNB may request an
immediate report. The RN may initiate a request for reconfiguration
and may include reporting values in the reconfiguration request
message to support the request.
[0062] FIG. 4 is a signaling diagram of an example handover
procedure. The RN configures the WTRU measurements (402). The WTRU
sends measurement reports to the RN in accordance with 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 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).
[0063] The target eNB/RN performs an admission control (412). The
target eNB/RN prepares for the handover and sends a handover
request acknowledgement 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. The container includes a new cell radio network temporary
identity (C-RNTI), target eNB security algorithm identifiers for
the selected security algorithms, may include a dedicated random
access channel (RACH) preamble, and the like.
[0064] The RN sends an RRC message to perform the handover, (i.e.,
RRC connection reconfiguration message including the mobility
control information), to the WTRU (418). After receiving the RRC
connection reconfiguration message, the WTRU detaches from the old
cell and performs synchronization and an initial access procedure
with the new cell (420). As soon as the RN receives the handover
request acknowledge, or as soon as the transmission of the handover
command is initiated in the downlink, data forwarding from the RN
to the target eNB/RN may be initiated (422). When the WTRU has
successfully accessed the target cell, the WTRU sends the RRC
connection reconfiguration complete message to the target eNB/RN to
confirm the handover (424). The target eNB/RN may now begin sending
and receiving data to and from the WTRU and the serving gateway
(426).
[0065] The target eNB/RN sends a path switch message to the
mobility management entity (MME) to inform that the WTRU has
changed a cell (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), and sends one or
more "end marker" packets on the old path to the RN and then may
release any user plane/TNL resources towards the RN (434). To
assist the reordering function in the target eNB/RN, the serving
gateway may send one or more "end marker" packets on the old path
immediately after switching the path for the WTRU. Upon receiving
the "end marker" packets, the RN forwards the end marker packet to
the target eNB/RN (436). On detection of the end marker, the target
eNB/RN initiates any necessary processing to maintain in-sequence
delivery of user data forwarded over X2 interface and user data
received from the serving GW over S1 as a result of the path switch
(438).
[0066] The serving gateway sends a user plane update response
message to the MME (440). The MME confirms the path switch message
with the path switch acknowledge message (442). By sending WTRU
context release message to the RN, the target eNB/RN informs
success of handover to the RN and triggers the release of resources
by the RN (444). Upon reception of the WTRU context release
message, the RN may release radio and C-plane related resources
associated to the UE context (446).
[0067] When a WTRU is to be handed over to a different eNB or RN,
the data forwarding path may be established or widened over the Un
interface between the RN and the DeNB for forwarding the WTRU data
existing in the RN to the DeNB and beyond. After the WTRU completes
the 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 the RN receives a handover request acknowledge
message from the DeNB for a WTRU handing over from the RN to a
different eNB or RN, or when the RN has received a handover request
acknowledge message from the DeNB such that the resulting
aggregated Un traffic now may exceed a value that is the sum of the
currently configured bandwidth and a predefined or configured
threshold value.
[0068] The RN may send an RRC indication message to the DeNB when
the RN finishes forwarding the data for the concerned WTRU to the
DeNB, when the RN receives an end marker message or similar
indication from the network, or when the RN receives the WTRU
context release message from the network.
[0069] To reduce the signaling load and the Un reconfiguration
processing burden, the RN may send the RRC indication message for
the WTRU handover if the forwarding path bandwidth to be added or
removed is significantly impacting the Un capability configured for
the RN over a predefined or configured threshold. The threshold may
be configured as a data byte count or a percentage with respect to
the total bandwidth for the RN over the Un interface.
[0070] When the RN experiences a certain amount of data backlog or
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 BSRs), is over a threshold or below a
threshold, the RN may send an RRC indication message to the DeNB to
request for Un resource reconfiguration.
[0071] Parameters for a data volume change figure (V) and/or a time
figure (T) may be defined for such reporting. The parameter T may
be used as the minimum time a data backlog or underflow or a
bandwidth volume change amount may be above or below a threshold
before the RRC indication message may be sent. The parameter T may
be used as the minimum interval between the DeNB's last Un
(re)configuration message, (e.g., RRCConnectionReconfiguration),
and the new RRC indication message. The parameter V may be used as
the threshold for the data backlog/underflow or for the bandwidth
requirement change amount threshold.
[0072] In addition to providing WTRUs with the normal voice and
data services, the RN may provide other user applications and
services to the WTRUs. The setup or reconfiguration of these
applications may involve the DeNB unlike regular radio bearer
handling and, as a result, the DeNB may know that the Un interface
may be reconfigured. In this case, the RN may indicate the resource
requirements to the DeNB. For example, in case where the RN
provides multimedia broadcast multicast services (MBMS) services to
the WTRUs, the RN (when activating or deactivating certain MBMS
services) may indicate to the DeNB a request for downlink Uu
subframe reconfiguration and/or for Un bandwidth and subframe
configuration changes by sending an RRC indication message when the
RN-cell MBMS service(s) start and stop, or configurations
change.
[0073] The RN may send an RRC indication message to the DeNB for
other applications that may change the Uu/Un configuration or
bandwidth requirement and that the DeNB is not involved with their
start, stop, and/or changes. The RN may send an RRC indication
message to the DeNB when the WTRU application changes QoS
requirements, (e.g., a normal QoS requirement has changed to
require low jitter or low delay such that it cannot be guaranteed
by the current Un subframe allocation).
[0074] Both the RN and the DeNB monitor the channel quality. In the
Un uplink the DeNB may learn the RN transmission quality by the
hybrid automatic repeat request (HARQ) reception and the DeNB may
learn its Rn downlink transmission quality by the RN's feedback of
the channel quality indicator (CQI), rank indicator (RI), or
precoding matrix indicator (PMI). The DeNB may adjust the related
Un parameters without additional information from the RN.
[0075] The DeNB by itself does not know the RN-Uu link quality. For
an inband Type1 Relay, if there are many WTRUs over an unstable
RN-Uu interface, the allocation of the RN-Uu configuration may be
adjusted. This adjustment of RN-Uu configuration may affect the Un
configuration. In this case, the RN may transmit an RRC indication
message requesting some RN-Uu configuration change if that change
affects the configuration on the Un interface.
[0076] 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 operating 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
reconfiguration. For example, this may happen when a change occurs
on the following DeNB system information parameters: downlink
bandwidth change which affects the RN usage of the Un frequency
resource, 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, MBSFN
subframe configuration list which affects the Un subframe
allocation.
[0077] When the RN transitions from the connected state to the idle
state, the RN may notify the DeNB by an RRC indication message on
its intended detach, release or shutdown action so that the DeNB
may release the Un resource allocated to the RN as well as other
connections the RN has with various network nodes. The RN may leave
the connected state when the RN is shutdown by the local operation,
administration, and maintenance (OAM), (e.g., when the RN receives
the DETACH-ACCEPT or the signaling-connection-release message from
the core network), when the RN is detached or is ordered to
disconnect by the core network mobility management entity (MME),
(e.g., when the RN has replied to the network with the
DETACH-ACCEPT message), or when the RN has operational problems,
(e.g., the RN detects security violations or unrecoverable error
conditions over ciphering or integrity protection).
[0078] In case where the RN has a lot of WTRUs connected and the Uu
interface resource is either limited or the radio link quality is
low, the UL data may be accumulated at the WTRU side and the Uu DL
data may be buffered at the RN side. The DeNB may not know the data
accumulation status of WTRU UL buffer and RN DL buffer. In one
embodiment, the RN may send an indication to the DeNB when the
total WTRU UL buffer exceeds a threshold (detected from the WTRU
BSRs reported to the RN), or the total RN DL buffer exceeds a
threshold, to indicate to the DeNB that the Un interface needs to
be reconfigured to leave more resource to the Uu interface. The RN
may send an RRC indication message to the DeNB when the RN wants to
adjust the Uu interface configurations.
[0079] The RRC indication message may include a cause indicating
the purpose of the RRC indication message. The cause may be Un or
Uu resources related, such as a resource addition request for Un or
Uu, a resource reduction request for Un or Uu, a resource release
request, and the like. The RRC indication message may include other
cause or sub-cause including MBMS resource reconfiguration,
handover resource reconfiguration. The RRC indication message may
include an uplink bandwidth request (addition or reduction), and an
amount indication, the uplink Uu subframe change request, (e.g.,
add, reduce, shift), and/or the uplink power change request.
[0080] In the embodiments above, use of an RRC indication message
is an example and alternatively any other message(s) or information
elements in new or existing message(s) may be used.
[0081] Embodiments for reporting BSRs are disclosed hereafter.
[0082] In one embodiment, the RN may generate buffer status reports
(BSRs) for the RN DRBs, and send the reports to the DeNB. An RN
receives UL RBs from the WTRUs, and maps them to the UL RN DRBs.
The uplink data accumulated in the RN uplink buffers may be
organized and reported to the DeNB as the RN BSR contents. The
buffer status report may include an actual count of data, (e.g.,
byte count), and/or a value (such as an index into a look up table)
representing that count of data, and/or a value representing a
range in which the count falls. Other traffic volume related
information may also be reported as an independent item or be
reported in association with the byte count or equivalent.
[0083] The RN uplink buffers may be organized based on how the WTRU
RBs are mapped to the RN DRBs. The RN DRB may be organized per WTRU
such that the RBs of a WTRU map to one RN DRB (RBs of multiple
WTRUs may map to one RN DRB). Alternatively, the RN DRB 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 QoSes may map to one
RN DRB). Alternatively, the RN DRB may be organized per RN such
that the WTRU DRBs are mapped to a single RN DRB.
[0084] The RN BSR may include a buffer status of a single RN DRB.
The RN BSR may include the sum (or an indication of the sum or
range) of the uplink buffer accumulation of the active WTRU RBs
which are mapped to one RN DRB. The RN DRB may be identified by an
RN DRB ID (or equivalent).
[0085] Alternatively, the RN BSR may include a buffer status of a
single RN DRB reporting group. The RN BSR may include the sum (or
an indication of the sum or range) of the uplink buffer
accumulation of the active WTRU RBs which 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 an RN DRB reporting group ID
(or equivalent).
[0086] Alternatively, the RN BSR may include buffer statuses of
multiple RN DRB reporting groups. Each buffer status is the sum (or
an indication of the sum or range) of the uplink buffer
accumulation of the active WTRU RBs which are mapped to one or more
RN DRBs that belong to one RN DRB reporting group. The report may
include an 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 of the RN DRB reporting groups
in a predetermined order, (e.g., the order may be signaled to the
RN or may be fixed by the standard), such that the RN DRB reporting
group IDs may be omitted. If there are a set of predetermined
orders, (e.g., based on signaling to the RN or defined by the
standard), the report may use one of those orders and indicate in
the report which one is used, and the reporting group IDs may be
omitted.
[0087] Alternatively, the RN BSR may include a combination of
buffer status for one or more individual RN DRBs, the individual
buffer status of one or more RN DRB reporting groups, and/or the
sum of the buffer statuses from one or more RN DRB reporting
groups.
[0088] In case where the RN DRBs are organized per WTRU, the RN BSR
may include a sum (or an indication of the sum or range) of the
uplink buffer accumulation of the active RBs from the one WTRU,
which are mapped to one RN-DRB.
[0089] Alternatively, the RN BSR may include a sum (or an
indication of the sum or range) of the uplink buffer accumulation
of the active RBs from one or more WTRUs that are mapped to one or
more RN DRBs that belong to a reporting-WTRU-group. In this case,
the RN DRBs and/or the associated WTRU RBs are assigned with the
same reporting-WTRU-group-identifier.
[0090] Alternatively, the RN BSR may include the buffer statuses
for several reporting-WTRU-groups (with 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 the active RBs from one or more RN WTRUs that are mapped to one
or more RN DRBs that belong to a 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 of the reporting-WTRU-groups
in a predetermined order, (e.g., the order signaled to the RN or
configured by the standard), such that the
reporting-WTRU-group-identifiers may be omitted. Alternatively, if
there are a set of predetermined orders (e.g., based on signaling
to the RN or defined by the standard), the report may use one of
those orders and indicate in the report which is used, and the
reporting-WTRU-group-identifiers may be omitted.
[0091] Alternatively, the RN BSR may include a combination of
buffer status for 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 statuses from one or more
reporting-WTRU-groups.
[0092] In case where the RN DRBs are organized per-QoS, (e.g., by
DRB priority or QCI value), the RN BSR may include a sum (or an
indication of the sum or range) of the uplink buffer accumulation
of the active WTRU RBs with the one or more QoS which are mapped to
one RN-DRB.
[0093] Alternatively, the RN BSR may include a sum (or an
indication of the sum or range) of the uplink buffer accumulation
of the active WTRU RBs with the one or more QoS that are mapped to
one or more RN-DRBs that belong to a reporting-QoS-group. The RN
DRBs and/or the associated WTRU RBs may be assigned with the same
reporting-QoS-group-identifier.
[0094] Alternatively, the RN BSR may include the buffer status for
each of several reporting-QoS-groups (with one buffer status per
reporting-QoS-group) where each buffer status is the sum (or an
indication of the sum or range) of the uplink buffer accumulation
of the active WTRU RBs with the one or more QoS that are mapped to
one or more RN DRBs that belong to a 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 of the
reporting-QoS-groups in a predetermined order, (e.g., the order may
be signaled to the RN or may be fixed by the standard), such that
the reporting-QoS-group-identifiers may be omitted. Alternatively,
if there are a set of predetermined orders, (e.g., based on
signaling to the RN or defined by the standard), the report may use
one of those orders and indicate in the report which is used, and
the reporting-QoS-group-identifiers may be omitted.
[0095] Alternatively, the RN BSR may include a combination of
buffer status for 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 statuses from one or more
reporting-QoS-groups.
[0096] The uplink buffer status may be included in the RN BSR alone
or together with other aspects of buffer or traffic related
status.
[0097] In another embodiment, the RN may report RN downlink buffer
status to the DeNB. Downlink data buffered in the RN may be
reported to the DeNB to support DeNB management of radio resources.
For certain types of relays, (e.g., half-duplex type 1 relays
operating the Uu and Un interfaces in the same frequency band),
transmitting on the Un causes interference to reception on the Uu,
and vice versa. In such case, resources on the Uu and Un may be
allocated to reduce such interference. If the DeNB understands the
needs of the Relay Uu, the DeNB may take that into account it when
allocating resources on the Un.
[0098] The DL buffer status in the RN may indicate an overflow or
underflow situation. The report may include a cause, (e.g.,
shortage of Uu bandwidth or Uu transmission issues). The DL status
report may indicate an overflow with a high Uu transmission NACK
rate. This may indicate the downlink transmission is operating
under bad interference or under poor radio coverage and that a flow
control towards the WTRU radio bearer may be exercised 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 Uu bandwidth shortage problem. The
DeNB may use this information to adjust the Un configuration for
the RN which may enable 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 DL Uu bandwidth over allocation. The DeNB may use
this information to adjust the Un configuration for the RN, for
example to reduce the allocation to the Un for this RN and use the
resources for other RNs or macro WTRUs.
[0099] The RN downlink data buffer status may be included in the RN
BSR or in another RN report to the DeNB such as a Un subframe
configuration report.
[0100] The RN DL buffer status may include total downlink buffered
data (including control plane and/or user plane data) in the RN.
The RN DL buffer status may include a sum of the downlink buffer
accumulations for the active WTRU RBs of one or more WTRUs, or the
active WTRU RBs belonging to one or more reporting-WTRU-groups. The
grouping of the WTRUs into the downlink reporting-WTRU-groups may
be the same as in the uplink reporting-WTRU-groups, or it may be
assigned differently. The RN DL buffer status may include a sum (or
indication of a sum or range) of the downlink buffer accumulations
for the active WTRU RBs related to one or more QoS data streams, or
the active WTRU RBs related to one or more reporting-QoS-groups.
The downlink reporting-QoS-grouping configuration may be the same
as in the uplink reporting-QoS-group, or it may be assigned
differently. The RN DL buffer status may include any combination of
the above.
[0101] The downlink buffer status may indicate an actual count
(e.g., byte count), a value (such as an index in a look up table)
representing that count, or a value representing a range in which
the count falls.
[0102] 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 uplink data buffered, when the status
of the buffered uplink data is not triggering a BSR, (e.g., based
on thresholds). The RN downlink buffer status may be transmitted on
a periodic basis, or in response to an explicit request from the
DeNB. In case, the BSR is reported via a MAC CE, the MAC BSR CE may
be identified by the logical channel identity (LCID) in the MAC
header. When the downlink buffer status is reported either alone or
together with the uplink BSR, a new LCID or equivalent may be used
for the DL BSR or the mixed UL/DL BSR report. The LCID in the MAC
CE for downlink buffer status report may be defined similarly as
the uplink BSR LCID.
[0103] The DL BSR reporting may be triggered based on the
comparison of the RN Uu DL buffer accumulation with the RN Un DL
buffer accumulation. If the RN Un DL buffer accumulation is larger
than or smaller than the RN Uu DL buffer accumulation by a
threshold value (configured or predetermined), a DL RN BSR
reporting may be triggered.
[0104] In another embodiment, the RN may report WTRU buffer status
reports to the DeNB. FIG. 3 shows reporting WTRU BSRs to the DeNB.
An RN receives WTRU BSRs from a plurality of WTRUs that are served
by the RN (302). The WTRU BSRs indicate uplink buffer status at the
WTRUs, which reflects the uplink data accumulation for the RN Uu
interface. The RN then forwards the WTRU BSRs to the DeNB
(304).
[0105] This information may be used to support DeNB management of
radio resources. For certain types of relays (e.g., half-duplex
type 1 relays operating the Uu and Un interfaces in the same
frequency band) transmitting on the Un causes interference to
reception on the Uu, and vice versa. In such case, resources on the
Uu and Un may be allocated to reduce such interference. If the DeNB
understands the needs of the RN Uu, the DeNB may take it into
account when allocating resources on the Un.
[0106] The WTRU BSRs may be relayed to the DeNB in the basic unit
of RN WTRUs. The RN may sum the LCG loads of a WTRU. Other
information such as the current Uu UL resource allocation status or
the allocated subframes together with the Uu UL NACK rate may also
be provided by the RN to the DeNB to, for example, serve as the
indications for the Uu link transmission and Uu UL bandwidth
allocation conditions.
[0107] The RN may report to the DeNB for each WTRU the buffer
overflow with a high NACK rate, which may indicate poor
transmission conditions, the buffer overflow with a low NACK rate,
which may indicate Uu bandwidth restriction if RN determines that,
the buffer underflow with a low NACK rate, which may indicate the
Uu bandwidth over allocation. These indications may be derived by
the RN from the individual WTRU BSRs and other information. These
indications may be transmitted to the DeNB, either as part of the
RN BSR, or in a special report to DeNB, (e.g., one for Un
reconfiguration).
[0108] Reports of WTRU BSRs may be grouped in one or more of the
following ways. BSRs of the WTRUs that report BSR may be summed.
Alternatively, BSRs of a specific set of WTRUs may be summed.
Alternatively, WTRU BSR may be reported individually.
Alternatively, BSRs on a specific LCG value (e.g., LCG=0) from the
WTRUs reporting BSR may be aggregated. Alternatively, BSRs on each
of the four LCGs may be aggregated, respectively, resulting total
four from the WTRUs reporting BSR. When grouping the WTRU BSRs and
reporting an aggregated BSR for a group, the number of WTRUs in
that group may be reported.
[0109] The reported buffer status in each case may be an actual
count, (e.g., byte count), a value (such as an index in a look up
table) representing that count, or a value representing a range in
which the count falls.
[0110] The RN may include the individual and/or aggregated WTRU
BSRs in the RN BSR separately or together with other buffer status
report contents, or they may be in a separate report. When
reporting the WTRU BSRs to the DeNB, the RN may include the Uu
subframe configurations to the DeNB.
[0111] In another embodiment, the RN may include in the RN BSR (or
in another report) a satisfaction indicator which indicates whether
the RN is satisfied or not with its resource allocation with
respect to the current traffic load and its transmission and
reception operations. The satisfaction indicator may indicate the
degree of satisfaction.
[0112] When determining the satisfaction indicator value, the RN
may take into account the Un uplink resources and traffic load
(e.g., Un uplink resource allocated vs. the uplink load, for
example, as indicated by RN UL BS, RN Un uplink power head room, RN
transmission NACK rate), the Un downlink transmission and load,
(e.g., RN Un downlink reception NACK rate and/or RN CQI detection
conditions), the Uu uplink resource and load (e.g., RN WTRU BSRs,
RN WTRU power headroom reports (PHRs), RN WTRU SRS measurements, RN
Uu resource allocation), or the Uu downlink resource, load and
transmission (RN DL buffer status, RN DL transmission NACK rate, RN
WTRU-CQI reports), and the like.
[0113] The satisfaction indicator may be included in the RN BSR or
other reports, and may be sent regularly or when it is 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 on the conditions/status with some or all of the above
discussed parameters or more. The indicator may be an index value
into a satisfaction indicator table. There may be more than one
satisfaction indicator to indicate the satisfaction status related
to different sets of criteria.
[0114] Embodiments for grouping RN BSR reports are disclosed
hereafter. As disclosed above, the RN DRBs may be grouped into a
plurality of reporting groups and the buffer accumulation status of
each reporting group may be reported to the DeNB. The BSR reports
may be grouped per-QoS and per-WTRU.
[0115] If the RN DRBs are organized per-QoS, a
reporting-QoS-group-ID may be assigned to each RN DRB, for example,
at the RN DRB establishment via dedicated signaling by the DeNB. If
the RN DRBs are organized per-WTRU, a reporting-WTRU-group-ID may
be assigned to each RN DRB, for example, at the RN DRB
establishment via dedicated signaling by the DeNB. The assignment
of an RN DRB to a reporting group may be re-assigned or revoked. An
RN DRB with a revoked reporting group ID may be treated as if it
had not been assigned a reporting-group-ID.
[0116] An RN DRB may not be assigned to a reporting group. In this
case, the RN may report the RN DRB BSR alone, or may report it with
other assigned reporting group(s) BSRs. Individual RN DRB BSR
reporting may be triggered independently.
[0117] In one embodiment, the RN-DRBs are organized based on QoS,
and the RN DRBs may be assigned to a reporting-QoS-group based on
the QoS requirements of the RN DRB. For example, the QoS may be
defined based on a QCI or a traffic class. The RN DRBs may be
grouped into a reporting-QoS-group based on the traffic class. In
this case, the reporting-QoS-groups may correspond to the
conversational, streaming, interactive and background traffic
classes. The RN DRBs may be assigned to reporting-QoS-groups based
on these characteristics.
[0118] Alternatively, the RN DRBs may be grouped based on a QCI. In
this case, up to nine reporting-QoS-groups may be defined. Some
QCIs may be combined together, such as QCI 8 and QCI9. RN DRBs with
the same QCI value (or values if some are combined into one group)
may be assigned to a predetermined reporting-QoS-group.
[0119] Alternatively, the RN DRBs may be grouped based on a QCI per
their resource type. In this case, RN DRBs with the QCI QoS values
corresponding to the resource type guaranteed bit rate (GBR) may be
assigned to one reporting-QoS-group, and the RN DRBs with QCI
values corresponding to the resource type non-GBR may be assigned
to another reporting-QoS-group.
[0120] Alternatively, the RN DRBs may be grouped based on a QCI per
their packet delay budget or per their packet error or loss rate,
or by a combination of some of them with the resource type and
priority. For example, the RN DRBs may be grouped based on the
attributes of the QCI resource type and their delay budget, wherein
the example grouping may be: resource type GBR with delay budget
150 ms or below, resource type GBR with delay budget 300 ms,
resource type non-GBR with delay budget 100 ms, and resource type
non-GBR with delay budget 300 ms. In another example, the RN DRBs
may be grouped based on the resource type GBR with different packet
error or loss rates, or based on resource type Non-GBR with
different delay budgets.
[0121] Alternatively, the RN DRBs may be grouped based on the
allocation and retention priority (ARP) characteristics, (i.e., the
ARP-priority, the ARP-pre-emption capability, or the
ARP-pre-emption vulnerability, individually or a combination of
some or all of them).
[0122] Alternatively, the RN DRBs may be grouped based on their QCI
characteristics together with their ARP characteristics with
different combinations. For example, the resource type GBR with
ARP-pre-emption capability="yes" and the ARP-pre-emption
vulnerability="no" as one reporting group, the resource type GBR
with ARP-pre-emption capability="no" and the ARP-pre-emption
vulnerability="no" as another reporting group, and the rest with
their different delay budgets as another group.
[0123] Alternatively, the RN DRBs may be grouped based on their QoS
parameters as defined by the priority value assigned to the logical
channel. The priority value is used by logical channel
prioritization in the MAC layer.
[0124] When the RN BSR is triggered, the RN may sum the available
data in buffers (uplink, or uplink+downlink) assigned to a
reporting group(s) and format the BSR record with the assigned
reporting group ID and the total data buffered (for one group or
each group) in actual or converted size indication. The converted
size indication may be a value (such as an index into a look-up
table) representing the buffer size or range in which the buffer
size falls.
[0125] In another embodiment, the RN DRBs are organized per WTRU,
and the RN DRBs may be assigned to a reporting-WTRU-group based on
the characteristics of the WTRU (or WTRUs) mapped to it. The RN
DRBs may be grouped into a reporting-WTRU-group based on the WTRUs'
current QoS category (Q.sub.UE).
[0126] In one embodiment, the WTRU current QoS category Q.sub.UE
may be determined by the data radio bearer of the highest required
or prioritized QoS on the WTRU, (i.e., Q.sub.UE=the highest
Q.sub.val of the WTRU RBs). Q.sub.val a numerical value reflected
or redefined from the data radio bearer's QoS assignment or
association by the network. The Q.sub.val may be the QCI value of
the QCI table or the priority value of the QCI table, or may be
defined as the aggregation of these and other factors in the table
in consideration of the RN operating characteristics. The Q.sub.val
and the Q.sub.UE are numeric values such that the smaller the
Q.sub.val or the Q.sub.UE value the higher the QoS requirement or
priority it may imply. For example, if the WTRU currently has three
data radio bearers active, (i.e., not suspended), and they are
assigned or associated with a QCI value by the network as its QoS
assignment/classification, hence having the Q.sub.val values of 2,
4, and 7, the WTRU current QoS category may be 2. In this
embodiment, the highest prioritized WTRU DRB (and therefore the
WTRU or the RN DRB) reporting activity on the RN may be recognized
and somehow biased and the subsequent resource scheduling effort by
the DeNB with respect to the highest prioritized WTRU-DRB and the
WTRU may be supported properly.
[0127] In another embodiment, the WTRU current QoS category
Q.sub.UE may be determined by the combination of the data radio
bearers QoS on the WTRU (or WTRUs) mapped to the RN DRB. For
example, the sum of the Q.sub.val values of the active WTRU DRBs
may be used in such a way as to consider the RBs with high priority
QCIs as well as the number of active DRBs of the WTRU, (i.e., a
WTRU with more active DRBs may get a higher QoS category). For
example, the WTRU QoS category value Q.sub.UE may be determined as
follows:
Q.sub.UE=(Q.sub.val-1+Q.sub.val-2+ . . .
+Q.sub.val-m+defQ.sub.val-m+ . . . +defQ.sub.val-w)/w; Equation
(1)
where Q.sub.val-1, Q.sub.val-2 . . . Q.sub.val-m are the
normalized/converted Q.sub.val values of the m active DRBs, w is
the maximum number of allowed WTRU DRBs, (e.g., 8), and
defQ.sub.val are for the remaining inactive DRBs among the m
maximum WTRU DRBs, in which the defQ.sub.val value equals to the
maximum Q.sub.val value normalized/converted from the QCI-table,
(e.g., 9). For example, a WTRU with two active DRBs of Q.sub.val
values 2 and 3 may have a lower WTRU QoS category value than
another WTRU with three active DRBs of Q.sub.val values 2, 3 and 4,
while a WTRU with two active DRBs of Q.sub.val values 2 and 3 may
have a higher WTRU QoS category value than a WTRU with two active
DRBs of Q.sub.val values 3 and 4, and so on. The resulting Q.sub.UE
may require some rounding and mapping (e.g., to a set of ranges) to
obtain a reasonable set of groups for per-WTRU based
reporting-WTRU-grouping.
[0128] In another embodiment, the WTRU current QoS category
Q.sub.UE may be determined by a weighted Qval combination on the
WTRU. A different scaling factor may be applied to the Qval values
in Equation (1) according to their priority so that the higher
prioritized Qval values may be counted more in combination. For
example, the WTRU QoS category value Q.sub.UE may be determined as
follows:
Q.sub.UE=(u.sub.1Q.sub.val-1+u.sub.2Q.sub.val-2+ . . .
+u.sub.mQ.sub.val-m+u.sub.wdefQ.sub.val-m+1+ . . .
+u.sub.wdefQ.sub.val-w)/w; Equation (2)
where Q.sub.val-1, Q.sub.val-2, . . . , Q.sub.val-m are the
normalized/converted Q.sub.val values of the m active DRBs, and
u.sub.1, u.sub.2, . . . , u.sub.m are the scaling factors on the
Q.sub.val values.
[0129] The scaling factors, u.sub.x, may be pre-determined by
definition, (for example, u.sub.x=[1.0, 1.1, 1.2. 1.3 . . . , 1.9,
2.0]). Alternatively, the scaling factors may be determined by a
default rule such that the lower the Q.sub.val value, the smaller
the u.sub.x value, (e.g., for the Q.sub.val values assigned to GBR
data radio bearers the u.sub.x may be 1.0, while for the Q.sub.val
values assigned for non-GBR data radio bearers the u.sub.x may be
1.3). Alternatively, the scaling factors may be determined by the
network.
[0130] Alternatively, Q.sub.UE in Equation (2) may be normalized
taking into account the scale factors u.sub.x(s) as follows:
Q.sub.UE=(u.sub.1Q.sub.val-1u.sub.2Q.sub.val-2+ . . .
+u.sub.mQ.sub.val-mu.sub.wdefQ.sub.val-m+1+ . . .
+u.sub.wdefQ.sub.val-w)/U; Equation (3)
where U=sum (u.sub.1, u.sub.2, . . . u.sub.m). The resulting
Q.sub.UE may require some rounding and mapping, (e.g., to a set of
ranges), to obtain a reasonable set of groups for per-WTRU based
reporting-WTRU-grouping.
[0131] In this embodiment, (by assigning different weights to the
WTRU DRBs), a controlled balance may be achieved on the final
outcome of the WTRU QoS category Q.sub.UE in RN BSR between the
highest prioritized Qval and the number of active DRBs in the WTRU,
while not totally sacrificing the WTRUs with few higher prioritized
Q.sub.vals.
[0132] In another embodiment, the WTRU current QoS category
Q.sub.UE may be determined by the current aggregated prioritized
bit rate (PBR) of active DRBs on the WTRU. The larger the
aggregated bit rate, the higher the WTRU QoS category value, in
terms of using the WTRU QoS category for the reporting-WTRU-group
assignment. An example of the aggregated bit rate is to sum up the
PBRs for the WTRU active DRBs.
[0133] When the RN BSR is triggered, the RN may sum the available
data in buffers (uplink or uplink+downlink) assigned to a
reporting-WTRU-group (or each of multiple reporting-WTRU-groups)
and format the BSR record with the assigned
reporting-WTRU-group-ID(s) and the total data buffered (for the one
group or each group) in actual or converted size indication. The
converted size indication may be a value (such as an index into a
look-up table) representing the buffer size or range in which the
buffer size falls.
[0134] WTRU control plane traffic that does not terminate in the RN
may be grouped as one reporting group. Several control plane
bearers may exist over the Un for control signaling between the
DeNB and the RN. These control channels at least include the S1-AP
from the MME/serving gateway (S-GW), the X2-AP to each of the
potential target eNBs and the RRC protocol between the DeNB and the
RN. These channels may be grouped together as one RN SRB or as
multiple RN SRBs. In either case, they may be grouped into one
reporting group for buffer status reporting and other
reporting.
[0135] In case the RN DRBs are organized per-RN, one DRB is
configured. In this case, in addition to a sum report of the entire
accumulated data in the RN, some of its component streams or
sub-data streams (corresponding to a WTRU DRB or to some other
aggregation scheme) may be grouped for BSR reporting purposes for
better reporting granularity.
[0136] The report may be configured for the RN as a general
configuration or may be individually configured or ordered by the
DeNB for the sub-streams of the per-RN DRB configuration. The BSR
reporting group may be organized per-WTRU or per-WTRU group(s). In
this case, one or more WTRUs individual buffer status, or the sum
of one or more reporting-WTRU-groups may be reported. The grouping
may be performed in a similar way disclosed above. The BSR
reporting group may be organized per QoS or per-QoS group(s). In
this case, individual or aggregated data buffer accumulation status
of one or more QoS or QoS groups may be reported. The grouping may
be performed in a similar way disclosed above.
[0137] Embodiments for triggering RN BSR reporting are disclosed
hereafter. It may be noted that the embodiments may be used
independently, together, or as a sub-part of another embodiment.
The embodiments for triggering the RN BSR may be applied to any
types of RN BSRs disclosed above.
[0138] In one embodiment, the RN may be configured with a
triggering events such that the RN BSR is generated and sent by the
RN when a specific event occurs. Such triggering events include,
but are not limited to, buffer accumulation going above a
threshold, buffer accumulation going below a threshold, an
expiration of a timer which may be restarted due to other triggers,
(such as a command from the DeNB or buffer accumulation going above
or below a threshold), etc.
[0139] In another embodiment, the DeNB may specifically trigger an
RN for an RN BSR. For example, in case where the configured BSR
triggering does not happen often enough or the DeNB needs some
immediate BSRs before reconfiguring a cell, the DeNB may trigger a
BSR for a specific RN(s). When the DeNB triggers the RN BSR report,
the DeNB may specify the required status types in the report,
(e.g., whether the report may include an uplink BSR, a downlink
BSR, or both, or the WTRU BSRs or a satisfaction indicator, or a
combination of these), and/or the reporting groups such as which
DRB group (per-WTRU or per QoS), which SRB group, or a combination
of them. The response from the RN may be sent via an RRC message or
an MAC message.
[0140] In another embodiment, the RN may be configured with a
periodic timer to send BSR reports periodically such that the RN
BSR is generated and sent regardless of the amount of data in the
buffers in concern when the periodic timer expires. The periodic RN
BSR reporting may be activated if a special flag indicates to do
so, (such as a periodic reporting flag provided to the RN in a
message from the DeNB). The RN may send the periodic BSR reports if
no threshold-related parameters are configured for event-triggered
reporting. If no specific period is provided, a default value may
be used.
[0141] In another embodiment, event triggering may be configured in
conjunction with a periodic timer. For example, thresholds related
to the buffer accumulation volume, (e.g., the byte count or byte
count range), may be used in conjunction with the periodic timer.
The thresholds may be a low buffer accumulation mark and/or a high
buffer accumulation mark. The buffer accumulation count may be
considered normal when it is between the low mark and the high
mark. If the buffer accumulation is below the low mark, it may mean
that the RN load is somehow reduced or deflated. On the other hand,
if the buffer accumulation count is above the high mark, it may
mean that either the link condition is poor or the resources
allocated for transmitting the load is not enough.
[0142] FIG. 5 is a flow diagram of an example process 500 of
combined event-triggered and periodic BSR reporting in one
embodiment. In this embodiment, the RN reports a BSR(s) based on
buffer accumulation, (i.e., based on comparison to one or more
thresholds (e.g., a low mark and/or a high mark). When one or more
of the thresholds is crossed, RN reports BSR periodically based on
the configured periodic timer. When the buffer accumulation is
normal, (e.g., between the low and high marks), for one or more
reporting periods for the RN, the RN may stop sending the periodic
reports. Each report may be for one or more RN-DRBs or for one or
more reporting groups, or for one or more WTRU RBs based on
configuration and/or buffer accumulation.
[0143] When a periodic timer expires (502), the RN evaluates the
buffer accumulation status (all, or one or more specifically
configured, or a default set), (e.g., using one or more
pre-configured buffer accumulation marks) (504). The periodic timer
is initially set to an originally configured value. If it is
determined that the buffer accumulation is normal, (i.e., between a
low mark and a high mark), at this period, the RN further
determines whether the buffer accumulation status changed normal at
this period, (or alternatively the buffer accumulation status has
remained normal for a recent predetermined number of periods (m))
(506).
[0144] If the buffer accumulation status changed normal at this
period (or alternatively, the buffer status has remained normal for
the recent m periods), the RN reports a BSR (508). If the buffer
accumulation status did not change normal at this period (or
alternatively the buffer accumulation status has remained normal
for more than recent m periods), the RN may not report a BSR, and
the RN may reset the periodic timer to N times the originally
configured value, and the process 500 returns to step 502 to wait
for expiration of the periodic timer.
[0145] 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 the RN DRB that triggers the BSR. Alternatively, the RN
may report a BSR for a default reporting group(s) or RN DRB(s) in
addition to a BSR for the triggering RN DRB or reporting-group. The
RN may reset the periodic timer to the originally configured value
if it has changed (512), and the process returns to step 502.
[0146] If the buffer accumulation is above the high-mark, the RN
reports a BSR (514). The RN may report a BSR for the reporting
group or the RN DRB that triggers the BSR. Alternatively, the RN
may report BSRs for either triggered ones, triggered ones plus
default ones, or all BSRs. The RN may reset the periodic timer to
the originally configured value if it has changed (516).
[0147] At the next expiration of the periodic timer, the RN
evaluates the buffer accumulation status (all, or one or more
specifically configured, or a default set) (518). If it is
determined at step 520 that the buffer accumulation stays above the
high mark, the RN reports BSRs for either triggered ones, triggered
ones plus default ones, or all BSRs (522), and the process 500
returns to step 518.
[0148] If it is determined at step 520 that the buffer accumulation
is not above the high mark, the RN may report a BSR(s), (e.g., the
previous one triggered by going above the high mark, a new BSR
triggered by going below the low mark, a default one(s), all, etc.)
(524), and the process returns to step 502, (or alternatively to
step 518 if the buffer accumulation has been below the high mark
for a predetermined times, which may be defined by the standards or
configured by the DeNB or any network entity, otherwise to step
502).
[0149] The thresholds (e.g., high mark and/or low mark) to use for
event triggered reporting or the combined periodic and event
triggered reporting may be fixed. Alternatively, the thresholds may
be semi-statically configured by the network. Alternatively, the
thresholds may be computed by the RN, for example dynamically
corresponding to the ups and downs of the aggregated throughput
value of the BSR reporting unit. For example, the thresholds may be
related to the aggregated GBR or AMBR, when applicable, from each
of the component radio bearers of the basic BSR reporting unit, or
the sum of the bucket sizes (obtained by multiplying the
prioritized bit rate with the buffer size duration) of its
component radio bearers of the basic BSR reporting unit.
[0150] A time-to-trigger value may be configured for the RN BSR
reporting such that a BSR is triggered when a threshold is crossed
and maintained for a time period equal to or longer than the
time-to-trigger value.
[0151] In one embodiment, an RN BSR may be piggybacked in the MAC
PDU if there is an available space in the MAC PDU. A periodic timer
may be employed to trigger the piggybacked RN BSR generation. The
piggybacked RN BSR may be triggered based on the availability of a
MAC PDU unfilled space of at least certain predetermined size. The
predetermined size may be defined to hold a certain minimal RN BSR
or several of a category or a combination of RN BSRs and other
relevant traffic information, such as the uplink RN SRB report, or
the high priority uplink BSR or the uplink BSR plus downlink BSR,
etc.
[0152] The piggybacked RN BSR may have a buffer accumulation
threshold value so that the BSR is generated, for example, when the
buffer accumulation is below a low mark and/or above a high mark.
The thresholds may have values more lenient for generating the
piggybacked RN BSR, (i.e., the piggybacked BSR triggering
thresholds have a higher low mark and a lower high mark by an
offset (which may be a default value in the standards or signaled
by the DeNB or network entity) from the ones disclosed above.
[0153] The piggybacked RN BSR triggering time may be close to the
next periodic timer occasion as follow:
trigger time.gtoreq.previous_report_time+(periodic_timer_value)/2;
Equation (4)
trigger
time.gtoreq.(previous_report_time+periodic_timer_value)-T.sub.of-
fset; Equation (5)
where T.sub.offset may be a default value defined in the standards
or signaled by the DeNB or any network entity.
[0154] A piggybacked RN BSR may be generated if there is space and
the timing is right, or if there is space and the threshold event
is triggered, or if there is space and the timer is expired not
long ago a predefined tolerance value. The periodic timer may
restart if a piggybacked RN BSR is transmitted. If the timer
expires and there is no piggyback space, the RN may wait until
there is a grant or subframe resource available for a full RN BSR
or start a uplink grant request action (to be defined for RN).
[0155] Although features and elements are described above in
particular combinations, one of ordinary skill in the art will
appreciate 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 may be implemented in a computer program,
software, or firmware incorporated in a computer-readable medium
for execution by a computer or processor. Examples of
computer-readable media include electronic signals (transmitted
over wired or wireless connections) and computer-readable storage
media. Examples of computer-readable storage media include, but are
not limited to, a read only memory (ROM), a random access memory
(RAM), a register, cache memory, semiconductor memory devices,
magnetic media such as internal hard disks and removable disks,
magneto-optical media, and optical media such as CD-ROM disks, and
digital versatile disks (DVDs). A processor in association with
software may be used to implement a radio frequency transceiver for
use in a WTRU, UE, terminal, base station, RNC, or any host
computer.
* * * * *