Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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.