Method and apparatus for supporting uplink starvation avoidance in a long term evolution system

This application relates to wireless communication.

The 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) program will bring new technologies, new architectures, and new ways to new LTE configurations and configurations. It is supposed to be. LTE programs are being pursued to improve spectral efficiency, reduce latency, and provide better use of wireless resources, which provides a faster user experience and richer applications and services at lower cost. Will be done.

E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and UTRAN objectives are packet-optimized with high data rates, low latency, improved system capacity and improved coverage. To develop a radio access network adapted for the system. Achieving this may require the evolution of wireless interfaces along with wireless network architectures. For example, instead of using the CDMA (Code Division Multiple Access) radio interface technology currently used in 3GPP, DL (DownLink) and UL (UpLink) transmissions, respectively. OFDMA (Orthogonal Frequency Division Multiple Access) and FDMA (Frequency Division Multiple Access) Access: Frequency division multiple access) may be used. In addition, LTE could employ full packet-switched services, which would mean that all voice calls would also be based on packet-switched.

In scenarios where wireless resources are limited, high priority services such as video conferencing will use as much available wireless resources as possible from the wireless resources assigned to the WTRU (Wireless Transmit Receive Unit). Try to get it. Since NW (NetWork: Network) has no control over how to distribute the allowed resources between applications, when this extends to the bandwidth where higher priority flows are available, HTTP (Hyper Text Transfer) Low priority flows such as Protocol) can result in a deficiency.

In HSUPA (High Speed Uplink Packet Access), the extended UL was built with the existing QoS (Quality of Service) model. In this model, if the network allows radio resources to the WTRU, the WTRU uses the priority associated with each flow supplied by the RRC (Radio Resource Control) signaling scheme. It is then responsible for choosing which uplink QoS flow should be provided. In this scheme, the network may need to provide those flows with the same priority as the higher priority flows in order to avoid the resource starvation of the lower priority flows. is there. Even so, by essentially aggregating these flows together, the WTRU assigns each flow equal transmission rights to each queue.

There are two proposals to solve the UL deficiency problem in RAN2 (Radio Access Network 2: Radio Access Network 2). One is a NW-centric solution, and the other is a WTRU-centric solution. The NW-centric solution is characterized by the monitoring of post-transmission traffic performed by the NW after receiving data from the WTRU. GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate), and PBR (Prioritized Bit Rate) information should not be sent to the WTRU.

WTRU-centric solutions can include pre-transmission traffic monitoring. Traffic monitoring is performed by the WTRU before the data is transmitted over the radio, and GBR, MBR, and PBR information can be sent to the WTRU when the RB (Radio Bearer) is established or modified. A WTRU-centric solution can be used to avoid UL deficiency in LTE and can be specified based on the number of token buckets. FIG. 1 shows an example token bucket configuration 100.

As shown in Figure 1, tokens are added to each bucket according to a certain rate (eg number of tokens / section). In order to schedule a packet the size of X tokens and send it from the WTRU, the WTRU has enough tokens to send this packet (ie, packet size <= token bucket size). Check the size of the current token bucket to confirm, and if there are enough tokens, the WTRU can send out packets. If there are not enough tokens to allow the packet to be sent, the WTRU will not send the packet at that point, but it can be sent if a sufficient number of tokens have been accumulated.

However, there are various problems when using WTRU-centric solutions for UL deficiency avoidance in LTE systems. Since RAN2 cannot handle the relationship between BSR (Buffer Status Reporting) and the set MBR / GBR, there may be a problem of loss of immediate (impending) permission. When grant loss occurs, signal system overhead, resource allocation loss, etc. may occur.

Permit loss generally means that the WTRU has received a permit but cannot fully utilize it. Since the WTRU does not know at what rate the grant will be received, will this buffer level exceed the set MBR / aMBR (aggregate MBR) when dealing with a buffer level? Since it is difficult for the WTRU to determine in advance whether or not it is, permission loss may occur. Thus, at this time, there is no mechanism to take into account the MBR / aMBR with the WTRU set when reporting the BSR. As a result, even if the WTRU reports a buffer level, it means that the configured MBR / aMBR will be exceeded when trying to obtain UL permission to handle this buffer level, which is relevant. There may be situations where the SAE bearer cannot be scheduled. This is what can be called "grant loss". eNB (evolved Node) Even if B: Advanced node B) only provides permissions corresponding to the data represented in the BSR, permission loss may occur.

Therefore, it would be beneficial to provide methods and devices to assist UL deficiency avoidance in LTE systems.

UL (UpLink) methods and devices for avoiding deficiency conditions are disclosed. This method involves determining the current buffer state information. The current buffer status information is reported to eNB (evolved Node B). A WTRU (Wireless Transmit Receive Unit) receives permission from its eNB, including determining the number of tokens it can store.

A more detailed understanding can be obtained from the following description given as an example in connection with the attached drawings.

<figref num="1">It is a figure which shows the token bucket configuration of one example.</figref><figref num="2">It is a figure which shows an example wireless communication system which includes a plurality of WTRUs and one eNB.</figref><figref num="3">It is a functional block diagram of an example of WTRU and eNB of FIG.</figref><figref num="4">It is a flow chart of the method which supports UL deficiency state avoidance.</figref><figref num="5">It is a flow chart of an alternative method to help avoid UL deficiency.</figref>

Referenced hereafter, the term "WTRU (Wireless Transmit Receive Unit)" is not limited to UE (User Equipment), mobile terminals, fixed or mobile subscriber units, Includes pagers, mobile phones, personal digital assistants (PDAs), computers, or any other type of user device capable of operating in a wireless environment. As referenced hereafter, the term "base station" operates in a Node-B, site controller, AP (Access Point), or wireless environment, without limitation. Includes any other type of capable interface device.

FIG. 2 shows a wireless communication system 200 including a plurality of WTRU210s and one eNB220. As shown in Figure 2, the WTRU210 is in communication with the eNB220. Although the configuration of the WTRU 210 and the base station 220 is represented in FIG. 2, it should be noted that the wireless communication system 200 can include any combination of wireless and wired devices.

FIG. 3 is a functional block diagram 300 of the WTRU210 and eNB220 of the wireless communication system 200 of FIG. As shown in Figure 3, the WTRU210 is in communication with the eNB220, and both are configured to implement methods that help avoid uplink deficiency conditions.

In addition to the components found in a typical WTRU, the WTRU 210 includes a processor 215, a receiver 216, a transmitter 217, and an antenna 218. The processing device 215 is configured to implement a method that assists in avoiding an uplink deficiency condition. The receiver 216 and the transmitter 217 are in communication with the processor 215. Antenna 218 is in communication with both receiver 216 and transmitter 217, facilitating transmission and reception of radio data.

In addition to the components found in a typical eNB, the eNB 220 includes a processor 225, a receiver 226, a transmitter 227, and an antenna 228. The processor 225 is configured to implement a method that assists in avoiding an uplink deficiency condition. The receiver 226 and the transmitter 227 are in communication with the processor 225. Antenna 228 is in communication with both receiver 226 and transmitter 227, facilitating transmission and reception of radio data.

FIG. 4 is a flow chart of Method 400 to support UL deficiency avoidance. At step 410, the WTRU210 reports the current buffer status information to the eNB220. This information can include information for some or all RBs and can be directed to prevent permission loss. This information can include BO (Buffer Occupancy) information, the size of the token bucket of each RB for each of the PBR, GBR MBR, and eMBR, the token storage pattern in the WTRU, the remaining power, etc. ..

BO information can be for one RB, a group of RBs, or all RBs, while remaining power is for all RBs. The token size and token accumulation pattern can be for PBS, GBR, MBR, and aMBR for RB, respectively. Alternatively, you can report the number of token aggregates for some RBs, and report another aggregate individually. For example, aggregate tokens for GBS, MBR, and eMBR can be reported regardless of each other. Since grants are in WTRU units, the total number of tokens available to WTRU210 can provide an efficient way to schedule grants.

During the reporting in step 410, the WTRU210 can report the ratio of tokens to the maximum size of the token bucket. For example, 2 bits to indicate that the WTRU210 has 0 to 1/4, 1/4 to 1/2, 1/2 to 3/4, 3/4 to 100 percent of the maximum size of the token bucket. Can be used. Also note that the 2 bits can be defined to support non-uniform ranges such as no tokens, less than 1/4 tokens, between 1/4 tokens and 1/2 tokens, greater than 1/2 tokens, etc. Should be done.

As an example, if 2 bits are used to represent a range, then "00" is in the range 0 to 1/4, "01" is in the range 1/4 to 1/2, and "10" is in the range 1/2 to. On 3/4, "11" is available for 3/4 to 100 percent. It should be noted that any combination of bits can also be used to represent a different range than those described. Similar rules can be used for non-uniform ranges (eg, "00" means no token, "01" means less than 1/4 token, and so on).

To help the eNB 220 synchronize as described above, the WTRU210 reports to the eNB 220 all or only a portion of the information related to the WTRU210. The eNB 220 is therefore aware of the WTRU situation and can issue accurate permit decisions to help avoid permit losses. In addition, the WTRU210 can report for each RB, group of RBs, all RBs, only high priority RBs, or any combination. The WTRU210 will also accumulate enough tokens for the WTRU210 to send at least one packet (eg the size of the smallest TB (Transport Block)) in its buffered state (eg permission request). A deaf target time can be specified to allow the eNB 220 to schedule permissions at or after that indicated time. WTRU210 is TTI (Transmission Time) Any part or all of the information can be reported per Interval) or every few TTIs that can be set by the RRC signaling scheme during the RB establishment or modification process.

The WTRU210 can periodically send its report or token bucket information (step 410) or can trigger it by a predefined event. Events that can be used to trigger a report include events in which a value for pre-described information exceeds or falls below a threshold. For example, if the amount of tokens for an RB or group of RBs falls below a predefined threshold, the WTRU210 can be triggered to report. The threshold can be set by the RRC signaling scheme in the RB establishment and can be defined as a fraction of the maximum size of the token bucket.

Thus, the state information of the WTRU210 (eg, the buffer state) can be evaluated by the WTRU210 on a sliding window, but can be sent to the eNB 220 every TTI or after two or more TTIs.

In step 420, the eNB 220 determines how many tokens the WTRU210 can accumulate. In one embodiment, weights are provided for each bucket corresponding to a signal to each application and network. These weighted values are formed in the form of cumulative values and can be signaled to the WTRU210. Depending on the application priority, one WTRU210 may require more resources, even if there are multiple RBs for different WTRU210s, all sending packets at the same rate. Therefore, the priority can be shared among various WTRU210s based on the weight signaled from the NW.

Once the eNB 220 has all the information it needs to make the authorization allocation, the eNB 220 signals the WTRU210 with the authorization allocation (step 430). It should be understood that the eNB 220 can signal an individual WTRU210, a group of WTRU210s, or all WTRU210s in the wireless communication system 200.

FIG. 5 is a flow chart of an alternative method 500 that assists in avoiding UL deficiency. In step 510, the WTRU210 determines its own buffer state. In one example, the WTRU210 can calculate and evaluate its own buffer state and send an authorization request to the eNB 220 based on that evaluation (step 520).

The permit request can be a relative or absolute request sent per TTI or every several TTIs. Whether to send a relative or absolute permit request and how often a permit should be sent from the WTRU should be set by the RRC signaling scheme at the RB establishment or modification stage. For example, a relative permission request is relative to a previously used value, and changes are signaled to the WTRU210 so that the WTRU210 can derive the actual permission from the previous and current permissions. .. For absolute permissions, the value that WTRU210 should use is represented without the need for WTRU210 to make any derivation.

The permission request can be in the form of a "Happy Bit", where a single bit or multiple bits are sent to the eNB 220 in the Happy Bit format. If a single bit permit request is used, that single bit is the WTRU buffer occupancy, packet information, power remaining, tokens for all RBs (eg for PBR, GBR, MBR, aMBR). It should represent the evaluation results for all the various attributes, such as the remaining amount, and the like.

The happy bit can represent only the state for one RB or the attributes of each RB, and can be evaluated on a sliding window. A happy bit can represent any RB, high priority RB, or any combination thereof, and can be reported to the eNB 220 per TTI or after many TTIs. The Happy Bit can also represent the amount of permission request that the WTRU210 desires.

If the authorization request contains multiple bits, one bit can represent one RB or all attributes of a group of RBs (eg, with similar characteristics such as priority and etc.), or That one bit can be representative of one attribute of all RBs (eg, token remaining, BO, or power remaining). In addition, multiple bits can be used as indexes to represent various combinations of WTRU210 states for authorization requests. For example, the plurality of bits can represent whether the WTRU210 is a token, power, or data limit. If more bits are needed for permission request purposes, a BSR (Buffer Status Report) can be used to represent the permission request from the WTRU210.

Table 1 below shows an example index representing the mapping that reflects the various permission vs. status display requests.

<tables num="1"><img file="JP4806077B2_D0001.tif" /></tables>

As shown in Table 1 above, several index values represent whether the WTRU210 is a token limit, a power limit, a data limit, or a combination of both. It should be noted that although Table 1 shows an example mapping, other mappings can also be used and other restrictions can be reported. For example, the WTRU210 can include saying that the number of TTIs given to the WTRU210 was insufficient to transmit the data of the WTRU210. After receiving the information from the WTRU210, the eNB 220 signals the WTRU210 for permission (step 530).

To assist in UL deficiency avoidance, an RRC signaling scheme containing assisted parameters may be required. Table 2 below shows RRC parameters as an example to help avoid UL deficiency, and the types are associated with IE (Information Element).

<tables num="2"><img file="JP4806077B2_D0002.tif" /></tables>

Another parameter that may need to be signaled is whether the token bucket is allowed to be negative. This additional parameter allows various variations of the token bucket implementation method. For example, some WTRU210s may want to check if there are enough tokens to send a packet, while other implementations of token buckets have less than 0 tokens. As long as it is large, the WTRU210 will be allowed to send packets. In the latter implementation method, the token bucket is allowed to be negative. Whether the token bucket implementation method enables a negative token bucket depends on whether the WTRU210 signals this parameter to the eNB220 or the network signals it to the WTRU210 via the eNB220. It can be any of the additional signaling parameters. Combinations of signal schemes can also be supported.

Table 3 below shows the token bucket parameters as an example that can signal in addition to the parameters shown in Table 2.

<tables num="3"><img file="JP4806077B2_D0003.tif" /></tables>

During the RB establishment or modification stage, it is possible that many parameters need to be signaled through the RRC message. Since the parameters related to the token bucket are quasi-static and do not need to be updated for each permission, even if the parameters related to the token bucket must be signaled, the network can use those parameters (eg, for example). , Bucket size, token arrival time interval, and similar) need not necessarily be included per permit. Alternatively, it is possible to signal those parameters first in RB establishment or during RB modification. If any of the token bucket parameters described in Table 2 or Table 3 need to be updated, only those parameters need to be signaled from the eNB 220 to the WTRU210. Therefore, using the parameters described in Table 2 or Table 3, the "range" and / or "granularity" of the token arrival time intervals that the WTRU210 can support, as well as the WTRU210, are The capabilities of the WTRU210, such as the smallest and / or largest bucket size that can be assisted, and the like are signaled. For example, these parameters can be signaled during the RB establishment or modification phase through an RRC re-configuration message.

As an alternative to the parameters defined in Tables 2 and 3, a table can be predefined for each RB with various variants of the parameters associated with each token bucket indexed. .. The index of the parameter associated with each token for that RB can then be signaled. Indexes can also be provided for various combinations of token-related parameters for an RB, and only one index for the token-related parameters of that RB is signaled. Parameters for GBR and non-GBR such as GBR or MBR token bucket can share one index table for signaling purposes. Alternatively, parameters related to different tokens for different RBs can be indexed in the form of a single table. However, if there is only one set of parameters for the GBR or MBR of one RB, it is possible to predefine these parameters, such as by standardizing, and it is necessary to send a signal. May not be done. Therefore, the index can contain parameters related to one RB or parameters related to multiple RBs.

The WTRU210 can also store token-related parameters locally and communicate the appropriate parameters to the network. For example, the WTRU210 can have a token bucket size and a token arrival cycle that depend on its own implementation method. In this case, it can be notified to the network by signaling these parameters if necessary. In one example, this signaling scheme may be in the form of a WTRU capability information report.

Functions and elements are described above in specific combinations, but each function or element varies, either alone without other functions and elements, or with or without other functions and elements. Can be used in combination. The method or flow diagram provided herein is performed in a computer program, software, or firmware embodied in a computer-readable storage medium for execution by a computer or processor for general purpose purposes. be able to. Examples of computer-readable storage media include ROM (Read Only Memory), RAM (Random Access Memory), registers, cache memory, semiconductor memory devices, and so on. Includes magnetic media such as internal hard disks and removable disks, magnetic-optical media, and optical media such as CD-ROM disks and DVDs (Digital Versatile Disks).

Examples of suitable processing devices are general purpose processing devices, dedicated purpose processing devices, conventional processing devices, DSPs (Digital Signal Processors), multiple micro processing devices, and one associated with a DSP core. Or multiple micro-processing devices, control devices, micro-control devices, ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array) circuit, or any other type of IC (Integrated Circuit) ), And / or state machines are included.

Used in WTRU (Wireless Transmit Receive Unit), UE (User Equipment), terminal, base station, RNC (Radio Network Controller), or any host computer A processing device associated with the software can be used to implement a radio frequency transmitter / receiver for the purpose. WTRU is implemented in hardware and / or software, camera, video camera module, videophone, speakerphone, vibrating device, speaker, microphone, TV transmitter / receiver, hands-free handset, keyboard, Bluetooth (Bluetooth (registration) Trademark)) Module, FM (Frequency Modulated) wireless unit, LCD (Liquid Crystal Display) display unit, OLED (Organic Light-Emitting) Diode: Organic light emitting diode display unit, digital music player, media player, video game player module, internet browser, and / or any WLAN (Wireless Local Access Network) or UWB (Ultra Wide Band:) It can be used in conjunction with modules such as ultra-wideband) modules.

<u style="single">Embodiment</u> 1. A method for avoiding UL (UpLink) deficiency status implemented in WTRU (Wireless Transmit Receive Unit).

2. The method of embodiment 1, further comprising determining the current buffer state information.

3. The method in any of the previous embodiments, further comprising reporting the current buffer state information to the eNB (evolved Node B).

4. The method in any of the preceding embodiments, further comprising receiving a permit from the eNB, wherein the permit comprises determining the number of tokens that the WTRU can accumulate.

5. The method in any of the previous embodiments where the current buffer state information contains information for at least one RB (Radio Bearer).

6. The method in any of the previous embodiments where the current buffer state information contains information for multiple RBs.

7. The method in any of the previous embodiments for determining the number of tokens that the WTRU can accumulate is based on the size of the current token bucket for at least one RB.

8. The size of the token bucket is one of the following: GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate), and / or PBR (Prioritized Bit Rate). The method in any of the previous embodiments, which is for the vehicle.

9. The method in any of the previous embodiments, further comprising reporting the aggregate number of tokens for multiple RBs.

10. The method in any of the previous embodiments, further comprising triggering a reporting step.

11. Triggering a report is a method in any of the previous embodiments, comprising reducing the value of the token for RB below a predefined threshold.

12. The method in any of the previous embodiments where the current buffer status information includes BO (Buffer Occupancy) information.

13. The method in any of the previous embodiments, further comprising reporting a target time by which sufficient tokens will be accumulated to send at least one packet.

14. The method in any of the previous embodiments, further comprising assessing the buffer state.

15. The method in any of the previous embodiments, further comprising sending a permission request based on an assessment of buffer status.

16. The method in any of the previous embodiments, comprising calculating the buffer state.

17. The method in any of the previous embodiments, wherein the permission request comprises at least one bit.

18. The method in any of the previous embodiments, wherein the permission request further comprises more than one bit.

19. The method in any of the previous embodiments, wherein at least one bit represents at least one attribute of at least one RB (Radio Bearer).

20. The method in any of the previous embodiments where the authorization request comprises at least one token bucket parameter.

21. The method in any of the previous embodiments further comprising determining whether the value of the token for sending a packet in the token bucket exceeds a threshold.

22. The method in any of the previous embodiments, further comprising transmitting at least one packet.

23. The method in any of the previous embodiments, further comprising subtracting a token value equivalent to the size of at least one outgoing packet from the token bucket.

24. The method in any of the previous embodiments where subtracting the token value from the token bucket reduces the number of tokens to less than zero.

25. The method in any of the previous embodiments further comprising receiving a configuration parameter representing the minimum number of tokens for sending a packet in a token bucket.

26. Any of the previous, further comprising determining whether sending at least one packet would reduce the number of tokens in the token bucket to less than the minimum number of tokens. The method in the embodiment.

27. The method in any of the previous embodiments, further comprising transmitting at least one packet based on the determination.

28. The method in any of the previous embodiments, wherein the configuration parameter represents that the minimum number of said tokens for packet transmission is less than zero.

29. The method in any of the previous embodiments where the configuration parameter explicitly represents the minimum number of tokens.

30. A WTRU configured to perform the method in any of the previous embodiments.

31. WTRU of embodiment 30, further comprising a receiver.

32. The WTRU of any of embodiments 30-31, further comprising a transmitter.

33. The WTRU of any of embodiments 30-32, further comprising a receiver and a processor in communication with the transmitter.

34. The WTRU of any of embodiments 30-33, wherein the processor is configured to determine the current buffer status information.

35. The WTRU of any of embodiments 30-34, wherein the processor is configured to report current buffer status information to the eNB.

36. The WTRU of any of embodiments 30-35, wherein the processor is configured to receive a permit from the eNB, the permit comprising determining the number of tokens the WTRU can accumulate.

37. The WTRU of any of embodiments 30-36, wherein the processor is configured to include information for at least one RB in the buffer state information.

38. The WTRU of any of embodiments 30-37, wherein the processor is configured to include information for a plurality of RBs in the buffer state information.

39. The WTRU of any of embodiments 30-38, wherein the processor is configured to determine whether the value of the token for packet transmission in the token bucket exceeds a threshold.

40. The processing device is configured to transmit at least one packet and to subtract the token value equivalent to the size of the at least one transmitted packet from the token bucket, embodiments 30-39. Either WTRU.

41. The WTRU of any of embodiments 30-40, wherein subtracting the value of the token from the token bucket reduces the number of tokens to less than zero.

42. The threshold is the WTRU of any of embodiments 30-41, which is indicated by the setting parameter in the WTRU.

43. The configuration parameter is the WTRU of any of embodiments 30-42, which is explicitly signaled.

44. An eNB configured to perform any of the methods 1-29.

45. The eNB of Embodiment 44, further comprising a receiver.

46. The eNB of any of embodiments 44-45, further comprising a transmitter.

47. The eNB of any of embodiments 44-46, further comprising a receiver and a processor in communication with the transmitter.

48. The eNB of any of embodiments 44-47, wherein the processor is configured to receive current buffer status information from the WTRU.

49. The eNB of any of embodiments 44-48, wherein the processor is configured to determine the number of tokens that the WTRU can accumulate.

50. The eNB of any of embodiments 44-49, wherein the processor is configured to send a permit to the WTRU.