Bug #3554
closed
trxcon/scheduler: misaligned burst reception
Added by fixeria over 5 years ago.
Updated about 4 years ago.
Description
In some cases, as soon as a logical channel is activated, the following errors can be seen:
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
this can happen if the burst reception would start from bid != 0.
- Subject changed from trxcon/scheduler: misaligned xCCH reception to trxcon/scheduler: misaligned burst reception
Actually, the TCH/F implementation is also affected.
- Target version deleted (
Improvement of the higher layers of OsmocomBB)
- Status changed from New to In Progress
- Priority changed from Normal to High
Since [1], the layer23 applications may crash on receipt of an incomplete (but successfully decoded) xCCH block where the first burst (bid=0) is missing. The problem is that in this case trxcon (no idea about Calypso PHY) sets TDMA frame number of the corresponding L1CTL DATA.ind to 0, so the assert() in fn2ccch_block() crashes the process.
We could try to recover TDMA frame number of the first burst by subtracting 4, but this would not be correct for SACCH and PTCCH, where the bursts are being interleaved in a non-consecutive order. A smart (but of course more complicated way) would be to look-up the first frame number using the multi-frame layout tables as we already do for TCH/H.
[1] https://gerrit.osmocom.org/q/I0adab003a4060c9cef730e0432859659c51bd087
- Status changed from In Progress to Feedback
- % Done changed from 0 to 90
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF