ion buffer, in order to protect the last PDU from being lost. Also, the poll timer should be enabled in order to detect possible loss of the polling PDU and triggering retransmission. Because the RLC sender could often forward data instantly to the MAC (if allowed by the sending window), a timer should be set to determine the last PDU in the buffer. The value of the timer should be generally very small, in order not to add extra delay to the PDU. In our simulation, we set it to four times the physical layer TTI (transmission time interval). The other polling triggers-that is, timer-based polling, poll every N SDU (or PDU), and windows-based polling-are generally periodic methods. Given the sender-side HARQ/ARQ interaction and the missing PDU indicator at the receiver side, errors would be unheeded only if a HARQ NACK ACK error happened to the retransmission PDUs because the "missing PDU indicator" would not respond to a "hole" in the PDU sequence that has been reported. Our suggestion is to select at least one of the periodic polling mechanisms to detect such kinds of errors. If the other two kinds of HARQ/ARQ interaction could recover such errors, the period timers would become unnecessary. However, as has been said, the HARQ/ARQ interaction and NACK ® ACK error constitute a complicated issue that is out of our consideration here. Because we assume no NACK R ACK error, simply select only the window-based polling, which sets the polling bit whenever 50 or 100% of the RLC sender window is sent. In reality, special polling/status report triggers might be needed for special events such as handover; however, those are out of the boundar- ies of our discussion here. It should be noted that RLC cannot be 100% reliable; the protocol itself defines a way to discard SDUs if any PDU fails to be delivered successfully after MaxDAT [1] times of transmission or after a predefined time. This operation is surely the last resort because the data recovery would then depend only on the higher layer, which usually takes longer. Giv