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/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi!
Some other 'bug' that I discovered while looking at traces recently is
in RSL, where we
* Send RSL ACTIVATE CHANNEL to open a channel on the BTS side
* Send RR IMMEDIATE ASSIGN through the AGCH to the MS
and only later receive RSL ACT CHAN ACK.
This seems to work fine, since we queue the messages in-order and dequeue them
in-order and simply assume the BTS will ACK. but what if it cannot activate
the channel due to a hardware problem? Or what if we have a bug and try to
assign the same channel twice?
However, on the E1 protocol analyzer the ordering of events was reversed, i.e.
the IMMEDIATE ASSIGN happened before the RSL CHAN ACT. I couldn't understand
why, since we always enqueue at the end of the queue and dequeue from the
front. But what I was missing: In a multi-TRX setup, the IMMEDIATE ASSIGN
gets sent over the TRX0 (AGCH, part of BCCH) while the RSL CHAN ACTIVATE
gets sent over TRX1. Each TRX has its own RSL link, and the TRX0 link
might be ready to receive our message a bit sooner than the TRX1 link...
So in this case, we send the messages in wrong order, and risk a channel
assignment error.
What needs to be done is to actually send the RSL CHAN ACT, save the state,
wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
Similar issues might exist in other cases of channel activation, such as
handover.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)