ipacc style dyn TS become unusable after first voice call
TCH/F_PDCH timeslots work fine for data, and then work fine for the first voice call.
But after that, neither data nor another voice call will go through.
Reproduce: one sysmoBTS and a TS config of
timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F_PDCH timeslot 3 phys_chan_config TCH/F_PDCH timeslot 4 phys_chan_config SDCCH8 timeslot 5 phys_chan_config SDCCH8 timeslot 6 phys_chan_config SDCCH8 timeslot 7 phys_chan_config SDCCH8
At first, both TS are used as PDCH. When placing a voice call, this switches both to TCH/F and works fine.
After the call, the RSL signalling and PCU log look as though switching back to PDCH was perfectly fine as well.
But no data will go through anymore. Switching GPRS off and on on a phone will also then cease to show a GPRS icon.
Also placing another voice call looks like switching the TS back to TCH/F works fine, but the call will abort early.
In contrast, Osmocom style dynamic timeslots (TCH/F_TCH/H_PDCH) switch back and forth fine any number of times.
That doesn't really make sense, since the only difference is the RSL messaging used to switch to/from PDCH.
(Osmocom style tested with a TS config like above, but only a single TCH/F_TCH/H_PDCH yielding two TCH/H, instead of the two TCH/F_PDCH ts;
so I guess another difference is that two timeslots are switched in close succession, which I believe not to be the cause.)
In attached pcap, two phones attach, one phone browses osmocom.org, then the first voice call is started at packet 10548.
After the voice call, one phone detaches and re-attaches and fails to re-establish GPRS, from packet 14798.
The second voice call is initiated from packet 16660, which fails to be established; followed by another failing call attempt.
I should mention that testing was done with patches not yet merged to master,
osmo-bts Ic06c8f0fe82ae8a06afa5defd93a685010687965 I654b963815b32fcbce050c2e15f3190c97bc259f
osmo-bsc Icf6e25ff068e8a2600562d52726ead65e864ec02 Iedb4fb63bf1959d5f1d2c6edb6a7f5097ff16bd7 Id7d9dd06451722eb328db77bb586826c954bd85c and various others
see on branches neels/dyn_ts_fix
- File verbose_log.pcapng added
another pcap with more gsmtap_log from BTS and PCU, this time starting from just before one voice call is made, and after the call showing the "START Immedate Assignment Uplink (AGCH)" which seem to fail with T3169 timing out. Haven't yet spotted the difference to operation with TCH/F_TCH/H_PDCH.
- % Done changed from 0 to 60
The reason why the PDTCH lchan did not receive any more UL data was
5169 20.010225965 May 5, 2018 02:21:55.681068746 CEST 192.168.0.125 192.168.0.6 GSMTAP OsmoBTS oml.c 1424 (bts=0,trx=0,ts=3,ss=0) SET_CIPHERING (ALG=1 RxUL)
I routinely use ciphering in my CS network, something I haven't always done.
When switching to TCH/F, the BSC sets the lchan's ciphering parameters.
When switching back to PDCH with the ip.access style PDCH act, these remain set, and the BTS would enable ciphering.
With Osmocom style dynamic timeslots, we use a proper Chan Activ, which overwrites various stale state, including ciphering.
Hence after activating PDCH, the ciphering setting is cleared for Osmocom style dyn TS.
I will submit a patch to properly clear lchan attributes upon PDCH Act / Deact.
Probably, TCH/F_PDCH have always shown this behavior from the start, just no-one tested it with ciphering enabled :/