This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
David A. Burgess dburgess at jcis.netSylvain - There was an unintentional change in filler table behavior between 2.6 and 2.8, probably as a result of modifications to support multi-ARFCN operation. A known symptom of this change in normal OpenBTS operation is the occasional failure of an assignment to a TCH for some MS basebands, most notably Nokia DTC4 series handsets, like the 1600. We are looking for the bug ourselves now. -- David On Jan 8, 2013, at 7:40 AM, Sylvain Munaut wrote: > Hi, > >> Anything OpenBTS is doing wrong? > > Well, kind of. > > Seems that when the L2 doesn't have anything "new" to send, it doesn't > send anything, which causes the filler table to repeat the last > message. Now AFAIU, it is the intended behavior, but all in all I'm > not convinced it's a good idea. It can help if the process generating > the burst doesn't send them to transceiver in time (and so they'll be > 'replayed' a multiframe later), but that only works IF: > - The message are time independent (eg some messages on CCCH need to > at the right time (longer than 1 multiframe) to be in the good paging > group, each SI message is supposed to be in some specific order, ...) > - No new L1 bursts are generated in the mean time that would > overwrite the non transmitted bursts from the filler table > - The L1FEC was really too late to TX message to the transceiver to > send them in time > > I'm kind of wondering how often all those 3 conditions are met and > this filler table actually helps. > > If instead of retransmitting the last L2 packet, it would just > transmit a filler, then if the L1FEC was late, the packet would be > lost and the LAPDm recovery would kick-in. > > As it is now, it _should_ work since the LAPDm receiver is essentially > supposed to ignore all those redudant packet. But that doesn't mean it > won't trigger weird bugs in the stack. > > Cheers, > > Sylvain