Distributed GSM: Distributed GSM / Multicast MS Lookup

Added by neels 16 days ago

When building communal mobile telephony networks, traditional core network infrastructure poses a fundamental challenge: it is built on a centralised paradigm and requires highly available network links at all times. Osmocom is currently implementing Distributed GSM (D-GSM), a concept that is a far better match for a decentralised cooperation of independent communal mobile networks, who don't have the luxury of ultra-reliable networking infrastructure.

When several communities, who have each built their own independent mobile network infrastructure, would like to join their services to allow calling, messaging and roaming across sites, the usual answer would be a centralised gateway entity to locate subscribers, and, naturally, a central authority governing all participating communities. That is a challenge, not only socially and administratively, but is also quite impractical when the network links between communities tend to be unstable or expensive.

For example, when a phone has just moved to a different coverage area, but weather conditions impair the hypothetical wireless link to a central subscriber database, the phone becomes unreachable, even for callers in the local vicinity where connecting a voice call would not have posed any problem.

A solution that comes to mind is a series of mirrors of that central database, one for each site. However, that requires database synchronisation, which can lead to a considerable delay. After a subscriber has moved to a different coverage area, practice shows that it can take something like half an hour until a site notices that a given subscriber has lost reception to its network, and until it has synchronised that fact with other sites. For that duration, callers are unable to get the accurate current position of the person they are trying to reach. Imagine a subscriber located just between two coverage areas, often switching back and forth between them at random -- service would be disrupted probably for most of the day.

To solve these challenges, we are implementing D-GSM as part of the Osmocom CNI stack. D-GSM is a close cooperation with/for Rhizomatica [1], an organization of community owned operators providing mobile telephony service in numerous rural communities in Oaxaca, Mexico. We are aiming to overcome common practical problems that their current mobile networks are experiencing, improving availability and stability. The results of this work are naturally contributed to the Osmocom project and are freely available for anyone to use, under terms of the GNU AGPL. The implementation of D-GSM is mostly funded by the Mozilla MOSS grant [2], and carried out by sysmocom-employed [3] Osmocom contributors. Thank you for making this possible!

The solution we are implementing is inspired by the actual social and physical structure that we aim to service: each village in Oaxaca has their own fully independent core network stack, and each community is fully in charge of their own infrastructure. There is no central authority governing across communities, by deliberate choice. Because the infrastructure is operated in remote rural areas, often from a pole on a hill crest running on solar panels, and with directional wifi over large distances, network links between villages can be unstable.

D-GSM is a relatively simple, low impact addition to an Osmocom CNI, which is designed to match Rhizomatica's situation:

  • it de-centrally resolves the current location of a subscriber (by MSISDN or IMSI),
  • provides service addresses to directly reach the subscriber (so far SIP, SMPP and GSUP; freely extendable), and
  • it proxies HLR services to provide roaming across villages.

The key technology that enables D-GSM in Osmocom is called mslookup, which is built on multicast DNS -- quite similar to the concept of service discovery in zeroconf networking [4].

Whenever calling or messaging a particular phone number (MSISDN), a multicast request is dispatched to all connected sites. Each site where that subscriber has recently been attached replies with the age of the local record, and the youngest aged response wins.

Figure 1: mslookup for connecting subscribers: Alice is visiting village C; a phone call gets routed directly to her current location independently from her resident village infrastructure

Furthermore, when a subscriber visits a site where its IMSI is not known, mslookup can find the IMSI's home HLR location, and OsmoHLR can provide roaming service by transparently proxying to the remote site's HLR.

Figure 2: mslookup for roaming: Alice visits village B; she can attach to the local mobile network, which proxies HLR administration to her home village.

By nature of multicast lookups, D-GSM is highly resilient against single sites or links becoming temporarily unavailable. Service between still reachable sites simply continues; Service to a disconnected site resumes as soon as it becomes reachable again. Even adding a new site to the communal network is basically done by setting up a network link with multicast routing, and by choosing distinct naming for the local GSUP services.

OsmoHLR is the workhorse for our D-GSM implementation. In fact, no other Osmocom CNI program's code base besides OsmoHLR itself needs to be touched for implementing D-GSM:

  • OsmoHLR answers all service endpoint requests for locally attached subscribers, as configured in osmo-hlr.cfg;
  • For IMSIs it doesn't find in the local db (outbound roaming), OsmoHLR takes care of requesting the home HLR of the IMSI and of proxy-routing HLR operations there; and
  • OsmoHLR answers requests for all IMSIs it finds in the local db (inbound roaming).

A D-GSM enabled OsmoHLR will soon be available on the osmo-hlr.git master branch -- the implementation is currently undergoing peer review to be merged to the master branch.

The elements that request cross-site service for voice and SMS (currently) are:

  • a custom dialplan implementation for a PBX connected to OsmoMSC via OsmoSIPConnector (we're using FreeSWITCH [5] in the lab), and
  • a custom SMPP handler connected to OsmoMSC,

both of which are available as example implementations in osmo-hlr.git/contrib/dgsm [6] / [6].

This list is likely to be enhanced with further example integrations, like more FLOSS PBX integrations, or SMS-over-GSUP transport instead of SMPP. That's up to the Osmocom community to implement and contribute. If you need more information, take a look at OsmoHLR's user manual [7] / [7].

All of the above technology is fully functional in our lab setup right now: we are routing Location Updating requests, calls, and SMS to the right site, entirely without the need for centralised administrative infrastructure.

A further aim of D-GSM is providing roaming service even though the link to the respective home HLR is unstable or altogether down. The solution is adding a persistent local cache to the HLR proxy, which we are going to implement next.

D-GSM is, technologically, a relatively trivial enhancement of the Osmocom CNI. Yet it brings an entirely new paradigm to mobile core network infrastructure: It allows independent mobile core network stacks to provide voice, SMS and roaming services cooperatively, without the need for centralised infrastructure or administration authority, and is resilient against unstable network links between sites. It elegantly provides ad-hoc service for subscribers, who are free to move across all coverage areas, and it allows sites to dynamically join or leave the cooperative network without the need for configuration changes nor administrative decisions at other sites.

It also has been and is great fun to implement a versatile enhancement that, for a change, completely surpasses 3GPP specifications, and has the potential to change the fundamental shape of communal mobile coverage. We're looking forward to see D-GSM in action in Oaxaca, soon.


OsmoPCU: September/October OsmoPCU code sprint

Added by laforge 27 days ago

This is a (late) update about the September/October 2019 activities regarding improvement of OsmoPCU and OsmoSGSN functionality and reliability.

Work has been done, among others, on #4111, #3828, #4228, #3827, #4247, #4102, #3995, #3969, #4029, #1977, #4024, #2406, #4204, #2857, #3922, #4048, #4173, #3727, #43, #4058, #2408, #2955

Unfortunately, OsmoPCU is still one of the least loved projects in the Osmocom universe. Not many people contribute to it, and there are very few commercial users wanting to contribute either financially or by helping with closing some more of the open issues :/

OsmoSTP: OsmoSTP features added (traffic-mode load-share, ...)

Added by laforge 27 days ago

OsmoSTP has received a variety of new features over the last few weeks.

This includes:
  • operation of STP in M3UA ASP role (normally a STP operates in SG role): #2005
  • operation as STP in STCP client/connect role (normally a STP operates in SCTP server/bind): #2005
  • support for SCTP multi-homing with configurable IPs on local and remote end: #3608
  • make point-code insertion into SCCP optional at for IPA ASPs: #4219
  • dynamic creation of ASPs within an IPA/SCCPlite AS: #4218
  • support traffic-mode load-share (in M3UA and IPA): #4220

We also discovered a number of drive-by bugs which were encountered while working on the implementation of the above, see #4247, #4236, #4238, #4234, #4239, #4233, #4235, #4232 - most of which are already fixed.

We furthermore have created a TTCN-3 test suite for OsmoSTP covering those parts that the existing nplab m3ua and sua test suites don't cover. Test results of all STP related test suites can be seen (as usual) in our jenkins:

Related developments have been funded by a commercial user of OsmoSTP and implemented by pespin and laforge at sysmocom. We rely on funding for maintenance, feature development and bug fixing.

m.2 (NGFF) WWAN modem USB breakout board: Second prototype of m.2/NGFF modem breakout functional

Added by laforge 27 days ago

We had recently received the prototype v2 of the m.2/NGFF WWAN modem breakout board and are happy to report that it immediately worked for both USB 3.0 super-speed as well as for PCIe. All debug results and reworks from v1 have been incorporated in this v2.

Design validation has completed, which means a first manufacturing batch is in up in the pipelnie, and we expect boards to become available from the sysmocom webshop in some 4-6 weeks (maybe a bit later due to christmas holidays).

As usual, as the project is an Open Source Hardware, and anyone can go ahead and build their own boards, see for the design files.

fun fact: The part most difficult to source is the M2x3 wide-flat-head screw that holds the M.2 card in place.

Cellular Network Infrastructure: Binary packages for Raspbian 10 and Ubuntu 19.10

Added by laforge 29 days ago

Retro-Networking / BBS-Revival: Retro-BBS plans for #36C3

Added by laforge about 2 months ago

At 36C3, the Osmocom Retro-bBS project will be running a PBX with analog lines and ISDN S0 ports as well as a RAS Server in order to host multiple BBSs and enable attendees to connect modems/ISDN-TA to their computers and dial in to the local BBSs

Current status and plans are summarised at - please do join us if you'd also like to revive the good old BBS days!

SIMtrace 2: Card Emulation with SIMtrace2 boards

Added by tsaitgaist 2 months ago

The SIMtrace project has from beginning on been designed to not only monitor the communication between a card and the reader (e.g. a SIM and a phone), but also to emulate cards. This card emulation functionality has never been implemented, at least not by the osmocom community, and the project has been hibernating for quite some time. A year ago, the SIMtrace project has been revived. The now old and deprecated micro-controller has been replaced with ARM Cortex-M, but the initial design remains. This change forced us to rewrite the code from scratch, and this is now the SIMtrace 2 project. Monitoring the communication is still available, even with increased stability, but this fresh start was to opportunity the also implement the other long awaited features.

Card emulation is finally there. Is it currently in it's beta phase, but has already been successfully tested. It can even be used in combination with the recent osmo-remsim project, allowing to use multiple cards at remote locations. While it is not completely emulating a card since it only forwards the traffic to a card present in another reader, we are currently working on also providing this functionality. So, feel free to try it out yourself, and let us know using the SIMtrace mailing list if you find any issues. The card emulation wiki article will be updated as we continue on our journey to make SIMtrace the tool it was intended for from beginning on.

Cellular Network Infrastructure: August 2019 Osmocom CNI releases

Added by laforge 3 months ago

It seems we forgot the release announcement in early August:

The Osmocom project has released new version of the CNI (Cellular Network Infrastructure) software, including OsmoTRX, OsmoBTS, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN.

Those new tagged/released versions contain four months of work since the previous versions released during April 2019. The primary focus was on bug-fixing and stabilization as well as some major new features, such as inter-MSC-handover support in osmo-msc.

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

List of tagged versions and link to related ChangeLog

Project Version Changelog
libosmocore 1.2.0
libosmo-abis 0.7.0
libosmo-netif 0.6.0
libosmo-sccp 1.1.0
OsmoTRX 1.1.1
OsmoBTS 1.1.0
OsmoBSC 1.5.0
OsmoMSC 1.5.0
OsmoHLR 1.1.0
osmo-mgw 1.6.0
osmo-sip-connector 1.3.0
OsmoSTP 1.1.0
OsmoSGSN 1.5.0
OsmoGGSN 1.4.0

Noteworthy Changes

Misc / Common

  • debian packages now have -doc sub-packages containing the corresponding user and VTY reference manuals of each program.
  • various robustness fixes
  • support LAPDm payloads with more than 200 bytes
  • fsm: Allow millisecond granularity in osmo_fsm built-in timer
  • CBSP (Cell Broadcast Service Protocol) implementatin in libosmogsm
  • vty parser fixes: don't pass incomplete arguments to vty funcs
  • work around gcc bug with gcc < 7.3.0 on ARM related to thread-local storage
  • shared IPA keep-alive FSM in libosmocore; use it wherever possible
  • libosmo-netif Stream client: fix disconnection logic


  • new protocol (TRXDv1) support, mainly for passing C/I value from TRX->BTS->PCU for rate adaptation
  • proper counting of under/overruns
  • LimeSuite stability improvements (recovery / re-synchronization after drop-outs)
  • various internal refactoring / code de-duplication
  • fix ARM VFP4 convolution
  • LimeSuite: automatic detection of device type and device specific gains


  • Various Abis OML protocol conformance fixes
  • handling of GPRS SUSPEND (from DCCH -> PCU)
  • Full CBCH (Cell Broadcast Channel) support, both basic and extended
  • RSL CBCH LOAD INDICATION for CBCH flow control
  • Fix RACH load percentage computation
  • clear GPRS indicator form SI3 when PCU is not connected
  • fix (so far ignored) MS power control in RSL CHANNEL ACTIVATION
  • osmo-bts-oc2g specificx
    • systemd service file + example config installation
    • status LED fixes
    • nominal transmit power fix
    • generate failure event report if calibration data missing
  • osmo-bts-trx specifics
    • TRXDv1 protocol support
    • 11-bit RACH support


  • Various AMR rate handling related fixes between AoIP and Abis
  • AMR: Signal usage of octet-aligned or bandwith-efficient mode to MSC
  • various inter-BSC hand-over related fixes for AoIP
  • various manual updates, including documentation for 3G/4G neighbor cells, OSMUX, ...
  • always default to octet-aligned AMR mode
  • keep per-BTS statistics about RACH utilization
  • re-introduce support for IPA-encapsulated MGCP (used with osmo-bsc_nat)
  • OSMUX support with AoIP (we only supported it with SCCPlite so far)
  • support assigning TCH/x in signaling mode


  • Add SGs interface for CSFB (circuit switched fall-back) and SMS-over-SGs
  • various SMS and USSD handling related fixes
  • include libsmpp34 memory allocations in talloc reports
  • Fix SMS transmission over Iu (use SAPI3)
  • allow user to disable retrieval of IMEISV early
  • allow transmission of IMEI to HLR (for subscriber-create-on-demand)
  • support inter-BSC hand-over
  • support inter-MSC hand-over
  • do not force encryption on UTRAN/Iu
  • OSMUX support with AoIP


  • document --db-upgrade command line argument
  • optionally store IMEI in subscriber table (for non-standard subscriber-create-on-demand)
  • support routing of GSUP messages between clients (MSCs) for inter-MSC hand-over

OsmoMGW (and libosmo-mgcp-client)

  • Add config option to use RFC5593 for GSM HR frames (we normally use ETSI TS 101318 format)
  • SDP parsing related fixes
  • Support OSMUX configuration via MGCP (activated via BSC and MSC)


  • support international Caller-ID
  • support emergency calling
  • handle SIP re-invite

OsmoSTP (and libosmo-sigtran)

  • enable statsd export
  • fix bug when saving config file (pointcode+mask of route)
  • enable memory usage debugging via talloc introspection


  • various parser correctness imporvements for LLC
  • send Iu Release Command upon Attach Complete
  • send Service Reject when no PDP contexts available
  • fix GTP echo behavior
  • require GMM authentication by default

OsmoGGSN (and libgtp)

  • various PCO handling related improvements/fixes
  • minimalistic PAP support during PDP context activation
  • fix missing GTP-C re-transmission
  • Introduce new pdp APIs (and deprecate old ones) to support multiple GSN

gr-osmosdr: gr-osmosdr maintainer needed

Added by laforge 3 months ago

The original author and maintainer of gr-osmosdr (Dimitri horiz0n Stolnikov) has lost time and/or interest in maintaining gr-osmosdr. That's very sad, but it is a fact that people have a limited amount of time, and priorities change. We'd like to thank Dimitri and all other gr-osmosdr developers/contributors for what they have done so far.

We're publicly calling for some other community member[s] to step up and become maintainer[s] of gr-osmosdr.

Who is interested in gr-osmosdr and willing to maintain it, possibly in a team with other interested folks?

The original related mailing list post can be found at - it is best to follow-up there in case you are interested and/or have comments.

Ericsson RBS 6xxx: Presentation on commercial cellular base station technology

Added by laforge 3 months ago

On September 10, 2019 Osmocom founder Harald "LaF0rge" Welte gave a presentation as part of the Datengarten series of lectures at the Chaos Computer Club Berlin.

The abstract of the talk is:

In today’s hyper-connected society, everyone constantly uses their smartphone, which in turn uses the commercial cellular networks (from 2G/GSM to 4G/LTE) in order to achieve connectivity. However, contrary to WiFi technology, even most technology-minded people don’t have much of an idea how the infrastructure behind those cellular networks looks like. This talk does not cover the architecture and protocols of underlying cellular systems, but focuses on the physical side of things: what are the typical components of cellular base stations? what are their key functionalities? how did cellular base station technology evolve during the past 20 years? how do we expect cellular base stations to change in the [near] future? We will not cover DIY or hobbyist projects here, but the actual technology deployed in the field by real-world commercial operators.

If you're interested in the presentation, feel free to check out:

Also available in: Atom

Add picture from clipboard (Maximum size: 48.8 MB)