Project

General

Profile

Support #2622

Prepare automatic interop testing of OmsoBSC against NG40 core simulator + osmo-bts-virtual + mobile

Added by laforge about 1 year ago. Updated 3 months ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
11/07/2017
Due date:
% Done:

10%

Spec Reference:

Description

Please create a setup where the signaling tests (LU, MO-SMS, MT-SMS, USSD) can be done with osmocombb-mobile + virt_phy + osmo-bts-virtual + osmo-bsc against NG40.

This is in preparation of automatizing this task as soon as we have a scripting interface towards OsmocomBB "mobile"

Building all components should be automatic / scripted. It might be an idea to do this via Dockerfiles. Execution of the tests + checking results is not automatic yet, as this is pending the OsmocomBB "mobile" script interface.

The goal is basically to have a single command/script to
  • build/install osmo-bsc, osmo-bts-virtual, virt-phy + mobile
  • might make sense to have
    • one docker image for osmo-bsc
    • one docker image for osmo-bts-virtual + virt_phy
and then have another scripted way to
  • start N instances of each of them (except "mobile"), where the number of BSCs is different from the number of BTSs and again different from the number of virt-phy instances
testnet_ng40_virtual.tar.gz testnet_ng40_virtual.tar.gz 596 KB dexter, 08/27/2018 12:49 PM

Related issues

Related to OsmoBSC - Feature #2478: Manual interop testing with NG40 core simulatorResolved2017-08-31

Related to Cellular Network Infrastructure - Feature #2558: Scripts to manage thousands of "mobile" and hundreds of osmo-bts-virtual instancesIn Progress2017-10-06

Related to OsmocomBB - Feature #2555: script interface to OsmocomBB "mobile"In Progress2017-10-06

History

#1 Updated by laforge about 1 year ago

  • Related to Feature #2478: Manual interop testing with NG40 core simulator added

#2 Updated by laforge about 1 year ago

  • Related to Feature #2558: Scripts to manage thousands of "mobile" and hundreds of osmo-bts-virtual instances added

#3 Updated by laforge about 1 year ago

  • Related to Feature #2555: script interface to OsmocomBB "mobile" added

#4 Updated by dexter 12 months ago

  • Status changed from New to In Progress

I managed to get the following running:

mobile <--> virtphy <--/--> osmo-bts-virtual <--> osmo-bsc <--> NG40 tester

I did not test very much yet, but I see the location update is getting accepted. However, in my mobile.cfg I currently have an all-zero-ki. I am a bit confused that I am still getting accepted on NG40. I remember we configured proper KI keys, at least on the simcards.

#5 Updated by dexter 12 months ago

I wonder if it is somehow possible to send audio streams through the mobile application when it runs with virtphy. In order to do meaningful tests we should have something like this. I have to try it out. For first tests it is probably enough when we generate silence voice frames. The RTP packets from the BTS should still be there, even if they carry only silence.

#6 Updated by laforge 12 months ago

On Mon, Dec 04, 2017 at 08:51:06PM +0000, dexter [REDMINE] wrote:

I wonder if it is somehow possible to send audio streams through the
mobile application when it runs with virtphy.

Not yet, but there is a separate ticket to extend GSMTAP, virt_phy and
osmo-bts-virtual for this. See #2557

For first tests it is probably enough when we generate silence voice
frames. The RTP packets from the BTS should still be there, even if
they carry only silence.

I was so far thinking of implementing voice frame looping inside
'mobile'. But of course one could also hook up some static play-back.

If you want to go crazy: 'mobile' always had a MNCC interface, just like
OsmoNITB/OsmoMSC. You can attach lcr (or possibly even
osmo-sip-connector) with it. Jolly implemented it for LCR support.
This was of course with real phone hardware, not with virt_phy. But
once we pass the voice frames through, there's no reason why MNCC
couldn not be used :)

#7 Updated by pespin 7 months ago

After discussing for a while with Philipp, we decided as a first step to follow with the virtphy solution to have at least some automatized tests the same way we already have for ng40<->osmo-msc.

Information on the setup can be found in: https://projects.sysmocom.de/redmine/projects/office/wiki/NG40_Setup
The jenkins job running the ng40<->osmo-msc test can be found in: http://sysmocom-jenkins/job/ng40-test-core-network
The repo containing all the configurations and scripts used to set up the jenkins job, alice and bob are found in: https://git.admin.sysmocom.de/ng40/config-alice/

The best idea is probably to move all current stuff in config-alice git repository into an "test-osmo-msc" repository, and copy the same structure in "test-osmo-bsc" subdir. Then in there modify osmocom-setup/run.sh accordingly to start the desired osmocom services, and update osmocom cfg files in osmocom-setup/config accordingly. Also update ng40 config in "sysmocom-ran" directory. The build.sh and update.sh scripts can most probably be shared between both test directories in a "bin" directory.

Then either update the existing jenkins job to run tests for both bsc and msc setup, or clone the existing job into a new job and modify accordingly.

#8 Updated by dexter 3 months ago

There are two variants. We can use osmo-bts-virtual with virtphy, or we can use osmo-bts-trx with fake_trx and trxcon. I have tested both versions with limited success.

For both approaches it seems not to be possible to use two virtual ms at the same time. For the osmo-bts-trx with fake_trx and trxcon variant we already have confirmed that it indeed does not work at the moment, but for osmo-bts-virtual with virtphy it should be possible. I have tried it with two different virtphy/mobile processes on two different sockets and it does still not work. I wonder how the two processes can collide, tey use different l1ctl sockets. There should be a complete separation up until the GSMTAP multicast communication.

Mon Aug 27 14:36:40 2018 DVIRPHY <0002> virtphy.c:230 Virtual physical layer starting up...
Mon Aug 27 14:36:40 2018 DVIRPHY <0002> virtphy.c:240 Virtual physical layer ready, waiting for l23 app(s) on /tmp/osmocom_l2_2
Mon Aug 27 14:36:55 2018 DMAIN <0003> virt_l1_model.c:41 MS 0000: allocated
Mon Aug 27 14:36:55 2018 DL1C <0000> l1ctl_sock.c:141 Accepted client (fd=6) from server (fd=5)
Mon Aug 27 14:36:55 2018 DL1C <0000> l1ctl_sock.c:99 Failed to receive msg from l2. Connection will be closed.
Mon Aug 27 14:36:55 2018 DMAIN <0003> virt_l1_model.c:48 MS 0000: destroyed
Copyright (C) 2010-2015 Andreas Eversberg, Sylvain Munaut, Holger Freyther, Harald Welte
Contributions by Alex Badea, Pablo Neira, Steve Markgraf and others

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000d> sap_interface.c:585 init SAP client
<000f> sim.c:1232 init SIM client
<0006> gsm48_cc.c:61 init Call Control
<0007> gsm480_ss.c:231 init SS
<0018> gsm411_sms.c:63 init SMS
<0001> gsm48_rr.c:5495 init Radio Ressource process
<0005> gsm48_mm.c:1319 init Mobility Management process
<0005> gsm48_mm.c:1032 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5042 init PLMN process
<0003> gsm322.c:5043 init Cell Selection process
<0003> gsm322.c:5101 Read stored BA list (mcc=226 mnc=99  Romania, 99)
<0011> app_mobile.c:244 Mobile '1' initialized, please start phone now!
Using configuration from ./mobile.cfg

I also tried with one virtphy and two mobiles connecting to the same socket. This does not work either:

While the first mobile connects fine and works fine, the second one is rejected:

Mon Aug 27 14:42:02 2018 DL1P <0001> virt_prim_data.c:109 MS 0000: TX L1CTL_DATA_IND (link_id=0x00) 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
Mon Aug 27 14:42:02 2018 DMAIN <0003> virt_l1_model.c:41 MS 0001: allocated
Mon Aug 27 14:42:02 2018 DL1C <0000> l1ctl_sock.c:141 Accepted client (fd=7) from server (fd=5)
Mon Aug 27 14:42:02 2018 DL1C <0000> l1ctl_sock.c:99 Failed to receive msg from l2. Connection will be closed.
Mon Aug 27 14:42:02 2018 DMAIN <0003> virt_l1_model.c:48 MS 0001: destroyed
Mon Aug 27 14:42:02 2018 DL1P <0001> virt_prim_data.c:109 MS 0000: TX L1CTL_DATA_IND (link_id=0x00) 55 06 19 8f b1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 79 04 00 2b 
Mon Aug 27 14:42:02 2018 DL1C <0000> l1ctl_sap.c:697 MS 0000: Tx L1CTL_RESET_CONF (reset_type: 1)
Mon Aug 27 14:42:02 2018 DL1C <0000> virt_prim_fbsb.c:61 MS 0000: Rx L1CTL_FBSB_REQ (arfcn=866, flags=0x7)
Copyright (C) 2010-2015 Andreas Eversberg, Sylvain Munaut, Holger Freyther, Harald Welte
Contributions by Alex Badea, Pablo Neira, Steve Markgraf and others

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000d> sap_interface.c:585 init SAP client
<000f> sim.c:1232 init SIM client
<0006> gsm48_cc.c:61 init Call Control
<0007> gsm480_ss.c:231 init SS
<0018> gsm411_sms.c:63 init SMS
<0001> gsm48_rr.c:5495 init Radio Ressource process
<0005> gsm48_mm.c:1319 init Mobility Management process
<0005> gsm48_mm.c:1032 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5042 init PLMN process
<0003> gsm322.c:5043 init Cell Selection process
<0003> gsm322.c:5101 Read stored BA list (mcc=226 mnc=99  Romania, 99)
<0011> app_mobile.c:244 Mobile '1' initialized, please start phone now!
Using configuration from ./mobile.cfg

The problem is probably somewhere with the configuration. I have attached all the configuration files for both approaches.

Apart from that the communication with the NG40 core network looks very good. When the phone connects I can see the location update.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)