Feature #2582
closedosmo-gsm-tester: add test case: dynamic timeslot data usage
Added by neels over 6 years ago. Updated over 5 years ago.
100%
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.
Files
| last_run.tar.gz | last_run.tar.gz | 1.33 MB | pespin, 09/21/2018 12:13 PM |
Related issues
Updated by neels over 6 years ago
- Related to Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslots added
Updated by neels over 6 years ago
- Blocked by Feature #2202: osmo-gsm-tester: add GPRS data services added
Updated by pespin over 6 years ago
- Subject changed from add dynamic timeslot data usage test to osmo-gsm-tester: add test case: dynamic timeslot data usage
Updated by pespin over 5 years ago
- Blocked by deleted (Feature #2202: osmo-gsm-tester: add GPRS data services)
Updated by pespin over 5 years 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
Updated by pespin over 5 years 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.
Updated by neels over 5 years 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.
Updated by pespin over 5 years 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.
Updated by pespin over 5 years 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.
Updated by pespin over 5 years 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
Updated by pespin over 5 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Merged, closing.
