Cellular Network Infrastructure » Radio Access Network » OsmoBTS

I noticed that "RF-locking" a transceiver with active connections (e.g. voice calls) causes a resource leak: the BSC would continue to consider the associated logical channels occupied, so the MSC would also consider the CS connections active (if any). What's even more annoying is that the phones, that were previously connected and lost the signal, would be unable to attach again, because the MSC thinks that they still are.

23:34 < fixeria> interestingly, both BSC and MSC still consider the connection (silent call) as established
23:37 <@LaF0rge> fixeria: The BTS radio link timeout should still be counting down, which in turn should result in a channel releae after some seconds
23:37 <@LaF0rge> fixeria: if that doesn't happen, it's a bug (pleae file one)
23:38 <@LaF0rge> fixeria: so basically to the higher layers it doesn't matter why the RF connection is gone (no more signal, bad antenna/cable, broken power amplifier, 
                 or TRX locked) - the radio link is gone and it must detect that and handle it identical
23:39 <@LaF0rge> once the BTS reports radio link failure to the BSC, the BSC will start the release procedure for the A interface SCCP connection and the MSC will 
                 release all related resouces
23:39 < fixeria> LaF0rge: yep, looks like a resource leak
23:42 < fixeria> lol, after that osmo-msc refuses to accept a Location Update
23:43 < fixeria> "Cannot associate with VLR subscr, another connection is already active at IMSI-262423403******:MSISDN-******:TMSI-0x7CB52857:GERAN-A-2:PAGING_RESP" 
23:45 < fixeria> LaF0rge: I guess the problem is that rf-locking causes osmo-bts to reset the scheduler, from what I see in the logs
23:47 < fixeria> "DL1C NOTICE scheduler.c:616 Exit scheduler for trx=0" then "DL1C NOTICE scheduler.c:591 Init scheduler for trx=0" 
23:48 < fixeria> this is basically a result of trx_sched_reset() that calls trx_sched_exit() and then trx_sched_init()
23:49 < fixeria> so if we reset the scheduler, the BTS would simply "forget" all active connections and never report "radio link failure(s)" 
23:59 <@LaF0rge> fixeria: I think the radio link timeout etc. are implemented above L1SAP
23:59 <@LaF0rge> fixeria: but maybe if no more events are coming up from the bts-model part, those are never triggered.
00:00 < fixeria> LaF0rge: ok, I'll open a ticket with all the findings

I think we can fix this by sending the RSL Radio Link Failure for all (still) active DCCHs as soon as the ramping down is completed.
And this seems to be what the other BTS models are doing when a transceiver gets RF-locked.