Project

General

Profile

Actions

Bug #3238

closed

ipacc style dyn TS become unusable after first voice call

Added by neels almost 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/04/2018
Due date:
% Done:

100%

Spec Reference:

Description

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.


Files

tch_f_pdch_break_after_first_voice_call.pcapng tch_f_pdch_break_after_first_voice_call.pcapng 5.44 MB neels, 05/04/2018 11:46 PM
verbose_log.pcapng verbose_log.pcapng 1.22 MB TCH/F_PDCH neels, 05/05/2018 12:24 AM
verbose_log_fine_with_tch_f_tch_h_pdch.pcapng verbose_log_fine_with_tch_f_tch_h_pdch.pcapng 2.67 MB identical action to verbose_log.pcap, working well because with TCH/F_TCH/H_PDCH, as comparison neels, 05/05/2018 12:32 AM
Actions #1

Updated by neels almost 6 years ago

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

Actions #2

Updated by neels almost 6 years ago

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.

Actions #3

Updated by neels almost 6 years ago

to have a chance to spot the difference, here another pcap with the working TCH/F_TCH/H_PDCH config.

Actions #4

Updated by neels almost 6 years ago

  • % 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 :/

Actions #5

Updated by neels almost 6 years ago

  • Status changed from New to In Progress
  • Assignee set to neels
Actions #6

Updated by neels almost 6 years ago

  • % Done changed from 60 to 90
Actions #7

Updated by neels over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

merged months ago.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)