Case Studies

5.8.1.1 Performed Measurements

There is a benefit for the MS in performing all measurements for cell reselection during the paging decoding process in order to stop its radio activity between two consecutive paging blocks. This operation allows for a limiting of the battery consumption in idle or packet idle mode.

Note that between two paging periods, the MS enters a low-power mode where the radio activity is fully stopped. As waking up of the radio activity is not instantaneous, the MS enters a normal power-management mode a very short time before the paging block decoding. As there is a latency time for radio activation, there is a benefit for the MS in limiting the number of radio activations for cell-reselection measurements in order to optimize battery consumption. That is the reason that it is good to take advantage of the paging-decoding process for cell-reselection measurements.

Measurement Window

As a PPCH block consists of four bursts on four consecutive TDMA frames, the MS may open measurement windows on time slots that are not used for paging block decoding. For example, with a quickly configurable and reactive radio, it will be possible to open several measurement windows within a TDMA frame. The number of measurement windows for a given MS is limited by two factors (see Figure 5.29):

• Time to perform a measurement on a carrier;

• Time to lock on a new frequency.

Figure 5.29: Measurement windows during paging block decoding.

GPRS Constraints

The MS is required to calculate a running average on measurements collected on a period equal to MAX (5s, five consecutive paging blocks) in order to evaluate the cell-reselection criteria. At least five RXLEV measurements are taken for each carrier. The network broadcasts a list of neighbor cells, called the BA list (BCCH allocation). This list may contain up to 32 neighbor cells, meaning that the MS will perform up to 5 × 33 measurements on neighbor cells plus the serving cell during a period equal to MAX (5s, five consecutive paging blocks).

The occurrence of a paging block within a 52-multiframe according to DRX parameters is defined by:

(5.28)

where 0.240s is the time duration of a 52-multiframe.

As the range of SPLIT_PG_CYCLE values is between 1 and 352, the occurrence of a paging block lies between 0.0436s and 15.36s. When SPLIT_PG_CYCLE is greater or equal to 16, the paging occurrence becomes lower than 1s. Thus the average running for cell reselection measurements is equal to 5s for all these SPLIT_PG_CYCLE values. Table 5.10 gives the period for the running average.

Table 5.10: Cell Reselection Measurement Periods

SPLIT_PG_CYCLE	Period for Running Average (s)
1	76.80
2	38.4
3	25.6
4	19.2
5	15.36
6	12.8
7	10.9714
8	9.6
9	8.5333
10	7.68
11	6.9818
12	6.4
13	5.9077
14	5.4857
15	5.12
16	5
>16	5

Moreover, the recommendation gives the following constraints:

• At least one measurement on each neighbor cell every 4 seconds;

• One measurement as a maximum on each BA list carrier every second.

SPLIT_PG_CYCLE Value Less Than or Equal to 3 As the MS will respect the constraint of at least one measurement on a carrier every four seconds, the opening of a measurement window occurring every five consecutive paging blocks is not enough for these SPLIT_PG_CYCLE values (see Table 5.10). In this configuration, the MS will open additional measurement windows outside the ones opened during paging block decoding in order that the constraint described above be respected.

SPLIT_PG_CYCLE Values Less Than 16 and Greater Than 3 As the measurement period is equal to "5 five consecutive paging blocks" and as five RXLEV measurements are taken for each carrier, the MS will perform one measurement on each neighbor cell belonging to the BA list plus on the serving cell. If the number of neighbor cells plus the serving cell is greater than the number of measurement windows opened during paging block decoding, then the MS will open additional measurement windows outside the TDMA frames containing paging blocks.

SPLIT_PG_CYCLE Values Greater Than or Equal to 16 As the measurement period is equal to 5s, there is a number n of paging blocks during this period (e.g., for SPLIT_PG_CYCLE = 16, n = 5) and since the MS is able to perform n × N measurements on n × N/5 cells (neighbor cells plus serving cell) during this period, the number N represents the number of measurement windows opened during paging block decoding. If the number of neighbor cells is greater than or equal to n × N/5, then the MS will open additional measurement windows outside the ones opened during paging block decoding. If the number of neighbor cells is lower than n × N/5, then the MS will not be obliged to open all n × N/5 measurement windows during 5s period in order to save battery consumption.

Note

The SPLIT_PG_CYCLE is a fixed value in the MS; it does not change according to the number of neighbor cells. This means that it makes sense to choose a SPLIT_PG_CYCLE value that allows measurements to be performed on the maximum number of neighbor cells (32) during five seconds without opening additional windows outside the TDMA frames containing paging blocks.

5.8.1.2 BSIC Decoding on Neighbor Cells

The MS is required to check the BSIC on each of the six best neighbor cells at least every 14 consecutive paging blocks or 10s. The BSIC decoding process is performed outside the paging block decoding process.

5.8.1.3 Choice of SPLIT_PG_CYCLE Value

As discussed above, the SPLIT_PG_CYCLE value has an impact on the following points:

• Paging reactivity: range between 0,0436s and 15,36s;

• Serving and neighbor-cells measurement strategy;

• BSIC decoding on neighbor cells;

• Power-saving management.

A high value for SPLIT_PG_CYCLE is required for a good paging reactivity. In contrast, a low value for SPLIT_PG_CYCLE is beneficial in terms of power-saving management. A very low value for SPLIT_PG_CYCLE is risky for the MS, since it may lose synchronization in frequency and in time with the network if the paging occurrence is too long; the MS uses the paging block decoding to adjust frequency and time drift. The MS makes a tradeoff between these criteria, then, in order to determine a SPLIT_PG_CYCLE value.

Note that a value for SPLIT_PG_CYCLE lying between 8 and 32 seems a good tradeoff between paging reactivity and power savings. This value corresponds to a BS_PA_MFRMS value included between 2 and 8 used for paging recurrence on the 51-multiframe.

5.8.2.1 Sharing of Time Slots Between Circuit-Switched and Packet-Switched Services

From a radio point of view, the evolution of a GSM network toward GPRS requires the introduction of radio resources dedicated to packet transfer within the cells. This is the case in most of the networks, as most of them will support both packet- and circuit-switched modes. PDCHs are introduced within cells already having BCCH, SDCCH, TCH, and so on.

The introduction of GPRS dedicated radio resources has a direct impact on available circuit-switched resources. The more PDCHs available in the cell, the less TCHs if GPRS is introduced without any change in the radio network planning. In order to introduce GPRS as smoothly as possible and avoid impacting speech service, it is important to optimize the allocation of PDCHs within the cell and have a coordinated strategy between packet and circuit radio resource management.

The RR allocation algorithm will also be able to manage the increase of packet traffic with time. At the introduction of GPRS service within networks, in order not to impact the speech service, an operator will probably request the allocation of few PDCHs within the cell. The allocation of PDCHs should be dynamic and reactive due to the small number of GPRS users in the introductory phase of the system.

In the same way, when the load of speech calls increases within a cell, it is important to keep enough free radio resources within the cell in order that incoming speech calls are able to be accepted in the cell. These incoming speech calls can be due to a mobile trying to access the network or to handovers from other cells. In fact, from a user point of view it is probably more important to maintain a speech call (successful handover) than to maintain packet transfers.

Thus in order to avoid an increase of the speech-call blocking rate, operators may request dynamic allocation of PDCHs depending on the circuit-switched load and packet load.

When the number of GPRS users increases, it will become necessary to have permanent GPRS radio resources in the cell, so that GPRS users are very quickly allocated resources.

In order to take advantage of the multislot class of the mobile, the network must optimize the allocation of PDCHs. In fact, if two PDCHs are allocated in the cell on two different frequency allocations, it will not be possible to allocate the two PDCHs to the same mobile during one TBF. Furthermore, if the two PDCHs are not consecutive, it will not be possible to allocate two PDCHs (even if they have the same frequency allocation) to a class 4 mobile, even if it can support two received time slots.

In order to avoid this kind of problem, the network must allocate PDCHs in a very efficient way. In order to increase the probability of consecutively allocated PDCHs, it could be possible on the network side to reserve a pool of radio resources for circuit-switched only, another one to packet services only, and a last one allocated to both packet and circuit. Figure 5.30 gives an example of a possible mapping between these different pools. In this example, the cell supports three hardware units, each one handling reception and transmission (TRX) on a different frequency allocation. Up to eight TCHs can be supported on TRX 2.

Figure 5.30: Example of time slot allocation in a cell.

The resource allocation algorithm can then be as follows: When there is an incoming speech call, it is allocated a resource in the circuit-switched pool when available. This avoids monopolization of a resource in the common pool that could be allocated to another GPRS user during the speech call. When there is an incoming speech call and no resource is available in the circuit-switched pool, it is allocated a resource in the common pool. However, it is very important in this pool to avoid a random mixing of TCHs and PDCHs in order to avoid breaking up consecutive resources that can be used for PDCHs. In our example, a solution to this problem could be to allocate PDCHs from the right to the left and TCHs from the left to the right on TRX 3.

The last case is when a TCH is requested and no resources are available in both pools. Either the speech call is rejected or it could be possible to release a PDCH and allocate a TCH in place of this latter. In the same way, the allocation of a PDCH is done in the packet pool if resources are available, or otherwise in the common pool.

This allocation mechanism is very flexible, as it also allows for a smooth introduction of packet resources within the network. The only constraint for the operator will be to choose the right size for the different pools. At the introduction of the GPRS service, the strategy will be to have a small packet pool, and when the GPRS traffic has grown, to increase the size of this pool.

Another key issue when allocating PDCHs is the average throughput that will be available. As described in Chapter 4, during a TBF, link adaptation is used to adapt the throughput on the channel depending on the quality of the radio link. So the greater the average C/I for a TRX, the higher the average throughput on the PDCHs of this TRX. In most of the networks today, the average C/I is around 11 or 12 dB. This corresponds to an average throughput per PDCH of 12 Kbps. A user that is near the BTS will get a higher throughput but a user far from the BTS will get a lower one.

However, an operator that wants to provide a better GPRS service with higher average throughputs could decide to have a dedicated frequency planning for TRXs that support GPRS (in our example, TRX 3). Another possibility will be to map the packet pool on the TRX that supports BCCH, as this one is generally well planned (highest C/I) because it supports BCCHs.

This section has given an example of an algorithm for the allocation of PDCHs and TCHs at the network side. The intention was to show the considerations that must be taken into account from a BSS implementation point of view and the impact of the GPRS introduction of RR management.

5.8.2.2 Dynamic Allocation of PBCCH and PCCCH

As the presence of PBCCH and PCCCH is not mandatory within a cell, GPRS access can be performed via CCCH when PBCCH is not present in the cell or PCCCH when PBCCH is present. When PBCCH is not present in the cell and GPRS service is supported, all the mobiles within the cell access the network on CCCH.

The introduction of GPRS mobiles in the network will considerably increase the load on these CCCHs. In fact, a packet transfer such as a Web page download can require a lot of TBF establishments (e.g., request, answer, acknowledgment) within a few seconds' duration. As soon as the GPRS traffic in the cell increases, the common channels will be more loaded and a high risk of congestion will appear, impacting the circuit-switched access and degrading the speech service.

In this case, the allocation of a PDCH carrying PBCCH/PCCCH becomes necessary to handle the increasing flow of GPRS access. The allocation of the PBCCH/PCCCH can be either static (one or more PBCCH/PCCCH are statically allocated within the cell) or dynamic (depending on the load on CCCH or PCCCH, one or more PBCCH/PCCCH are allocated).

Moreover, when the GPRS load in the cell decreases, these PDCHs can be deallocated.

The dynamic allocation of PBCCH/PCCCH can take into account the following load indicator:

• Load on RACH/PRACH;

• PRACH collision indicating the number of collisions detected on RACH or PRACH;

• Load on PPCH;

• Load on PCCCH;

• Evaluate the rate of successful access at the first attempt using the retry bit of the RLC/MAC header.

Depending on these measurements, the network can evaluate whether the allocation of a PBCCH/PCCCH is necessary and whether additional PCCCHs are necessary in the cell.

5.8.2.3 Allocation of MS Radio Resources

PDCH Allocation

This section describes the constraints that have to be taken into account by the network in allocating PDCHs to an MS.

In case of a downlink TBF, the network allocates downlink PDCHs and one uplink PDCH that carries the uplink PACCH. For an uplink TBF, when fixed allocation is used, the network allocates uplink PDCHs and one downlink PDCH for the downlink PACCH. When dynamic allocation is used, the network allocates the same number of PDCHs in uplink and downlink, since the transmission on one uplink PDCH is allowed by the decoding of an allocated USF on the associated downlink PDCH.

The information that can be used by the network to allocate the PDCHs is the multislot class of the mobile when it is available, and the type of TBF (uplink or downlink) and its nature (GMM procedure signaling or data transfer). The number of PDCHs that can be allocated to the mobile is dependent on its multislot class and the availability of PDCHs in the cell.

The network is interested in allocating as many PDCHs matching the multislot class of the mobile as possible, in order to provide a higher throughput and increase the multiplexing gain. However, this is not for all the TBFs. In fact, for example, TBFs that are used to carry GMM signaling do not need to be allocated multiple PDCHs, since from a user point of view there is no difference if this kind of TBF is carried with a high throughput or not. It can be handled on a single PDCH.

The network must also take into account the number of mobiles that are multiplexed on the same PDCHs. If too many TBFs are allocated on the same PDCH, the available bandwidth per mobile will be very low and the experienced service very bad for all the users.

One problem inherent in GPRS is the allocation of the uplink PDCH. Due to the multislot constraints, the allocation of uplink PDCH is often shifted on the highest TN as compared with the downlink allocation. Figure 5.31 shows the possible PDCHs mapping for multislot class 6 and class 12 mobiles during downlink transfer. For the class 6 mobile, TS 5 and TS 7 cannot be allocated. For multislot class 12, time slots 2, 3, and 5 will never be allocated in uplink.

Figure 5.31: Mapping of class 6 and class 12 mobiles on a TRX.

The consequence of this is that the uplink traffic is not well distributed between all the available uplink time slots. However, we can consider this to be a minor problem, being that the downlink traffic is much higher than the uplinktraffic.

However, when the network allocates uplink PDCHs to an MS, it will take care not to allocate the uplink resources on the extreme side of the PDCH pool on a TRX. For example, the mobile requests the allocation of an uplink TBF and the network allocates a PDCH on the extreme left of the TRX. If a concurrent downlink TBF is established during the uplink transfer, the BSS will not be able to allocate in downlink as many PDCHs as could be supported by the multislot class. It could be possible to change the uplink allocation of the mobile, but this will make the handling of resources more complex.

Figure 5.32 shows that for a class 6 mobile, if an uplink TBF is handled on time slot 0, the PDCHs allocated to the concurrent TBF can only be mapped on time slot 0 and 1, although three time slots could have been supported in downlink.

Figure 5.32: Mapping of a class 6 mobile on a TRX when the uplink time slot is at the border of the TRX.

Multiplexing of Mobiles onto PDCHs

Once PDCHs have been allocated to the different mobiles for uplink or downlink transfers, the network must manage the allocation of downlink and uplink blocks. Since different users can be multiplexed on the same PDCHs, the BSS must share the bandwidth between the different mobiles.

Different strategies can be considered for the allocation of blocks when a PDCH is shared between several mobiles. One can be the allocation of the full PDCH to a mobile until its transfer is finished, and then allocation of the PDCH to the next TBF. The major drawback of this solution is that it delays the other TBFs. When the current TBF is very long, the other TBFs cannot be allocated resources on the PDCH. The other solution is to share alternatively and dynamically the bandwidth on the PDCH between the different users that are multiplexed on it.

Downlink Multiplexing Figure 5.33 shows how the downlink multiplexing can be managed at the network side. In this example, three PDCHs are allocated on the TRX. The first PDCH on the left supports PBCCH and PCCCH; the two others are used for data transfer. The PDCH that supports the PBCCH is allocated to MS1. MS2 and MS3 are multiplexed on the two other PDCHs. One queue that contains the segmented RLC data blocks is dedicated to each mobile.

Figure 5.33: Example of downlink multiplexing.

If the algorithm consists of giving alternatively downlink block allocations to the mobiles, on the second PDCH the first block period will be allocated to MS2, the second to MS3, the third again to MS2, and so on. The multiplexing of the PDCH that supports PBCCH will be exactly the same, except that for PBCCH and PCCCH fixed occurrences signaling must be transmitted.

Depending on the QoS of the mobile, the network may decide to give more or less consecutive block occurrences to a mobile on a given PDCH. If the QoS of MS2 is higher, MAC may allocate three block occurrences to MS2 and one to MS1 alternatively.

Note

The downlink scheduler must also manage the transfer of signaling blocks for the uplink TBFs that share the same PDCH.

Uplink Multiplexing For the uplink, the management of the multiplexing is quite different depending on whether the network uses dynamic allocation or fixed allocation. Dynamic allocation allows uplink block occurrences to be allocated with a very short anticipation. With this kind of multiplexing scheme, the same principle as for the downlink can be reused. The USFs can be distributed to the different mobiles that share the same PDCH alternatively. This ensures the sharing of the uplink bandwidth. However, the scheduler must also manage the fixed-block instance reserved by the RRBP values scheduled in downlink blocks. The scheduler during these instances will avoid scheduling a USF value that is allocated to a mobile on this PDCH in order to avoid collision on the uplink PDTCH occurrence.

When the network uses fixed allocation, the sharing of the bandwidth between the different mobiles is not as easy as for the dynamic allocation scheme. For this mode, the network allocates many uplink block occurrences to the mobile with anticipation (bitmap mechanism).

If two mobiles are sharing the same PDCH, the network distributes the bandwidth between the two mobiles, allocating one part of the bandwidth to one mobile and the other part to the other one. But if during the uplink transfer a new mobile is allocated the same PDCH, the network will need to reserve some bandwidth for it. Moreover, when there are downlink TBFs sharing this PDCH, some uplink bandwidth must be reserved for the transmission of their uplink PACCH.

This management of bandwidth allowing for other mobiles is very difficult to handle at the network side. It is difficult to forecast how much bandwidth will be required for downlink TBF signaling and when it will be needed. One possible solution would have been to reduce the length of the fixed resource allocation. This could lend more flexibility to the allocation scheme, but it requires a frequent sending of resource allocation messages, bringing about a reduction of the downlink bandwidth for data. The other solution involves regularly reserving some bandwidth for unexpected uplink block occurrences. The drawback of this solution is that, when this additional bandwidth is not requested, it cannot be allocated to the uplink users due to the slow reaction time of the fixed allocation scheme.

Figure 5.34 shows how fixed allocation can be managed at the network side with an uplink allocation table. Each row of the table stands for a PDCH, and the columns for block periods. On the left of the table, the mobiles that are multiplexed on each PDCH are indicated. Each block period on a PDCH is reserved either for one mobile, for signaling (PBCCH, PCCCH) or for other unexpected needed uplink occurrences. Each time a block period occurs on the air interface, the corresponding column is removed from the table.

Figure 5.34: Example of resource management for the fixed-allocation multiplexing scheme.

5.8.3.1 Downlink TBF

For a downlink TBF, the network requests the sending of the PACKET DOWNLINK ACK/NACK message from the mobile by including a valid RRBP value in the header of the downlink RLC data block. The PACKET DOWNLINK ACK/NACK message is sent by the mobile some block periods after, as specified by the RRBP field. This field specifies a single uplink block occurrence by giving the number of TDMA frames the mobile must wait before transmitting. Four values are available (N+ 13), (N+ 17 or N+ 18), (N+ 21 or N+ 22), or (N+ 26) where N is the frame number in which is received the first burst of the block giving the RRBP value. In two cases, two values are given for example (N+ 17 or N+ 18). N+ 17 corresponds to the case where there is only one idle frame between the reception and the transmission; in N + 18 there are two idle frames.

There is some delay between the request of the ACK/NACK message and its reception at the network side. This delay is linked to the RRBP period and to the global round-trip delay. The round-trip delay is for example the time that elapses between the sending of a USF value within one downlink radio block and the reception of the answer at network side. This time is dependent on the PCU location within the BSS. The closer the PCU to the BTS, the shorter the round-trip delay. Depending on the BSS implementation, the delay between the ACK/NACK message request and its reception can vary from 100 ms and 300 ms. This corresponds to 5 to 15 block periods.

This means that if a mobile is assigned one PDCH and it is not multiplexed with another mobile, between the request of the ACK/NACK message and its reception, the network will have sent between 5 to 15 more downlink data blocks to the mobile depending on the round-trip delay. Now, if we consider a mobile that is allocated 4 PDCHs, it will receive four times more blocks during this period, equivalent to 20–60 downlink data blocks.

In case of 4 time slots, the number of blocks that can be received during the polling period can be very important. The RLC window of 64 can be filled just between the request and the reception of the acknowledgment message. In the case of 4 time slots and considering a round-trip delay of 300 ms, it will be necessary to poll the mobile for the next acknowledgment message transmission before having received the first ACK/NACK message.

One possible solution for the polling algorithm is to poll the mobile after having addressed to it a constant number of blocks (for example, the mobile is polled every 20 blocks addressed to it). This number of blocks can be adapted dynamically depending on the state of the sending window. When the RLC protocol is about to be stalled, the polling period is reduced in order to receive ACK/NACK messages more often.

Figure 5.35 describes the way the polling mechanism works. In this example, the network requests the sending of an ACK/NACK message every x blocks sent. The first polling indication is sent within the block with BSN = x - 1. So the downlink ACK/NACK is received after the BSS has sent block y. Then the network retransmits unacknowledged downlink RLC data blocks. The second polling indication is sent after the 2 × x block transmitted by the BSS.

Figure 5.35: Polling mechanism.

Note that the choice of the RRBP value by the network at the moment it wants to poll a mobile is dependent on the availability of an uplink block occurrence. The network chooses the minimum RRBP value available in order to reduce the round-trip delay. However, some of the RRBP values may be unavailable, since multiple mobiles can be multiplexed on the same PDCH and some uplink block occurrences have been reserved for those mobiles limiting the choice in the RRBP value.

5.8.3.2 Uplink TBF

For an uplink TBF, the receiver is the BSS. It triggers the sending of PACKET UPLINK ACK/NACK messages indicating to the mobile which blocks have been correctly received. For this kind of TBF, no round-trip delay takes place in the process of uplink block acknowledgment. As soon as the network receives a block, it knows the difference between the oldest unacknowledged block and the block decoded with the highest BSN. If this difference in terms of BSN reaches 64, the protocol is stalled.

The network can easily avoid this situation, as at the reception of each block it knows whether or not the RLC protocol at the mobile side is about to stall. If this is indeed the case, it can decide to send an uplink acknowledgment message.

The same mechanism as for downlink transfer can be used. The network sends PACKET UPLINK ACK/NACK messages regularly, for example every x received RLC data blocks. The value of x can be larger than that used for the downlink transfer, since the influence of the round-trip delay does not have to be taken into account (there is only a half round-trip delay).

5.8.4.1 Link Adaptation Metrics

In order to adapt and choose the most adequate coding scheme, the network can use different measurements.

5.8.4.2 Link Adaptation Algorithm

One simple algorithm involves defining three fixed C/I thresholds defining the switching boundary between the different coding schemes. When the average C/I is higher than the threshold plus a margin, a less-protected coding scheme is chosen. When the average C/I falls below the threshold minus a margin, a more robust coding scheme is used. The margin is used as a hysteresis to avoid a ping-pong effect from one coding scheme to the other around the boundary. A more sophisticated algorithm could involve dynamic thresholds.

As stated previously, the switching point between two coding schemes is dependent on the mobile environment (TU, rural area, and hilly terrain). Knowing this, it is possible to estimate the environment in which the mobile is and then adapt the threshold depending on the environment.

Note that the BLER can be computed in uplink in the following way. For each block received at the network side, the BTS checks the BCS of the block to determine whether or not the block has been correctly decoded. The RLC/MAC layer, knowing to which mobile it has assigned the uplink resource on which the block was received and decoded or not, can deduce the BLER relative to this mobile. In the downlink direction, the network can compute the BLER based on the acknowledgments that are reported by the mobile.

An important issue when dealing with the link adaptation is its interaction with the power control algorithm. In fact, reducing the transmission level in uplink or in downlink impacts the quality of the transmission. Reducing the power has the effect of lowering the throughput. However, reducing the transmission power decreases the global interference level in the network and improves the transmission quality. Thus a tradeoff between PR and throughput must be found, although this is not necessarily easy to do.

5.8.4.3 Initial Coding Scheme Determination

At the beginning of the packet transfer, the BSS has no knowledge of the link quality between the BTS and the mobile, so there is no real metric allowing the determination of the initial coding scheme. One method is to always use a robust coding scheme (CS-1 or CS-2) at the beginning of the TBF in order to begin the TBF safely. Once a first evaluation of the link quality is available, the network can start to adapt dynamically the coding scheme.

However, between two TBFs, the network can keep in memory the last coding scheme used by the mobile during the previous TBF and reuse it as the initial coding scheme for the next TBF, as long as the time between the two TBFs is not too long.