Dynamic PDCH / TCH switching assumes RSL link is up
It seems the existing code has the assumption that the RSL link is up at the time the OML MO for the timeslot is enabled.
This might be the case, but might also not be the case.
Also, the RSL link might get lost and get re-established. In that case, all ts/lchan are again in intial state and the PDCH will need to be activated. This should be fairly simple to simulate with dropping the RSL link from either BTS or BSC point of view.
From my point of view, it might make sense to have an (explicit or implicit) FSM with time-outs. So whenver a dynamic timeslot is currently not used for TCH but the PDCH is not active either, we should re-attempt to activate the PDCH after some time out, again and again.
In the Ericsson case, also if the PCU looses sync with the CCU, the BTS releases the PDCH timeslot/lchan after some time with an error - similar to the case where no TRAU/RTP connection can be established for voice on a voice channel. For that reason, too, the PDCH will need to be periodically re-activated if for some reason it gets deactivated.
Furthermore, in the abis/ip case, the RSL CHAN ACT (PDCH) seems to be sent before the OPSTART of the TS is acknowledged by the BTS.
#2 Updated by laforge over 1 year ago
On Thu, Nov 24, 2016 at 04:07:54PM +0000, neels [REDMINE] wrote:
what scale of timeout would make sense for PDCH reactivation? Is 10 seconds too frequent?
I think it would be OK, but 30s or 60s would be equally fine.
- Harald Welte <firstname.lastname@example.org> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)