Open Source Mobile Communications

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

Those new tagged/released versions contain five months of work since the previous versions released during August 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.3.0	http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.3.0
libosmo-abis	0.8.0	http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=0.8.0
libosmo-netif	0.7.0	http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=0.7.0
libosmo-sccp (+ OsmoSTP)	1.2.0	http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.2.0
osmo-iuh (+ OsmoHNBGW)	0.6.0	http://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=0.6.0
OsmoTRX	1.2.0	http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.2.0
OsmoBTS	1.2.0	http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.2.0
OsmoPCU	0.8.0	http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=0.8.0
OsmoBSC	1.6.0	http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.6.0
OsmoMSC	1.6.1	http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.6.1
OsmoHLR	1.2.0	http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.2.0
OsmoMGW	1.7.0	http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.7.0
OsmoSIPConnector	1.4.0	http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.4.0
OsmoSTP	1.1.0	http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.1.0
OsmoSGSN	1.5.0	http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.5.0
OsmoGGSN	1.5.0	http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.5.0
OsmoPCAP	0.1.2	http://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.1.2
osmo-gsm-manuals	0.3.0	http://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=0.3.0

Noteworthy Changes¶

Misc / Common¶

• libosmocore: logging (and other subsystem) improvements for multi-thread processes (like osmo-trx)
• libosmocore, libosmo-netif, libosmo-sccp: multi-address (multi-homing) support (multi-homing) and configure flags for libsctp (--enable-libsctp)
• libosmocore: integration of libusb in libosmocore's main loop (--enable-libusb)
• libosmocodec: new generic Error Concealment Unit abstraction
• libosmovty: Several crash fixes and improvements regarding command parsing, node tracking, etc.
• libosmogsm: add support for XOR authentication
• libosmo-abis: DAHDI support fixes and improvements. It is now enabled by default (--enable-dahdi)
• osmo-iuh: First version of libosmo-sabp now available, containing SABP ASN.1 from 3GPP TS 25.419 V11.1.0
• osmo-iuh: First version of OsmoHNBGW User Manual now available.
• Add code coverage support
• port most python scripts to use python3 (python2 will become deprecated soon)
• Improve reproducibility, fix sporadic failures of some tests

OsmoTRX¶

• Improved robustness all along the code, fixing several crashes and regressions, avoiding unnoticed underrun events, etc.
• Lots of logging improvements (use libosmocore multi-thread lock API, print channel, new log categories, support libuhd's >=3.11 logging system, etc.)
• Several fixes in TRXDv1 and TRXC (avoid dropping ul idle indications, wrong responses on some CMDs, etc.)
• Improved performance in some specific cases (Enable EDGE detection only on PDCH timeslots)
• Multi-arfcn improvements: ARFCN setup verficiation (RXTUNE/TXTUNE), code cleanup
• vty: Simplify filler burst settings and improve help and readability

OsmoBTS¶

• Increased robustness and small fixes and improvements all over the code
• Several fixes and improvements in PCU interface: fix endian-swapped CellID, forward ETWS Primary Notification, set correct ARFCN, etc.
• New improved generic MS Power Control Loop available for all BTS variants ("ms-power-control osmo")
• Migrate to use new libosmocore's generic ECU abstraction
• Several fixes and improvements for measurement reports.
• vty: add "logging filter l1-sapi"
• bts-trx: Fix several inconsistencies in TRX setup and lifecycle management of each TRX, clock availability, etc.
• bts-trx: Improvements thanks to information available from TRX using TRXDv1 (C/I, ToA, etc.)
• bts-trx: Improvements handling PDCH: fix handling of PTCCH/U and PTCCH/D logical channels, detect TSC for Access Burstsm etc.

OsmoPCU¶

• Improve User Manual documentation
• Forward ETWS Primary Notification to MS
• Several crash, assertion fixes and robustness improvements
• GSMTAP support improved, with more categories and fixes on existing ones
• Move some of the existing timer infrastructure to use osmo_tdef
• PTCCH support added
• bssgp: do not reject SUSPEND ACK / NACK messages
• vty: fix command 'show tbf all': properly filter TBFs

OsmoBSC¶

• Cell Broadcast: CBSP and CBCH scheduling support
• SMSCB: Send ETWS primary Notification/Warning
• Fix RSL connection timeout for TRX other than first one
• Send IE MS Power Param during CHAN ACT (to osmo-bts only, to enable Autonomous MS Power Control Loop in BTS)
• Decode classmark of MS and infer its the maximum MS Power Control level, then tell the BTS through MS PWR CTRL message
• Support SCTP multi-homing in AoIP, lots of sigtran improvements (thanks to new libosmo-sccp)
• Several crashes fixes, robustness and logging improved

OsmoMSC¶

• Improvements in SGs interface and CSBF
• Several crash fixes, memory leak fixes, robustness and logging improved, specially during Call Control
• MNCC v6: add optional SDP to the socket protocol. Now SDP can be passed SIP<->MSC<->MGW.
• Improved counter documentation
• Fix SM-RP-OA encoding for MO SMS over GSUP
• Implement a VTY global switch on the network to disable call waiting ("[no] call-waiting")
• Support SCTP multi-homing in AoIP, lots of sigtran improvements (thanks to new libosmo-sccp)

OsmoHLR (and libosmo-gsup-client)¶

• Add --db-check program option
• Update tb dv schema v4 (and lots of infra added to test schema update)
• AUC: Add support for setting the AMF separation bit to '1' for EUTRAN
• Make tests more robust: return codes on mipsel and alpha archs, test_nodez.vty expectancies, etc.
• Several crash fixes and increased robustness

OsmoMGW (and libosmo-mgcp-client)¶

• Improvements in codec parsing and management
• Several crash fixes, memleak fixes and increased robustness

OsmoSIPConnector¶

• MNCC v6: add optional SDP to the socket protocol
• logging from sofia: add missing newline
• Fixes in systemd's osmo-sip-connector.service dependencies
• Several robustness improvements

OsmoSTP (and libosmo-sigtran)¶

• Introduce SCTP multi-homing (multi address socket) support
• Support for all SS7 traffic modes: override, load-share, broadcast
• Dynamic ASP creation in AS for IPA connetions (identified by IPA unit id)
• Configure freely IPA/SCTP links as client or server, and M3UA link role as SGW or ASP
• osmo_sccp_simple_client(): use sccp instance index 0 instead of 1
• A lot more other SS7 protocol stack fixes and improvements

OsmoSGSN¶

• File/directory structure cleanup
• Initial OsmoGbPROXY user manual
• Fix of some long standing bugs and crashes
• LLC: Don't use hard-coded N201-U / N201-I values in XID
• Improved Iu/RANAP support and related fixes
• Logging improvements
• Migrate timers to osmo_tdef
• gtp: Drop related pdp contexts on echo timeout against GGSN
• Lots of improvements in (P)MM state FSMs: related timers, actions, etc.
• Gb: implement PS Paging when MS is MM_STANDBY

OsmoGGSN (and libgtp)¶

• Implement echo req/resp and recovery
• libgtp: Manage queue timers internally
• libgtp: Remove packets in tx queue belonging pdp being freed
• Improvedd logging
• Some IPv6 related fixed
• Several crash fixes and improved robustness

Osmocom founder LaF0rge has presented a talk titled SIM Card Technology from A to Z at the 36th annual Chaos Communication Congress

The talk tries to be an in-depth technical introduction into various aspects of SIM cards, ranging from relevant standards, electrical aspects, protocols, command set, operating systems all the way up to SIM toolkit, proactive SIM and also slightly touch eSIM.

If you're interested, you can find the following related resources:

• Slides in PDF format
• Video Recording on media.ccc.de

The Osmocom Retro-Networking / BBS-Revival project has successfully been operating at the 36th annual Chaos Communication Congress where it was known as the Retronetworking / BBS-Revival Assembly.

At this assembly, we operated our Dialup_Network_In_A_Box setup, providing both analog telephone lines as well as ISDN BRI (S0) interfaces for dial-up. We could verify that the physical layer (telephony) was working as expected, and had a variety of demonstrations:

• dial-up to a variety of (ANSI) BBSs from TELIX on MS-DOS 6.22
• dial-up to a RIPscrip BBS (ACiD Underworld 2 from RIPterm on Novell DOS 7
• dial-up to a BBS from a Datenklo (DIY accoustic coupler with 300 bps)
• dial-up internet access using PPP over analog modem (Interfax at 28.8 kbps) lines
  • tested from Windows 95
• dial-up internet access using PPP over ISDN lines
  • tested from Windows 2000 with 1 B-channel but also bundling up to 3 B-channels resulting in blazingly-fast 192 kbps

Many people were interested in the setup - both those remembering the good old BBS days, as well as those who didn't witness it back then. Clearly, the modem connect sounds from the USR Sportster (set to highest volume) were drawing most attention. ISDN is boring in comparison ;)

We also had several visitors who would either bring their own computer + modem (for example Aminga 500 or x86 PC with Windows 2000) and connect to the system. Equally, several others have borrowed some modems from our pool to connect with their own machines. One supporter even brought their own DOS BBS, ran it in a VM on Linux and set up actual modem dial-in to that BBS on the venue itself.

All in all, it was a successful first event for the project to participate. As the core setup is running now, future events will likely have more emphasis on the software side of things, i.e. showcasing a variety of different protocols and systems, such as FTN networks, QWK readers, Zerberus/ZConnect/CrossPoint, etc.

If you're interested in working on any of this, your contribution is more than welcome. Feel free to reach out at the bbs-revival mailing list

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.

Links¶

• [1] https://www.rhizomatica.org/
• [2] https://www.mozilla.org/en-US/moss/
• [3] https://sysmocom.de/
• [4] https://en.wikipedia.org/wiki/Zeroconf#DNS-based_service_discovery
• [5] https://freeswitch.org/
• [6] Soon on the master branch at https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm , at the time of writing only on the development branch at https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm?h=neels/dgsm
• [7] Soon from the master branch at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf, at the time of writing only on the development branch at https://git.osmocom.org/osmo-hlr/tree/doc/manuals/chapters/dgsm.adoc?h=neels/dgsm

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 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:

• nplab-m3ua-test
• nplab-sua-test
• osmocom TTCN-3 STP tests

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.

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 http://git.osmocom.org/osmo-small-hardware/tree/ngff-breakout 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.

Thanks to the great support of the OpenSuSE Build Service, Osmocom is now offering binary package feeds for Raspbian 10 and Ubuntu 19.10.

• Latest_Builds:
  • https://download.opensuse.org/repositories/network:/osmocom:/latest/Raspbian_10/
  • https://download.opensuse.org/repositories/network:/osmocom:/latest/xUbuntu_19.10

• Nightly_Builds:
  • https://download.opensuse.org/repositories/network:/osmocom:/nightly/Raspbian_10/
  • https://download.opensuse.org/repositories/network:/osmocom:/nightly/xUbuntu_19.10

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 http://lists.osmocom.org/pipermail/bbs-revival/2019-October/000014.html - please do join us if you'd also like to revive the good old BBS days!

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.