Upcoming Osmocom talks at OpenCellular Workshop in Nairobi

Added by laforge about 5 hours ago

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.

The two talks about Osmocom will be on:

  • Osmocom: Open-source cellular stack for 2G and 3G by Harald Welte, Osmocom and sysmocom co-founder
  • End to end testing of the Osmocom stack by Pau Espin Pedrol, engineer at sysmocom

You can learn more about the event (including venue, schedule, etc.) at

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.

Osmocom 3G and 2G Now Support Milenage Authentication

Added by neels 2 months ago

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:

  • OsmoHLR has full UMTS AKA support.
  • It serves GSUP to both our MSC and SGSN.
  • As a separate process, the HLR now runs fully asynchronously.

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.

Here is an overview of the current landscape:

Legacy 2G without UMTS AKA
openbsc.git master

                   │ OsmoNITB               │
  ┌─────┐          ├╌╌╌╌╌┐ ╔═════╤════════╗ │
  │ BTS │ <-Abis-> │ BSC ┆ ║ SMS ┆ subscr ║ │
  │     │          └─────┴─╨─────┴────────╨─┘
  │     │
  │     │          ┌──────────┐         ┌──────────┐
  │ PCU │ <-Gb---> │ OsmoSGSN │ <-GTP-> │ OpenGGSN │
  └─────┘          └──────────┘         └──────────┘

2G with UMTS AKA
openbsc.git vlr_2G

                   │ OsmoNITB            │
  ┌─────┐          ├╌╌╌╌╌┐ ╔═════╗ ┌╌╌╌╌╌┤          ┌────────────┐
  │ BTS │ <-Abis-> │ BSC ┆ ║ SMS ║ ┆ VLR │ <-GSUP-> │ OsmoHLR    │
  │     │          └─────┴─╨─────╨─┴─────┘          │            │
  │     │                                           │            │
  │     │          ┌─────────────────────┐          │ ╔════════╗ │
  │ PCU │ <-Gb---> │ OsmoSGSN            │ <-GSUP-> │ ║ subscr ║ │
  └─────┘          │                     │          └─╨────────╨─┘
                   │                     │          ┌──────────┐
                   │                     │ <-GTP--> │ OpenGGSN │
                   └─────────────────────┘          └──────────┘

3G with UMTS AKA
openbsc.git vlr_3G

                                               │ OsmoMSC             │
  ┌───────────┐         ┌───────────┐          │       ╔═════╗ ┌╌╌╌╌╌┤          ┌────────────┐
  │ 3G hNodeB │ <-Iuh-> │ OsmoHNBGW │ <-IuCS-> │       ║ SMS ║ ┆ VLR │ <-GSUP-> │ OsmoHLR    │
  └───────────┘         │           │          └───────╨─────╨─┴─────┘          │            │
                        │           │                                           │            │
                        │           │          ┌─────────────────────┐          │ ╔════════╗ │
                        │           │ <-IuPS-> │ OsmoSGSN            │ <-GSUP-> │ ║ subscr ║ │
                        └───────────┘          │                     │          └─╨────────╨─┘
                                               │                     │          ┌──────────┐
                                               │                     │ <-GTP--> │ OpenGGSN │
                                               └─────────────────────┘          └──────────┘

2G with UMTS AKA and 3G support are not packaged yet. To use them, you need to build the software from source.

  • For OsmoNITB with 2G UMTS AKA, you need to build openbsc.git using the vlr_2G branch.
  • For 3G including UMTS AKA support, refer to the 3G wiki page.

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!

1 News post: 3G Voice Works

2 Universal Mobile Telecommunications System, Authentication and Key Agreement protocol

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.

5 See config item auth-policy remote.

Call for accelerate3g5 Proposals Concluded

Added by neels 3 months ago

The lucky receivers of a free nano3G femto cell sponsored by sysmocom have been contacted.
The selected projects will be documented at the accelerate3g5 wiki page.
If your project has been selected, kindly follow the instructions found there and mark the start of your project.

We are glad to have reached many new community members and are looking forward to seeing your projects evolve.
Here is a huge Thank You to all contestants from the Osmocom community and the sysmocom team!

First OsmoCon Conference on April 21st, 2017

Added by neels 4 months ago

The OsmoCon 2017 is the first technical conference for Osmocom users, operators and
developers and will be held on April 21st, 2017 in Berlin, with kind organizational
support by sysmocom s.f.m.c. GmbH.

For the first time ever, the Osmocom Conference brings together users, operators
and developers of the Osmocom Open Source cellular infrastructure projects, such as
OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others.

Join us for a day of presentations and discussions with the main developers behind
Open Source Mobile Communications, as well as commercial and non-profit users of
the Osmocom cellular infrastructure software.

Read more on our OsmoCon 2017 wiki page

Join 3.5G Osmocom Development, With Your Own Free Femtocell

Added by laforge 5 months ago

Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking
on the next level: 3G/3.5G. The key to running your own 3G network is to obtain
actual 3G cell hardware -- here is an exciting opportunity to get started:

No less than 50 femtocells will be given away for free by sysmocom, one of the
main drivers of the Osmocom project. To receive a free 3G femtocell, tell
sysmocom how you will help the Osmocom project drive 3.5G forward if you had
one, before the end of January 2017. This marks the launch of the 3.5G
Acceleration Project, backed by the Osmocom community. Join us!

Find further details on the 3.5G Acceleration Project and receiving your own 3G
femtocell for free at

Discontinuous Transmission (DTX) Support

Added by laforge 10 months ago

Back in May, Osmocom developer Max Suraev has been working on implementing both uplink and downlink DTX support in the Osmocom GSM stack, most notably OsmoBTS and the OpenbSC libbsc (OsmoBSC and OsmoNITB).

The purpose of uplink DTX is to
  • reduce uplink interference with other (remote) cells on the same ARFCNs
  • conserve battery power in the mobile station (lower transmit duty cycle)
The purpose of downlink DTX is to
  • reduce power consumption and heat dissipation on the BTS
  • reduce downlink interference with other (remote) cells on the same ARFCNs

Downlink DTX is only permitted on secondary trnansceivers, i.e. on those TRX that do not carry the FCCH/SCH/BCCH beacon.

All related patches to OsmoBTS and OpenBSC have meanwhile been merged. You can use the dtx uplink [force] and dtx downlink VTY commands at the BTS node to enable the features.

Support for dynamic TCH / PDCH switching

Added by laforge 10 months ago

The classic ETSI/3GPP specifications about GSM, particularly those related to A-bis, assume a fairly static allocation of the timeslots of a TRX inside a BTS. This means that the administrator configures each timeslot in the BSC to be one of the permitted channel combinations, for user traffic that's either SDCCH, TCH/F, TCH/H or PDCH.

The Osmocom project software, including OsmoBSC, OsmoNITB, OsmoBTS and OsmoPCU followed this static timeslot allocation when first implementing the related standards and systems.

This static allocation, particularly between circuit-switched calls and packet data leads to sub-optimal use of available (scarce) resources. What if there are no voice calls, but a high demand for packet data? Or why not (as an operator policy) provide more voice channels on demand, at the expense of packet data?

In 2013 years, Osmocom developer Andreas Eversberg did a BSC-side implementation of dynamic PDCH switching in OsmoNITB. However, related code unfortunately never made it to Osmocom master and it exposed some bit-rot over the years.

Neels Hofmeyr has recently picked up those patches, extended, fixed and forward-ported them to current master. They were subsequently merged. Corresponding changes inside OsmoBTS have been made with osmo-bts-sysmo and osmo-bts-litecell15, and have also been merged. Implementation for osmo-bts-trx is still ongoing (but difficult due to the desolate state of osmo-bts-trx with lack of a current maintainer).

With this first series of changes, only switching between TCH/F and PDCH is possible. Neels is currently working on making TCH/F, TCH/H and PDCH dynamic, resulting in even more flexibility even among full-rate and half-rate voice channels.

Osmocom Wireshark improvements for AMR and Osmux

Added by laforge 10 months ago

Over the past weeks, Osmocom developer Daniel Willmann has been working on various improvements/extensions of the popular wireshark dissector in the context of using it with (Osmocom) GSM networks.

The extensions include:
  • support for playback of AMR from captured RTP streams (using libopencore-amrnb)
  • extend RTP jitter/delay statistics for AMR-RTP as used in A-bis/IP and A/IP
  • a new dissector for the Osmux (Osmocom Multiplex) protocol
  • statistics support for the Osmux protocol.

The above features allow for much better analysis of any voice plane related issues in Osmocom GSM networks.

All related changes can be found in and we are actively submitting them to mainline wireshark at this point.


Also available in: Atom