U.S. patent application number 12/766157 was filed with the patent office on 2010-10-28 for base station assistance for random access performance improvement.
This patent application is currently assigned to INTERDIGITAL PATENT HOLDINGS, INC.. Invention is credited to Ronald G. Murias, Lei Wang, Eldad M. Zeira.
Application Number | 20100272066 12/766157 |
Document ID | / |
Family ID | 42341413 |
Filed Date | 2010-10-28 |
United States Patent
Application |
20100272066 |
Kind Code |
A1 |
Wang; Lei ; et al. |
October 28, 2010 |
BASE STATION ASSISTANCE FOR RANDOM ACCESS PERFORMANCE
IMPROVEMENT
Abstract
A base station (BS) may be configured to assist in the detection
of a random access (RA) request failure and in clued an antenna
configured to receive a RA request; a processor configured to
decode the RA request; and a transmitter configured to transmit an
aggregate RA response message comprising one or more RA responses
that respond to one or more received and decoded RA requests.
Inventors: |
Wang; Lei; (San Diego,
CA) ; Murias; Ronald G.; (Calgary, CA) ;
Zeira; Eldad M.; (Huntington, NY) |
Correspondence
Address: |
VOLPE AND KOENIG, P.C.;DEPT. ICC
UNITED PLAZA, 30 SOUTH 17TH STREET
PHILADELPHIA
PA
19103
US
|
Assignee: |
INTERDIGITAL PATENT HOLDINGS,
INC.
Wilmington
DE
|
Family ID: |
42341413 |
Appl. No.: |
12/766157 |
Filed: |
April 23, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61172072 |
Apr 23, 2009 |
|
|
|
61183700 |
Jun 3, 2009 |
|
|
|
Current U.S.
Class: |
370/331 ;
370/328 |
Current CPC
Class: |
H04W 88/08 20130101;
H04W 88/02 20130101; H04W 84/042 20130101; H04W 74/0833 20130101;
H04W 74/006 20130101 |
Class at
Publication: |
370/331 ;
370/328 |
International
Class: |
H04W 36/00 20090101
H04W036/00; H04W 74/08 20090101 H04W074/08 |
Claims
1. A base station (BS) configured to assist in the detection of a
random access (RA) request failure comprising: an antenna
configured to receive a RA request; a processor configured to
decode the RA request; and a transmitter configured to transmit an
aggregate RA response message comprising one or more RA responses
that respond to one or more received and decoded RA requests.
2. The BS of claim 1, wherein the RA request comprises an initial
ranging request.
3. The BS of claim 2, wherein the initial ranging request comprises
an initial ranging code in an initial ranging channel.
4. The BS of claim 2, wherein the one or more RA responses comprise
a ranging status notification.
5. The BS of claim 4, wherein the one or more RA responses comprise
uplink (UL) parameter adjustments.
6. The BS of claim 1, wherein the RA request comprises a handover
(HO) ranging request.
7. The BS of claim 6, wherein the HO ranging request comprises a HO
ranging code in a HO ranging RA channel.
8. The BS of claim 7, wherein the one or more RA responses comprise
a ranging status notification.
9. The BS of claim 8, wherein the one or more RA responses comprise
uplink (UL) parameter adjustments.
10. The BS of claim 1, wherein the RA request comprises a periodic
ranging request.
11. The BS of claim 10, wherein when the BS receives and decodes
the periodic ranging request, the BS estimates the channel strength
and the time/frequency of the received UL signals corresponding to
the periodic ranging request.
12. The BS of claim 10, wherein the one or more RA responses
comprise a ranging status notification.
13. The BS of claim 12, wherein the one or more RA responses
comprise uplink (UL) parameter adjustments.
14. A wireless transmit/receive unit (WTRU) that detects failure of
a random access (RA) request comprising: a transmitter configured
to transmit a RA request; a receiver configured to receive an
aggregate RA response message; and a processor configured to
determine whether the RA request was successful by determining if
the aggregate RA response message comprises a RA response
corresponding to the RA request.
15. The WTRU of claim 14, wherein the RA request comprises an
initial ranging request.
16. The WTRU of claim 14, wherein the RA request comprises a
handover ranging request.
17. The WTRU of claim 14, wherein the RA request comprises a
periodic ranging request.
18. A base station (BS) that assists in random access (RA)
collision detection comprising: an antenna configured to receive a
RA request and to receive an uplink (UL) data burst; a processor
configured to decode the RA request, construct and schedule an RA
response to the RA request, schedule UL data allocation in response
to the RA request, and decode the UL data burst; and a transmitter
configured to transmit a RA response to the RA request, the
transmitter further configured to transmit an UL allocation in
response to the RA request, and also transmit a RA-initiated UL
data negative acknowledgement (NACK) on a condition that data was
not received in an UL data region corresponding to the RA
request.
19. A method to assist in detection of random access (RA) request
failure comprising: receiving and decoding a RA request; and
transmitting an aggregate RA response message comprising one or
more RA responses that respond to one or more of the received and
decoded RA requests.
20. A method for detecting a random access (RA) failure, the method
comprising: transmitting a RA request; receiving an aggregate RA
response message comprising one or more RA responses; and
determining whether the RA request was successfully transmitted by
determining if the aggregate RA response message comprises a RA
response corresponding to the RA request.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. application
61/172,072 filed Apr. 23, 2009 and U.S. application 61/183,700
filed Jun. 3, 2009, which are incorporated by reference as if fully
set forth.
FIELD OF INVENTION
[0002] This application is related to wireless communications.
BACKGROUND
[0003] Two issues that currently exist in wireless broadband
systems are latency of random access (RA) failure detection on the
subscriber side and collisions. An RA attempt fails when the BS
fails to receive the RA signal correctly either due to collision,
i.e., two or more users (subscribers) use the same RA opportunity,
or due to an insufficient signal level.
[0004] The first issue is the latency issue of RA failure detection
on the subscriber side. In scheduling-based access systems, RA
accommodates new access needs, e.g., new users, existing users' new
requirements, etc. Broadband Wireless Access systems, e.g.,
worldwide interoperablility for microwave access (WiMAX), and long
term evolution (LTE), are typical scheduling-based access systems,
where a base station (BS) controls the use of the air link
resources.
[0005] When a RA failure occurs, the subscriber needs to detect it
and then take actions accordingly, e.g., retry, or ramp up its
transmission power. A commonly-used mechanism for a subscriber to
detect the failure of its random access attempt is timer-based,
i.e., after waiting a pre-defined time period without getting the
expected response, the subscriber assumes that its previous RA
attempt failed, where the expected response depends on the purpose
of the RA.
[0006] The pre-defined time period may play a role in a timer-based
RA failure detection mechanism because the recovery from a RA
failure has to wait for the pre-defined time that needs to be
sufficiently long enough to process the RA request receptions and
responses under the worst-case considerations, e.g., the heaviest
traffic loading.
[0007] The second issue relates to collision scenarios. A collision
occurs when two or more subscribers choose the same RA opportunity,
where a RA opportunity refers to the opportunity for subscriber to
send a RA request, for example, a RA opportunity in IEEE 802.16
systems consists of a RA channel and a RA code sent on the RA
channel. When a collision occurs, there are several possible
results. The first result is that the BS detects nothing. The
second result is that the BS detects a collision. The third result
is that a single RA Request is erroneously detected by the BS in
the RA opportunity with collision.
SUMMARY
[0008] A base station (BS) may be configured to assist in the
detection of a random access (RA) request failure and include an
antenna configured to receive a RA request; a processor configured
to decode the RA request; and a transmitter configured to transmit
an aggregate RA response message comprising one or more RA
responses that respond to one or more received and decoded RA
requests.
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. 1 shows an example wireless communication system
including a plurality of WTRUs, a BS, and an RNC.
[0011] FIG. 2 is a functional block diagram of a wireless
transmit/receive unit (WTRU) and the BS of FIG. 1.
[0012] FIG. 3 shows a sample TDD frame structure.
[0013] FIG. 4 shows an example ranging RA region and a BS's ranging
RA response.
[0014] FIG. 5 shows an example of a BS's ranging RA response per RA
region or per RA types when a RA region is shared by multiple RA
types.
[0015] FIG. 6 is a diagram of an example of a single BS RA response
message for contention-based bandwidth request.
[0016] FIG. 7 shows an example of an uplink data collision after RA
requests when HARQ is not used.
[0017] FIG. 8 shows an example of an UL data region collision after
RA request when UL HARQ is used.
[0018] FIG. 9 is a diagram of an example using BS-Assistance
information in a RA timer or a negative acknowledgement (NACK).
DETAILED DESCRIPTION
1. Introduction
[0019] When referred to hereafter, the terminology "wireless
transmit/receive unit (WTRU)" includes but is not limited to a user
equipment (UE), a mobile station (MS), a fixed or mobile subscriber
station (SS or MS), an advanced mobile station (AMS), a pager, a
cellular telephone, a personal digital assistant (PDA), a computer,
or any other type of user device capable of operating in a wireless
environment. When referred to hereafter, the terminology "base
station (BS)" includes but is not limited to a BS, a site
controller, an access point (AP), an advanced base station (ABS), a
Node-B, or any other type of interfacing device capable of
operating in a wireless environment. The solutions and mechanisms
described herein may be applicable to TDD, FDD, and other
systems.
[0020] FIG. 1 shows a wireless communication system 100 including a
plurality of WTRUs 110, a BS 120, and a radio network controller
(RNC) 130. As shown in FIG. 1, the WTRUs 110 are in communication
with the BS 120, which is in communication with the RNC 130. The
WTRUs 110 are configured to receive data transmissions from the BS
120 over a high speed shared data channel. The BS 120 and/or WTRUs
110 are configured to detect random access (RA) failures and
collisions, as described herein. Although only three WTRUs 110, one
BS 120, and one RNC 130 are shown in FIG. 1, it should be noted
that any combination of wireless and wired devices may be included
in the wireless communication system 100. For example, although the
RNC 130 is shown in the wireless communication system 100, the RNC
130 may not exist in the system 100 and may be included in the BS
120 or any other entity in the system 100. It should be understood
that the communication between the WTRUs 110, BSes 120, and RNC 130
or other networks like the Internet may be done using packet-based
communication.
[0021] FIG. 2 is a functional block diagram 200 of the WTRU 110 and
the BS 120 of FIG. 1. As shown in FIG. 2, the WTRU 110 is in
communication with the BS 120 and both may be configured to detect
random access (RA) failures and collisions, as discussed below.
[0022] In addition to the components that may be found in a typical
WTRU, the WTRU 110 includes a processor 115, a receiver 116, a
transmitter 117, and an antenna 118. The processor 115 is
configured to detect RA failures and collisions. The receiver 116
and the transmitter 117 are in communication with the processor
115. The antenna 118 is in communication with both the receiver 116
and the transmitter 117 to facilitate the transmission and
reception of wireless data.
[0023] In addition to the components that may be found in a typical
BS, the BS 120 includes a processor 125, a receiver 126, a
transmitter 127, and an antenna 128. The processor 125 is
configured to detect RA failures and collisions. The receiver 126
and the transmitter 127 are in communication with the processor
125. The antenna 128 is in communication with both the receiver 126
and the transmitter 127 to facilitate the transmission and
reception of wireless data.
2. Example Frame Structure
[0024] FIG. 3 shows an example of a TDD frame structure that
currently corresponds to the IEEE 802.16m TDD frame structure,
although other frame structures can of course be used with the
embodiments described herein. Regardless of channel bandwidth (5,
7, 8.75, 10, or 20 MHz), the superframe 310 may be 20 ms in length
as shown and may be divided into four 5 ms frames 320. The frames
320 may be further divided into 5-8 subframes 330. These subframes
330 may each contain, five, six, seven, or nine OFDM symbols,
depending on the type of subframe 330 in use.
[0025] Each TDD subframe 330 contains a downlink portion 340 and an
uplink portion 350, separated by a TTG (Transmit/Receive gap) 360
and an RTG (Receive/Transmit gap) 380, inserted between transmit
and receive, or receive and transmit, respectively. Downlink/Uplink
ratios may vary for the 5, 7, 8.75, 10, and 20 MHz bandwidths. Some
examples of Downlink/Uplink ratios are: 8/0, 6/2, 5/3, 4/4,
3/5.
[0026] FIG. 3 shows the frame structure for 5, 10, and 20 MHz TDD
with 5/3 DL/UL split.
[0027] A single downlink frame 340 may contain multiple bursts of
varying size and type carrying data for several WTRUs. The frame
size could also be variable on a frame-by-frame basis. Each burst
may contain multiple concatenated fixed-size or variable-size
packets or fragments of packets received from higher layers.
[0028] The uplink subframe 350 may be made up of several uplink
data bursts from different WTRUs. A portion of the uplink subframe
350 may be set aside for contention-based access, also called
Random Access (RA), that may be used for a variety of purposes,
including ranging for UL, time, and power adjustments during
network entry as well as periodically afterward. The RA channel may
also be used by WTRUs to make uplink bandwidth requests. In
addition, best-effort data may be sent on this contention-based
channel, particularly when the amount of data to send is too small
to justify requesting a dedicated channel.
3. Random Access (RA)
[0029] In scheduling based wireless broadband access systems,
Random Access (RA) refers to an uplink (UL) region that is
allocated for WTRUs to access. It is also referred to as
contention-based access. The UL region allocated for RA may be
called a Random Access (RA) region.
[0030] A RA region commonly includes RA channels, where a RA
channel is physically modulated to carry certain information codes.
The information code carried by a RA channel is called a RA code.
In some RA code designs, multiple codes with certain orthogonal
properties can be transmitted by different WTRUs in the same RA
channel. For example, in IEEE 802.16 systems, a Code Division
Multiple Access (CDMA)-like RA code may be used, so that one RA
channel may be accessed by multiple WTRUs with different RA
codes.
[0031] A RA opportunity may refer to the opportunity that a WTRU
uses to transmit its RA request. When a RA channel may carry
multiple RA codes, a RA opportunity may be a combination of a RA
channel and a RA code. When a WTRU needs to send a RA request, it
may transmit a specific RA code in a RA channel.
[0032] After sending a RA request, the WTRU waits for the BS to
provide a response to its RA request that is identified by the RA
opportunity that the WTRU used to send the RA request, e.g., the
location of the RA region, RA channel, and RA code. The expected
response varies with the intention of the WTRU's RA request.
[0033] 3.1 RA Use Cases
[0034] The RA opportunities for different RA use cases may be
identified by different RA regions allocated by the BS or by
different RA codes domains/different RA channels in the same RA
region. At least four use cases of Random Access (RA) may exist:
initial access for a new subscriber (WTRU) to join the network
(initial ranging); Handover of a subscriber (WTRU) from one BS to
another BS (HO ranging); periodic maintenance of the uplink (UL)
transmission parameters (periodic ranging); and bandwidth request
for existing subscriber (WTRU) (contention-based bandwidth
request).
[0035] Initial ranging is a process for a new WTRU to initiate
communication with a BS. The WTRU sends an initial ranging request
in an initial ranging RA opportunity to the BS, for example, an
initial ranging code in an Initial Ranging RA channel. After
sending its initial ranging request, the WTRU waits for a response
from the BS. The expected response to an initial ranging request
may be a ranging status notification with or without UL
transmission parameter adjustments.
[0036] HO ranging is a process for a WTRU to initiate communication
with the target BS during handover from one BS to another BS. The
WTRU sends a HO ranging request in a HO ranging RA opportunity to
the BS, i.e., a HO ranging code in a HO ranging RA channel. After
sending its HO Ranging request, the WTRU waits for a response from
the BS. The expected response to a HO ranging request may be a
ranging status notification with or without UL transmission
parameter adjustments.
[0037] With respect to periodic ranging, since each WTRU may be a
different distance from a BS, it may be important in the uplink to
synchronize symbols in both time domain and frequency domain and
equalize the received power levels among the various active WTRUs.
In the uplink, the active WTRUs may need to be synchronized to at
least within a cyclic prefix guard time of one another. Otherwise,
significant intercarrier and intersymbol interference may result.
Similarly, although downlink power control may be used in order to
reduce spurious other-cell interference, it may not be not strictly
required. Uplink power control may (1) improve battery life, (2)
reduce spurious other-cell interference, and (3) avoid drowning out
faraway WTRUs in the same cell that are sharing an Orthogonal
Frequency Division Multiplexing (OFDM) symbol with them.
[0038] This periodic ranging process, when initiated, may require
the BS to estimate the channel strength and the time/frequency of
the received UL signals from the WTRU in question, and then send
the necessary UL transmission parameter adjustments, e.g., time,
frequency, and/or power level, to the WTRU. When the WTRU uses
unicast UL allocation, the BS may estimate the received unicast UL
data from the WTRU to determine if UL transmission parameter
adjustment is needed. When the WTRU does not have unicast UL
allocation and the periodic ranging is initiated, the WTRU needs to
use a periodic ranging RA opportunity to send the BS a periodic
ranging request. After sending its periodic ranging request, the
WTRU waits for a response from the BS. The expected response to
periodic ranging request may be a ranging status notification with
or without UL transmission parameter adjustments
[0039] A contention-based bandwidth request may be a process that a
WTRU uses to request UL bandwidth by sending a Bandwidth Request
(BR) RA request. The WTRU may send a BR RA request in a BR RA
opportunity to the BS, i.e., a BR RA code in a BR RA channel. After
sending a BR RA request, the WTRU waits for a response from the BS.
The expected response to a BR RA request may be an UL bandwidth
grant.
4. Embodiments Addressing Latentcy and Collisions
[0040] 4.1 Latency
[0041] Within this or other systems, there are several embodiments
that may address the latency issue of RA failure detection at the
WTRU. Generally, the embodiments may use BS assistance to help the
WTRUs in the RA-failure detection, so that the WTRUs may detect the
failures of their RA attempts timely and accurately, and then start
their RA recovery processes accordingly.
[0042] In a first embodiment, the BS may send responses to all the
received RA requests in a RA region in the same aggregate BS RA
response message and this aggregate BS response may be sent at the
earliest possible BS RA response opportunity. Depending on the
purpose of the RA request, the BS RA responses may be ranging
status notifications with or without parameter adjustments,
resource allocations, or simple acknowledgements indicating a
successful reception of the RA request.
[0043] In the event that no RA request is successfully received by
the BS in a RA region, the BS may not transmit the response message
or the BS may transmit a null message.
[0044] Upon receiving and decoding a BS RA response message that
contains responses to the successful received WTRU RA requests, a
WTRU may deterministically detect if its own RA request was
successfully received at the BS. The WTRU does this by checking
whether the aggregate BS RA response message contains a response to
its RA request, for example, a RA channel plus a RA code in 802.16
systems. If the aggregate BS RA response message does not contain
any response to its RA request, the WTRU may consider that its RA
request failed and then start its RA recovery process. This
recovery process could begin immediately, without waiting for a
timer out, such that the latency of RA failure detection at WTRU
side is significantly reduced.
[0045] Another benefit of using an aggregate BS RA message may be
overhead reduction as the BS sends the responses to all the
received RA requests in the same aggregate BS RA response message,
compared to sending an individual TA response message to each RA
request. The overhead reduction comes from saving multiple message
headers and having a more efficient way to identify the RA
opportunities in one aggregate message rather than identifying them
each individually in separate messages.
[0046] 4.1.1 Initial Ranging Request
[0047] For example, the BS may allocate a ranging RA region in the
UL in order to provide initial ranging opportunities for the new
WTRUs to join the network. A new WTRU, after acquiring the
essential system configuration parameters and synchronized with the
downlink (DL) of the BS, may start the initial ranging process by
sending an initial ranging request, i.e., transmitting a selected
initial ranging RA code in a selected initial ranging channel.
After receiving and decoding an initial ranging region, the BS may
send an aggregate RA response message at the earliest possible BS
initial ranging RA response opportunity. The aggregate RA response
message may contain initial ranging RA responses to all the
successfully received and decoded initial ranging RA requests in
the initial ranging RA region. For each successfully received and
decoded initial ranging request, the BS's RA response may contain
the ranging status and the necessary UL transmission parameter
adjustments.
[0048] As shown in FIG. 4, after an UL initial ranging region 1010,
the earliest BS initial ranging RA response opportunity may be
determined by the BS's scheduler that manages and allocates the
radio link resources based on the BS's real-time traffic load and
traffic composition. For an initial ranging region in frame n 1000,
the earliest BS initial ranging RA response opportunity 1035 may be
a DL frame 1020 of frame n+1 1030, i.e., the next DL frame after
the UL frame with the initial ranging region, if the BS scheduler
can accommodate the initial ranging RA aggregate response message
in it after other higher priority traffic data; otherwise, the
earliest BS initial ranging RA response opportunity 1045 may be the
DL frame of frame n+2 1040 or later.
[0049] After sending an initial ranging RA request, the WTRU waits
for the initial ranging RA response from the BS. Once the initial
ranging RA response message is received and decoded, the WTRU
attempts to identify the response to its request based on the used
initial ranging RA channel and initial ranging RA code. If the BS
aggregate initial ranging RA response message contains a response
to the WTRU's request, the WTRU may consider its initial ranging RA
request successful and moves to the next step according the given
response. If the BS initial ranging RA aggregate response message
does not contain a response to the WTRU's request, the WTRU may
consider its initial ranging RA request failed and it can
immediately start the initial ranging RA recovery process.
[0050] The use of a BS initial ranging RA response message
containing the responses to all successfully received and decoded
initial ranging RA requests in an initial ranging region may make
it possible for the WTRUs to timely and deterministically detect
the status of their initial ranging RA attempts. If a WTRU detects
a failure of its initial ranging RA request, the initial ranging RA
recovery process may be started immediately, minimizing the latency
in the initial ranging RA failure detection and recovery.
[0051] Comparing this to a method where the BS sends separate
initial ranging responses to each successfully received and decoded
initial ranging RA request, the aggregation of the responses to the
successfully received and decoded initial ranging RA requests in
one BS initial ranging RA response message reduces the overhead of
MAC encodings, as it saves multiple MAC headers and also it may
have more efficient way to identify the RA requests when
aggregating them together.
[0052] An initial ranging RA timer may still be used to handle the
exceptions, such as message delivery errors, in order to improve
overall system robustness.
[0053] 4.1.2 HO Ranging Request
[0054] A similar embodiment may also be applied to the HO ranging
RA process where the HO ranging RA opportunities may be in a
separate RA region. Alternatively, as shown in FIG. 5 the HO
ranging RA opportunities may share the same RA region 1110 as
initial ranging opportunities as shown in frame n 1100. For
example, in IEEE 802.16 systems, the initial ranging and HO ranging
may share the same RA region where they are distinguished by using
different RA codes.
[0055] When the HO ranging shares the same RA region with the
initial ranging, the BS may send one RA response message 1135
containing the responses to all successfully received and decoded
initial ranging RA requests and HO ranging RA requests at the
earliest BS initial/HO ranging response opportunity (in frame n+1
1130 for the HO ranging RA request). Alternatively, the BS may send
two separate aggregate RA response messages 1138, 1145, one for
initial ranging and one for HO ranging, at the earliest BS HO
ranging RA response opportunity and the earliest BS initial ranging
RA ranging response opportunity in frames n+1 1130 and n+2 1140,
respectively. The earliest BS initial ranging RA response
opportunity may be different from the earliest BS HO ranging RA
response opportunity, depending on the BS scheduler's decision
regarding the priorities of those RA responses and the BS's
real-time traffic load and traffic composition.
[0056] 4.1.3 Periodic Ranging Request
[0057] In addition, a similar embodiment may also be applied to
periodic ranging RA process. Similarly, the periodic ranging RA
opportunities may be in a separate RA region. In this case, after
each periodic ranging RA region, the BS sends a periodic ranging RA
response message containing the RA responses to all successfully
received and decoded periodic ranging RA requests, at the earliest
possible BS periodic ranging response time.
[0058] The periodic ranging RA region may have a different PHY
channel design from the initial ranging/HO ranging RA region, as it
may be for the random access from the WTRUs that have been
synchronized with the BS in the UL.
[0059] Alternatively, the periodic ranging RA opportunities may
share the same RA region with other ranging types, e.g., initial
ranging and/or HO ranging. In this case, after each ranging RA
region, the BS may sends one single ranging RA response message
containing the RA responses to all successfully receive and decoded
ranging RA requests including all ranging types, at the earliest
possible BS ranging RA response time. Alternatively, the BS may
sends multiple ranging RA response message, one for each ranging
types or any combinations of the ranging types supported in the
ranging RA region, at the same or different earliest RA response
time.
[0060] 4.1.4 Contention Based Request
[0061] In another embodiment, with the contention-based bandwidth
Request RA, the BS RA response messages may contain the resource
allocations that may be located in the next UL region or spread in
the next multiple UL regions. As shown in a simplified frame shown
in FIG. 6, for the RA region 602 in frame n-1 600, the BS sends a
BS RA aggregate response message 611 in the DL 612 of frame n 610,
which contains the responses to all the correctly received RA
requests, where the responses 611 may contain the resource
allocations 616 in frame n 610 or the next several frames 620.
[0062] The BS response 611 may also indicate a future sub-frame
where UL resource allocation control signal, e.g., Advanced-MAP
(A-MAP) in IEEE 802.16m, containing the actual allocation may be
found.
[0063] In this way, the BS RA aggregate response 611 also serves as
the acknowledgement to the WTRUs for their bandwidth request RA
requests sent in the previous bandwidth request RA region. That is,
the BS RA aggregate response message may serve two functions: one
to allocate resources; and the other to acknowledge WTRUs that used
the previous RA region.
[0064] For a WTRU that used a RA opportunity for an UL bandwidth
request in the previous bandwidth request RA region, if the WTRU
receives the expected response from the BS RA aggregate response,
it may consider that its RA attempt was successful and also knows
where its UL unicast allocation is. If the WTRU does not receive
its expected response in the BS RA response, it may recognize that
its RA attempt failed and it may start the recovery process
immediately or at such time as makes sense.
[0065] 4.1.5 Additional Embodiments Regarding Responses
[0066] In another embodiment, after sending a RA request, if the
WTRU does not receive a response in the RA response message from
the BS, it may start the RA recovery procedure, unless a maximum
number of allowed RA attempts have been reached.
[0067] Alternatively, in another embodiment, an explicit ACK may be
sent immediately upon detection of the RA request. For a RA request
that requires resource allocation, the actual resource grant may be
sent at a later time when resources are available.
[0068] Upon receiving an ACK for a RA request requiring resource
allocation, the WTRU may start a timer. Expiration of the timer
without grant/response may be a cause for the WTRU to retry the
access procedure. This may prevent the WTRU from waiting too long
in the event of a reception error.
[0069] In another embodiment, in the BS RA aggregate response
message, the successfully received and decoded RA requests are
identified by the RA opportunity descriptors, e.g., the RA region,
the RA channel, and the RA code (as used, for example in IEEE
802.16 systems), or identifiers derived from the RA opportunity
descriptors. If the RA opportunity descriptors are used in the BS
RA response message for a RA region, the coding efficiency may be
improved by using a two-level list, i.e., listing the RA channels
with at least one RA code received and decoded and then, for each
listed RA channel, listing all received and decoded RA codes,
comparing to using an one-level list of the pairs (RA channel, RA
Code) for the received and decoded RA opportunities.
[0070] In another embodiment, the ACK may be sent per code and RA
channel combination, together called a RA opportunity. RA
opportunities may be partitioned into groups. For each group, all
successfully received RAs are signaled. For each access group with
N opportunities, up to Kmax received RAs may be signaled. The
number K may be signaled, which requires log2 (Kmax) bits. An index
to the combination of successful RA's may be signaled, which
requires log2(N over K) bits. An index may be reserved to signal
the event where K>Kmax.
[0071] In another embodiment, the BS assists the WTRUs to have an
improved time period for the RA timer that is dynamic and varies
with the system loads. For example, for the RA requests resource
allocations, when the system is lightly loaded, the required
resources can be allocated quickly, therefore the RA timer value
can be smaller. When the system is heavily loaded, then the
required resources will be allocated spreading in the time domain,
therefore the timer value should be larger. It is difficult or
impossible for the WTRUs to dynamically change their RA timer
because the WTRU does not have the system loading information
without being informed by the BS. With BS assistance, after the BS
receives/processes a RA region, it sends out a broadcast message,
telling the WTRUs the RA timer values for the given RA region,
based on the BS's knowledge about how long it will take to finish
responding to those correctly received RA requests. Alternatively,
sending time is unspecified and the WTRU follows the last RA timer
value available.
[0072] When multiple classes of RA requests are supported, if the
RA class information is provided in the received RA requests, the
BS may also send multiple RA time values, each for a specific RA
request class. An RA timer setting broadcast message may be very
short, as it only contains small numbers, i.e. the RA timer values.
This proposed embodiment may also apply to the detections of both
collision-caused RA failure and power-too-low-caused RA failure. If
the WTRU does not receive the expected RA response within the given
time, it may start the RA recovery procedure unless the maximum
number of allowed RA attempts has been reached.
[0073] 4.2 Collisions
[0074] In a first method to address collisions, all wireless
transmit/receive units (WTRUs) may use distinct codes, however due
to receiver limitations, more codes are used than can be detected.
The first result may be that not all codes are detected, but those
that are detected are correct. This is a problem only if all WTRUs
choose the same channel again. The second result is that false
detections are made. This would be a low probability event and the
recovery from it would be in a verification stage.
[0075] A first embodiment may address the UL data collision problem
caused by missed-detection of RA collisions when UL Hybrid
Automatic Repeat Request (HARQ) is not used. A missed-detection of
RA collision happens when the BS erroneously detects a single RA
request 1210 (in FIG. 7) in a RA opportunity that had a RA
collision, i.e., accessed by two or more WTRUs. If the expected RA
response 1235 may involve a unicast UL data allocation, for
example, in the contention-based UL bandwidth request RA process,
the BS may allocate a unicast UL allocation to the decoded RA
request 1210. However, two or more WTRUs that used the same RA
opportunity 1210 may then transmit in the UL allocation 1238, thus
resulting in data region collision.
[0076] When UL HARQ is not used for the UL transmission, the
involved WTRUs may detect the UL data region collision by a failure
of receiving the expected response from the BS to their UL data if
their UL data requires certain response, for example, as part of
hand-shaking protocol data; otherwise, the involved WTRUs may not
be able to detect such an UL data region collision at the MAC
layer. The proposed embodiment may use the BS's assistance to the
WTRUs in detecting such an UL data region collisions. The BS has
the knowledge about which UL data allocation is for a RA response
and the BS also has the knowledge if the UL data region has been
successfully received. Therefore, in case of UL data region
collision, the BS can use its knowledge to send an indication to
the WTRUs to inform the failure of reception of the UL data region
allocated for a RA request. Such an indication of UL data region
collision may be called as RA-initiated UL data
Negative-ACKnowledgement (NACK).
[0077] When the WTRUs that used the given UL allocation receive
such a RA-initiated UL data NACK from the BS, they may realize that
an error occurred in their "on-going" procedure, and an error
recovery is needed.
[0078] In a RA-initiated UL data NACK 1245 sent by the BS, the UL
data region may be identified by the RA request to which the UL
data allocation was given as the response, where the RA request may
be identified by the RA request descriptors, for example, the RA
region, the RA channel, and the RA code, or an identifier derived
from these RA descriptors.
[0079] In a RA-initiated UL data NACK 1245 sent by the BS, the UL
data region may also be identified by the UL data allocation
descriptors, for example, frame index, subframe index, LRU (Logical
Resource Unit) index, etc, or an identifier derived from these UL
allocation descriptors.
[0080] The BS may send a RA-initiated UL data NACK 1245 as a MAC
control signal, for example, in the IEEE 802.16 systems, such a
RA-initiated UL data NACK may be encoded as a control message, a
control signaling header, or a subheader or extended header of a
MAC PDU (Protocol Data Unit), or an Advanced-MAP (A-MAP)
Information Element (IE).
[0081] Another embodiment may address the UL data collision problem
caused by missed-detection of a RA collision when UL HARQ is used.
In this case, the UL data collision caused by missed-detection of a
RA collision may cause substantial resource waste, because it may
force the collided WTRUs to repeatedly retransmit and hence
re-collide until reaching the max allowed number of HARQ
retransmissions. With UL HARQ, detecting an UL data region
collision may require additional attempts and/or other techniques
than just normal UL data HARQ decoding, because a single burst
error may be difficult to tell it is the result of normal link
error or a collision.
[0082] As shown in FIG. 8, multiple RA request opportunities 1310
are transmitted in a frame n in an uplink, and in the frame n+1 the
BS aggregate RA response message 1335 provides responses to the RA
request 1310 and other requests. After receiving and decoding the
first UL transmission in an UL data allocation as the response to a
RA request 1310, the BS may still be able to detect a collision.
For example, the BS may consider a collision is detected if the UL
data region 1338 experiences an abnormally high level of errors
based on the channel coding, such as Incremental Redundancy HARQ
(IR HARQ), or if it observes other abnormal physical signal
changes, e.g., channel delay spread.
[0083] When receiving and decoding a subsequent UL HARQ
retransmission 1338 but before reaching the maximum number of HARQ
retransmissions, the BS may be able to detect a collision in an UL
data allocation as the response to a RA request. For example, the
BS may consider a collision is detected if it observes no gain has
been obtained from the UL HARQ retransmissions.
[0084] Once detected, an UL data region collision may be handled by
using the BS's assistance to help the WTRUs to timely detect the
error condition, stop UL HARQ retransmissions, and enter an error
recovery process. The BS assistance may be an indication signal
sent by the BS to the WTRUs, e.g., a RA-initiated UL data Negative
ACKnowledgement (NACK) 1350 in the downlink in frame n+3 in FIG.
8.
[0085] When receiving such a RA-initiated UL data NACK 1350 from
the BS, the WTRU may stop the HARQ retransmission process and enter
the random access recovery process immediately.
[0086] Similar to the previous embodiment, the RA-initiated UL data
NACK 1350 signaled by the BS may be encoded as a MAC control
signal, for example, in the IEEE 802.16 systems, a control message,
or a control signaling header, or a subheader or extended header of
a MAC PDU (Protocol Data Unit), or an Advanced-MAP (A-MAP)
Information Element (IE).
[0087] In addition, if the synchronized UL HARQ is used, the
RA-initiated UL data NACK sent by the BS may be the same control
signal used to terminate the synchronized UL resource allocations
for UL HARQ retransmissions 1350, for example in frame n+3 in FIG.
9. For example, in IEEE 802.16 systems, a CDMA allocation A-MAP IE
with zero allocation can be used by the BS to signal the
RA-initiated UL data NACK and also to terminate the synchronized UL
resource allocations for UL HARQ retransmissions.
[0088] Also, if the non-synchronized UL HARQ is used, the
RA-initiated UL data NACK signaled by the BS may be a combination
of UL HARQ NACK and no UL resource allocated for the HARQ
retransmission within a pre-defined time interval after the
previous HARQ transmission or retransmission.
[0089] Alternatively, if the non-synchronized UL HARQ is used, the
RA-initiated UL data NACK signaled by the BS may be a combination
of UL HARQ NACK and zero UL resource allocation for the HARQ
retransmission. For example, in IEEE 802.16 systems, zero UL
resource allocation may be a CDMA allocation A-MAP IE with zero
allocation.
[0090] When using the zero allocation for the UL HARQ
retransmission for an UL allocation following a RA request to
terminate its UL HARQ retransmission process, the intended WTRUs
may be identified by the previously used RA opportunity
descriptors, for example, the RA region, the RA channel, and the RA
code, or an identifier derived from these RA descriptors.
[0091] Alternatively, when using the zero allocation for the UL
HARQ retransmission for an UL allocation following a RA request to
terminate its UL HARQ retransmission process, its intended WTRUs
may be identified by the previously used UL data allocation
descriptors, for example, frame index, subframe index, LRU (Logical
Resource Unit) index, etc, or an identifier derived from these UL
allocation descriptors.
[0092] When using the zero allocation for the UL HARQ
retransmission for an UL allocation following a RA request to
terminate its UL HARQ retransmission process, the identifiers of
its intended WTRUs may be included as information field in the zero
allocation control signal or may be masked with the Cyclic
Redundancy Check (CRC) of the zero allocation control signal.
[0093] The zero allocation control signal may be encoded as a
stand-alone UL resource allocation information element, for
example, a stand-alone A-MAP IE, where its type value indicates the
zero UL allocation.
[0094] Alternatively, the zero allocation control signal may be
encoded as a special case of the UL allocation IE for the UL
allocation following a RA request, for example, the CDMA Allocation
IE, where the special case may be indicated by a specific value of
an information field in the UL allocation IE.
[0095] Another embodiment may address the UL data collision problem
caused by missed-detection of RA collisions when UL HARQ is used.
The BS may configure a limited number of UL HARQ retransmissions
for the UL data region allocated as a response to a RA request,
where such a limited number is less than maximum number of UL HARQ
retransmissions for other UL allocations. With this embodiment, the
WTRU that transmits in an UL allocation following a RA request may
exist the UL HARQ retransmission when transmitted n times including
the original transmission, where 1.ltoreq.n.ltoreq.Max_num_HARQ
retransmissions. The value of n may be decided by system
configuration. The n-th HARQ NACK from the BS also indicates the
termination of the HARQ retransmission process. When receiving the
n-th HARQ NACK, the WTRU terminates the UL HARQ retransmission and
may enter the random access recovery process.
[0096] Another embodiment may address the collision problem where
not all codes are detected and where nothing is detected. This
embodiment uses a recovery mechanism such that the WTRU may
randomize its choice of slot and codes.
[0097] Another embodiment may address the RA collision problem
where a RA collision is detected. In this example, the BS may send
a NACK to notify the WTRUs that the RA failures that the BS
detected in the previous RA region are due to collisions. The
benefit of sending a NACK and not an ACK is in reduced overhead as
NACK signals are the exception rather than the rule.
[0098] FIG. 9 is a diagram of a frame using BS-Assistance
information in a RA timer or a NACK. When a BS detects a collision
in RA, at the next DL opportunity, the BS may send a NACK message
613 to inform the subscribers of the detected collision. This will
simultaneously eliminate/minimize the false detection at the WTRU
side and reduce the RA latency significantly. The proposed NACK
mechanism may be an addition to the WTRU timer-based mechanism, not
a replacement. A timer-based mechanism may be employed to be the
backup mechanism in certain scenarios.
[0099] The embodiments discussed herein may address the detections
of both collision-caused RA failure and insufficient signal power
RA failure, as well as other causes RA failure.
[0100] Although features and elements are described above in
particular combinations, each feature or element can be used alone
without the other features and elements or in various combinations
with or without other features and elements. The methods or flow
charts provided herein may be implemented in a computer program,
software, or firmware incorporated in a computer-readable storage
medium for execution by a general purpose computer or a processor.
Examples of computer-readable storage mediums include 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).
[0101] Suitable processors include, by way of example, 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 Arrays (FPGAs)
circuits, any other type of integrated circuit (IC), and/or a state
machine.
[0102] A processor in association with software may be used to
implement a radio frequency transceiver for use in a wireless
transmit receive unit (WTRU), user equipment (UE), terminal, base
station, radio network controller (RNC), or any host computer. The
WTRU may be used in conjunction with modules, implemented in
hardware and/or software, such as a camera, a video camera module,
a videophone, a speakerphone, a vibration device, a speaker, a
microphone, a television transceiver, a hands free headset, a
keyboard, a Bluetooth.RTM. module, a frequency modulated (FM) radio
unit, a liquid crystal display (LCD) display unit, an organic
light-emitting diode (OLED) display unit, a digital music player, a
media player, a video game player module, an Internet browser,
and/or any wireless local area network (WLAN) or Ultra Wide Band
(UWB) module.
* * * * *