Planet Osmocom

September 18, 2022

Harald "LaForge" Welte

Deployment of future community TDMoIP hub

I've mentioned some of my various retronetworking projects in some past blog posts. One of those projects is Osmocom Community TDM over IP (OCTOI). During the past 5 or so months, we have been using a number of GPS-synchronized open source icE1usb interconnected by a new, efficient but strill transparent TDMoIP protocol in order to run a distributed TDM/PDH network. This network is currently only used to provide ISDN services to retronetworking enthusiasts, but other uses like frame relay have also been validated.

So far, the central hub of this OCTOI network has been operating in the basement of my home, behind a consumer-grade DOCSIS cable modem connection. Given that TDMoIP is relatively sensitive to packet loss, this has been sub-optimal.

Luckily some of my old friends at noris.net have agreed to host a new OCTOI hub free of charge in one of their ultra-reliable co-location data centres. I'm already hosting some other machines there for 20+ years, and noris.net is a good fit given that they were - in their early days as an ISP - the driving force in the early 90s behind one of the Linux kernel ISDN stracks called u-isdn. So after many decades, ISDN returns to them in a very different way.

Side note: In case you're curious, a reconstructed partial release history of the u-isdn code can be found on gitea.osmocom.org

But I digress. So today, there was the installation of this new OCTOI hub setup. It has been prepared for several weeks in advance, and the hub contains two circuit boards designed entirely only for this use case. The most difficult challenge was the fact that this data centre has no existing GPS RF distribution, and the roof is ~ 100m of CAT5 cable (no fiber!) away from the roof. So we faced the challenge of passing the 1PPS (1 pulse per second) signal reliably through several steps of lightning/over-voltage protection into the icE1usb whose internal GPS-DO serves as a grandmaster clock for the TDM network.

The equipment deployed in this installation currently contains:

  • a rather beefy Supermicro 2U server with EPYC 7113P CPU and 4x PCIe, two of which are populated with Digium TE820 cards resulting in a total of 16 E1 ports

  • an icE1usb with RS422 interface board connected via 100m RS422 to an Ericsson GPS03 receiver. There's two layers of of over-voltage protection on the RS422 (each with gas discharge tubes and TVS) and two stages of over-voltage protection in the coaxial cable between antenna and GPS receiver.

  • a Livingston Portmaster3 RAS server

  • a Cisco AS5400 RAS server

For more details, see this wiki page and this ticket

Now that the physical deployment has been made, the next steps will be to migrate all the TDMoIP links from the existing user base over to the new hub. We hope the reliability and performance will be much better than behind DOCSIS.

In any case, this new setup for sure has a lot of capacity to connect many more more users to this network. At this point we can still only offer E1 PRI interfaces. I expect that at some point during the coming winter the project for remote TDMoIP BRI (S/T, S0-Bus) connectivity will become available.

Acknowledgements

I'd like to thank anyone helping this effort, specifically * Sylvain "tnt" Munaut for his work on the RS422 interface board (+ gateware/firmware) * noris.net for sponsoring the co-location * sysmocom for sponsoring the EPYC server hardware

by Harald Welte at September 18, 2022 10:00 PM

September 08, 2022

Harald "LaForge" Welte

Retronetworking at VCFB 2022

I'm happy to announce active participation at the Vintage Computing Festival Berlin 2022 in two ways:

The exhibit will be similar to the exhibit at the retrocomputing village of the last CCC congress (36C3): A digital telephony network with ISDN BRI and POTS lines providing services to a number of laptops with Modems and ISDN terminal adapters.

We plan to demo the following things: * analog modem and ISDN dial-up into BBSs ** text / ANSI interfaces via Telix, Telemate, Terminate ** RIPterm graphical interfaces * analog modem and ISDN dial-up IP/internet * ISDN video telephony

The client computers will be contemporary 486/Pentium machines wit DOS, Windows 3.11 and OS/2.

by Harald Welte at September 08, 2022 10:00 PM

Progress on the ITU-T V5 access network front

Almost one year after my post regarding first steps towards a V5 implementation, some friends and I were finally able to visit Wobcom, a small German city carrier and pick up a lot of decommissioned POTS/ISDN/PDH/SDH equipment, primarily V5 access networks.

This means that a number of retronetworking enthusiasts now have a chance to play with Siemens Fastlink, Nokia EKSOS and DeTeWe ALIAN access networks/multiplexers.

My primary interest is in Nokia EKSOS, which looks like an rather easy, low-complexity target. As one of the first steps, I took PCB photographs of the various modules/cards in the shelf, take note of the main chip designations and started to search for the related data sheets.

The results can be found in the Osmocom retronetworking wiki, with https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS being the main entry page, and sub-pages about

In short: Unsurprisingly, a lot of Infineon analog and digital ICs for the POTS and ISDN ports, as well as a number of Motorola M68k based QUICC32 microprocessors and several unknown ASICs.

So with V5 hardware at my disposal, I've slowly re-started my efforts to implement the LE (local exchange) side of the V5 protocol stack, with the goal of eventually being able to interface those V5 AN with the Osmocom Community TDM over IP network. Once that is in place, we should also be able to offer real ISDN Uk0 (BRI) and POTS lines at retrocomputing events or hacker camps in the coming years.

by Harald Welte at September 08, 2022 10:00 PM

Clock sync trouble with Digium cards and timing cables

If you have ever worked with Digium (now part of Sangoma) digital telephony interface cards such as the TE110/410/420/820 (single to octal E1/T1/J1 PRI cards), you will probably have seen that they always have a timing connector, where the timing information can be passed from one card to another.

In PDH/ISDN (or even SDH) networks, it is very important to have a synchronized clock across the network. If the clocks are drifting, there will be underruns or overruns, with associated phase jumps that are particularly dangerous when analog modem calls are transported.

In traditional ISDN use cases, the clock is always provided by the network operator, and any customer/user side equipment is expected to synchronize to that clock.

So this Digium timing cable is needed in applications where you have more PRI lines than possible with one card, but only a subset of your lines (spans) are connected to the public operator. The timing cable should make sure that the clock received on one port from the public operator should be used as transmit bit-clock on all of the other ports, no matter on which card.

Unfortunately this decades-old Digium timing cable approach seems to suffer from some problems.

clock drift between master and slave cards

Once any of the spans of a slave card on the timing bus are fully aligned, the transmit bit clocks of all of its ports appear to be in sync/lock - yay - but unfortunately only at the very first glance.

When looking at it for more than a few seconds, one can see a slow, continuous drift of the slave bit clocks compared to the master :(

Some initial measurements show that the clock of the slave card of the timing cable is drifting at about 12.5 ppb (parts per billion) when compared against the master clock reference.

This is rather disappointing, given that the whole point of a timing cable is to ensure you have one reference clock with all signals locked to it.

The work-around

If you are willing to sacrifice one port (span) of each card, you can work around that slow-clock-drift issue by connecting an external loopback cable. So the master card is configured to use the clock provided by the upstream provider. Its other ports (spans) will transmit at the exact recovered clock rate with no drift. You can use any of those ports to provide the clock reference to a port on the slave card using an external loopback cable.

In this setup, your slave card[s] will have perfect bit clock sync/lock.

Its just rather sad that you need to sacrifice ports just for achieving proper clock sync - something that the timing connectors and cables claim to do, but in reality don't achieve, at least not in my setup with the most modern and high-end octal-port PCIe cards (TE820).

by Harald Welte at September 08, 2022 10:00 PM

August 09, 2022

Osmocom.org News

OsmoCBC - osmo-cbc 0.4.0 released, now with 4G (SBcAP) support

We're happy to announce release 0.4.0 of OsmoCBC, the Open Source Cell Broadcast Centre.

The major news for this release (aside from the usual series of bugfixes) is the support of LTE/4G via the so-called 3GPP SBcAP interface. This means that emergency messages can now not only sent to a 2G/GSM cellular network, but also to a 4G/LTE network. The support of 3GPP standardized SBcAP ensures interoperability with a variety of different EPC/MME.

Development of this 4G capability was made possibly by a generous grant of the NLnet foundation

Pre-compiled packages for a variety of GNU/Linux distributions are available as usual via our Latest_Builds

For a full changelog, please see https://gitea.osmocom.org/cellular-infrastructure/osmo-cbc/commit/d5c0b73f00a415d7e95176f6bbf6b043e06b24d8

by laforge at August 09, 2022 08:35 AM

July 11, 2022

Osmocom.org News

Cellular Network Infrastructure - Binary packages moved to new location

The nightly and latest feeds of the Osmocom binary packages for Debian, Raspbian, Ubuntu, openSUSE and CentOS are from now on available at downloads.osmocom.org. See the binary packages wiki page for the exact, distribution specific URLs and for instructions for adding the repositories in these distributions.

As transitional phase, the packages will still be available at the old location (download.opensuse.org) until end of October 2022 . Make sure to change the URLs on your systems, so "apt upgrade" etc. still work as expected.

The reason for this change is, that we decided to self-host the openSUSE build service at https://obs.osmocom.org. See #5557 for details.

by osmith at July 11, 2022 11:26 AM

June 30, 2022

Osmocom.org News

Cellular Network Infrastructure - June 2022 Osmocom CNI releases

The Osmocom project has released new version 202206 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 7 months of work since the previous versions released during November 2021.

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.7.0 https://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.7.0
libosmo-abis 1.3.0 https://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=1.3.0
libosmo-sccp (+ OsmoSTP) 1.6.0 https://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.6.0
osmo-iuh 1.3.0 https://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=1.3.0
OsmoHNBGW 1.3.0 https://git.osmocom.org/osmo-hnbgw/plain/debian/changelog?h=1.3.0
OsmoTRX 1.4.1 https://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.4.1
OsmoBTS 1.5.0 https://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.5.0
OsmoPCU 1.1.0 https://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.1.0
OsmoBSC 1.9.0 https://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.9.0
OsmoMSC 1.9.0 https://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.9.0
OsmoHLR 1.4.0 https://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.4.0
osmo-mgw 1.10.0 https://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.10.0
osmo-sip-connector 1.6.1 https://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.6.1
OsmoSGSN 1.9.0 https://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.9.0
OpenGGSN 1.9.0 https://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.9.0
osmo-pcap 0.4.0 https://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.4.0
osmo-gbproxy 1:0.3.0 https://git.osmocom.org/osmo-gbproxy/plain/debian/changelog?h=0.3.0
osmo-cbc 0.3.0 https://git.osmocom.org/osmo-cbc/plain/debian/changelog?h=0.3.0
osmo-smlc 0.2.2 https://git.osmocom.org/osmo-smlc/plain/debian/changelog?h=0.2.2
osmo-e1d 0.4.0 https://git.osmocom.org/osmo-e1d/plain/debian/changelog?h=0.4.0
osmo-hnodeb 0.1.0 https://git.osmocom.org/osmo-hnodeb/plain/debian/changelog?h=0.1.0
osmo-uecups 0.2.0 https://git.osmocom.org/osmo-uecups/plain/debian/changelog?h=0.2.0
osmo-e1d 0.4.0 https://git.osmocom.org/osmo-e1d/plain/debian/changelog?h=0.4.0
osmo-gsm-manuals 1.3.0 https://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=1.3.0

Noteworthy Changes

Misc / Common

  • libosmocore: Fix several memleaks appearing under queue overflows ( async logging, gsmtap)
  • libosmocore: Improved IuUP support
  • libosmocore: New osmo_stats API which makes TCP socket statistics available as stats.
  • libosmocore: Fixes and improvements to osmo_time_cc subsystem
  • libosmocore: Improved support to run under OpenWRT (musl libc)
  • libosmovty: Implement 'no log gsmtap [HOSTNAME]' command
  • libosmovty: Add a 'skip-zero' version of 'show stats' and 'show rate-counters'
  • libosmogsm: Supprt SAI as Cell Identifier
  • libosmogsm: Handover Request ACK now contains "Codec List (BSS Supported)" IE
  • libosmogsm: Improved support encoding/decoding additional IEs in Perform Location Request
  • libosmogsm: Support decoding several more GSM 08.08 IEs
  • libusb: Several fixes and improvements
  • libosmocoding: Several fixes and improvementes to AMR and DTX support
  • libosmosim: APDU parsing support for GlobalPlatform
  • libosmoabis: TCP socket statistics of ipaccess RSL/OML are now monitored through osmocom stats
  • libosmoabis: Polling optimizations in ipaccess code (reduces CPU load)
  • libosmo-netif: osmo_stream API now supports UNIX sockets too
  • libosmo-netif: Introduced new osmo_prim API (exchange of osmo_prim based data types over IPC communication)
  • libosmo-netif: Improve and fix AMR support
  • osmo-hnbgw was moved from osmo-iuh.git to its own repository
  • Several fixes and improvements in build system regarding pkgconfig dependencies, linker, etc.

OsmoBTS

  • Fixed memleaks and NULL pointer dereferences
  • rsl: fixed parsing of the RSL MultiRate conf IE
  • cbch: fixed double-free in bts_smscb_state_reset()
  • measurement: fixed detection of SUB frames by TDMA FN
  • osmo-bts-trx: multiple performance improvements
  • osmo-bts-trx: fixed SID detection on TCH/H channels
  • osmo-bts-trx: fixed and improved the AMR loop implementation
  • osmo-bts-trx: improved Uplink measurement processing for TCH/[FH]
  • osmo-bts-trx: removed Uplink loss detection hack from Downlink path
  • osmo-bts-trx: new rate counter 'trx_sched:dl_fh_cache_miss'

OsmoPCU

  • llc: schedule frames to MS based on SAPI priority
  • Several crash fixes

OsmoBSC

  • Disable C/I based MS Power Control Loop by default
  • Multiple crash & memleak fixes
  • Lots of paging improvements and fixes (scheduling and CPU load optimizations)
  • Early avoid managing BTS which are considered to be wrongly configured at startup/connection time
  • Fix DLCI CC bits transmitted in SAPI "n" REJECT
  • bssmap_reset: make T4 user configurable
  • inter-BSC handover: Fixes in encryption
  • inter-BSC handover: Fixes and improvements to Speech related IEs
  • handover: Add handover2 penalty-time low-rxqual-ho
  • Fix handling of E-GSM ARFCNs in frequency list (Cell Channel Description IE)
  • counter: Add missing counter increment for Perform Location Request
  • counter: add counter for inter-BSC incoming Handover Request
  • Support "empty" SCCP N-Connect from MSC
  • ipa oml: Fix encoding of T3105
  • NM FSM fixes and improvements
  • System Information Type 3: allow updating T3212 at run-time
  • Fixes and improvements sending System Information Type 13
  • Improves and fixes in SMSCB code, specially in the CBSP protocol side
  • Improves and fixes in CBCH allocation and scheduling
  • Improve Adaptative Multi Rate config defaults
  • emergency call: fix RR release cause for pre-emption
  • Introduce VTY command 'ccch load-indication-period <0-255>'
  • acc: Fix erratic ramping behavior when several BTS configured
  • stats: new trackers for lchan life duration
  • stats: track TCH/SDCCH lchans reaching fully-established state
  • Fix performance for chan_counts and all_allocated stats (reduce CPU load)
  • Expand VTY option which controls use of TCH for signalling
  • ipaccess-config: improve readability of printed attribute response
  • ipaccess-config: request and print NM_ATT_IPACC_NV_FLAGS

OsmoMSC

  • Several memleak and crash fixes
  • Always send SecModeCmd for UTRAN
  • Announce IuFP audio codec for UTRAN conns in CRCX towards MGW
  • Avoid setting audio codec if not available during assignment_complete (MDCX)
  • Fix rate_ctr not being computed
  • Add VLR and SMS queue related rate counters and stat items
  • Add improvements and optimizations to sqlite based code handling the internal SMSC.
  • Drop use of libdbi in favour of using libsqlite3 directly.

OsmoHLR (and libosmo-gsup-client)

  • VTY: Fix wrong error message displayed when tyring to add an already existing subscriber
  • Introduce new CTRL commands to manage subscribers

OsmoMGW (and libosmo-mgcp-client)

  • Proper initial IuUP support
  • mgw: Fix memleak handling E1 frames
  • mgw: Some preparations for future multi-thread support

OsmoSTP (and libosmo-sigtran)

  • Several improvements to the sccp_demo_user tool
  • libosmo-sccp: M3UA/SUA: Implement handling of SCON (signaling congestion)

OsmoSGSN

  • Fix forwarding of QoS Profile IE Gb<->Gn
  • Iu: add UEA encryption

OsmoGGSN (and libgtp)

  • ggsn: Fix VTY cmd 'no echo-interval' doing nothing
  • libgtp: Fix ggsn crash if pdp alloc array is full (PDP_MAX)
  • libgtp: Define retransmit QUEUE_SIZE relative to PDP_MAX (increase)
  • libgtp: Logging improvements

osmo-pcap

  • client: Add 'wqueue max-length <0-4294967295>' VTY command
  • Increase wqueue max-length default from 10 to 1000

osmo-gbproxy

  • Route STATUS messages with truncated PDU in error
  • Fix crash when FLUSH_LL_ACK does not contain a BVCI IE
  • Free all related BVCs if the cell is freed
  • Only route to an SGSN if the BVC is not blocked
  • New rate counters counting packet forwarding errors
  • Ensure PtP-BVCs are also reset when the SGSN SIG-BVC is reset

osmo-uecups

  • Fix several crashes
  • Fix several multi-thread issues (deadlocks, race conditions, etc.)
  • Add command line optarg support

osmo-e1d

  • icE1usb: Add support for RAI interrupt error flag
  • icE1usb: Add support for GPS-DO
  • octoi: initial support for E1oIP forwarding
  • octoi: Use RIFO (random in, first out) for IP->E1 direction
  • octoi: Add new rate-counter for out-of-order packets
  • octoi: Improve underflow/overflow conditions
  • octoi: Support setting IP DSCP and socket priority via VTY
  • octoi: Add rate_ctr for rx + tx packet / byte count
  • octoi: Make batching-factor and prefill-frame-count configurable
  • Several USB related fixes and improvements
  • Allow configuration of interfaces/lines via VTY
  • Add support for osmocom CPU schedule VTY options
  • Add rate counters for number of frames muxed/demuxed (E1 side)
  • Add stat_items for the GPS-DO related bits
  • Fix crashes

osmo-cbc

  • Set Channel Indication IE in KILL for CBS
  • Append/store results in KILL COMPLETE + KILL FAIL
  • Several crash fixes

by pespin at June 30, 2022 12:53 PM

April 24, 2022

Osmocom.org News

OCTOI - Osmocom Community TDM over IP - Successful tests with HDLC over OCTOI TDMoIP

During the past months, the primary focus in the project was on setting up reliable ISDN PRI services via the OCTOI protocol and the related hub ("central office").

Today, we've tested yet another service over OCTOI: IP in HDLC. This broadband technology doesn't use individual 64kbps E1 timeslots like in ISDN, bug it aggregates the entire 31 timeslots of the E1 link (exept for TS0) into one fat HDLC pipe. It is customary to either put raw IP packets, or Ethernet packets, or PPP frames or even Frame_Relay into that HDLC. These method of operation is supported by a variety of routers from the 1990ies.

We've tested two configurations:

Pysical E1 on client side, virtual E1 (dahdi-trunkdev) on hub side

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" * "/usr/local/bundle/gems/redmine_crm-0.0.57/app/views" )

In this configuration, an overall inner RTT of 150ms was achieved, a 115ms increase compared to the native underlying IP link.

virtual E1 (dahdi-trunkdev) on both client and hub side

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" * "/usr/local/bundle/gems/redmine_crm-0.0.57/app/views" )

In this configuration, an overall inner RTT of 108ms was achieved, a 73ms increase compared to the native underlying IP link.

by laforge at April 24, 2022 03:00 PM

April 22, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-04-29: Osmocom Community TDMoIP

We're happy to announce the next incarnation of OsmoDevCall

This time, laforge will be presenting an Osmocom Community TDMoIP (OCTOI)

When: Friday, April 29, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 Osmocom Community TDMoIP laforge
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting5.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at April 22, 2022 06:24 AM

April 18, 2022

Osmocom.org News

Retronetworking - isdn4linux historical CVS archive

Thanks to Fritz Elfert, we were able to acquire a full CVS backup of the no-longer-accessible CVS server cvs.isdn4linux.de.

We manually created mapping tables for CVS user names to real names / e-mail addresses and used cvs2git to import those into git repositories for contemporary viewing, analysis and long-term archieval.

The results can be found in our gitea, individual repositories linked below:

In case you're interested in the above, you might also be interested in our previous re-construction of the u-isdn history

by laforge at April 18, 2022 03:28 PM

April 01, 2022

Osmocom.org News

Retronetworking - New Retronetworking Project: Software-Defined Uk0

Osmocom developer jolly has started a new project for implementing the central-office side of the ISDN U (Uk0 in Germany) interface using a sound card with 192kHz samplerate.

Using this setup, you can connect an ISDN NT for BRI (NTBA in Germany) to your sound card, and provide ISDN services via mISDN.

Some basic information about a first proof-of-concept can be found at Software_Defined_Uk0; stay tuned for more information.

photo_2022-03-24_18-48-24.jpg photo_2022-03-24_18-48-46.jpg photo_2022-03-24_18-49-08.jpg photo_2022-03-24_18-50-02.jpg photo_2022-03-28_19-36-49.png

There is no real documentation yet on how to reproduce this, but code can be found at https://gitea.osmocom.org/retronetworking/uk0 (SDR PHY for Uk0) and https://gitea.osmocom.org/cc/osmo-cc-misdn-endpoint/src/branch/jolly/uk0 (mISDN port to make use of the former).

by laforge at April 01, 2022 08:16 AM

March 24, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-03-25: Iridium reverse engineering ...

We're happy to announce the next incarnation of OsmoDevCall

This time, Sec and schneider will be presenting an Iridium reverse engineering update

When: Friday, March 25, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 Iridium reverse engineering update Sec, schneider
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting5.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

NOTE: There will be no recording of this talk. If you're interested, you have to participate live!

by laforge at March 24, 2022 03:05 PM

March 10, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-03-11: USB-C - the connector and US...

We're happy to announce the next incarnation of OsmoDevCall

This time, tsaitgaist will be presenting on USB-C - the connector and USB-PD

When: Friday, March 11, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 USB-C - the connector and USB-PD tsaitgaist
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting5.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/) NOTE: URL has changed recently

by laforge at March 10, 2022 01:33 PM

February 28, 2022

Osmocom.org News

OCTOI - Osmocom Community TDM over IP - First ISDN deployment over new OCTOI TDMoIP protocol

Yesterday, laforge and manawyrm have managed to establish the first successful calls between two ISDN PBX interconnected via the Proposed_efficient_TDMoIP protocol implemented in osmo-e1d using the icE1usb hardware.

The setup looks as follows:

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" * "/usr/local/bundle/gems/redmine_crm-0.0.57/app/views" )

Using this setup we could validate so far:
  • the new, efficient and transparent OCTOI TDMoIP protocol works over public consumer internet access (VDSL on one end / DOCSIS on another end)
  • GPS-locked oscillators on both sides provide stable shared clock for cycle-slip free operation

Contrary to other established TDMoIP protocols, it is both transparent / protocol-agnostic and only transmits those timeslots of a E1 PRI circuit that are in use.

We are therefore fairly certain that this setup can be the basis of the larger intended Community_TDMSS7_Network we have in mind. There is lots of work to do, and we appreciate any help (see project issue tracker).

by laforge at February 28, 2022 09:35 AM

February 24, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-02-25: Advanced SIM topics: SCP02, ...

We're happy to announce the next incarnation of OsmoDevCall

This time, laforge will be presenting on Advanced SIM card topics: GlobalPlatform SCP02, OTA, ARA-M, ISIM

The talk covers some of the more advanced topics related to SIM cards:
  • GlobalPlatform commands / SCP02 protocol
  • OTA (Over The Air) RFM/RAM via TS 03.34
  • The ARA-M applet
  • The ISIM application

It is expected that the audience is familiar with SIM card basics, such as SIM/UICC/USIM concepts and the general file system abstraction.

When: Friday, February 25, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 Advanced SIM card topics: GlobalPlatform SCP02, OTA, ARA-M, ISIM laforge
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting5.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/) NOTE: URL has changed

by laforge at February 24, 2022 01:46 PM

February 10, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-02-11 : No presentation, just USSE

We're happy to announce the 23nd incarnation of OsmoDevCall

In this edition, we will not have any presentation, as sadly nobody has volunteered to present this time. Nevertheless, we still hold the call in case anyone wants to chat about random stuff.

When: Friday, February 11, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting5.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/) NOTE: URL has changed!

by laforge at February 10, 2022 10:18 AM

February 09, 2022

Osmocom.org News

pySim - pySim user manual now also published as HTML

The pySim source code has contained built-in sphinx based documentation for quite some time, but users had to build the manual locally from source.

A HTML rendering of the [latest git master] pySim user manual is now published at https://downloads.osmocom.org/docs/latest/pysim/ - it is automatically updated via our jenkins CI.

by laforge at February 09, 2022 08:09 PM

February 02, 2022

Osmocom.org News

Retronetworking - German Historical FTZ Standards for ISDN, SS7 and more

A number of previously unavailable historical German national standards related to (mainly) ISDN have been uncovered and are now availale as PDFs from https://people.osmocom.org/laforge/ftz/ (and in more structured presentation with metadata at German_FTZ_ISDN_Specifications).

The standards include, among many others
  • 1TR6 - German National ISDN variant of the 1980ies, before Euro-ISDN was introduced in the 1990ies
  • 1TR7 - German National SS7 dialect
  • various physical layer specs for interfaces such as S2M, V2M, Uk0, Uk2, UG2 and more

by laforge at February 02, 2022 09:19 PM

January 31, 2022

Osmocom.org News

OCTOI - Osmocom Community TDM over IP - successful initial proof-of-concept of OCTOI TDMoIP

Yesterday, the concepts of the Proposed_efficient_TDMoIP could be validated in practice for the first time using the work-in-progress implementation in the laforge/e1oip branch of osmo-e1d

The setup consisted of two icE1usb USB-E1 interfaces with built-in GPS-DO transporting an E1 line over an intermediate IP network. The clock synchronization has been monitored and sufficient stability over a period of several hours was confirmed, with no underruns/overruns or cycle slips.

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" * "/usr/local/bundle/gems/redmine_crm-0.0.55/app/views" )

The compression feature was working as expected: E1 timeslots with no change compared to the previous frame were supressed. The batching feature (32 E1 frames per UDP packet) was equally working as expected.

There's still a lot of work to do to make this more usable via consume internet connections with NAT and dynamic IP addresses, but the concepts could be shown to work in practice:
  • using GPS-DO clocked icE1usb to avoid clock drift
  • using batching of E1 frames
  • suppressing transmission of timeslots with no data

by laforge at January 31, 2022 11:40 AM

January 28, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-01-28 : Various short [mostly retro...

We're happy to announce the 22nd incarnation of OsmoDevCall

In this edition, laforge will present a number of brief (lightning) talks about a number of projects he's currently been thinking about or working on, including
  • efficient TDMoIP protocol
  • TDMoIP community network
  • hardware design of ISDN BRI interface for TDMoIP community network
  • continuous testing setup for simtrace2 "cardem" firmware
  • non-transparent ISA-over-USB bridge attached to qemu

The idea is to ping-pong some ideas wit others and maybe find somebody interested in helping out.

When: Friday, January 28, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 series of brief talks on topics stated above laforge
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at January 28, 2022 01:00 PM

January 11, 2022

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-01-14: Codecs in OsmoMSC, MNCC and SIP

We're happy to announce the 21st incarnation of OsmoDevCall

In this inaugural 2022 edition, neels will be presenting on Codecs in OsmoMSC, MNCC and SIP.

The talk covers the handling and negotiation of GSM/UMTS voice codecs in the core network, both in current master as well as in a long-standing to-be-merged branch.

When: Friday, January 14, 2022 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 Codecs in OsmoMSC, MNCC and SIP neels
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at January 11, 2022 09:13 PM

December 26, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2021-12-28 Retronetworking: ETSI/ITU V5 ...

We're happy to announce the 20th incarnation of OsmoDevCall

In this X-mas special retronetworking edition, laforge will be presenting on The ETSI V5 interface in digital telephone exchanges

The ETSI/ITU V5 interface is an internal interface of a digital telephone exchange (aka "central office") for POTS and ISDN in the PSTN. The talk will introduce the interface and present some ongoing efforts towards a FOSS implementation of it.

When: Tuesday, December 28, 2021 from 20:00 CET (yes, Tuesday instead of Friday this time due to Christmas)

Time Topic Who
20:00 Meet and Greet everyone
20:10 ETSI V5 in [historical] digital telephone exchanges laforge
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at December 26, 2021 08:07 PM

December 24, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoC3 - Osmocom related video chat room...

The history of Osmocom is intertwined with a group of poeple that used to meet at the Chaos Communication Congress.

For more than the past decade, before the pandemic, Osmocom always used to have a physical room at the annual Chaos Communication Congress. Attendees of the event interested in open source mobile communications could just come over and ahve a chat with like-minded people.

In 2021, like in 2020, there is no Chaos Communcation Congress due to the global pandemic.

However, we have created a virtual room (big blue button audio/video conference) where we invite anyone interested to join during the traditional December 27 to December 30 time frame.

The room is called OsmoC3 and you can find it at https://meeting4.franken.de/b/har-ohz-mqu-irn

Merry Christmas, and a Happy New Year,

Harald "LaF0rge" Welte

by laforge at December 24, 2021 04:46 PM

December 20, 2021

Osmocom.org News

Cellular Network Infrastructure - binary package feeds for Raspbian 11

Starting from today, the Osmocom project is offering Raspbian 11 binary package feeds for both

For more information check the related pages linked above.

by laforge at December 20, 2021 04:46 PM

December 09, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - osmo-dev and running Osmocom TTCN-3 test...

We're happy to announce the 19th incarnation of OsmoDevCall

This time osmith will be presenting on osmo-dev and running Osmocom TTCN-3 testsuites locally

When: Friday, December 10, 2021 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 osmo-dev and running Osmocom TTCN-3 testsuites locally osmith
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at December 09, 2021 04:39 PM

November 23, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #18 - Control/User Plane Sep...

We're happy to announce the 18th incarnation of OsmoDevCall

This time laforge will be presenting on Control/User Plane Separation (CUPS) and PFCP

When: Thursday, November 25, 2021 from 20:00 CET (yes, thursday instead of friday this time due to scheduling conflicts of the speaker)

Time Topic Who
20:00 Meet and Greet everyone
20:10 Control/User Plane Separation (CUPS) and PFCP laforge
21:00 USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at November 23, 2021 08:04 PM

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall videos at media.ccc.de

Thanks to tnt and the c3voc team, we now are publishing all of our OsmoDevCall videos on https://media.ccc.de/ - specifically at https://media.ccc.de/c/osmodevcall

We strive to continue to push all OsmoDevCall recordings there to reach a wider audience of like-minded hackers (in the sense of people who want to understand technology down to the last bit and play with it) and ensure long-term availability of our video recordings.

(For those who prefer a proprietary service like youtube, there is also a mirror at https://www.youtube.com/c/mediacccde/videos - but it's harder to filter out the OsmoDevCall specific videos)

by laforge at November 23, 2021 06:51 AM

November 19, 2021

Osmocom.org News

Cellular Network Infrastructure - November 2021 Osmocom CNI releases

The Osmocom project has released new version 202111 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 9 months of work since the previous versions released during February 2021.

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.6.0 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.6.0
libosmo-abis 1.2.0 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=1.2.0
libosmo-sccp (+ OsmoSTP) 1.5.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.5.0
libosmo-ranap (+ OsmoHNBGW) 1.1.0 http://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=1.1.0
OsmoTRX 1.4.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.4.0
OsmoBTS 1.4.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.4.0
OsmoPCU 1.0.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.0.0
OsmoBSC 1.8.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.8.0
OsmoMSC 1.8.0 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.8.0
OsmoHLR 1.4.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.4.0
osmo-mgw 1.9.0 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.9.0
osmo-sip-connector 1.6.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.6.0
OsmoSGSN 1.8.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.8.0
OpenGGSN 1.8.1 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.8.0
osmo-pcap 0.2.1 http://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.2.1
osmo-gbproxy 1:0.2.0 http://git.osmocom.org/osmo-gbproxy/plain/debian/changelog?h=0.2.0
osmo-cbc 0.2.3 http://git.osmocom.org/osmo-cbc/plain/debian/changelog?h=0.2.3
osmo-smlc 0.2.1 http://git.osmocom.org/osmo-smlc/plain/debian/changelog?h=0.2.1
osmo-e1d 0.2.2 http://git.osmocom.org/osmo-e1d/plain/debian/changelog?h=0.2.2
osmo-hnodeb 0.0.1 http://git.osmocom.org/osmo-hnodeb/plain/debian/changelog?h=0.0.1
osmo-uecups 0.1.4 http://git.osmocom.org/osmo-uecups/plain/debian/changelog?h=0.1.4
osmo-gsm-manuals 1.2.0 http://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=1.2.0

Noteworthy Changes

Misc / Common

  • libosmocore: rate_ctr/stat_item groups can now be identified by a unique name string, not only by id number.
  • libosmocore: stat_item groups are now accessible through CTRL interface
  • libosmocore: Important AMR fixes
  • libosmocore: New APIs introduced for base64 encode/decode
  • libosmocore: Osmocom logging system becomes non-blocking by default
  • libosmocrypt: New APIs introduced for key dferivation functions
  • libosmogb: Lots and lots of fixes and improvements in new NS protocol implementation (NS2)
  • libosmo-sigtran: Automatically create routes for routing key when in ASP role
  • libosmo-sigtran: Allow apps set internally proper IPv4/v6 default hosts
  • VAMOS support
  • Support to set socket DSCP and priority values (QoS)
  • New PCUIF over IPA multiplex of OML BTS<->BSC link to communicate transparently osmo-pcu and osmo-bsc
  • Osmocom style dynamic timeslots support now being configured as SDCCH8
  • A5/4 support

OsmoTRX

  • uhd: Ensure clock source is locked before using it
  • lms: Fix very low output power due to band not probperly set.
  • lms.uhd: Allow changing band between poweroff & poweron

OsmoBTS

Common:
  • Massive refactoring of the shutdown/reconnect logic
  • BSC redundancy: support for multiple OML addresses
  • Keep the process ongoing trying to reconnect on Abis link down
  • Try one reconnect to previously connected BSC before trying next one
  • Support forwarding proto IPAC_PROTO_EXT_PCU BSC<->PCU (PCUIF over IPA multiplex of OML link)
  • SDCCH8 support for the Osmocom style dynamic timeslots
  • MS power control: C/I based power control decision
  • MS Power control: Use P_CON_INTERVAL=2 by default
  • BS power control: EWMA averaging for reported RxQual
  • MS/BS power control: fixed handling of -SUB/-FULL values
  • MS/BS power control: fixed EWMA downscaling bug
  • MS/BS power control: logic and logging improvements
  • Timing Advance control: interval (loop suspension) support
  • Timing Advance control: various fixes and logic improvements
  • Early Immediate Assignment support
  • Interference reporting to BSC and PCU (#1569)
  • Prioritization of CS paging over PS paging
  • Configurable socket priority of RTP sockets
  • Improved handling of the Uplink and Downlink measurements
  • Fixed and improved handling of the Channel Identification IE
  • Fixed a race condition during the activation of dynamic timeslots
  • Fixed sending Load Indications when BTS is not RSL-connected
  • Fixed re-(de)activation of already (de)activated lchans
  • Initial support for static userspace probes via systemtap
  • Various stability and performance improvements and bugfixes
osmo-bts-trx:
  • New TRXDv2 protocol and burst batching (#4006)
  • Support for different per-timeslot TSC values
  • Initial VAMOS and AQPSK support (#4941)
  • Constrained BS power control on BCCH carrier
  • BCCH carrier power reduction mode
  • PDCH power saving (#4772)
  • Temporary ACCH Overpower
  • Important AMR fixes
  • A5/4 support

OsmoPCU

  • Heavy refactoring of code, reworked to use osmocom FSMs.
  • Change code to be GSM-clock driven, instead of mostly wall-clock driven. As a result most N3.. and T3... are much more reliable now.
  • Polling capacity improvements through introduction of new PDCH UL Controller class (allow multiple concurrent polls per PDCH, polling for other than N+13 is now supported).
  • Uplink multi-slot TBF allocation support added
  • Transmit empty blocks through PCUIF instead of dummy rlcmac blocks when there is no MS listening on PDCH
  • Implement T3141 (3GPP TS 44.018 sec 3.5.2.1.5, contentiuon resolution timeout)
  • PAGING-CS optimizations for known MS (send paging on subset od all PDCHs where MS is listening)
  • Several fixes for CSN.1 decoder
  • Bunch of new counters/stats added
  • Several fixes and improvements in NS code
  • NACC: Support Neighbor Address Resolution over PCUIF IPA multiplex
  • PAGING-PS fixes: Fix paging with TMSI and MS ending with assigned IMSI 000. Avoid repeated paging if T3113 is still running.
  • Lots of fixes in lots of places, and lots of code clean up
  • VTY: new gsmtap related commands available, similar to those in osmo-bts.

OsmoBSC

  • MGW pooling
  • Call-reestablishment
  • Temporary ACCH Overpower for osmo-bts
  • Support for adding a new BTS at run-time
  • VAMOS PoC (signalling and VTY commands) for osmo-bts
  • BS Power control: BCCH carrier power reduction operation
  • BS Power control: constrained power control on BCCH carrier
  • BS Power control: avoid inheriting bs_power from old lchan
  • MS Power control: initial MS power loop implementation
  • MS Power control: parameters for C/I based power control
  • MS Power control: use P_CON_INTERVAL=2 by default
  • Channel allocator: pick lchans with least interference
  • Support for Location Services and the Lb interface to SMLC
  • Support SDCCH/8 for Osmocom style dynamic timeslots
  • Support Neighbor Address Resolution over PCUIF IPA multiplex
  • Support for A5/4: signalling and VTY parameters
  • Support Channel Mode Modify procedure
  • Handover: support upgrade TCH/H -> TCH/F (without AFS bias)
  • Handover: proper handling of the -FULL/-SUB measurements
  • DSCP and PCP differentiation of Downlink Abis traffic
  • Early Immediate assignment for VSAT backhaul
  • CTRL interface bindings for applying a VTY config file
  • CTRL interface bindings for handover parameters
  • CTRL interface bindings for neighbour cells
  • VTY sets default TEI for 'trx' nodes according to TRX number
  • VTY commands for Ericsson RBS2000: sync and RX diversity
  • VTY command 'assignment' actually triggers Assignment, not HO
  • VTY option to forbid use of TCH for non-voicecall signalling
  • Configurable interference measurement parameters
  • Configurable TA filtering for CHANnel ReQuireD messages
  • Reworked warnings about unknown/non-supported BTS features
  • Frequency hopping: various fixes and improvements
  • BTS type 'sysmobts' is deprecated in favor of 'osmo-bts'
  • Fixed manual channel activation (from the VTY) for nanoBTS
  • ipaccess-config: various fixes and improvements
  • Speedup shutdown using the new osmo_select_shutdown() API
  • Fixed and improved neighbor configuration options
  • Use osmo_clock_gettime everywhere
  • stats: BTS uptime counter
  • stats: transitions from BORKEN state due to LCHAN_EV_TS_ERROR
  • stats: all_allocated:{sdcch,tch} rate counters
  • stats: all_allocated:{static_sdcch,static_tch} rate counters
  • stats: bts.N.cm_serv_rej:<cause> rate counters
  • stats: incoming_intra_bsc_ho:* rate counters

OsmoMSC

  • SGs, CSFB / SRVCC improvements and fixes
  • Support for Call Re-establishment
  • Support new MNCCv8 protocol version (with GCR support for LCLS)
  • UMTS UEA encryption is working properly now, and UTRAN encryption algorithms are not VTY configurable

OsmoHLR (and libosmo-gsup-client)

  • VTY: save config format fixes
  • VTY: enable show subscribers filtered by IMEI
  • packaging: Add post-upgrade script for automatic db upgrade
  • New DB schema format: v6.

OsmoMGW (and libosmo-mgcp-client)

  • mgcp-client: Fix dupicated MGCP DLCX being sent sometimes
  • mgcp-client: Add support for MGW pooling
  • mgw: fix RTP patching not taking into account RTP marker (M) bit
  • Support wildcarded MGCP DLCX to allow resetting endpoint on startup
  • Several more counters/stats added
  • Several fixes here and there

osmo-sip-connector

  • MNCC v8: GCR support (for LCLS)
  • Several fixes (crash, memleak), improved logging

OsmoSTP (and libosmo-sigtran)

  • Several fixes and improvements for IPA AS/ASP
  • Introduce notion of configurable 'quirks' (compatibility against peers containing deviations from standard)
  • vty: automatically create routes for routing key when in ASP role
  • Minimalistic support for XUDT/XUDTS
  • Introduce rx/tx rate counteres on AS and ASP level

OsmoSGSN

  • Several (G)MM FSM improvements (GERAN, UTRAN)
  • Iu: Timer X3314 has been dropped
  • gtp: Delete ctx upon receive UpdateCtxResp with cause Non-existent
  • Support forwarding RIM messages over GTPCv1 EUTRAN<->GERAN
  • Several logging improvements

OsmoGGSN (and libgtp)

  • ggsn: Reject PDP CTX ACT for static IP addresses (not supported)
  • ggsn: Fix heap-use-after-free during Recovery without associated PDP
  • Several logging improvements
  • Introduce program gtp-echo-responder

osmo-pcap

  • Change default ports of client, server_
    • osmo-pcap-client 4237 -> 4227
    • osmo-pcap-server 4238 -> 4228

osmo-gbproxy

  • Support setting rt-prio and cpu-affinity mask through VTY
  • Add CTRL VTY commands
  • Don't route messages to an SGSN if it is down
  • Forward MS_REGISTR_ENQ/_RESP correctly
  • Improve routing of BSSGP STATUS
  • Improved documentation
  • Lots of fixes and improvements

osmo-uecups

  • Add VTY command to configure local bind IP of UECUPS socket

by pespin at November 19, 2021 03:39 PM

November 11, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #17 - TDM basics + icE1usb i...

We're happy to announce the 17th incarnation of OsmoDevCall

This time the main presentation by tnt will be presenting on icE1usb in practice

When: Friday, November 12, 2021 from 20:00 CET

Time Topic Who
20:00 Meet and Greet everyone
20:10 Introduction into E1, TDM, PDH, SDH laforge
20:30 icE1usb in practice tnt
later USSE (Unstructured Supplementary Social Event) everyone

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at November 11, 2021 07:32 AM

October 21, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #16 - SIM profile, personali...

We're happy to announce the 16th incarnation of OsmoDevCall

This time laforge will be presenting on SIM card profile creation, personalization, production

When: Friday, October 22nd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at October 21, 2021 08:15 AM

October 16, 2021

Osmocom.org News

pySim - pySim-shell support for sysmoISIM-SJA2 key data / files

Starting from f44256c7dff6d24f1f940d4ca71219abbb0c7e34, pySim-shell now supports the non-standard files of the sysmoISIM-SJA2 SIM cards containing authentication key material for AKA and TS 03.48 OTA.

This way you can now interactively inspect and/or modify aspects such as

UMTS AKA key material and configuration

pySIM-shell (MF/ADF.USIM/EF.USIM_AUTH_KEY)> read_binary_decoded
{
    "cfg": {
        "only_4bytes_res_in_3g": 0,
        "use_sres_deriv_func_2_in_3g": 0,
        "use_opc_instead_of_op": 1,
        "algorithm": "milenage" 
    },
    "key": "07583fd7518b42752fea8b7063faa756",
    "op": null,
    "opc": "440aac831e58941abe17a5db76470776" 
}
pySIM-shell (MF/ADF.USIM/EF.USIM_SQN)> read_binary_decoded 
{
    "flag1": {
        "skip_next_sqn_check": 0,
        "delta_max_check": 1,
        "age_limit_check": 0,
        "sqn_check": 0,
        "ind_len": 5
    },
    "flag2": {
        "rfu": 0,
        "dont_clear_amf_for_macs": 0,
        "aus_concealed": 1,
        "autn_concealed": 1
    },
    "delta_max": 8589934592,
    "age_limit": 8589934592,
    "freshness": [ 32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ]
}

Milenage configuration (constants)

pySIM-shell (MF/DF.SYSTEM/EF.MILENAGE_CFG)> read_binary_decoded
{
    "r1": 64,
    "r2": 0,
    "r3": 32,
    "r4": 64,
    "r5": 96,
    "c1": "00000000000000000000000000000000",
    "c2": "00000000000000000000000000000001",
    "c3": "00000000000000000000000000000002",
    "c4": "00000000000000000000000000000004",
    "c5": "00000000000000000000000000000008" 
}

OTA key material

pySIM-shell (MF/DF.SYSTEM/EF.0348_KEY)> read_record_decoded 1
{
    "sec_domain": 0,
    "key_set_version": 112,
    "key_type": "kic",
    "key_length": 16,
    "algorithm": "des",
    "mac_length": 8,
    "key": "c039ed58f7b81446105e79ebfd" 
}

by laforge at October 16, 2021 08:31 AM

pySim - pySim-prog critical fix against corruption of key material

In 80901d6d39fd05b923c48145147c47f0ad5252ca we fixed a critical bug regarding the writing of key material when using the classic pySim-prog utility. All versions since 2e6dc03f345150353ecc796f18614c02256bd2df on July 31st are affected.

This means if you are using any of the affected versions in the range above, writing keys will write an erroneous key to your card, where the first byte of the user-specified key is dropped, the remaining 15 bytes are written from offset 0, and the last byte of the key will not be updated on the card.

Programming key material by sysmo-{isim,usim}-tool was not affected by this.

Users are requeste to update to current master or any version including 80901d6d39fd05b923c48145147c47f0ad5252ca

We apologize for any inconvenience.

by laforge at October 16, 2021 08:22 AM

October 10, 2021

Harald "LaForge" Welte

First steps towards an ITU-T V5.1 / V5.2 implementation

As some of you may know, I've been starting to collect "vintage" telecommunications equipment starting from analog modems to ISDN adapters, but also PBXs and even SDH equipment. The goal is to keep this equipment (and related software) alive for demonstration and practical exploration.

Some [incomplete] information can be found at https://osmocom.org/projects/retro-bbs/wiki/

Working with PBXs to simulate the PSTN (ISDN/POTS) network is fine to some extent, but it's of course not the real deal. You only get S0-buses and no actual Uk0 like actual ISDN lines of the late 80ies and 90ies. You have problems with modems not liking the PBX dialtone, etc.

Hence, I've always wanted to get my hand on some more real-world central-office telephone network equipment, and I finally have a source for so-called V5.1/V5.2 access multiplexers. Those are like remote extension boxes for the central office switch (like EWSD or System 12). They aggregate/multiplex a number of analog or ISDN BRI subscriber lines into E1 lines, while not implementing any of the actual call control or ISDN signalling logic. All of that is provided by the actual telephone switch/exchange.

So in order to integrate such access multiplexers in my retronetworking setup, I will have to implement the LE (local exchange) side of the V5.1 and/or V5.2 protocols, as specified in ITU-T G.964 and G.965.

In the limited spare time I have next to my dayjob and various FOSS projects, progress will likely be slow. Nonetheless I started with an implementation now, and I already had a lot of fun learning about more details of those interfaces and their related protocols.

One of the unresolved questions is to what kind of software I would want to integrate once the V5.x part is resolved.

  • lcr would probably be the most ISDN-native approach, but it is mostly unused and quite EOL.

  • Asterisk or FreeSWITCH would of course be obvious candidates, but they are all relatively alien to ISDN, and hence not very transparent once you start to do anything but voice calls (e.g. dialup ISDN data calls in various forms).

  • yate is another potential candidate. It already supports classic SS7 including ISUP, so it would be a good candidate to build an actual ISDN exchange with V5.2 access multiplexers on the customer-facing side (Q.921+Q.931 on it) and SS7/ISUP towards other exchanges.

For now I think yate would be the most promising approach. Time will tell.

The final goal would then be to have a setup [e.g. at a future CCC congress] where we would have SDH add/drop multiplexers in several halls, and V5.x access multiplexers attached to that, connecting analog and ISDN BRI lines from individual participants to a software-defined central exchange. Ideally actually multiple exchanges, so we can show the signaling on the V5.x side, the Q.921/Q.931 side and the SS7/ISUP between the exchanges.

Given that the next CCC congress is not before December 2022, there is a chance to actually implement this before then ;)

by Harald Welte at October 10, 2021 10:00 PM

October 08, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #15 - VoLTE/IMS pcap deep-dive

We're happy to announce the 15th incarnation of OsmoDevCall

This time laforge will be presenting a VoLTE / IMS pcap file deep dive.

When: Friday, October 8th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

UPDATE: Location moved to https://meet.sysmocom.de/OsmoDevCall due to server problems at franken.de

by laforge at October 08, 2021 05:49 AM

September 23, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #14 - ISO7816 smart card int...

We're happy to announce the 14th incarnation of OsmoDevCall

This time tnt will be presenting about his work on an ISO 7816 smart card interface FPGA softcore.

When: Friday, September 24th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at September 23, 2021 06:49 PM

September 03, 2021

Osmocom.org News

Cellular Network Infrastructure - Osmocom package feeds for Debian 11 + Ubuntu 21.04

Osmocom is happy to announce releasing binary package feeds for the latest tagged versions and nightly builds for both Debian 11 and Ubuntu 21.04.

At the same time, we have retired the support for Debian 8 and Ubuntu 19.10.

The full list of distributions and architectures we provide binary packages for can be seen at Latest_Builds and Nightly_Builds - including links to the package feeds and instructions how to use them.

by laforge at September 03, 2021 03:57 PM

August 24, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #13 - osmo-remsim in practice

We're happy to announce the 13th incarnation of OsmoDevCall

This time laforge will be presenting about osmo-remsim in practice

The talk will cover
  • introduction to osmo-remsim architecture
  • supported hardware / software
  • practical demonstration

When: Friday, August 27th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at August 24, 2021 11:49 AM

August 12, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #12 - GSM-R and its differen...

We're happy to announce the 12th incarnation of OsmoDevCall

This time laforge will be presenting about GSM-R and its differences to GSM.

When: Friday, August 13th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at August 12, 2021 11:30 AM

July 22, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #11 - high-level overview on...

We're happy to announce the 11th incarnation of OsmoDevCall

This time laforge will be presenting a high-level introduction to IMS and its use in VoLTE and VoWiFi.

When: Friday, July 23rd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at July 22, 2021 06:43 AM

July 19, 2021

Harald "LaForge" Welte

Notfallwarnung im Mobilfunknetz + Cell Broadcast (Teil 2)

[excuse this German-language post, this is targeted at the current German public discourse]

Ein paar Ergänzungen zu meinem blog-post gestern.

Ich benutzt den generischen Begriff PWS statt SMSCB, weil SMSCB strikt genommen nur im 2G-System existiert, und nur ein Layer ist, der dort für Notfallalarmierung verwendet wird.

Zu Notfallwarn-Apps

Natürlich sind spezielle, nationale Deutsche Katastrophenschutz-Apps auch nützlich! Aber diese sollten allenfalls zusätzlich angeboten werden, nachdem man erstmal die grundlegende Alarmierung konform der relevanten internationalen (und auch EU-)Standards via Cell Broadcast / PWS realisiert. Man sagt ja auch nicht: Nachrichtensendungen braucht man im Radio nicht mehr, weil man die bereits im Fernsehen hat. Man will auf allen verfügbaren Kanälen senden, und zunächst jene mit möglichst universeller Reichweite und klaren technischen Vorteilen benutzen, bevor man dann zusätzlich auch auf anderen Kanälen alarmiert.

Wie sieht PWS für mich als Anwender aus

Hier scheint es größere Missverständnisse zu geben, wie das auf dem Telefon letztlich aussieht. Ist ja auch verständlich, hierzulande sieht man das nie, ausser man ist zufällig in einem Labor/Basttel-Netz z.B. auf einer CCC-Veranstaltung unterwegs, in der das Osmocom-Projekt mal solche Nachrichten versendet hat.

Die PWS (ETWS, CMAS, WEA, KPAS, EU-ALERT, ...) nachrichten werden vom Telefon empfangen, und dann je nach Konfiguration und Priorität behandelt. Für die USA ist im WEA vorgeschrieben, dass Alarme einer bestimmten Prioritatsklasse (z.B. der Presidential Level Alert) immer zwangsweise zur Anzeige gebracht werden und immer mit einem lauten sirenenartigen Alarmton einhergehen. Es ist sogar explizit verboten, dass der Anwender diese Alarme irgendwo ausstellen, stumm schalten o.ä. kann. Insofern spielt es keine Rolle, ob das Telefon gerade Lautlos gestellt ist, oder es nicht gerade unmittelbar bei mir ist.

Bei manchen Geräten werden die Warnungen sogar mittels einer text2speech-Engine laut über den Lautsprecher vorgelesen, nachdem der Alarmton erscheint. Ob das eine regulatorische Anforderung eines der nationalen System ist, weiss ich nicht - ich habe es jedenfalls bereits in manchen Fällen gesehen, als ich mittels Osmocom-Software solche Alarme in privaten Labornetzen versandt habe.

Noch ein paar technische Details

  • PWS-Nachrichten werden auch dann noch ausgestrahlt, wenn die Zelle ihre Netzanbindung verloren hat. Wenn also z.B. das Glasfaserkabel zum Kernnetz bereits weg ist, aber noch Strom da ist, werden bereits vorher vom CBC (Cell Broadcast Centre) an die Mobilfunkzelle übermittelte Warnungen entsprechend ihrer Gültigkeitsdauer weiter autonom von der Zelle ausgesendet Das ist wieder ein inhärenter technischer Vorteil, der niemals mit einer App erreichbar ist, weil diese erfordert dass das komplette Mobilfunknetz mit allen internen Verbindungen und dem Kernnetz sowie die Internetverbindung vom Netzbetreiber zum Server des App-Anbieters durchgehend funktioniert.

  • PWS-Nachrichten können zumindest technisch auch von Telefonen empfangen werden, die garnicht im Netz eingebucht sind, oder die keine SIM eingelegt haben. Ob dies in den Standards gefordert wird, und/oder ob dies die jeweilige Telefonsoftware das so umsetzt, weiss ich nicht und müsste man prüfen. Technisch liegt es nahe, ähnlich wie das Absetzen von Notrufen, das ja auch technisch in diesen Fällen möglich ist.

Zu den Kosten

Wenn - wie in der idealen Welt - das Vorhalten von Notfallalarmierung eine Vorgabe bereits zum Zeitpunkt der Lizenzvergabe für Funkfrequenzen gewesen wäre, wäre das alles einfach ganz lautlos von Anfang an immer unterstützt gewesen. Keiner hätte extra Geld investieren müssen, weil diese minimale technische Vorgabe dann ja bereits Teil der Ausschreibungen der Betreiber für den Einkauf ihres Equipments gewesen wäre. Zudem hatten wir ja bereits in der Vergangenheit Cell Brodacast in allen drei Deutschen Netzen, d.h. die Technik war mal [aus ganz andern Gründen] vorhanden aber wurde irgendwann weggespart.

Das jetzt nachträglich einzuführen heisst natürlich, dass es niemand eingeplant hat, und dass jeder beteiligte am Markt sich das vergolden lassen will. Die Hersteller freuen sich in etwa wie "Oh, Ihr wollt jetzt mehr als ihr damals beim Einkauf spezifiziert habt? Schön, dann schreiben wir mal ein Angebot".

Technisch ist das alles ein Klacks. Die komplette Entwicklung aller Bestandteile für PWS in 2G/3G/4G/5G würde ich auf einen niedrigen einmaligen sechsstelligen Betrag schätzen. Und das ist die einmalige Investition in der Entwicklung, welche dann über alle Geräte/Länder/Netze umgebrochen wird. Bei den Milliarden, die in Entwicklung und Anschaffung von Mobilfunktechnik investiert wird, ist das ein Witz.

Die Geräte wie Basisstationen aller relevanten Hersteller unterstützen natürlich von Haus aus PWS. Die bauen für Deutschland ja nicht andere Geräte, als jene, die in UK, NL, RO, US, ... verbaut werden. Der Markt ist international, die gleiche Technik steht überall.

Weil man jetzt zu spät ist, wird das natürlich von allen Seiten ausgenutzt. Jeder Basisstationshersteller wird die Hand aufhalten und sagen, das kostet jetzt pro Zelle X EUR im Jahr zusätzliche Lizenzgebühren. Und die Anbieter der zentralen Komponente CBC werden auch branchenüblich die Hand aufhalten, mit satten jährlichen Lizenzgebühren. Und die Consultants werden auch alle die Hand aufhalten, weil es gibt wieder etwas zu Integrieren, zu testen, ... Das CBC ist keine komplexe Technik. Wenn man das einmalig als Open Source entwickeln lässt, und in allen Netzen einsetzt, bekommt man es quasi zum Nulltarif. Aber das würde ja Voraussetzen, dass man sich wirklich mit der Technik befasst, versteht um welch simple Software es hier geht, und dass man mal andere Wege in der Beschaffung geht, als nur mal eben bei seinen existierenden 3 Lieferanten anzurufen, die sich dann eine goldene Nase verdienen wollen.

In der öffentlichen Diskussion wird von 20-40 Millionen EUR gesprochen. Das sind überzogene Forderungen der Marktteilnehmer, nichts sonst. Aber selbst wenn man der Meinung ist, dass man lieber das Geld zum Fenster hinauswerfen will, statt Open Source Alternativen zu [ver]suchen, dann ist auch diese Größenordnung etwas, dass im Vergleich zu den sonstigen Anschaffungs- und Betriebskosten eines Mobilfunknetzes verschwindend gering ist. Ganz zu schweigen von den Folgekosten im Bereich Bergung/Rettung, Personenschäden, etc. die sich dadurch mittelfristig bei Katastrophen einsparen lassen.

Oder anders betrachtet: Wenn sogar das wirtschaftlich viel schwächere Rumänien sich sowas leisten kann, dann wird es wohl auch die Bundesrepublik Deutschland stemmen können.

by Harald Welte at July 19, 2021 10:00 PM

July 18, 2021

Harald "LaForge" Welte

Notfallwarnung im Mobilfunknetz + Cell Broadcast

[excuse this German-language post, this is targeted at the current German public discourse]

In mehrerern Gegenden Deutschlands gab es verheerende Hochwasser, und die Öffentlichkeit diskutiert deshalb mal wieder die gute alte Frage nach dem adäquaten Mittel der Alarmierung der Bevölkerung.

Es ist einfach nur ein gigantisches Trauerspiel, wie sehr die Deutsche Politik und Verwaltung in diesem Punkt inzwischen seit Jahrzehnten sämtliche relevanten Standards verpennt, und dann immer wieder öffentlich durch fachlich falsche und völlig uninformierte Aussagen auffällt.

Das Thema wurde vor dem aktuellen Hochwasser bereits letztes Jahr im Rahmen des sog. WarnTag öffentlich diskutiert. Auch hier von Seiten der öffentlichen Hand ausschliesslich mit falschen Aussagen, wie z.B. dass es bei Cell Broadcast Datenschutzprobleme gibt. Dabei ist Cell Broadcast die einzige Technologie, wo keine Rückmeldung des einzelnen Netzteilnehmers erfolgt, und das Netz nichtmal weiss, wer die Nachricht empfangen hat, und wo dieser Empfang stattgefunden hat. Ganz wie beim UKW-Radio.

Fakt ist, dass alle digitalen Mobilfunkstandards seit GSM/2G, d.h. seit 1991 die Möglichkeit mitbringen, effizient, schnell und datensparsam alle Nutzer (einer bestimmten geographischen Region) mit sogenannten broadcast Nachrichten zu informieren. Diese Technik, in GSM/2G genannt Cell Broacast (oder auch _SMSCB_), unterscheidet sich Grundlegend von allen anderen Kommunikationsformen im Mobilfunknetz, wie Anrufe und herkömmliche SMS (offiziell SMS-PP). Anrufe, SMS und auch mobile Paketdaten (Internet) werden immer f"ur jeden Teilnehmer individuell auf ihm zugewiesenen Funkressourcen übermittelt. Diese Ressourcen sind beschränkt. Es können in keinem Mobilfunknetz der Welt alle Teilnehmer gleichzeitig telefonieren, oder gleichzeitig SMS empfangen.

Stattdessen benutzt Cell Broadcast - wie der Name bereits unmissverständlich klar macht - Einen broadcast, d.h. Rundsendemechanismus. Eine Nachricht wird einmal gesendet, benötigt also nur eine geteilte Ressource auf der Luftschnittstelle, und wird dann von allen Geräten im Empfangsbereich zeitgleich empfangen und dekodiert. Das ist wie UKW-Radio oder klassisches terrestrisches Fernsehen.

Cell Broadcsat wurde bereits in den 1990er Jahren von Deutschen Netzbetreibern benutzt. Und zwar nicht für etwas lebensnotwendiges wie die Notfallsignalisierung, sondern für so banale Dinge wie die Liste jener Vorwahlen, zu denen gerade ein vergünstigter "wandernder Ortstarif" Besteht. Ja, sowas gab es mal bei Vodafone. Oder bei O2 wurden über lange Zeit (aus unbekannten Gründen) die GPS-Koordinaten der jeweiligen Basisstation als Cell Broadcast versendet.

In der folgenden (nun fast abgeschalteten) Mobilfunkgeneration 3G wurde Cell Broadcast leicht unbenannt als Service Area Broadcast beibehalten. Schliesslich gibt es ja Länder mit - anders als in Deutschland - funktionierender und kompetenter Regulierung des Telekommunikationsmarktes, und die langjährig bestehenden gesetzlichen Anforderungen solcher Länder zwingen die Netzbetreiber und auch die Ausrüster der Neztbetreiber, neue Mobilfunkstandards so zu entwickeln, dass die gesetzlichen Vorgaben bzgl. der Alarmierung der Bevölkerung im Notfall funktioniert.

Im Rahmen dieser Standardisierung haben eine Reihe von Ländern innerhalb der 3GPP-Standardisierung (zuständig für 2G, 3G, 4G, 5G) sogenannte Public Warning Systems (PWS) standardisiert. Zu diesen gehören z.B. das Japanische ETWAS (Earthquake and Tsunami Warning System), das Koreanische KPAS (Korean Public Alerting System), das US-Amerikanische WEA (Wireless Emergency Alerts) und auch das EU-ALERT mit den nationalen Implementationen NL-ALERT (Niederlande) und UK-ALERT (Großbritannien).

Die zahlreichen Studien und Untersuchungen, die zur Gestaltung obiger Systeme und der internationalen Standards im Mobilfunk geführt haben, weisen auch nochmal nach, was sowieso vorher jedem Techniker offensichtlich erscheint: Eine schelle Alarmierung aller Teilnehmer (einer Region) kann nur über einen Broadcast-Mechanismus erfolgen. In Japan war die Zielvorgabe, die Alarmierung in Erdbebenfällen innerhalb von weniger als 4 Sekunden an die gesamte betroffene Bevölkerung zu übertragen. Und das ist mit PWS möglich!

Die relevanten PWS-Standards in 2G/3G/4G/5G bieten jede Menge nützliche Funktionen:

  • Benachrichtigung in bestimmten geographischen Regionen

  • Interoperable Schnittstellen, so das Netzwerkelemente unterschiedlicher Hersteller mit einander Kommunizieren

  • Konfigurierbare Benachrichtigungstexte, nicht nur in der primären Landessprache, sondern auch in mehreren anderen Sprachen, die dann automatisch je nach Spracheinstellung des Telefons wiedergegeben werden

  • Unterschiedliche Schweregrad von Alarmierungen

  • Übermittlung nicht nur im Broadcast, sondern auch im Unicast an jeden Teilnehmer, der gerade in einem Telefongespräch ist, und dessen Telefon gerade währenddessen aus technischen Gründen den Broadcast nicht empfangen würde

  • Unterschied zwischen Wiederholung einer Übertragung ohne Änderung des Inhalts und einer übertragung mit geändertem Inhalt

Es gibt also seit vielen Jahren internationale Standards, wie sämtliche heute eingesetzten Mobilfunktechniken zur schnellen, effizienten und datensparsamen Alarmierung der Bevölkerung eingesetzt werden können.

Es gibt zahlreiche Länder, die diese Systeme seit langem einsetzen. Das US-Amerikanische WEA wurde nach eigenen Angaben seit 2012 bereits mehr als 61.000 Mal benutzt, um Menschen vor Unwetter oder anderen Katastrophen zu warnen.

Sogar innerhalb der EU hat man das EU-ALERT System spezifiziert, welches weitgehend mit dem amerikanischen WEA identisch ist, und auf die gleichen Techniken aufbaut.

Und dann gibt es Länder wie Deutschland, die es seit genauso vielen Jahren vermissen lassen, durch Gesetze oder Vorschriften

  1. die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet

  2. die Netzbetreiber zur Bereitstellung von standardisierten Schnittstellen gegenüber den Behörden wie Zivilschutz / Katastrophenschutz zu verpflichten, so das diese selbständig über alle Netzbetreiber Warnungen versenden können

  3. die Gerätehersteller z.B. über Vorschriften des FTEG (Gesetz über Funkanlagen und Telekommunikationsendeinrichtungen) zu Verpflichten, die PWS-Nachrichten anzuzeigen

In den USA, dem vermeintlich viel mehr dem Freien Markt und dem Kapitalismus anhängenden System ist all dies der Regulierungsbehörde FCC möglich. In Deutschland mit seiner sozialen Marktwirtschaft ist es anscheinend unmöglich, den Markt entsprechend zu regulieren. Eine solche Regulierung schafft man in Deutschland nur für wirklich wichtige Themen wie zur Durchsetzung der Bereitstellung von Schnittstellen für die Telekommunikationsüberwachung. Bei so irrelevanten Themen wie dem Katastrophenschutz und der Alarmierung der Bevölkerung braucht man den Markt nicht zu regulieren. Wenn die Netzbetreiber kein PWS anbieten wollen, dann ist das einfach so Gottgegeben, und man kann da ja nichts machen.

Falls jemand sich SMSCB und PWS technisch näher ansehen will: In 2019 haben wir im Osmocom-Projekt eine Open Source Implementation des kompletten Systems von BTS über BSC bis zum CBC, sowie der dazwischen befindlichen Protokolle wie CBSP vorgenommen. Dies wurde freundlicherweise durch den Prototype Fund mit EUR 35k finanziert. Ja, so günstig kann man die nötige Technik zumindest für eine einzelne Mobilfunkgeneration entwickeln...

Man kann also in einem selbst betriebenen Labor-Mobilfunknetz, welches auf Open Source Software basiert mehr in Punkt standardkonformer Notfallalarmierung, als die Deutsche Politik, Verwaltung und Netzbetreiber zusammen hinbekommen.

Wir haben in Deutschland Leute, die diese Standards in und auswendig kennen, sogar daran mitgearbeitet haben. Wir haben Entwickler, die diese Standards implementiert haben. Aber wir schaffen es nicht, das auch mal selbst praktisch zu benutzen - das überlassen wir lieber den anderen Ländern. Wir lassen lieber zuerst die ganze Katastrophenalarmierung mittels Sirenen vergammeln, machen den Netzbetreibern keine Vorgaben, entwicklen komische Apps, die Anwender extra installieren müssen, die prinzipbedingt nicht skalieren und beim Test (WarnTag) nicht funktionieren.

Was für eine Glanzleistung für den hochentwickelten Techhologie-Standort Deutschland.

by Harald Welte at July 18, 2021 10:00 PM

Notfallwarnung im Mobilfunknetz + Cell Broadcast

[excuse this German-language post, this is targeted at the current German public discourse]

In mehrerern Gegenden Deutschlands gab es verheerende Hochwasser, und die Öffentlichkeit diskutiert deshalb mal wieder die gute alte Frage nach dem adäquaten Mittel der Alarmierung der Bevölkerung.

Es ist einfach nur ein gigantisches Trauerspiel, wie sehr die Deutsche Politik und Verwaltung in diesem Punkt inzwischen seit Jahrzehnten sämtliche relevanten Standards verpennt, und dann immer wieder öffentlich durch fachlich falsche und völlig uninformierte Aussagen auffällt.

Das Thema wurde vor dem aktuellen Hochwasser bereits letztes Jahr im Rahmen des sog. WarnTag öffentlich diskutiert. Auch hier von Seiten der öffentlichen Hand ausschliesslich mit falschen Aussagen, wie z.B. dass es bei Cell Broadcast Datenschutzprobleme gibt. Dabei ist Cell Broadcast die einzige Technologie, wo keine Rückmeldung des einzelnen Netzteilnehmers erfolgt, und das Netz nichtmal weiss, wer die Nachricht empfangen hat, und wo dieser Empfang stattgefunden hat. Ganz wie beim UKW-Radio.

Fakt ist, dass alle digitalen Mobilfunkstandards seit GSM/2G, d.h. seit 1991 die Möglichkeit mitbringen, effizient, schnell und datensparsam alle Nutzer (einer bestimmten geographischen Region) mit sogenannten broadcast Nachrichten zu informieren. Diese Technik, in GSM/2G genannt Cell Broacast (oder auch _SMSCB_), unterscheidet sich Grundlegend von allen anderen Kommunikationsformen im Mobilfunknetz, wie Anrufe und herkömmliche SMS (offiziell SMS-PP). Anrufe, SMS und auch mobile Paketdaten (Internet) werden immer für jeden Teilnehmer individuell auf ihm zugewiesenen Funkressourcen übermittelt. Diese Ressourcen sind beschränkt. Es können in keinem Mobilfunknetz der Welt alle Teilnehmer gleichzeitig telefonieren, oder gleichzeitig SMS empfangen.

Stattdessen benutzt Cell Broadcast - wie der Name bereits unmissverständlich klar macht - Einen broadcast, d.h. Rundsendemechanismus. Eine Nachricht wird einmal gesendet, benötigt also nur eine geteilte Ressource auf der Luftschnittstelle, und wird dann von allen Geräten im Empfangsbereich zeitgleich empfangen und dekodiert. Das ist wie UKW-Radio oder klassisches terrestrisches Fernsehen.

Cell Broadcast wurde bereits in den 1990er Jahren von Deutschen Netzbetreibern benutzt. Und zwar nicht für etwas lebensnotwendiges wie die Notfallsignalisierung, sondern für so banale Dinge wie die Liste jener Vorwahlen, zu denen gerade ein vergünstigter "wandernder Ortstarif" Besteht. Ja, sowas gab es mal bei Vodafone. Oder bei O2 wurden über lange Zeit (aus unbekannten Gründen) die GPS-Koordinaten der jeweiligen Basisstation als Cell Broadcast versendet.

In der folgenden (nun fast abgeschalteten) Mobilfunkgeneration 3G wurde Cell Broadcast leicht umbenannt als Service Area Broadcast beibehalten. Schliesslich gibt es ja Länder mit - anders als in Deutschland - funktionierender und kompetenter Regulierung des Telekommunikationsmarktes, und die langjährig bestehenden gesetzlichen Anforderungen solcher Länder zwingen die Netzbetreiber und auch die Ausrüster der Neztbetreiber, neue Mobilfunkstandards so zu entwickeln, dass die gesetzlichen Vorgaben bzgl. der Alarmierung der Bevölkerung im Notfall funktioniert.

Im Rahmen dieser Standardisierung haben eine Reihe von Ländern innerhalb der 3GPP-Standardisierung (zuständig für 2G, 3G, 4G, 5G) sogenannte Public Warning Systems (PWS) standardisiert. Zu diesen gehören z.B. das Japanische ETWAS (Earthquake and Tsunami Warning System), das Koreanische KPAS (Korean Public Alerting System), das US-Amerikanische WEA (Wireless Emergency Alerts, früher bekannt als CMAS) und auch das EU-ALERT mit den nationalen Implementationen NL-ALERT (Niederlande) und UK-ALERT (Großbritannien) sowie RO-ALERT (Rumänien).

Die zahlreichen Studien und Untersuchungen, die zur Gestaltung obiger Systeme und der internationalen Standards im Mobilfunk geführt haben, weisen auch nochmal nach, was sowieso vorher jedem Techniker offensichtlich erscheint: Eine schelle Alarmierung aller Teilnehmer (einer Region) kann nur über einen Broadcast-Mechanismus erfolgen. In Japan war die Zielvorgabe, die Alarmierung in Erdbebenfällen innerhalb von weniger als 4 Sekunden an die gesamte betroffene Bevölkerung zu übertragen. Und das ist mit PWS möglich!

Die relevanten PWS-Standards in 2G/3G/4G/5G bieten jede Menge nützliche Funktionen:

  • Benachrichtigung in bestimmten geographischen Regionen

  • Interoperable Schnittstellen, so dass Netzwerkelemente unterschiedlicher Hersteller miteinander kommunizieren

  • Konfigurierbare Benachrichtigungstexte, nicht nur in der primären Landessprache, sondern auch in mehreren anderen Sprachen, die dann automatisch je nach Spracheinstellung des Telefons wiedergegeben werden

  • Unterschiedliche Schweregrade von Alarmierungen

  • Übermittlung nicht nur im Broadcast, sondern auch im Unicast an jeden Teilnehmer, der gerade in einem Telefongespräch ist, und dessen Telefon gerade währenddessen aus technischen Gründen den Broadcast nicht empfangen würde

  • Unterschied zwischen Wiederholung einer Übertragung ohne Änderung des Inhalts und einer übertragung mit geändertem Inhalt

Es gibt also seit vielen Jahren internationale Standards, wie sämtliche heute eingesetzten Mobilfunktechniken zur schnellen, effizienten und datensparsamen Alarmierung der Bevölkerung eingesetzt werden können.

Es gibt zahlreiche Länder, die diese Systeme seit langem einsetzen. Das US-Amerikanische WEA wurde nach eigenen Angaben seit 2012 bereits mehr als 61.000 Mal benutzt, um Menschen vor Unwetter oder anderen Katastrophen zu warnen.

Sogar innerhalb der EU hat man das EU-ALERT System spezifiziert, welches weitgehend mit dem amerikanischen WEA identisch ist, und auf die gleichen Techniken aufbaut.

Und dann gibt es Länder wie Deutschland, die es seit genauso vielen Jahren vermissen lassen, durch Gesetze oder Vorschriften

  1. die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet

  2. die Netzbetreiber zur Bereitstellung von standardisierten Schnittstellen gegenüber den Behörden wie Zivilschutz / Katastrophenschutz zu verpflichten, so das diese selbständig über alle Netzbetreiber Warnungen versenden können

  3. die Gerätehersteller z.B. über Vorschriften des FTEG (Gesetz über Funkanlagen und Telekommunikationsendeinrichtungen) zu Verpflichten, die PWS-Nachrichten anzuzeigen

In den USA, dem vermeintlich viel mehr dem Freien Markt und dem Kapitalismus anhängenden System ist all dies der Regulierungsbehörde FCC möglich. In Deutschland mit seiner sozialen Marktwirtschaft ist es anscheinend unmöglich, den Markt entsprechend zu regulieren. Eine solche Regulierung schafft man in Deutschland nur für wirklich wichtige Themen wie zur Durchsetzung der Bereitstellung von Schnittstellen für die Telekommunikationsüberwachung. Bei so irrelevanten Themen wie dem Katastrophenschutz und der Alarmierung der Bevölkerung braucht man den Markt nicht zu regulieren. Wenn die Netzbetreiber kein PWS anbieten wollen, dann ist das einfach so Gottgegeben, und man kann da ja nichts machen.

Falls jemand sich SMSCB und PWS technisch näher ansehen will: In 2019 haben wir im Osmocom-Projekt eine Open Source Implementation des kompletten Systems von BTS über BSC bis zum CBC, sowie der dazwischen befindlichen Protokolle wie CBSP vorgenommen. Dies wurde freundlicherweise durch den Prototype Fund mit EUR 35k finanziert. Ja, so günstig kann man die nötige Technik zumindest für eine einzelne Mobilfunkgeneration entwickeln...

Man kann also in einem selbst betriebenen Labor-Mobilfunknetz, welches auf Open Source Software basiert mehr in Punkt standardkonformer Notfallalarmierung, als die Deutsche Politik, Verwaltung und Netzbetreiber zusammen hinbekommen.

Wir haben in Deutschland Leute, die diese Standards in und auswendig kennen, sogar daran mitgearbeitet haben. Wir haben Entwickler, die diese Standards implementiert haben. Aber wir schaffen es nicht, das auch mal selbst praktisch zu benutzen - das überlassen wir lieber den anderen Ländern. Wir lassen lieber zuerst die ganze Katastrophenalarmierung mittels Sirenen vergammeln, machen den Netzbetreibern keine Vorgaben, entwicklen komische Apps, die Anwender extra installieren müssen, die prinzipbedingt nicht skalieren und beim Test (WarnTag) nicht funktionieren.

Was für eine Glanzleistung für den hochentwickelten Techhologie-Standort Deutschland.

by Harald Welte at July 18, 2021 10:00 PM

July 09, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #10 - setting up open5gs

We're happy to announce the 10th incarnation of OsmoDevCall

This time miaoski will be presenting a live demo on how to setup a 4G/5G core network with open5gs.

The topics will include a brief introduction of open5gs, its environment, config files, network topology.

When: Friday, July 9th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at July 09, 2021 02:47 PM

June 25, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #9 - No presentation, just i...

We're happy to announce the 9th incarnation of OsmoDevCall

This time nobody has volunteered to give a talk, so we will just have the USSE (Unstructured Supplementary Social Event).

When: Friday, June 25th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at June 25, 2021 03:54 PM

June 08, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #8 - Screen sharing peek at ...

We're happy to announce the 8th incarnation of OsmoDevCall

This time keith will be presenting a screen sharing peek at TIC A.C. infrastructure in Oaxaca

TIC A.C. is an operator of Osmocom based community cellular networks in indigenous communities of the Mexican state of Oaxaca. Keith works with Rhizomatica and TIC A.C. and will give us some live insight into how they operate

When: Friday, June 11th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at June 08, 2021 01:26 PM

May 27, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #7 - Hacking binary protocol...

We're happy to announce the 6th incarnation of OsmoDevCall

This time fixeria will be presenting about Hacking binary protocols with Pycrate

When: Friday, May 28th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at May 27, 2021 05:04 PM

May 12, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #6 - SS7/SIGTRAN in 2G/3G networks

We're happy to announce the 6th incarnation of OsmoDevCall

This time laforge will be presenting about SS7 and SIGTRAN in 2G/3G networks

This talk will cover some classic circuit-switched SS7 basics as well as SIGTRAN (SS7 over IP) and how this is used as underlying transport for a variety of interfaces in the 2G (GSM) and 3G (UMTS) cellular networks even today.

When: Friday, May 14th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at May 12, 2021 09:58 PM

April 18, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #5 - YIG & YANG (Yet ANother yiG driver)

We're happy to announce the 5th incarnation of OsmoDevCall

This time horiz0n will be presenting about YIG & YANG (Yet ANother yiG driver)

This talk will briefly introduce the working principles of YIG (Yttrium Iron Garnet) microwave circuits, their applications and finally conclude with a presentation of a recently developed driver circuit.

When: Friday, April 23rd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at April 18, 2021 05:21 PM

April 11, 2021

Osmocom.org News

pySim - Video of pySim-shell presentation

As part of the April 9, 2021 OsmoDevCall, there was a presentation by laforge on pySim-shell, the latest member of the pySim software suite.

pySim-shell is an interactive, scriptable command-line environment for expliring, editing and configuring SIM/USIM/ISIM cards.

A video recording of the talk is now available from https://people.osmocom.org/tnt/osmodevcall/osmodevcall-20210409-laforge-pysim-shell_h264_420.mp4

Thanks to tnt for editing/merging the video.

by laforge at April 11, 2021 12:53 PM

April 07, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #4 - pySim-shell for SIM card configuration

We're happy to announce the 4th incarnation of OsmoDevCall

This time Harald Welte will be presenting about pySim-shell, the next generation of SIM card configuration tool

When: Friday, April 9th, 2021 from 20:00 CET

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at April 07, 2021 07:25 PM

March 20, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #3 - multi-TRX + frequency hopping in Os...

We're happy to announce the 3rd incarnation of OsmoDevCall

This time Vadim Yanitskiy will be presenting about multi-TRX + frequency hopping in OsmoBTS

When: Friday, March 26th, 2021 from 20:00 CET
Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at March 20, 2021 06:21 PM

February 26, 2021

Osmocom.org News

Cellular Network Infrastructure - February 2021 Osmocom CNI releases

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

Those new tagged/released versions contain in some cases up to one year of work
since the previous versions released during January 2020 (on some projects,
patch and intermediate releases were done during the year). The primary focus
was on bug-fixing and stabilization as well as some major new features, such as
IPv6 support.

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
libgtpnl 1.2.2 http://git.osmocom.org/libgtpnl/plain/debian/changelog?h=1.2.2
libasn1c 0.9.33 http://git.osmocom.org/libasn1c/plain/debian/changelog?h=0.9.33
libsmpp34 1.14.1 http://git.osmocom.org/libsmpp34/plain/debian/changelog?h=1.14.1
libosmocore 1.5.1 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.5.1
libosmo-abis 1.1.1 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=1.1.1
libosmo-netif 1.1.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=1.1.0
libosmo-sccp (+ OsmoSTP) 1.4.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.4.0
libosmo-ranap (+ OsmoHNBGW) 0.7.0 http://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=0.7.0
OsmoTRX 1.3.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.3.0
OsmoBTS 1.3.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.3.0
OsmoPCU 0.9.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=0.9.0
OsmoBSC 1.7.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.7.0
OsmoMSC 1.7.0 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.7.0
OsmoHLR 1.3.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.3.0
osmo-mgw 1.8.1 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.8.1
osmo-sip-connector 1.5.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.5.0
OsmoSGSN 1.7.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.7.0
OpenGGSN 1.7.1 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.7.1
osmo-pcap 0.1.3 http://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.1.3
osmo-gbproxy 1:0.1.0 http://git.osmocom.org/osmo-gbproxy/plain/debian/changelog?h=0.1.0
osmo-cbc 0.2.2 http://git.osmocom.org/osmo-cbc/plain/debian/changelog?h=0.2.2
osmo-smlc 0.2.0 http://git.osmocom.org/osmo-smlc/plain/debian/changelog?h=0.2.0
osmo-e1d 0.2.0 http://git.osmocom.org/osmo-e1d/plain/debian/changelog?h=0.2.0
osmo-gsm-manuals 1.1.0 http://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=1.1.0

Noteworthy Changes

Misc / Common

  • libosmocore: Introduce support for signalfd
  • libosmocore: Improvements/fixes for multi-thread processes
  • libosmocore: Event loop migrated from select() to poll()
  • libosmocore: The library now provides Hashtable data structure support
  • libosmocore: The library now provides an inter-thread queue API
  • libosmocore: Initial support for static userspace probes via systemtap
  • libosmocore: lapdm: fixed SAPI-0/SAPI-3 frame prioritization on DCCH
  • libosmocore: logging: New systemd-journal target
  • libosmocore: logging: New log line prefix "thread-id"
  • libosmogb: New NS2 API (see Network_service_(NS))
  • libosmogb: Add Frame Relay support
  • libosmo-abis: Improve TRAU support
  • VTY: New "expert" mode introduced
  • VTY: Commands can now contain attributes providing information about the command
  • VTY: Most projects generate now xml output automatically at build time
  • VTY: Most projects now allow setting scheduler cpu-affinity and RR priority
  • Several improvements and fixes to stats / rate counters
  • Lots of fixes for struct bit fields on big-endian systems
  • RPM spec files added to most projects
  • IPv6 support added to lots of interfaces on several projects, both on transport side as well as on signalling.

OsmoTRX

  • uhd: Support UHD >=3.11 logging framework
  • lms: Initial multi-arfcn support
  • ipc: Introduce new backend osmo-trx-ipc
  • Introduce osmo-prbs-tool: PRBS tool sending PRBS sequence to TRX
  • CTRL threads removed, now handled by main thread
  • OsmoTRX now provides Nominal Tx Power to osmo-bts through "NOMTXPOWER" in TRXC protocol
  • Introduced new TRXC "MUTE" command
  • TxGain is now applied based on expected Tx output power through empirical measurements (#4583)
  • Calculate RSSI offset based on RxGain configuration
  • New rate counters available to check whether timing issues are occurring in low level layers, TRXD, etc.
  • Documentation improvementes and fixes
  • Several generic optimizations, fixes, etc.

OsmoBTS

OsmoPCU

OsmoBSC

  • Ericsson RBS2000: Improved Support (OM2000)
  • Siemens BS-11: Improved support
  • Validate codec settings configuration at startup
  • OML failure reports are store and can be displayed over VTY
  • Stats / counters improvements and fixes
  • IMSI filtering features have been removed completely
  • All BSC originated USSD notification features have been removed completely
  • Support MSC pooling
  • ACC barring: Implement barred subset rotation
  • Lots of improvements to Handover related logic
  • Cell Broadcast: CBSP VTY configuration commands rewritten
  • LCS: Introduced support for Lb interface (against SMLC)
  • New set of FSMs handling OML provisioning
  • Improvements to BTS power control (BS power)
  • Support ACCH repetition
  • Support Emergency Call preemption
  • Support specifying PS neighbors in VTY (Introduce CTRL interface for Neighbor resolution)
  • Per-burst attenuation for BS power control is now applied correctly

OsmoMSC

  • Rudimentary NRI support added
  • Support new MNCCv7 protocol version (with IPv6 support)
  • Lots and lots of fixes and small improvements
  • Proper call teardown if a call leg disconnects unexpectedly

OsmoHLR (and libosmo-gsup-client)

  • Introduce support for D-GSM (Distributed GSM), mslookup server
  • Introduce libosmo-mslookup library and osmo-mslookup-client tool
  • GSUP connections now set TCP_NODELAY
  • support the XOR algorithm for UMTS AKA

OsmoMGW (and libosmo-mgcp-client)

  • Add CTRL interface
  • Support E1 endpoints
  • Full IPv6 support in both MGCP and RTP

osmo-sip-connector

  • MNCC v7: IPv6 support

OsmoSTP (and libosmo-sigtran)

  • IPv6 support (together with IPv4+IPv6 SCTP multi-homing)
  • Initial support for M3UA and SUA sub-protocol [S]SNM
  • Initial support for SCCP minimalistic SCMG implementation
  • Lots of fixes and small improvements

OsmoSGSN

  • Implement RAT change between 2G and 3G
  • Support RIM procedure routing
  • Use the new NS2 osmocom stack

OsmoGGSN (and libgtp)

  • Introduce netns support for tun interfaces
  • sgsnemu: Support handling IPv6 SLAAC in tun interface, improve IPv6 support

by pespin at February 26, 2021 03:56 PM

February 13, 2021

Osmocom.org News

OsmoBTS - Summary of OsmoBTS work during 2020

This is a summary of the work that has happened on OsmoBTS in the January 2020 through early February 2021 time frame.

In general, a large focus has been on variuos "enterprise" features that are mostly relevant to operating BTSs with large number of TRX in dense (urban) interference limited networks. This is quite a bit different from the more traditional OsmoBTS use cases in rural applications, where networks are limited by coverage, and not by interference.

OsmoBTS (osmo-bts-trx) has now been tested successfully with configurations up to 8TRX.

Major changes:
  • BS (downlink) power control
  • baseband frequency hopping
  • tons of fixes regarding the accuracy of measurement reports (which is very important for proper hand-over performance)
  • EWMA based filtering of power control loops
  • Repeated downlink SACCH support; 3GPP Release 6 (#4794)
  • Repeated uplink SACCH support; 3GPP Release 6 (#4795)
  • Repeated downlink FACCH support (#4796)

The slightly more detailed versions below:

Common/General changes

  • various fixes regarding measurement reporting / averaging
  • 11bit RACH support
  • print lchan name in all log lines / simplify debugging (#1938)
  • improved reporting of BTS features/capabilities to BSC
  • BS (downlink) power control
  • power ramp-down on BTS shutdown
  • power ramp-up/ramp-down during ADM state changes
  • many fixes to A-bis OML MO finite state machines
  • OML: fix ARFCN range checks
  • support setting real-time scheduler priority via VTY
  • OML Fix Radio Carrier OPSTATE change report not sent in all scenarios
  • OML + PCU interface: Support for IPv6 NS-VCs to PCU
  • automatic VTY reference generation --vty-ref-xml (#1601)
  • Only send SI13 if PCU is connected (#3075)
  • Don't broadcast SI4 GPRS indicator if PCU is not connected (#3075)
  • power_control: EWMA based uplink power filtering
  • count measurements for FACCH/F only once (#4799)
  • count all blocks for "SUB" for TCH/F in signaling mode (#4799)
  • fix number of expected measurements (#4799)
  • fix integer overflow in measurement processing (#4799)
  • fix L1 SAPI activation ordering in hand-over (likely impacts handover performance)
  • Repeated downlink SACCH support; 3GPP Release 6 (#4794)
  • Repeated uplink SACCH support; 3GPP Release 6 (#4795)
  • Repeated downlink FACCH support (#4796)
  • Activate DL SACCH only when TA is known (#4008, #4009)

osmo-bts-trx specific changes

Traditionally, osmo-bts-trx used to have less features than the other osmo-bts variants (such as osmo-bts-sysmo for sysmoBTS devices).
The focus of the development has meanwhile shifted, and osmo-bts-trx has been catching up significantly, and in some cases even exceeding the capabilities of osmo-bts-{sysmo,lc15,oc2g,octphy}.

  • TRX: nope indications; fixes many measurement related issues
  • TRX: AMR DTX frame detection (#2978)
  • TRX: fix uplink measurement reporting durign hand-over (#4592)
  • TRX: power-ramping during BTS power up
  • TRX: Fix reading out of buffer during tx of dummy burst on PDCH TS with EGPRS enabled (#4606)
  • TRX: baseband frequency hopping support (#4546)
  • TRX: Fix crash due to ASSERT related to dynamic timeslots (#4920)
  • TRX: Fix crash due to ASSERT related to rf-lock and dynamic timeslots
  • TRX: significantly reduce clock advance, reducing latency significantly (#4487)

by laforge at February 13, 2021 06:01 PM

OsmoPCU - Summary of OsmoPCU work during 2020

This is a summary of the work that has happened on the osmo-pcu software in 2020, specifically the timeframe January 2020 through early February 2021.

  • large number of various CSN.1 encoder/decoder fixes
  • fix an infinite loop in CSN.1 dissector
  • fix pcu_sock related memory leak
  • MS RA capability parsing fixes (#4463)
  • properly encode P-TMSI in RR PAGING REQUEST
  • Fix UL-ACK not sent to MS if intermediate UL block is lost
  • 11bit RACH support (EGPRS Packet channel Requeset, #1548)
  • do not encode out-of-range TA value
  • fix RRBP field in packet uplink assignment
  • add support for IPv6 NS-VCs
  • add support for frequency hopping
  • fix crashes due to NULL pointer deref (#4756)
  • downgrade to DL MCS1-4 when USF for GPRS_only MS (#4544)
  • Get rid of LLC UI dummy blocks following other data (#4849)
  • support GPRS concurrently with EGPGRS (previously only either/or)
  • support Gb interface with IP-SNS
  • Fix Dl EGPRS data blocks being generated occasionally on GPRS TBFs (#4973)
  • NACC (Network Assisted Cell Change) support
So in short:
  • lots of bugs fixed all over
  • GPRS and EPGRS are no longer exclusive, but GPRS-only MS can be served while EGPRS is active
  • Network Assisted Cell Change is going to significantly improve cell reselection performance
  • IPv6 support on the Gb interface
  • IP-SNS support on the Gb interface

We are planning to tag a new osmo-pcu release soon-ish. This is mainly awaiting the full stabilization of the "NS2" (new NS code) VTY interface and APIs. Once released, those will be stable and cannot be modified in incompatible manner anymore.

by laforge at February 13, 2021 05:51 PM

December 27, 2020

Osmocom.org News

E1/T1 Hardware Interface (including icE1usb) - Development of DAHDI driver for icE1usb

So far, the icE1usb reuired a custom user-space driver (osmo-e1d) in order to operate. While this has the advantage that no kerne/operating system level code is required, it has a few disadvantages such as the increased overhead of frequent context switches, the increased propability of overruns/underruns and the lack of interoperability with other software outside the Osmocom universe.

A first version of a DAHDI hardware driver for icE1usb is now available for public beta-testing, for details see redmine issue #4923

Using this DAHDI driver, it should be possible to use icE1usb with any DAHDI-using application, such as Asterisk, FreeSWITCH and others.

by laforge at December 27, 2020 12:32 PM

E1/T1 Hardware Interface (including icE1usb) - Osmocom icE1usb USB E1 adapter available from sysm...

Fully assembled and tested icE1usb adapters are now available via the sysmocom webshop for purchase.

As a fully Open Source Hardware (OSHW) design, anyone can of course assemble their own hardware units based on the design files within the git repository.

by laforge at December 27, 2020 12:26 PM

December 04, 2020

Dieter Spaar

Modern TPMS Sensors: Let's try a DoS attack

TPMS (Tire-pressure monitoring system) sensors have been researched extensively many years ago, they periodically transmit the tire pressure, temperature and a unique ID which can be misused for tracking a vehicle. But there is another aspect: modern TMPS sensors also have a receiver which is typically used to trigger the data transmission when a new TPMS sensor is presented to the vehicle ("learning procedure").

Here in Europe TPMS sensors usually transmit on the 433 MHz ISM band. The receiver operates on 125 kHz, very similar to LF RFID. A simple way to make use of the receiver is just to look for the presence of the 125 kHz carrier and then trigger data transmission. Current sensors are usually more evolved and use a modulated carrier which contains command packets and only if the correct command is received data transmission is triggered.

If you already have a receiver you can do of course more than just trigger data transmission: For example there might be support for different commands, some sensors even allow firmware updates this way.

One such command which is typically supported is switching the sensor into "Shipping" mode. Why would you need that? When the sensor is operating normally it waits for motion (there is an acceleration/shock sensor inside) and only starts periodic data transmission when the wheel is rotating. This is used to safe battery life. When the TPMS sensor is not yet mounted in the tire it should not react on motion, that’s why there is this "Shipping" mode. In this mode the sensor only wakes up every few seconds and looks if there is a 125 kHz signal, if yes it checks for a valid command, for example the command to trigger data transmission which usually also leaves "Shipping" mode and switches the sensor into normal operation.

This "Shipping" mode can be misused: If you can switch a TPMS sensor of a vehicle’s wheel into "Shipping" mode the sensor will no longer transmit data and the vehicle's tire pressure control light will go on after a while. Just to make it clear: This warning light is annoying to the driver, it does not affect safety of the car because the deactivated TMPS sensor has not affected the actual tire pressure.

I have looked at a few TPMS sensors for different cars if this really works, I choose sensors for BMW and Ford cars. Please note that most certainly other car manufactures are affected too, mainly because there are only a few manufactures of TPMS sensors which deliver their sensors to various car manufactures. My choice for BMW and Ford came from the fact that I found lots of cheap, used sensor for those cars.

Also I only looked at "OEM" sensors for BMW and Ford, which means that those sensors are mounted by the car manufacturer. There are also so called "Universal" sensors which are typically mounted by tire dealers, there are some notes about them at the end of this text.

It is quite easy to build a tool for transmitting data on 125 kHz: There is this cheap EL-50448 TMPS sensor activation tool which only transmits a carrier without modulation. However the hardware can easily be modified to modulate the carrier: Most of the time OOK (On-Off Keying) is used for communication, which means that the carrier is just turned on and off. The EL-50448 uses a power driver with an unused "enable" pin to generate the carrier, you can use this "enable" pin to modulate the carrier. The data rate is slow, a frequently used rate is 3900 baud. Most of the time Manchester encoding of the data bits is used, which means that the carrier changes twice as much (7800 changes per second). This is nothing special and can be done with probably any microcontroller you prefer to use. The hardware costs for such a setup are below EUR 20, the transmission range is about 20 centimeters.

How can you find the command to switch to Shipping" mode? Brute force by trying all possible commands is only an option if the command is short. The reason is that the sensor only looks for the LF 125 kHz signal every few seconds. If the command is not longer than two bytes brute force is possible (it takes a few days), for longer commands it is impractical. Please note that you also have to find a way to detect if the command you send causes a reaction of the TPMS sensor, e.g. by monitoring the power consumption of the sensor or receiving the 433 MHz data signal (which of course only works if the command you send causes a data transmission).

Another option is looking at those TPMS tools which tire dealers and car repair workshops use to check TPMS sensors. Some of those tools might support switching a TPMS sensor into "Shipping" mode.

Those are the results I found (I won't go into the details to avoid misuse):

  • BMW: A certain sensor used in several car models from TPMS Sensor manufacturer "A" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. Also if the sensor detects a fast pressure change (e.g. by inflating the tire) the sensor leaves "Shipping" mode. The command length is four bytes so brute force is no option.
  • Ford: A certain sensor used in several car models from TPMS Sensor manufacturer "A" (the same manufacture as above for the BMW sensor) can be switched into "Shipping" mode, it is the same command as used by the BMW sensor from above. The deactivated TPMS sensor can be activated again with a different command.

    A certain sensor used in several car models from TPMS Sensor manufacturer "B" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. The command in this case is only two bytes and I tried all combinations which resulted in several more "interesting" commands, a few examples:

    • It is possible to completely turn off the TPMS sensor. In this case it will no longer react on anything, you have to break open the sensor case and apply a hardware reset or disconnect the battery to reactivate it again.
    • It is possible to switch the sensor into continuous "carrier transmit" mode on 433 MHz. In this mode the sensor will continuously transmit the 433 MHz carrier until the battery is empty or you apply a hardware reset (see above), it will not react on anything else. There are two other similar commands which transmit on the upper and lower shifted frequency (the sensor uses FSK modulation, Frequency Shift Keying, when transmitting data).

    Those examples show that it is basically possible to destroy this specific sensor by transmitting the appropriate command. Also if the sensor is in "carrier transmit" mode it probably disturbs the remote control car key fob which usually uses the same frequency as the TPMS sensor.

You have to be close to the sensor to send those LF 125 kHz signals but it only takes a few seconds to send the signal. Using a larger antenna (which is basically a coil) for the transmitter, e.g. large enough to fit in a suitcase, might extend the transmission range to more than a meter.

How can those problems be avoided? This is actually quite easy, the command to switch into "Shipping" mode should not be allowed if the measured tire pressure is above a certain limit, which means that the sensor is mounted in the tire of a vehicle. This also applies to those other commands of the sensor from manufacturer "B" which are probably some kind of factory test or developer commands. Please note that during my tests the commands I described were possible even when the measured tire pressure was in the range of a typical vehicle wheel.

I contacted the car manufactures (BMW and Ford) before I published this article, this is the experience I made:

  • BMW: The contact information for reporting security issues can be found on the BMW website. I had a phone call with the responsible person within a few days after reporting the issue. BMW already knew the problem, they found it during an internal review. Their latest TPMS sensors have fixed the issue by blocking certain commands if the tire pressure is above a certain limit.
  • Ford: I wasn't able to find a security contact on the website of Ford Germany so I contacted the person responsible for "Public Relation". He promised to look for someone who takes care of the issue I reported, after several days I got a reply that it is possible to disturb the TPMS system due to the nature of radio transmission and that this is a known problem. I wasn't able to communicate directly with the responsible person and I then replied that the reported issue is not about disturbance but a "Denial of Service" and that it is even possible to destroy a certain TPMS sensor used in Ford cars. I didn't receive any further information about the security issue, I notified them again after several weeks that I am now going to publish the issue which was acknowledged.

Some notes about those "Universal" sensors tire dealers normally use: Those sensors are "Universal" because they can be programmed for different car models. The main benefit for the tire dealer is that only a few different kind of "Universal" sensors have to be on stock, it’s not necessary to have lots of different "OEM" TPMS sensors for every possible car model lying around. The programming of those "Universal" sensors most of time uses the LF 125 kHz signal to transfer the programming data to the sensor. Many of those "Universal" sensors can be reprogrammed regardless of the measured tire pressure so an obvious "Denial of Service" attack on those sensors is to simply reprogram them for a different car model.

December 04, 2020 01:00 AM

October 03, 2020

Osmocom.org News

Osmocom.org Servers - gerrit and jenkins upgrades

Our gerrit instance at https://gerrit.osmocom.org has been upgraded from 2.16.x to the latest release 3.2.3. This migrates us away from an (since June) unsupported 2.16.x release.

For https://jenkins.osmocom.org/ we just did a minor LTS upgrade from 2.235.2 to 2.249.1

If there are any problems, please report them in the bug tracker associated with this "Osmocom.org Servers" project in redmine.

by laforge at October 03, 2020 02:01 PM

July 20, 2020

Osmocom.org News

Osmocom.org Servers - scheduled Osmocom outage on *2020-07-21 7:30am CEST*

There will be another scheduled outage of most public Osmocom services (redmine, jenkins, gerrit) on 2020-07-21 7:30am CEST with an expected maximum duration of 45 minutes.

by laforge at July 20, 2020 07:03 AM

July 17, 2020

Osmocom.org News

Osmocom.org Servers - scheduled Osmocom outage on *2020-07-19 9am CEST*

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on Sunday, July 19 2020, starting about 9am CEST.

The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit.

In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law.

Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate.

In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github.

Regards, laforge

by laforge at July 17, 2020 06:44 PM