Project

General

Profile

Feature #2582

osmo-gsm-tester: add test case: dynamic timeslot data usage

Added by neels about 1 year ago. Updated 17 days ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
10/19/2017
Due date:
% Done:

100%

Spec Reference:

Description

Make sure that a dynamic timeslot still is usable for data service after switching back from voice operation.

Have a pchan configuration where all pchans are not usable for voice or data, except for a single TCH/F_TCH/H_PDCH.
- First transfer some data to verify PDCH works.
- Do a voice call. Optionally verify that PDCH stops working during the voice call.
- End the voice call, then verify that PDCH works again.

Also do the same for TCH/F_PDCH.

last_run.tar.gz last_run.tar.gz 1.33 MB pespin, 09/21/2018 12:13 PM

Related issues

Related to OsmoGSMTester - Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslotsResolved2017-10-18

Related to OsmoGSMTester - Feature #3239: test dyn TS: switch to voice and back to data, ensure GPRS still works, and ensure switching back to voice still worksResolved2018-05-05

History

#1 Updated by neels about 1 year ago

  • Related to Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslots added

#2 Updated by neels about 1 year ago

  • Blocked by Feature #2202: osmo-gsm-tester: add GPRS data services added

#3 Updated by pespin about 1 year ago

  • Subject changed from add dynamic timeslot data usage test to osmo-gsm-tester: add test case: dynamic timeslot data usage

#4 Updated by pespin about 1 month ago

  • Blocked by deleted (Feature #2202: osmo-gsm-tester: add GPRS data services)

#5 Updated by pespin about 1 month ago

  • Related to Feature #3239: test dyn TS: switch to voice and back to data, ensure GPRS still works, and ensure switching back to voice still works added

#6 Updated by pespin about 1 month ago

  • Priority changed from Normal to High

We should have a test which iterates over several states. Can we have a setup with only 1 signalling TS and then 2 TS with dynamic TS to use for gprs and voice? This way se make sure the same channels are used.

Test would be include 2 MS, which would:
  • First, both MS register and activate a pdp ctx
  • Second, both MS deactivate the pdp ctx and establish a voice call between them
  • Third, hangup the voice call and attempt to activate pdp ctx again
  • Forth, deactivate again and attempt to establish a voice call again

neels any thoughts regarding this?
We already have tests verifying voice and call works fine with dynts, but not that we can switch between them.

#7 Updated by pespin about 1 month ago

  • Assignee changed from osmo-gsm-tester to neels

#8 Updated by neels about 1 month ago

On Tue, Sep 18, 2018 at 10:12:07AM +0000, pespin [REDMINE] wrote:

We should have a test which iterates over several states. Can we have a setup with only 1 signalling TS and then 2 TS with dynamic TS to use for gprs and voice? This way se make sure the same channels are used.

Yes, that's exactly what this test is asking for.

For example, I sometimes used a pchan config like

timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 2
phys_chan_config SDCCH8
timeslot 3
phys_chan_config SDCCH8
timeslot 4
phys_chan_config SDCCH8
timeslot 5
phys_chan_config SDCCH8
timeslot 6
phys_chan_config SDCCH8
timeslot 7
phys_chan_config SDCCH8

This makes sense for a TCH/H voice call with both call legs on the dyn TS.

For TCH/F, assign a second dyn TS.

(If you guarantee that TCH/F is used instead of TCH/H, you can also assign two
TCH/F_TCH/H_PDCH -- just avoid a case where TCH/H is used and only one of the
TS ends up being used for voice, and a second TS never leaves PDCH.)

Test would be include 2 MS, which would:
  • First, both MS register and activate a pdp ctx
  • Second, both MS deactivate the pdp ctx and establish a voice call between them
  • Third, hangup the voice call and attempt to activate pdp ctx again
  • Forth, deactivate again and attempt to establish a voice call again

Nice would be to verify that some actual data can be downloaded over GPRS, in
case we support that yet...

This test is a brutal scenario where we cut off PDCH communication forcibly.
It's non-graceful and shouldn't happen in real life configurations, but it's
the only 100% certain way I know to verify that we're really using a dyn TS as
PDCH that came back from voice mode.

Note that also, the PCU often takes a little moment before it gets to grips
again with the PDCH re-appearing.

I'm not sure whether the MS get a chance to deactivate PDP at all, except maybe
that during the phone call setup they suspend GPRS for other reasons. What
would happen is that all of a sudden, the uplink to the SGSN is completely gone
because the BTS/PCU have switched off all PDCH, i.e. not even GPRS-NS is
getting through. In manual testing I can then see that "the website doesn't
load". Not sure how we can verify that in osmo-gsm-tester?

Maybe a first step would be to verify that after the voice call, the MS can
still somehow communicate with the SGSN. Is that possible? It may need to
involve actively disabling and re-enabling GPRS on the modem to ensure we're
nost just seeing an old PDP context lingering, and then wait for the SGSN VTY
to show a fresh PDP context? ... I'm not entirely sure. The plainest would be
to try to download some file, if we can do that.

#9 Updated by neels about 1 month ago

  • Assignee changed from neels to pespin

#10 Updated by pespin 29 days ago

  • File last_run.tar.gz added

Here you can find the test, as well as all the required bits to run it (branch pespin/dynts):
https://git.osmocom.org/osmo-gsm-tester/tree/suites/dynts/switch_tch_pdch.py?h=pespin/dynts

I run it the following way:

-s dynts:trx-b200+mod-bts0-dynts67-osmo.conf+cfg-codec-fr1 -l dbg -T

So I force codec to be FR, I use a trx-b200 (it's the quicket BTS to setup for continuous test). The timeslot from the scenario above is the following:
modifiers:
  bts:
  - num_trx: 1
    trx_list:
    - timeslot_list:
      - phys_chan_config: 'CCCH+SDCCH4'
      - phys_chan_config: 'SDCCH8'
      - phys_chan_config: 'SDCCH8'
      - phys_chan_config: 'SDCCH8'
      - phys_chan_config: 'SDCCH8'
      - phys_chan_config: 'SDCCH8'
      - phys_chan_config: 'TCH/F_TCH/H_PDCH'
      - phys_chan_config: 'TCH/F_TCH/H_PDCH'

The test currently fails when switching from call back to gprs pdp activate context:

13:51:23.387166 tst            switch_tch_pdch.py:33: hangup success
13:51:23.991594 tst            switch_tch_pdch.py:92: 3: activate_pdp
13:51:24.461388 tst                        /sierra_1: DBG: activate_context {apn='inet46', protocol='ip', user='ogt'}
13:52:04.993189 tst            switch_tch_pdch.py:93: ERR: Error: g-io-error-quark: GDBus.Error:org.ofono.Error.Failed: Operation failed (36)  [trial↪dynts:trx-b200+mod-bts0-dynts67-osmo.conf+cfg-codec-fr1↪switch_tch_pdch.py:93]
13:52:05.003086 tst            switch_tch_pdch.py:93: TRACEBACK: Traceback (most recent call last):
  File "/home/pespin/osmo-gsm-tester/src/osmo_gsm_tester/test.py", line 61, in run
    self.path)
  File "/home/pespin/osmo-gsm-tester/src/osmo_gsm_tester/util.py", line 351, in run_python_file
    spec.loader.exec_module( importlib.util.module_from_spec(spec) )
  File "<frozen importlib._bootstrap_external>", line 673, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/home/pespin/osmo-gsm-tester/suites/dynts/switch_tch_pdch.py", line 93, in <module>
    activate_pdp(ms_mo, ms_mt)
  File "/home/pespin/osmo-gsm-tester/suites/dynts/switch_tch_pdch.py", line 7, in activate_pdp
    ctx_id_v4_mo = ms_mo.activate_context(apn='inet46', protocol=ms_mo.CTX_PROT_IPv4)
  File "/home/pespin/osmo-gsm-tester/src/osmo_gsm_tester/modem.py", line 618, in activate_context
    ctx.SetProperty('Active', Variant('b', True))
  File "/usr/local/lib/python3.5/dist-packages/pydbus/proxy_method.py", line 75, in __call__
    0, timeout_to_glib(timeout), None).unpack()
GLib.GError: g-io-error-quark: GDBus.Error:org.ofono.Error.Failed: Operation failed (36)

As you can see, Activating the pdp ctx stalls for aprox 40 seconds and then fails.
At the time of failure, ofono prints following error coming from QMI which aborts the activation (the first message is the one sent to the modem to do the pdp ctx activation). The example is not from this run so the timing doesn't match exactly, but you can get the idea:

Sep 21 13:35:26 osmo-gsm-tester-rnd ofonod[2550]: drivers/qmimodem/qmibridge.c:ask_qmi() _REQ: QMI QMUX:
                                                  QMI   length  = 35
                                                  QMI   flags   = 0x00
                                                  QMI   service = "wds" 
                                                  QMI   client  = 9
                                                  QMI QMI:
                                                  QMI   flags       = "none" 
                                                  QMI   transaction = 539
                                                  QMI   tlv_length  = 23
                                                  QMI   message     = "Start Network" (0x0020)
                                                  QMI TLV:
                                                  QMI   type       = "APN" (0x14)
                                                  QMI   length     = 6
                                                  QMI   value      = 69:6E:65:74:34:36
                                                  QMI   translated = inet46
                                                  QMI TLV:
                                                  QMI   type       = "IP Family Preference" (0x19)
                                                  QMI   length     = 1
                                                  QMI   value      = 04
                                                  QMI   translated = ipv4
                                                  QMI TLV:
                                                  QMI   type       = "Authentication Preference" (0x16)
                                                  QMI   length     = 1
                                                  QMI   value      = 02
                                                  QMI   translated = chap
                                                  QMI TLV:
                                                  QMI   type       = "Username" (0x17)
                                                  QMI   length     = 3
                                                  QMI   value      = 6F:67:74
                                                  QMI   translated = ogt

Sep 21 13:36:05 osmo-gsm-tester-rnd ofonod[2550]: drivers/qmimodem/qmibridge.c:ask_qmi() READ: QMI QMUX:
                                                  QMI   length  = 31
                                                  QMI   flags   = 0x80
                                                  QMI   service = "wds" 
                                                  QMI   client  = 9
                                                  QMI QMI:
                                                  QMI   flags       = "response" 
                                                  QMI   transaction = 539
                                                  QMI   tlv_length  = 19
                                                  QMI   message     = "Start Network" (0x0020)
                                                  QMI TLV:
                                                  QMI   type       = "Result" (0x02)
                                                  QMI   length     = 4
                                                  QMI   value      = 01:00:0E:00
                                                  QMI   translated = FAILURE: CallFailed
                                                  QMI TLV:
                                                  QMI   type       = "Call End Reason" (0x10)
                                                  QMI   length     = 2
                                                  QMI   value      = 01:00
                                                  QMI   translated = generic-unspecified
                                                  QMI TLV:
                                                  QMI   type       = "Verbose Call End Reason" (0x11)
                                                  QMI   length     = 4
                                                  QMI   value      = 02:00:CC:00
                                                  QMI   translated = [ type = 'internal' reason = '204' ]
Sep 21 13:36:05 osmo-gsm-tester-rnd ofonod[2550]: drivers/qmimodem/gprs-context.c:start_net_cb()
Sep 21 13:36:05 osmo-gsm-tester-rnd ofonod[2550]: src/gprs.c:pri_activate_callback() 0x55d8f4bb1770
Sep 21 13:36:05 osmo-gsm-tester-rnd ofonod[2550]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type
Sep 21 13:36:06 osmo-gsm-tester-rnd ofonod[2550]: plugins/udevng.c:remove_device() /sys/devices/virtual/net/tun4
Sep 21 13:36:06 osmo-gsm-tester-rnd ofonod[2550]: plugins/udevng.c:remove_device() /sys/devices/virtual/net/tun6
Sep 21 13:36:06 osmo-gsm-tester-rnd ofonod[2550]: plugins/udevng.c:remove_device() /sys/devices/virtual/net/tun46

I attach a last_run.tar.gz with all the information running that test showing the current issue.

#11 Updated by pespin 29 days ago

  • File deleted (last_run.tar.gz)

#12 Updated by pespin 29 days ago

#13 Updated by pespin 29 days ago

It seems adding a sleep(30) between Call hangup and next GPRS activate pdp ctx makes the MS able to activate the ctx and the test passes.

#14 Updated by pespin 29 days ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 90

New test submitted in:
https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11052 Add dynts suite to test switch between PDCH and TCH

#15 Updated by pespin 17 days ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)