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/.
Holger Freyther zecke at selfish.orgHi all,
I have merged the Channel Release changes that were prototyped/used in the
on-waves/bsc-master branch and basic testing shows that it is working. If you
see weird things happening, please tell me and I try to figure out if it is
due the changes I made or not.
The problem I tried to solve was this:
Assume a phone sends a SMS (allocates SAPI=3) and then we do release the
channel. Now this can happen with a nanoBTS (and I think it is a bug):
BSC BTS/MS
RF Channel Release ->
<- RF Channel Release Ack
<- Release Indication SAPI=0
<- Release Indication SAPI=3
The OpenBSC code used to declare the lchan as available with the RF Channel
Release ACK, we also decided to release the channel with the SAPI release
indication.. So we were sending a RF Channel Release twice... Now with a
loaded cell we could have re-allocated this lchan and then we release
someone's else lchan... I was seeing from RF Failures, to BTS crashes with two
concurrent phones doing call testing..
Our release procedure now works like this:
chan_alloc.c is called to release the lchan.
1.) we remember the release reason and if we should send a SACH deactivate
2.) we declare the channel to be in state release request
3.) we start to release the highest allocated SAPI != 0 (well only three)
4.) from abis_rsl.c we will call to chan_alloc.c in case a SAPI got released
and repeat 3rd).
5.) If only SAPI=0 is left we either release or send a SACH deactivate..
6.) we send a RF Channel Release...