TBF Release

5.7 TBF Release

5.7.1 Release of Uplink TBF

During an uplink transfer, the network allocates uplink resources to the mobile either dynamically with the use of the USF (dynamic allocation or extended dynamic allocation) or at fixed occurrences (fixed allocation). In the case of an open -ended TBF, however, the network does not know exactly when the TBF will end.

In order to avoid the loss of uplink resources allocated by the network (because the mobile has finished its uplink transfer), a countdown procedure has been introduced.

This procedure allows the network to anticipate the end of the TBF and thus to avoid wasting uplink resources. The procedure involves triggering a countdown when the mobile starts sending its last 16 blocks. It uses the CV of the uplink data block header. The procedure is illustrated in Figure 5.27.

Figure 5.27: Procedure for uplink TBF release.

When the mobile starts sending its last 16 blocks, it starts decrementing the CV at each transmission. The last block of the TBF is sent with CV = 0.

When the network receives the last uplink RLC data block and if all the blocks have been correctly received, it sends a PACKET UPLINK ACK/NACK message with the FINAL_ACK_INDICATOR bit set to 1. The network polls the mobile in order to be sure that the mobile has received the PACKET UPLINK ACK/NACK message and to confirm the release of the TBF.

At the reception of the PACKET UPLINK ACK/NACK message, the mobile transmits a PACKET CONTROL ACKNOWLEDGMENT message to the network and releases the TBF.

5.7.2 Release of Downlink TBF

The release of a downlink TBF is simpler. In fact, in this direction, the network directly controls the assignment of downlink resources and can anticipate the end of the transmission. Under this condition, there is no waste of downlink resources. The procedure is described in Figure 5.28.

Figure 5.28: Procedure for downlink TBF release.

When the network sends the last RLC data block of a downlink TBF, it sets the FBI to 1 in the last RLC data block (the block that has the highest BSN). This indicates to the mobile the last block of the TBF.

The network requests the sending of the final acknowledgment of the RLC data blocks by polling the MS. In response the mobile sends a PACKET DOWNLINK ACK/NACK message. If all the blocks have been decoded by the mobile, it sets the Final Ack Indicator to 1 within the message.

The mobile continues to monitor its downlink PDCHs during a guard timer. This is to ensure proper recovery in case the PACKET DOWNLINK ACK/NACK message would not be correctly received by the network, in which case the network would resend the last RLC data block with polling (if the network does not receive the PACKET DOWNLINK ACK/NACK message, it cannot know if this is because the PACKET DOWNLINK ACK/NACK message was lost or because the last RLC data block with polling was lost; therefore, the only possibility for the network is to resend the last RLC data block with polling to the mobile; but of course in order that this procedure eventually succeeds, it is necessary that the MS is still listening to the downlink PDCHs; hence the need for the guard timer).

When the network receives the message, it starts a timer and the TBF is released at the end of this timer. However, if in between the network wants to establish a new downlink TBF to the same mobile, it can send a PACKET DOWNLINK ASSIGNMENT message on PACCH as long as the guard timer is running.