Methods and apparatus for processing error control messages in a wireless communication system

Methods and apparatus for processing error control messages in a wireless communication system.

Technical field

The present invention relates generally to wireless communication systems, and more specifically relates to the processing of error control messages in a wireless system that programs link resources.

Background

The Third Generation Cooperation Project (3GPP) has launched a program to develop specifications for advanced wireless communication systems, in an initiative known as “Long Term Evolution” or LTE. In standardization discussions, it has been agreed that LTE systems will use an automatic repeat request (ARQ) mechanism in the radio link control protocol (RLC). The specified ARQ protocol is a selective repeat protocol (used in “RLC Recognition Mode”) which provides means to send status reports from a receiving node to a transmission node, as well as means for the transmission node to poll the receiving node for a state. In response to receiving a status report, the transmission node can resend any lost data, or take another action that is appropriate. In response to a poll, a receiver generally sends a status report. However, sending a status report may be prohibited under some circumstances. For example, a state prohibition timer, initiated in the sending of a previous status report, can prevent a status report for a period of time.

3GPP developers have also agreed to specify a set of polling and status triggers, as well as timers that regulate a node response to either a polling report or a status. Examples of triggers and timers that have recently been agreed for inclusion in 3GPP LTE standards include:

<dl><dt>• </dt><dd>automatic status report upon detection of a skipped protocol data unit (PDU); </dd></dl>

<dl><dt>• </dt><dd>automatic polling in response to the transmission of the last PDU in a temporary transmission store, thus providing the transmission node with an assurance that a burst of data has been fully received; </dd></dl>

<dl><dt>• </dt><dd>a state prohibition timer to prevent a node from sending status reports too frequently, since too much status reporting can cause unnecessary retransmissions; and</dd></dl>

<dl><dt>• </dt><dd>a polling retransmission timer, to ensure that an unanswered poll, which could have been lost, is retransmitted: </dd></dl>

Of course, additional triggers and timers are also likely to be adopted in LTE. It can be expected that the RCL ARQ protocol for LTE will ultimately have many similarities with the CDMA Broadband (W-CDMA) RLC protocol specified in TS 25.322 of the 3GPP. In addition to the Recognition Mode, the RLC protocol for LTE will also include a recognition mode as well as a transparent mode.

In a conventional RLC ARQ scheme, RLC timers and status reports are created in response to certain triggers. For example, if a receiving node receives a poll and there is no state prohibition timer running, then the receiving node immediately generates a status report that represents the status of the current receiver. A typical status report may include an identifier for a last received protocol data unit (PDU) and / or a negative acknowledgment for one or more PDUs that were not successfully received. The status report is then offered to the media access control (MAC) layer for transmission to the transmission node. (Those skilled in the art will appreciate that each wireless communication node will typically include a transmitter and a receiver. In addition, an ARQ scheme can be implemented in both directions. For the purposes of this disclosure, the term "transmission node" generally refers to the node that transmits one or more data PDUs, in recognition mode, to a "receiving node". In 3GPP terminology, the Recognition Mode data is sent by the "transmission side of an RLC Recognition Mode entity"; PDUs are transmitted to the "equal entity" or to the "receiving side" of an RLC Recognition Mode entity. Given this use, a receiving node can transmit a status PDU to the transmission node. Similarly, a transmission node can receive a PDU status.)

In systems that employ a state prohibition timer, the receiving node typically starts the state prohibition timer at the time the status report is transferred from the RLC layer to the MAC layer. Additional status reports are not allowed before the timer has elapsed, even if one or more new triggers of a status report occur in the meantime. Such triggers could be another poll received from the transmission node, the detection of a skipped PDU, or the like. In this way, the state prohibition time ensures that a subsequent status report is delayed for at least the period of time specified by the state prohibition timer.

In LTE systems, the uplink (for mobile to base station transmissions) is a programmed resource, in which the programming is controlled by a service base station (called an evolved Node B, or eNodeB, in LTE). As a result, a mobile station may not have immediate access to transmission resources at any given time. If the MAC layer in a mobile station receives a status report from the RLC layer when uplink resources are not currently programmed, then the mobile station must first request those resources before it can transmit the status report to the eNodeB. Since programming is controlled by the eNodeB, it may happen that an uplink resource grant is significantly delayed. For example, multi-user programming may slow down the allocation of resources, or an initial programming request may be lost during transmission. As a result, the transmission of the status report could be delayed to the point that the status of the receiver characterized by the status report may be outdated even before it is transmitted.

US 2006/0067238 refers to a mechanism for retransmission, and deals with state prohibition timers and status reports. This document reveals that a status report will not be sent until it is allowed by a prohibition function, for example a timer

Summary

Here, methods and apparatus for processing error control messages, such as RLC ARQ control messages, are disclosed. An exemplary method comprises signaling a media access controller (MAC) that the link resources are needed to transmit data, receive an indication from the MAC that link resources to transmit the data are programmed, and generate the control message of errors after receiving such indication, based on a current error control status. The error control message is then forwarded to the MAC for transmission. Because the generation of an error control message is delayed until resources are programmed for transmission, the queuing and transmission of status control messages is ignored.

In another aspect of the invention, the MAC can notify the radio link controller (RLC) when the transmission of an RLC ARQ control message is either started or recognized. In response to the notification, the RLC controller can start or reset an error control timer. The timer may comprise, for example, a poll timer or a state prohibition timer.

Brief description of the drawings

Figure 1 is a simplified view of a communication system according to an embodiment of the invention.

Figure 2 illustrates several layers of communication protocols that can be used in the system of Figure 1.

Figure 3 illustrates the effect of programming delay on the formation of an ARQ status report.

Figure 4 illustrates the effect of programming delay on an ARQ poll timer.

Figure 5 illustrates the generation timing of the ARQ status report according to an embodiment of the invention.

Figure 6 illustrates the polling timer processing according to an embodiment of the invention.

Figure 7 is a logical flow diagram illustrating an exemplary method of processing error control messages.

Figure 8 is a block diagram of a wireless apparatus according to one or more embodiments of the present invention.

Detailed description

Figure 1 provides a simplified view of a communication system 10, which includes a transmission node 110 and a reception node 120. As discussed above, the transmission node 110 and the reception node 120 each comprise a complete transceiver. ; the terms "transmission" and "reception" are used to describe particular endpoints in a transfer of recognition data. In this manner, the transmission node 110 transmits one or more data units, which may comprise protocol data units (PDUs), to the reception node 120, and can also transmit one or more error control messages, such as a poll request. (As will be discussed later, an error control message, such as a poll, may be included in the same protocol data unit as traffic data.) The receiving node 120 may in turn transmit one or more messages error control, such as a status report, or a request to retransmit a PDU that was received unsuccessfully.

In some embodiments of the present invention, the transmission node 110 may comprise an LTE eNodeB and the reception node 120 may comprise a mobile station compatible with LTE. In this case, the data units represented in Figure 1 are transmitted, by the eNodeB, on the downlink, while one or more error control messages are transmitted on the uplink. However, those skilled in the art will appreciate that an ARQ scheme can also be implemented in the opposite direction, to detect errors in the delivery PDUs on the uplink. In this case, the roles of the transmission and reception nodes are reversed between the eNodeB and the mobile station.

Although the inventive techniques disclosed herein are described in reference to an LTE system, the present invention is not limited to such a system. Truly, the skilled practitioner, after reading the following description and viewing the attached drawings, will appreciate that the techniques described herein can be applied to a variety of wireless systems, and in particular to systems that dynamically program transmission resources in the uplink, downlink, or both.

Each of the communication nodes in Figure 1 is configured to operate in accordance with a specified communication protocol, such as the LTE protocols specified by the 3GPP. Several layers of protocol are illustrated in Figure 2; These protocol layers can be implemented in each of the communication nodes using analog and digital physical components, programmable processors configured with appropriate software, or a combination. In particular, the transmission node 110, which may be a mobile LTE station, may use the protocol layers in the protocol stack 210 to communicate with the corresponding protocol layers in the protocol stack 220 of the receiving node 120, for example, an eNodeB LTE.

Each of the protocol stacks 210 and 220 includes a physical layer, a data link layer, and a network layer. The data link layer is divided into two sub-layers, a radio link control (RLC) layer and a media access control (MAC) layer. In this exemplary embodiment, the network layer is divided into a control plane protocol (RRC) and a user plane protocol (IP).

In an LTE system, the physical layer uses Orthogonal Frequency Division Multiple Access (OFDMA) technology for the downlink, and the closely related Multiple Carrier Frequency Division (SC-FDMA) Access for the link upward. In general, the physical layer provides data transfer over the air (radio) interface, and includes such functions as multiplexing and demultiplexing of transport channels, allocation of transport channels in physical channels, modulation and demodulation of physical channels, coding and decoding error correction without return channel, frequency and time synchronization, transmitted power control, RF processing, and the like.

The media access control (MAC) layer generally provides unrecognized transfer of service data units (SDUs) between equal MAC entities. MAC functions may include selecting an appropriate transport format for each transport channel depending on the data rate, managing priorities among the data flows of several users (on a base station that supports multiple users), programming control messages, multiplexing and demultiplexing upper layer PDUs, etc. In an LTE system, resource programming is also done by the MAC layer. In particular, uplink resources may be required by a MAC layer for a mobile station, and are assigned between the mobile stations by the corresponding MAC layer in the eNodeB.

The RLC layer performs several functions including the establishment, release and maintenance of an RLC connection, segmentation and reassembly of variable length, upper layer PDUs in or from smaller RLC PDUs, concatenation, error correction by retransmission (ARQ), delivery in sequence of upper layer PDU, duplicate detection, flow control, and other functions.

The RRC protocol handles the control signaling on the radio interface, for example, radio access bearer control signaling, measurement information and handover signaling. The user plane part of the network layer includes the traditional functions performed by level 3 protocols, such as the well-known Internet Protocol (IP).

The radio link control protocol (RLC) layer in protocol stacks 210 and 220 includes an Automatic Repeat Request (ARQ) mechanism. The RLC layer in a transmission node 110 receives user data, segments it, and transforms it into RLC PDUs. In some embodiments, a transmitted RLC PDU may include a field indicating whether the transmitted message is a data PDU or a control PDU. Another field may correspond to a polling field, which may contain a bit indicating that the transmission node 110 wants a status report from the receiving node. The RLC PDU may further comprise a "Sequence Number" field indicating the sequence number of a data PDU; This sequence number can be increased for each new data PDU. Finally, a data field contains upper level data information segments. The "Length Indicator" and "E" extension fields can also be included in an RLC PDU.

In response to a PDU in which the polling bit P is set to "1", the RLC layer of the receiving node can generate a status report indicating which RLC PDUs have been properly received. Positive or negative surveys, or a combination of both, can be used. In LTE, a status report PDU includes a Recognition Sequence Number (ACK_SN) field that indicates the smallest sequence between PDUs that have neither been received nor detected as lost by the receiving node. The status report PDU may also include one or more Negative Recognition Sequence Number (NACK_SN) fields that identify the PDUs detected as losses by the receiving node. Thus, when a transmission node 110 receives a status report PDU, it determines that all PDUs up to, but not including, the PDU corresponding to the ACK_SN have been received, except for those PDUs identified by the single or more NACK_SN fields. .

As briefly mentioned above, dynamic resource programming on some systems may cause delays between the generation of error control messages, such as polling PDUs or status report PDUs discussed here, and the actual transmission of those messages. In systems where transmission resources are persistently available, such as in 3GPP Broadband CDMA systems, an RLC control message (e.g., status report PDU or polling PDU) is typically transmitted immediately after it has been generated, except for a short processing delay. Thus, when a status report is transmitted, for example, it presents a generally accurate "snapshot" of the status of the receiver. In LTE, in contrast, the uplink is strictly programmed and the mobile station typically lacks any such persistent resources. If the mobile station is not programmed, the MAC layer of the mobile station must first request the uplink resources before it can transmit the status report PDU. The resulting delay may cause the status report PDU to become outdated before it is actually transmitted to the eNodeB.

This problem is illustrated in Figure 3, in which the events in the eNodeB are illustrated along the upper horizontal line, and the events in the mobile terminal are illustrated along the lower horizontal line. The flow of events in Figure 3 begins with the transmission of a polling request from the eNodeB to the mobile station, as depicted on the left side of the figure. As discussed above, in a conventional system, the mobile terminal immediately (except for processing delays) generates a status report. In an LTE system, as discussed above, this status report may indicate that one or more Recognition Mode PDUs (or parts thereof) were lost, or processed without success.

After the RLC layer generates the status report, the status report is forwarded to the MAC layer for delivery to the eNodeB. However, in the represented event flow, the resources are not immediately available to transmit data on the uplink. In this way, the MAC layer requests uplink resources from the eNodeB, sending a programming request. As discussed above, the granting of uplink resources may be subject to considerable delays. These delays may occur simply because the eNodeB is serving many mobile stations, or because the eNodeB is currently allocating resources to higher priority requests. In some cases, delays may be caused or exacerbated by the failure of the resource request to be successfully received by the eNodeB, so that the request must be repeated.

In any case, the granting of uplink resources in the event flow represented in Figure 3 is finally received by the mobile terminal, but after a considerable programming delay. This delay period is illustrated in Figure 3 from the perspective of the RLC, that is, from the moment the error control message (status report) is forwarded by the RLC to the MAC until the time the MAC receives the granting of uplink resources. During this period, several additional RLC PDUs, namely PDU 1 and PDU 2, are received by the mobile terminal. Thus, at the time the status report is transmitted to the eNodeB, as illustrated on the right side of the figure, the status report is then out of date. Because the status report does not reflect the receipt of PDU 1 and PDU 2, the eNodeB has been provided with inaccurate information as to the current status of the receiver of the mobile station. This could cause a retransmission of PDU 1 and PDU 2, wasting downlink resources and potentially causing additional delays in glued data.

Planning delays can also cause problems with the operation of timers related to error control processes. For example, if an RLC timer that controls the transmission of status reports, such as the state prohibition timer, is started when the PDU carrying the status report is offered to the MAC layer, then it may happen that the timer expires too soon. In the worst case, the RLC layer could offer several RLC status reports to the MAC layer, all of which are glued for transmission. If these status reports contain a negative recognition for the same RLC PDUs, the same PDUs can be retransmitted several times by the same RLC entity.

A similar problem may apply to timers that control polling. If a polling timer is initiated when the PDU carrying the polling is offered to the MAC layer, it may happen that the polling timer expires too soon due to the delay in the transmission of the PDU carrying the polling. This could cause unnecessary polls that are glued and transmitted to the receiver. This is illustrated in the event flow of Figure 4. As with Figure 3, the events in an eNodeB are illustrated along the upper horizontal line, while the events in the mobile terminal are shown along the lower line. On the left side of the figure, a poll control message, Poll 1, is generated by the RLC layer of the eNodeB.

The polling control message is immediately forwarded to the MAC layer for transmission to the mobile terminal, and a polling timer, which sets a minimum delay before another polling request can be generated, is initiated. However, the Poll 1 message is not actually transmitted to the mobile terminal until after a considerable delay, which may result from programming delays from a supported transmission queue.

In some cases, the delay in transmitting the polling request may be extended until after the polling timer expires, as shown in Figure 4. After the expiration of the polling timer, the RLC layer, which is not aware of that the previous polling has not been transmitted, generates a second polling request, Polling 2. This second polling request is forwarded to the MAC, and the polling timer is reset.

Finally, the first polling request (Polling 1) is transmitted to the mobile station. In the scenario represented, the uplink delays are not significant, so that a status report is returned quickly. Shortly after, the second polling request (Polling 2) is transmitted by the eNodeB and received by the mobile terminal. Although a state prohibition timer may prohibit the generation and transmission of another status report by the mobile terminal, the second polling request is clearly unnecessary, and a waste of system resources.

Figures 3 and 4 illustrate only a few of the RLC error control timing problems that could arise from programming and sizing delays in a wireless system with programmed resources. Another problem is that status reports or surveys may be delayed because higher priority data is already queued. Consider a mobile terminal (a receiving node with respect to the downlink, a transmitter with respect to the uplink) with multiple carriers, or "logical channels", which have different priorities. Assume that the mobile terminal has data in the temporary transmission store for the bearer of the highest priority and that the mobile terminal receives programming concessions from the eNodeB that do not leave bandwidth for the transmission of the PDUs associated with more priority carriers. low. Also, suppose a trigger to transmit a status report or a poll on a lower priority bearer occurs. Since the mobile terminal lacks resources to transmit this PDU, the status report or poll may be significantly delayed. As in the scenarios discussed above, the status report may in some cases become outdated before it is transmitted. In extreme cases, several status reports or polls can be queued until resources for the lowest priority bearer are available, leading to unnecessary retransmissions.

A solution to several of the above problems is to modify the conventional ARQ processes described above in such a way that the content of an error control message (for example, an RLC PDU carrying ARQ control information) is generated only when the layer MAC can offer resources to transmit the RLC PDU. In some embodiments this can be accomplished by providing an additional or modified interface between the RLC and MAC layers. This additional interface may allow the RLC layer to ask the MAC layer to transmit an RLC PDU that carries control information. In addition, this additional interface allows the MAC layer to notify the RLC layer when link resources are available to transmit the RLC PDU that carries control information. In this way, the RLC layer can actually differ by generating the control information to the resources, so that the error control message delivered lastly includes updated information on the status of the RLC layer.

On this interface, the RLC layer of a communication node (for example, a mobile station) may first report the need to the transmitting MAC layer of an RLC ARQ control message, such as a status report. Upon notification of the MAC layer to the RLC layer that the necessary resources are (or will be available soon), the RLC layer then creates the relevant control information (for example, status report information), packages the control information in an RLC PDU, and presents the RLC PDU to the MAC layer for transmission to the remote node. The embodiments of the invention cover cases in which the RLC PDU carries either an RLC status report or a poll, and can be applied similarly to other error control messages.

Figure 5 presents an event flow diagram, similar to those of Figures 3 and 4, illustrating the operation of a system according to some embodiments of the invention. As was the case in Figure 3, a polling request is transmitted by the eNodeB, and received by the mobile terminal, on the left side of the figure. In response to this trigger, the RLC layer in the mobile terminal determines that uplink resources will be necessary to transmit an error control message, in this case a status report. The RLC layer thus signals to the MAC layer that uplink resources are necessary, as indicated in Figure 5. The MAC layer responds by requiring uplink resources from the programmer, if the resources are not already programmed.

Those skilled in the art will appreciate that signaling from the RLC layer to the MAC layer that uplink resources are necessary may or may not specifically indicate that those resources are required for the transmission of an error control message. Thus, in some embodiments, the signal may simply indicate that an RLC PDU is pending, and that uplink resources should be programmed if they are not already available. In other embodiments, it may be advantageous for signaling to specifically indicate that resources are necessary for a control message.

In any event, the actual grant of resources can only come after a significant delay, as illustrated in Figure 5. During this delay, several RLC PDUs of recognition mode, PDU 3 and PDU 4, are received at the terminal mobile during programming delay. However, in this scenario the status report has not been generated, and is not glued in the MAC layer waiting for transmission. Instead, as illustrated in Figure 5, the RLC layer differs by generating the status report data until after the MAC layer notifies the RLC that the request for uplink resources has been granted (i.e., that the uplink resources are available). Thus, the status report includes current data (which includes the status of PDU 3 and PDU 4) when it is forwarded to the MAC and transmitted to the eNodeB. Although there may still be processing and queuing delays, these delays are minimal compared to the situation represented in Figure 3.

Some embodiments of the present invention use similar techniques to initiate and reset timers for error control processing, such as RLC ARQ polling and state prohibition timers discussed above. In these embodiments, the activation of an error control timer may be triggered by a MAC layer notification (to the RLC layer) that an RLC PDU carrying error control information has been transmitted, or is about to be transmitted to the remote node.

The exemplary operation for such an embodiment is depicted in Figure 6. In this event flow, as was the case in the event flow represented in Figure 4, a polling request is triggered in the eNodeB. The RLC PDU that carries the polling request is forwarded to the MAC for transmission to the mobile terminal. However, in this case, the polling timer is not started immediately. Instead, the polling timer is not started until after the MAC layer notifies the RLC layer that the polling request has been transmitted. As depicted in Figure 6, this could occur after a significant programming / queuing delay. Because the start of the polling timer was deferred until or near the time the polling request was actually transmitted, the timer does not expire prior to the receipt of the status report from the mobile terminal. An unnecessary retransmission of the polling request is thus avoided.

In some embodiments, the MAC layer may be configured to notify the RLC layer that the transmission of the PDU carrying the RLC ARQ control information has begun, or is about to begin. In other embodiments, the MAC layer may instead notify the RLC layer that the transmission of the PDU carrying the RLC ARQ control information has been recognized in the MAC HARQ layer. Those skilled in the art will appreciate that the techniques described above with respect to a polling timer can also be applied to other error control timers, such as a state prohibition timer.

Figure 7 is a logical flow diagram illustrating an exemplary method for processing error control messages such as could be carried out by one or more of the RLC and MAC controllers discussed above. In the method depicted, the inventive techniques disclosed herein are applied both to the generation of an error control message and to the activation of an error control timer. Those skilled in the art will appreciate, of course, that many embodiments of the invention will apply these techniques to both error control processes, but that some may apply the techniques of one process or the other, but not both.

In any event, the exemplary method of Figure 7 begins in block 710, with signaling, to the MAC controller in a communications node, which link resources are necessary for the transmission of an error control message. As discussed above, this can be triggered by any of several different events. For example, the receipt of a polling request at a receiving node will generally trigger a status report process. In this case, then, the signaling for the link resources in block 710 is for the resources to transmit the status report. Another possible trigger event is the expiration of an error control timer. For example, the expiration of a polling timer may trigger a new polling request, in which case the signaling in block 710 may be requesting resources to trigger the new polling request.

In any event, in block 720, an indication is received from the MAC controller that link resources are available. As previously discussed in depth, this may occur almost immediately after the resource request, or it may occur after a significant programming delay. In either case, an error control message is generated in block 730, in response to the indication that link resources are available. In this way, the contents of the error control message are generated based on a current state, and are not made "old" by any programming delay. In block 740, the error control message is forwarded to the MAC controller for transmission. Because the message generation of block 730 and the forwarding of block message 740 was deferred until after the indication that resources were available, transmission delays after forwarding to the MAC controller are minimized.

In block 750, a notification is received from the MAC controller that the transmission of the error control message has begun, or has been completed. In response to this notification, an appropriate error control timer, such as a polling timer or a state prohibition timer, is activated, as shown in block 760.

The RLC and MAC procedures described herein can be implemented respectively by an RLC controller and a MAC controller by implementing the RLC and MAC layers, respectively, of the protocol stacks 210 and 220 discussed above. Those skilled in the art will appreciate that these procedures can be implemented by modifying the RLC controller and conventional MAC controllers, which, as discussed above, can be implemented by one or more programmable processors, physical component circuits, or a combination thereof. .

In addition, the methods disclosed herein may be implemented at either or both ends of a wireless link, such as the LTE mobile terminals or the previously discussed eNodesB. Thus, Figure 8 illustrates the general features of a wireless communication apparatus according to one or more embodiments of the invention; The represented wireless device 800 may comprise, in several embodiments, a mobile terminal (including a cell phone, wireless personal digital assistant, wireless personal computer, machine-to-machine device, etc.), a base station, a repeater, or other node that A wireless link ends.

The wireless device 800 of Figure 8 includes a radio transceiver 810, operable to communicate over one or more radio links with a remote transceiver, through the antenna 815. In some embodiments, the radio transceiver 810 is configured to receive and transmit signals formatted according to a standard, such as any of the wireless standards promulgated by the 3GPP. In particular, the radio transceiver 810 can be configured to transmit and / or receive OFDMA and SC-FDMA signals in accordance with the LTE standards.

The wireless device 800 also includes a Media Access Control function 820, a Radio Link Control function 830, and other 840 processing. The general functions of the MAC and RLC functions are discussed above; These functions can be implemented in any of a variety of combinations of analog and digital physical components and programmable processors configured with software. Those skilled in the art will appreciate that these functions, as well as other functions necessary for the operation of the wireless apparatus 800 can be implemented using one or more programmable processors. In many embodiments, the MAC 820 and RLC 830 functions are implemented as a protocol stack, such as the protocol stack 210 of Figure 2, implemented in a single microprocessor or application-specific integrated circuit configured with software to perform the various RLC and MAC functions described here.

In particular, the RLC 830 controller can be implemented with a programmable microprocessor with software that defines an RLC layer, in which the RLC layer is configured to signal to a media access controller that link resources are necessary to transmit data, receive an indication from the media access controller that link resources are programmed to transmit the data, and, sensitive to the indication, generate an error control message based on a current error control state for the RLC layer. The error control message may comprise, but is not limited to, a polling request or a status report. In some embodiments, the RLC layer may also be configured to receive a notification that the transmission of the error control message has begun and to initiate a notification sensitive error control timer. The error control timer may comprise, but is not limited to, a poll timer or a state prohibition timer.

Similarly, all or part of the MAC 820 controller can be implemented in the same microprocessor, or in one or more different microprocessors, programmed with software that defines a MAC layer. The MAC layer is configured to receive a signal from the RLC layer indicating that link resources are needed to transmit data, and to require link resources as necessary. The MAC layer is also configured to notify the RLC layer after receiving a resource grant. In some configurations, the MAC layer is still further configured to notify the RLC layer when an error control message (provided to the MAC through the RLC layer) has been transmitted, or, in some embodiments, when the transmission of the Error control is imminent.

The teachings of the present disclosure can, of course, be carried out in other ways than those specifically set forth herein, without departing from the essential features of the invention. The present embodiments will be considered in all aspects as illustrative and not restrictive, and all changes that come within the meaning of the appended claims are intended to be adopted therein.