The Outreachy project has selected work on Debian packaging for Osmocom for the Dec 2017 to Mar 2018 Outreachy Interns
You can read the related announcement at the outreachy announce mailing list
Kira "kobr" Obrezkova will be working on this, with Debian developer Thorsten Alteholz as mentor.
Congratulations, Kira! Thanks to Thorsten Alteholz for mentoring as well as to Outreachy and its sponsors!
In Osmocom, we have made tremendous progress during 2016 and 2017 in re-structuring our code base, with a proper 3GPP AoIP interface between BSC and MSC, the split-up of OsmoNITB, the externalization of the HLR and full 3G integration. This has had lots of fall-out in terms of packaging, and it's important to have the new post-NITB architecture packaged properly in upstream Debian.
Outreachy provides three-month internships for people from groups traditionally underrepresented in tech. Interns are paid a stipend of $5,500 and have a $500 travel stipend available to them. Interns work remotely with mentors from Free and Open Source Software (FOSS) communities on projects ranging from programming, user experience, documentation, illustration and graphical design, to data science.
Heads up all OsmoBSC users: if you are deploying an osmo-bsc from osmo-bsc.git using the latest master branch (or nightly builds), you may notice voice streams not working anymore.
The reason is that OsmoBSC now supports intra-BSC handover (handover between separate BTS connected to the same BSC). To be able to redirect RTP streams between separate BTS, OsmoBSC now always requires an OsmoMGW instance to run alongside it.
Documentation on the Wiki and in the Manuals still needs to be updated, please bear with us until we get a chance to adjust those.
An OsmoMGW config example is
mgcp
bind ip 127.0.0.1
bind port 2427
rtp net-range 4002 16000
number endpoints 31
rtp-accept-all 1
If OsmoMGW is running on the same machine as OsmoBSC with MGCP at 127.0.0.1, OsmoBSC needs no further configuration and will find the OsmoMGW by default at 127.0.0.1 port 2427. More detailed OsmoBSC side config can be issued like:
msc
mgw remote-ip 127.0.0.1
mgw remote-port 2427
mgw endpoint-range 1 31
You can find OsmoMGW in the nightly (and "latest") builds as well as opkg feeds, it is installed by the osmo-mgw package and developed in the osmo-mgw.git repository.
The OsmoBSC change from which on we require an OsmoMGW is here
Previously, the higher level MGW would directly talk RTP to the BTS, which is now no longer the case. The BSC will always advertise its MGW's RTP ports towards the MSC. This means that the BTS can now be in a network segment that is not reachable by the MSC directly.
Starting today, Osmocom offers an osmocom:latest package feed with Ubuntu + Debian packages of the latest tagged releases of all Osmocom cellular infrastructure software.
Since early 2016, Osmocom has already been offering Nightly_Builds of the master-of-the-day of each individual projects git repository to enable users to utilize Osmocom software without having to build from source. However, by their very nature, nightly builds are volatile as they track each indiviudal development step. This is interesting for users who are testing latest developments or who need to track fixes introduced only very recently.
The new Latest_Builds only change whenever a new release tag is set in the respective source code repository, i.e. every few weeks to months for a given project. While this is not a long-terms supported release, osmocom:latest is a much more suitable choice for deployments.
As part of the NITB-Split and repository reorganisation, we have moved the GPRS code that used to live in openbsc.git to a separate repository.
Technically, the OsmoSGSN, GbProxy and GTPHUB never shared any code with osmo-nitb or the other circuit-switched code in openbsc.git. It was probably a bad idea to start writing the code in the same repository at all.
Some weeks ago, we started a separate osmo-sgsn.git repository for this code, and migrated the build jobs in jenkins as well as for the Nightly_Builds over.
Effective today, the GPRS components have been removed from openbsc.git. Please use osmo-sgsn.git from now on. Sorry for any inconvenience caused.
12 years after OpenGGSN was seemingly abandoned by its original creators, and 7 years after Osmocom adopted it, it is time for a significant change:
OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN.
We had already taken some baby-steps in the past by introduction of a CTRL interface as well as the use of libosmocore logging. However, my recent patches introducing a VTY interface and changing the configuration file format from the 'gengetopt' style to libosmovty based change the look+feel of the program significantly that it is a good point to rename.
After all, if command-line arguments and config file syntax are changing, documentation will also need to change and it becomes confusing to users to understand that depending on the version the documentation is correct or incorrect.
So from today on,
The introduction of the VTY interface comes with many new possibilities, such as
- multiple GGSN instances bound to different GTP IP addresses
- multiple APNs within each GGSN, each with different Address Pools and
tun-devices
- sophisticated logging configuration (syslog, file, stdout, telnet)
What's still missing:
- re-integrate kernel GTP-U support
- create OsmoGGSN VTY reference manual
- perl/python script to convert old config file to new config file format (any volunteers?)
Roadmap:
- IPv6 transport plane support (outer IP layer surrounding GTP/UDP)
- improved logging (ensure context is always included)
- libgtp: migration of kernel GTP-U support into libgtp (not just ggsn)
- libgtp: make PDP context hash table part of the 'gsn' structure
- once all expected ABI/API changes are done, rename libgtp to libosmo-gtp
In terms of maintenance, I don't want to continue to maintain OpenGGSN for much longer. We'll keep it around for some time and merge important security and/or bug fixes, but I won't accept new feature patches into OpenGGSN.
In order to facilitate the simpler use of the multi-voltage USB UART, an Annotated Pinout has been published.
Future PCB versions will have the signal names on the bottom layer silk screen (#2387), I'm sorry for not thinking of this for the first release already.
During the last couple of days, I've been working on completing, cleaning up and merging a Virtual Um interface (i.e. virtual radio layer) between OsmoBTS and OsmocomBB. After I started with the implementation and left it in an early stage in January 2016, Sebastian Stumpf has been completing it around early 2017, with now some subsequent fixes and improvements by me. The combined result allows us to run a complete GSM network with 1-N BTSs and 1-M MSs without any actual radio hardware, which is of course excellent for all kinds of testing scenarios.
The Virtual Um layer is based on sending L2 frames (blocks) encapsulated via GSMTAP UDP multicast packets. There are two separate multicast groups, one for uplink and one for downlink. The multicast nature simulates the shared medium and enables any simulated phone to receive the signal from multiple BTSs via the downlink multicast group.
In OsmoBTS, this is implemented via the new osmo-bts-virtual BTS model.
In OsmocomBB, this is realized by adding virtphy virtual L1, which speask the same L1CTL protocol that is used between the real OsmcoomBB Layer1 and the Layer2/3 programs such as Mobile and the like.
Now many people would argue that GSM without the radio and actual handsets is no fun. I tend to agree, as I'm a hardware person at heart and I am not a big fan of simulation.
Nevertheless, this forms the basis of all kinds of possibilities for automatized (regression) testing in a way and for layers/interfaces that osmo-gsm-tester cannot cover as it uses a black-box proprietary mobile phone (modem). It is also pretty useful if you're travelling a lot and don't want to carry around a BTS and phones all the time, or get some development done in airplanes or other places where operating a radio transmitter is not really a (viable) option.
If you're curious and want to give it a shot, I've put together some setup instructions at Virtual Um.
Yesterday we've reached a remarkable milestone: the new OsmoMSC has first subscribed a 3G as well as a 2G phone at the same time!
Recall the recent big developments in Osmocom:
- creating OsmoHLR to manage subscribers asynchronously and across voice and data realms,
- separating an OsmoMSC off OsmoNITB,
- creating a true asynchronous state machine driven VLR in OsmoMSC,
- adding UMTS authentication with Milenage,
- supporting IuCS (and IuPS) to enable hNodeB driven 3G in Osmocom,
- and last but not least adding a true A interface to OsmoMSC using our brand new SCCP/M3UA impementation.
After this work has reached a stage where we can subscribe phones, send SMS and call each other using AoverIP and 3G separately, the remaining big step was to combine all of this in the new OsmoMSC: can we talk both A over IP to our separate OsmoBSC as well as IuCS via OsmoHNBGW to a 3G hNodeB, at the same time?
Some patches are still in the queue, but since yesterday, the answer is a resounding: Yes!
Typical for a software engineer's mindset, the joy of reaching this milestone is immediately followed by an outlook of what is left open:
- Split the current / legacy openbsc.git repository in separate new projects and lay the OsmoNITB to rest.
- Rename our MGCP gateway (osmo-bsc_mgcp) to OsmoMGW and teach it to transcode between TRAU frames, RTP and the 3G IuUP to facilitate voice calls between all of legacy BTS models using E1, our "current" 2G BTSes talking RTP over IP as well as 3G hNodeBs that encapsulate IuUP in RTP.
- Polish to production quality, update the docs and package for various platforms.
These are exciting times to be part of Osmocom: big changes are finally converging, to open up new horizons for FOSS driven cellular network technology.
In the last few days, the Osmocom
gapk (GSM Audio Pocket Knife) has been extended with the following feature set:
- support of audio play-back via ALSA (standard Linux sound card drivers)
- support for Adaptive Multi-Rate (AMR)
- support for RTP payload formats for AMR, EFR HR-ETSI and HR-IETF
If all those new features are combined, you can use gapk as a RTP playback sink for any of the codecs used in (not only) Osmocom GSM networks. This is very useful for debugging, particularly if combined with a recent patch to OsmoBSC/OsmoNITB enabling the administrator to re-direct any BTS-originated RTP stream of an active call by issuing an IPA RSL MDCX command.
