The question of how idle sequences are generated drives much of the L1 and L2 architecture in a software BTS. In the OpenBTS architecture, the bulk of any idle fill task is handled at a very low level by the software defined radio, in what is sometimes called "L0", the radio interface below the L1 FEC modules.
To support idle filling, the software transmitter keeps a table for each timeslot large enough to store all of the radio bursts for a a complete cycle of that slot's TDMA pattern. (The software transmitter is aware of the channel combination in use on a given timeslot.) There are two rules for managing this table:
1. Whenever a radio burst is sent to the software transmitter, the transmitter stores a copy of the outgoing burst in that slot's filler table, indexed by the outgoing bust's frame number, modulo the TDMA cycle period.
1. Whenever the software transmitter needs to send a radio burst at a specific position in the TDMA pattern and none is enqueued for transmission, the transmitter will pull a substitute burst from the filler table.
The effect of this pair of rules is that whenever the bursts of an L2 frame are sent to the radio for transmission on a particular logical channel, that burst pattern will continue to be repeated in its TMDA positions on the radio link until the bursts of another L2 frame are sent to replace it. The implication for the higher layers is that an idle filling frame need only be sent once, at the start of an idle period, and the lower layers of the radio will continue to repeat that idle pattern until some new activity overwrites it.
With a sufficiently long TDMA cycle time, this mechanism may also be used to generate the system information messages of the SACCH or BCCH, although we do not do that yet.
注：Idle-Filling in OpenBTS（原文出处，翻译整理仅供参考!）