Actions
Bug #4694
closedRadio link timeout would never expire after RF-lock (resource leak)
Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
osmo-bts-trx
Target version:
-
Start date:
08/06/2020
Due date:
% Done:
100%
Spec Reference:
Description
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.
Related issues
Actions