GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Fri Jul 14 22:11:45 UTC 2017


Hi all!

Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).

Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.

This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves.  While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.

If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
  osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
  BSC/NITB, just like with real hardware

OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729.  If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route.  You
should see the GSMTAP frames in wireshark. 

On the OsmocomBB side, simply start the virt_phy binary.  It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile".  Once virt_phy is running, you can
start "mobile" just like with real hardware.  The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.

Everything from this point on is just normal.  You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work.  Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.

If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.

My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
  up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
  to different config files, ensuring that all related bits are set
  correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
  reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
  IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
  there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
  RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping

This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.

In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list