Thosw new tagged/released versions contain half a year of work since the previous versions released in early November 2017. The primary focus was on bug-fixing and stabilization. Many bugs were introduced during the split of the NITB into individual network elements during 2017, and even more bugs exposed by our ever-growing test coverage, particularly in the Osmocom TTCN-3 test suites.

All-in-all, the post-NITB stack has gained a lot in terms of spec compliance, robustness, stability and features during this period.

You can find pew-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at Latest_Builds.

The developer performing the release related work was Pau Espin. Thanks!

As Ubuntu 18.04 (Bionic Beaver) has been released two days ago, Osmocom has enabled Binary_Packages builds for this new distribution in both nightly and latest. As a result, you can now use our binary package feeds on this most recent incarnation of Ubuntu just like on the other supported distributions.

This was relatively easy due to the openSUSE Build Service (OBS) immediately adding support for Ubuntu 18.04. so all we had to o is enable it, and fix up some minor failures. Thanks to OBS for making supporting new distributions very easy!

A team of Osmocom volunteers has continued the tradition of operating an experimental test network at the annual Chaos Communication Congress 34C3 held in Leipzig (Germany) from December 27 through December 30, 2017.

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.

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.

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.

We're happy to announce that there will be two talks related to the Osmocom cellular infrastructure projects at the upcoming OpenCellular Workshop held in Nairobi, Kenya on June 19 and June 20.

At the OpenCellular workshop hosted by iHub, technology and business leaders will share their insights and drive discussions around radio design, site planning, business models and many other topics on rural connectivity.

We're looking forward to meeting all parties involved in providing rural communications, as we consider the Osmocom cellular protocol stack a key factor in driving cost and innovation in connecting the next billion mobile subscribers.

The Osmocom core network landscape is transforming. Adding full UMTS Authentication support, paired with the 3G developments of the past year, has rocked the boat of the good old OsmoNITB. Here is why:

From previous 3G announcements1, you may already know that the OsmoNITB, the Network-In-The-Box, combines BSC, MSC and HLR (among other things), which has drawbacks. Our MSC code was nicely placed in a separate libmsc, but libmsc never stood on its own. From the start it always had its fingers deep in libbsc data structures. In 3G core networks, there no longer is a BSC, so we needed a clear interface to talk to libmsc, and make it not depend on libbsc. We do have a standalone OsmoBSC, so technically, it could talk to a standalone MSC implementation, instead of having both in the same program. Thus, on the 3G branch, we basically killed off the BSC part of OsmoNITB: the first step towards our brand new standalone OsmoMSC.

But what is a 3G core network without full 3G authentication? UMTS AKA2 was published in Release 1999 of the 3GPP technical specifications (R99) and provides the means for mutual authentication, usually using the Milenage algorithm. Since R99, SIM cards (USIM) not only verify their authenticity to the core network, they also expect the core network to verify its own authenticity, hence the term mutual authentication. 3G USIMs may fall back to pre-R99 authentication, but in general, 3G is expected to be synonymous with UMTS AKA. So far, Osmocom fell short of that.

We have had the Milenage algorithms implemented in libosmocore for years, but our stock OsmoNITB is unable to use it. The main reason: the subscriber database is incapable of managing UMTS AKA tokens. Another shortcoming of this database is that it runs synchronously in the OsmoNITB process: if it is locked or needs a bit longer, our entire core network stalls until the request is completed. And a third clumsy fact is that the OsmoSGSN cannot use OsmoNITB's subscriber database, duplicating the authorization configuration.

It made sense to solve all of these subscriber database problems in one effort, again trimming OsmoNITB, but this time at the other end. Enter stage the brand new OsmoHLR, a separate process managing the subscriber database:

Of course, the MSC needs to act as a GSUP client to use the separate OsmoHLR server. We needed to teach libmsc to handle GSUP requests asynchronously. In the 3GPP TS specifications, this is handled by the VLR, the Visitor Location Register. So far the VLR existed implicitly within OsmoNITB, basically as an in-RAM storage of subscriber data read directly from the database storage. But the VLR is more than that: it is specified to follow detailed state machines interacting with MSC and HLR, which allow, you guessed it, asynchronous handling of subscriber data. With the HLR moving to a separate process, we needed to implement a VLR proper. A generic finite state machine implementation has been added to libosmocore, and the specs' state machine definitions for the VLR have been implemented, supporting UMTS AKA right from the start.

Adding the new feature set had the logical consequence of profound code changes. In the 3G developments, we have for some time called the OsmoNITB-without-BSC a Circuit-Switched Core Network (OsmoCSCN). As it turns out, OsmoCSCN was merely a working title, it is already gone from code and documentation. Because, what do you get when you also strip from it the HLR? You get an OsmoMSC! (Technically, to accurately call it "OsmoMSC", we would also need to externalize the SMS storage3. It's on the todo list!)

By now it may be clear to you that OsmoNITB will not be around for long. But the transition away from OsmoNITB is not trivial: users have to get familiar with the new OsmoHLR. OsmoNITB's VTY configuration commands for subscriber management no longer exist. And, of course, our OsmoMSC cannot talk to OsmoBSC yet: to fully replace OsmoNITB with OsmoBSC + OsmoMSC + OsmoHLR, we also need a proper A-interface implementation on the OsmoMSC side. Even though OsmoNITB will stick around as a 2G solution until then, the move to an external HLR process in itself is a profound change in admin processes.

In consequence, we have taken yet another profound decision: we will not merge these new developments to openbsc.git's master branch. To clearly mark the move to the new Osmocom core network topology with the VLR-HLR separation and support for 3G by the new OsmoMSC program, we will create a brand new git repository that will be the focus of ongoing development. The current openbsc.git repository will remain as it is; it may see backports in urgent cases, but in essence it will be laid to rest and clearly marked as legacy4. Before we can flip that switch, we still need to sort out some petty details of what should move where, and then agree on a good name for the new repository. Until then, 2G with UMTS AKA support will live on the openbsc.git vlr_2G branch, while 3G with UMTS AKA support will live on the vlr_3G branch. The vlr_2G branch still features an OsmoNITB, but with an external OsmoHLR. The vlr_3G (previously sysmocom/iu) extends the vlr_2G branch to transform OsmoNITB to OsmoMSC and support the IuCS interface.

What about UMTS AKA on packet-switched connections? OsmoSGSN has had a GSUP client for quite some time now5. In fact GSUP was initially named "GPRS Subscriber Update Protocol" -- the G now re-coined to "Generic". Adding UMTS AKA to the OsmoSGSN was a breeze. You don't even need a special branch for that, it's already merged to master.

UMTS AKA is not limited to 3G. Any 2G network that indicates compliance with Release 1999 in the System Information bits can benefit from mutual authentication, and so does Osmocom, now.

To get assistance, you may ask on the mailing list, or contact for example sysmocom for professional support and development services.

With the help of Osmocom's sponsors and supporters, including but not limited to NLnet and sysmocom, we were able to invest due time and effort and have reached a remarkable milestone: UMTS AKA is now supported on Osmocom 3G as well as 2G networks, using Free Software all the way. Thank you for making this possible!

3 So far our OsmoMSC has a local sqlite database to manage SMS persistently, which is still a potential source of stalling due to synchronism.

4 Another reason for moving to a new repository: OpenBSC was the early name of the project, but by now the lack of "Osmo" in its name is a source of confusion among new users, since "OpenBSC" wrongly suggests affiliation with the unrelated OpenBTS project.