MDL-Error in case of OsmocomBB+OpenBTS

[David A. Burgess]

Sylvain -

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