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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)