Method and apparatus for adaptive encoding of real-time information in wireless networks

BACKGROUND

Field

0001This disclosure relates generally to wireless communications. More specifically, embodiments disclosed herein relate to providing adaptive encoding of real-time information in packet-switched wireless communication systems.

Background

0002Wireless communication systems are widely deployed to provide various types of communications (such as voice and data) to multiple users. Such systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), or other multiple access techniques. A wireless communication system may be designed to implement one or more standards, such as IS-95, cdma2000, IS-856, WCDMA, TD-SCDMA, and other standards.

0003As the demand for multimedia services (e.g., real-time video and audio, wireless gaming, and other multimedia data) in wireless communication systems grows, there lies a challenge to provide efficient and high quality multimedia services. United States Patent Application Publication No. <patcit id="pcit0001" dnum="US2005210515A"><text>US2005210515</text></patcit> relates to a server system for performing communication over wireless network and operating method thereof. European Patent Application Publication No. <patcit id="pcit0002" dnum="EP1168732A"><text>1 168 732</text></patcit> relates to a communication system, communication method, transmitting terminal and receiving terminal.

0004The present invention relates to an access terminal apparatus for real-time information encoding in wireless communications and a method for real-time information encoding in wireless communications, as defined in the appended claims. Enabling disclosure for the invention is found in the embodiment of <figref idref="f0003 f0004 f0005 f0006">Figures 3-6</figref>. The remaining embodiments are to be understood as examples which do not describe parts of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0005<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">FIG. 1</figref> illustrates an embodiment of a communication system;</li><li><figref idref="f0002">FIG. 2</figref> depicts an embodiment of a rate-adaptation scheme, as illustrated by a plot of reverse link data delay as a function of time;</li><li><figref idref="f0003">FIG. 3</figref> illustrates an embodiment of adaptively adjusting set thresholds in a rate-adaptation scheme based on end-to-end data delay;</li><li><figref idref="f0004">FIG. 4</figref> illustrates a flow diagram of a process, which may be used to implement some disclosed embodiments;</li><li><figref idref="f0005">FIG. 5</figref> illustrates a flow diagram of a process, which may be used to implement some disclosed embodiments;</li><li><figref idref="f0006">FIG. 6</figref> illustrates a block diagram of an apparatus, in which some disclosed embodiments may be implemented;</li><li><figref idref="f0007">FIGs. 7A-7C</figref> illustrate embodiments of adaptively selecting the encoding frame type based on lost packet information; and</li><li><figref idref="f0008">FIG. 8</figref> illustrates a flow diagram of a process, which may be used to implement some disclosed embodiments.</li></ul>

DETAILED DESCRIPTION

0006Adaptive real-time multimedia sources (e.g., video telephony (VT)) are still in their early infancy in today's wireless environment, e.g., compared with their counterpart in a wireline (such as the Internet) environment. In a WCDMA system, for example, the current approach is to encode all video frames to fit within a specified bandwidth or bitrate. In light of varying complexity invariably associated with different video sequences, a fixed bitrate may be unnecessarily high for some video sequences and thus does not produce noticeable improvement in perceptual quality, yet unacceptably low for other video sequences and thus produces noticeably low perceptual quality. As for today's wireless packet data networks (e.g., a high rate packet data (HRPD) type system), there is no fixed or pre-defined traffic rate for VT flow (such as in a WCDMA system). In light of the growing demand for VT and other real-time multimedia services, a need therefore exists for advancing VT and other real-time information encoding in wireless communication systems.

0007In a wireless packet data network, an encoder (e.g., residing in a wireless communication device such as an access terminal) may be able to infer the current end-to-end traffic channel from the reverse link (RL) traffic channel (which is local information at the access terminal, as further described below), as well as an end-to-end (E2E) feedback signal from the decoder buffer in the receiving decoder. Thus, it would be desirable for the encoder to adapt its encoding rate according to the actual channel performance (e.g., RL traffic channel conditions, end-to-end congestion/delay/loss conditions, etc.) based on the feedback information available, while performing real-time information encoding (e.g., in a manner such that the information arriving at the decoder may be decoded without substantial buffering). Such an approach may allow the frame delay to be effectively controlled, and as a result, improve the quality and efficiency of VT and other real-time information transmission in a wireless environment. (Note, for VT in a wireline environment, the first hop (e.g., from a desktop to the Internet) is typically not the bottleneck, nor does the available bandwidth and condition of the first hop change rapidly with time. Therefore, the local traffic channel information may not be needed in adjusting the VT encoding rate in such an environment.)

0008Embodiments disclosed herein relate to methods and systems for providing adaptive encoding of real-time information in packet-switched wireless communication systems. In the ensuing description, VT may be used by way of example to illustrate aspects of the invention. Such should not be construed as limiting. Various embodiments and aspects disclosed herein may be applicable to adaptive encoding of any real-time information in wireless communication systems.

0009An encoder described herein may be associated with (e.g., reside in) a wireless communication device such as an access terminal (AT), configured to encode any real-time information, including (but not limited to) video, audio, gaming, and other real-time (e.g., interactive) data.

0010An AT described herein may refer to various types of devices, including (but not limited to) a wireless phone, a cellular phone, a laptop computer, a wireless multimedia device, a wireless communication personal computer (PC) card, a personal digital assistant (PDA), an external or internal modem, etc. An AT may be any data device that communicates through a wireless channel and/or through a wired channel (e.g., by way of fiber optic or coaxial cables). An AT may have various names, such as access unit, subscriber unit, mobile station, mobile device, mobile unit, mobile phone, mobile, remote station, remote terminal, remote unit, user device, user equipment, handheld device, etc. Different ATs may be incorporated into a system. ATs may be mobile or stationary, and may be dispersed throughout a communication system. An AT may communicate with an access network (AN) on a forward link (FL) and/or an RL at a given moment. The FL (or downlink) refers to transmission from the AN to AT. The reverse link (or uplink) refers to transmission from the AT to the AN.

0011An AN described herein may refer to the network portion of a communication system, and may include (but is not limited to) and/or implements the function of a base station (BS), a base-station transceiver system (BTS), an access point (AP), a modem pool transceiver (MPT), a Node B (e.g., in a WCDMA type system), etc. Further, a cell may refer to a coverage area serviced by an AN. A cell may be divided into one or more sectors.

0012Various aspects, features, and embodiments are described in further detail below.

0013<figref idref="f0001">FIG. 1</figref> illustrates an embodiment of a communication system 100, in which various embodiments disclosed herein may be implemented. By way of example, an encoder 120, along with a rate-adaptation unit (or module) 130, may reside in an AT 110. Encoder 120 may be configured to have a range of encoding rates. Encoder 120 may access wireless/wired networks 150 via a wireless access module 140 in AT 110. Wired/wireless networks may include one or more ANs, backhaul and core networks, and other network infrastructure. Wireless access module 140 may include, e.g., media access channel (MAC) layer, physical layer, and other means configured to provide access to wireless/wired networks 150. In some embodiments, for example, the physical/MAC layer at wireless access module 140 may be configured to be in communication with an AN in wireless/wired networks 150 and to receive some local feedback information available in the AN. A decoder 170, along with a decoder buffer 180, may reside in another AT 160, configured to decode the encoded data from encoder 120 via wireless/wired networks 150.

0014In system 100, rate-adaptation unit 130 may be configured to receive feedback information associated with data transmission, which may include "local feedback information" (as illustrated by "Local" in <figref idref="f0001">FIG. 1</figref>) and "end-to-end feedback information" (as illustrated by "E2E" in <figref idref="f0001">FIG. 1</figref>), from wireless access module 140, and adapt the real-time information encoding according to such feedback information, as further described below.

0015The term "local feedback information" disclosed herein may refer to feedback information readily available and without substantial delay at encoder 120 (e.g., provided by wireless access module 140), including (but not limited to) RL data delay (e.g., provided by the physical/MAC layer at wireless access module 140), RL channel condition (e.g., AT's transmit power headroom, estimated channel rate, etc.), RL sector loading status (e.g., associated with the number of transmitters on RL, rise-over-thermal (RoT) measured on RL, etc.), RL physical/MAC layer packet payload (e.g., provided by the physical/MAC layer at wireless access module 140), RL lost packet information (e.g., provided by the physical/MAC layer at wireless access module 140), the amount of data currently buffered in wireless access module 140, etc.

0016The term "end-to-end feedback information" disclosed herein may refer to feedback information transmitted from a receiver (e.g., decoder 170) back to a sender (e.g., encoder 120), e.g., via wireless/wired networks 150 and wireless access module 140 (such as illustrated by the dashed line in <figref idref="f0001">FIG. 1</figref>), including (but not limited to) end-to-end data delay, end-to-end jitter, decoder buffer status, core network and backhaul traffic delay, end-to-end missing packet information, etc. The end-to-end feedback information may also take into account FL channel condition (e.g., as reflected by signal-to-noise-plus-interference ratio (SINR) measured on FL), FL sector loading status (e.g., associated with the number of users sharing the scheduler at the AN), etc.

0017In some embodiments, end-to-end data delay may be determined at decoder 170 and provided to rate-adaptation unit 130, e.g., via wireless/wired networks 150 and wireless access module 140, such as shown in <figref idref="f0001">FIG. 1</figref>. In other embodiments, end-to-end data delay may be inferred (or estimated) based on the feedback information rate-adaptation unit 130 receives from decoder 170, e.g., via wireless/wired networks 150 and wireless access module 140. The end-to-end feedback information may be carried, e.g., via RTP (real-time transport protocol) Control Protocol (RTCP), embedded in the traffic stream from the receiver to the sender, or via application-defined messages.

0018In an embodiment, rate-adaptation unit 130 may adapt the encoding rate according to RL data delay. For example, rate-adaptation unit 130 may decrease the encoding rate, if RL data delay is deemed large, e.g., compared with a predetermined threshold (or "delay target"). Rate-adaptation unit 130 may increase the encoding rate (e.g., to improve the quality), if RL data delay is well below the delay target. Consider video encoding as an example. An encoder may adjust its encoding rate by way of a quantization parameter (QP), such as in a MPEG-4, H.263, or H.264 type system. QP indicates the quantization step size for a given frame, which may for example range between {1,...,31}. A smaller QP may yield a better video quality and result in a higher frame size for a given frame. In contrast, a larger QP may yield a poorer video quality and result in a smaller frame size. In some embodiments, rate-adaptation unit 130 may use RL data (e.g., frame) delay to adjust the QP value for the next frame based on the current QP value. If RL frame delay incurred is deemed large for decoder buffer 180 (e.g., compared with a delay target), QP may be increased to reduce the next frame size (and hence the future frame delay). Conversely, if RL frame delay is deemed small (e.g., below the delay target), QP may be decreased to improve the video quality, e.g., in a manner that maintains RL frame delay within the delay target.

0019In an embodiment, rate-adaptation unit 130 may adapt the encoding rate by changing the frequency at which the encoded data may be sent to decoder 170. For example in VT applications, such may include adjusting the encoded video frame rate according to the feedback information.

0020In some embodiments, rate-adaptation unit 130 may adapt the encoding rate according to RL channel condition, RL sector loading status, etc. Such may allow encoder 120 to react to time-varying events (e.g., sudden changes in AT's transmit power headroom, network congestion, and/or AT 110 being handed off between sectors of different loading) in wireless/wired networks 150, while ensuring that the information still arrives at decoder 170 substantially on time and uninterrupted, and is decoded with sufficient quality. For example, rate-adaptation unit 130 (and/or wireless access module 140) may first determine an estimated channel rate (e.g., the available throughput in the wireless channel) based on RL channel condition, RL sector loading status, and other feedback information, and then adjust the actual encoding rate based on the estimated channel rate.

0021In an embodiment, rate-adaptation unit 130 may be configured to increase the encoding rate when the sector is lightly loaded, and throttle back the encoding rate when the sector is heavily loaded.

0022In an embodiment, rate-adaptation unit 130 may adapt the encoding rate according to RL channel condition, e.g., the transmit power headroom of AT 110. Such may allow an AT with limited power (e.g., with limited power headroom, or situated at the edge of its sector) to carry on real-time information encoding (e.g., VT applications) at an acccptablc quality level by lowering the encoding rate.

0023In an embodiment, rate-adaptation unit 130 may adapt the encoding rate according to RL physical layer packet payload and/or MAC layer packet payload. For example, the encoder may encode the information at an encoding rate that is compatible with (e.g., smaller than) RL physical/MAC layer packet payload.

0024In an embodiment, rate-adaptation unit 130 may adapt the encoding rate according to end-to-end feedback information (e.g., end-to-end data delay), which may be provided by decoder 170 along with decoder buffer 180 via wireless/wired networks 150 (such as illustrated in <figref idref="f0001">FIG. 1</figref>). For example, in the event that AT 110 is in a poor FL condition or in a highly-loaded FL sector, rate-adaptation unit 130 may reduce the encoding rate, so as to lighten the sector loading and ensure that the information still arrives at decoder 170 substantially on time and uninterrupted and is decoded with sufficient quality. In the event that AT 110 is in a good end-to-end condition, rate-adaptation unit 130 may increase the encoding rate, thereby providing better overall quality while still meeting delay requirements.

0025In VT applications, for example, missing video frames or delayed video frame arrival may be indicative of the current encoding rate being too large. In such events, QP may be adjusted accordingly, e.g., increased to reduce the frame size. In some embodiments, the end-to-end feedback information may also be used to adjust the set thresholds in rate-adaptation control schemes, as further described below.

0026<figref idref="f0002">FIG. 2</figref> depicts an embodiment of a rate-adaptation control scheme, where a plot of RL data delay as a function of time for a VT application is illustrated by way of example. RL data (e.g., frame) delay may be measured (or estimated) based on local feedback information available at wireless access module 140 and provided to rate-adaptation module 130, such as illustrated in <figref idref="f0001">FIG. 1</figref>. One or more set thresholds, e.g., denoted as (Ti+D), i =1,2,3,4, may be used to adjust RL data delay, where the parameter D may be representative of the effect of end-to-end data (e.g., frame) delay, as further described below. For example, if RL data delay at some instance exceeds a particularly threshold, e.g., between (T3+D) and (T4+D), QP may be adjusted, e.g., increased to (QP+QP3) to reduce the delay. If RL data delay at another instance falls below another threshold, e.g., between (T1+D) and (T2+D), QP may also be adjusted, e.g., decreased to (QP-QP2) to provide a better quality.

0027<figref idref="f0003">FIG. 3</figref> illustrates an embodiment of how the end-to-end delay information may be used to adjust the set thresholds in a rate-adaptation control scheme (such as in the embodiment of <figref idref="f0002">FIG. 2</figref>). By way of example, box 310 illustrates RL data delay as a function of time, which may be determined (e.g., measured or estimated) at wireless access module 140 and provided to rate-adaptation unit 130 (such as illustrated in <figref idref="f0001">FIG. 1</figref>). Box 320 illustrates end-to-end data delay as a function of time, which rate-adaptation unit 130 may also receive from wireless access module 140 (such as described above). As illustrated in the figure, if end-to-end data delay falls below a lower threshold T_L (e.g., at point 322), the set thresholds (Ti, i=1,2,3,4) in box 310 may be increased, as section 312 illustrates (which may be equivalent to including a larger D in the set thresholds, such as shown in <figref idref="f0002">FIG. 2</figref>). If end-to-end data delay exceeds an upper threshold T_H (e.g., at point 324), the set thresholds (Ti, i=1,2,3,4) in box 310 may be decreased, as section 314 illustrates (which may be equivalent to including a smaller D in the set threshold, such as shown in <figref idref="f0002">FIG. 2</figref>).

0028<figref idref="f0004">FIG. 4</figref> illustrates a flow diagram of a process 400, which may be used to implement some disclosed embodiments. Step 410 receives RL data delay (e.g., from wireless access module 140). Step 420 compares RL data delay with one or more set thresholds and adjusts an encoding rate accordingly. Step 430 receives end-to-end data delay (e.g., from wireless access module 140). Step 440 adjusts the set thresholds based on the received end-to-end data delay. Subsequently, process 400 returns to step 410.

0029<figref idref="f0005">FIG. 5</figref> illustrates a flow diagram of a process 500, which may be used to implement some disclosed embodiments, e.g., process 400 of <figref idref="f0004">FIG. 4</figref> in a VT application. Step 510 receives RL data delay (e.g., from wireless access module 140). Step 520 compares RL data delay with one or more set thresholds. If RL data delay is deemed high (e.g., in reference to a predetermined threshold, such as illustrated in <figref idref="f0002">FIG. 2</figref>), step 530 follows and increases QP. If RL data delay is deemed low, on the other hand, step 540 follows and decreases QP. Alternatively, if RL data delay is deemed acceptable (or "OK"), no adjustment needs to be made. Subsequently, step 550 follows and receives end-to-end data delay. Step 560 then determines if end-to-end data delay is acceptable (e.g., in reference to some predetermined thresholds, such as illustrated in <figref idref="f0003">FIG. 3</figref>). If end-to-end data delay is deemed high, step 570 follows and reduces the set thresholds (such as illustrated in <figref idref="f0003">FIG. 3</figref>). If end-to-end data delay is deemed low, step 580 follows and increases the set thresholds (such as illustrated in <figref idref="f0003">FIG. 3</figref>). Alternatively, if end-to-end data delay is deemed acceptable (or "OK"), no adjustment needs to be made. Process 500 subsequently returns to step 510.

0030In some embodiments (such as illustrated in <figref idref="f0002 f0003 f0004 f0005">FIGs. 2-5</figref> above), a rate-adaptation control scheme may be implemented by employing two control loops, e.g., including a fast (or inner) loop associated with RL data delay and a slow (or outer) loop associated with the end-to-end data delay (such as schematically illustrated in <figref idref="f0001">FIG. 1</figref>). Such a two-loop approach may effectively make use of both the small delay provided by local feedback information and the large delay provided by end-to-end feedback information. (In the latter case, there may also be additional time needed to estimate the end-to-end behavior.) In an embodiment, the two control-loops may be configured to allow the encoder/decoder system to adapt its performance according to a desired tradeoff between delay and quality. For example, data delay may be used as the "target measure" (hence quality being subject to it) for the control scheme in some situations; while quality may be used as the target measure (hence data delay being subject to it) for the control scheme in other situations.

0031In other embodiments, a rate-adaptation control scheme may make use of a single control loop, e.g., based on RL data delay, end-to-end data delay, or other types of feedback information (such as described above). Other rate-adaptation schemes may also be implemented. The rate-adaptation schemes thus described may be utilized to control the encoding of any real-time information.

0032<figref idref="f0006">FIG. 6</figref> illustrates a block diagram of an apparatus 600, in which some disclosed embodiments may be implemented. Apparatus 600 may include local-feedback-receiving unit (or module) 610 configured to receive RL data delay and other local feedback information (e.g., from wireless access module 140); a threshold-adjusting unit 620 configured to generate and/or adjust one or more set thresholds; a comparing unit 630 configured to compare the target measure (e.g., RL data delay) with the set thresholds provided by threshold-adjustment unit 620; and a rate-adjusting unit 640 configured to adjust the encoding rate (e.g., by way of QP or frame rate as in VT applications) based on the output from comparing unit 630. Apparatus 600 may further include an E2E-feedback-receiving unit 650, configured to receive end-to-end feedback information (e.g., from wireless access module 140) and provide it to threshold unit 620. Threshold unit 620 may further adjust the set thresholds based on end-to-end feedback information (such as described above).

0033In some situations, it may be desirable to use RL lost packet information (e.g., provided locally by way of RL physical layer automatic repeat request (ARQ), RL hybrid ARQ, and/or RLMAC-ARQ) to determine the next unit of the information to be encoded, e.g., a frame type for a subsequent frame to be encoded in a VT application. By way of example, <figref idref="f0007">FIGs. 7A-7C</figref> illustrate embodiments of adaptively selecting the encoding frame type based on RL lost packet information. In VT applications, because of the decoding dependency for Predicted frames (or P-frames), a lost I-frame or P-frame causes propagating errors for the subsequent P-frames, such as illustrated in <figref idref="f0007">FIG. 7A</figref>. In such an event, if the encoder continues sending the remaining P-frames with reference to the missing frame until the end of Group-of-Picture (GOP), the visual quality of the remaining frames may be significantly degraded. Thus, by making use of local feedback information regarding the lost frames, the encoder may encode the next frame as an I-frame to interrupt the propagation of errors, as illustrated in <figref idref="f0007">FIG. 7B</figref>. The cncodcr may encode the next frame as a new P frame whose reference frame is the latest successful transmitted frame, as illustrated in <figref idref="f0007">FIG. 7C</figref>.

0034<figref idref="f0008">FIG. 8</figref> illustrates a flow diagram of a process 800, which may be used to implement some disclosed embodiments. Step 810 receives feedback information associated with data transmission from a wireless access module. Step 820 encodes real-time information in accordance with the received feedback information.

0035In process 800, step 820 may further include adapting an encoding rate in accordance with the feedback information and encode the real-time information at the encoding rate (such as described above). Step 820 may also include determining the next unit of the information to be encoded (e.g., selecting a frame type for a subsequent frame to be encoded as in VT applications) in accordance with the feedback information (such as illustrated in <figref idref="f0007">FIGs. 7A-7C</figref>).

0036Embodiments disclosed herein provide some embodiments of adaptive encoding of real-time information in packet-switched wireless communication systems. There are other embodiments and implementations.

0037Various units/modules described herein may be implemented in hardware, software, firmware, or a combination thereof. In a hardware implementation, various units may be implemented within one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPDs), field programmable gate arrays (FPGA), processors, microprocessors, controllers, microcontrollers, programmable logic dcviccs (PLD), other electronic units, or any combination thereof. In a software implementation, various units may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by a processor (or a processing unit). The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means known in the art.

0038Various disclosed embodiments may be implemented in an AT, and other means configured to encode real-time information.

0039Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

0040Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

0041The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general, purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also he implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

0042The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in random access memory (RAM), flash memory, read only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in all ASIC. The ASIC may reside in an AT. In the alternative, the processor and the storage medium may reside as discrete components in an AT.