Planet Osmocom

Osmocom.org News: Misc DECT hacks - New DECT research / playground

Fri, 02 Dec 2022 21:02:37 +0000

Millenia (on the IT timescale) after deDECTed and about a decade after the now abandoned OsmocomDECT project, a group of people in and around Osmocom started to play with DECT again. There's no big plan, or no specific goal, other than getting more hands-on hack value with consumer DECT hardware, at its lowest levels.

It started with some innocent ringtone-hacking on a Gigaset C430 by manawyrm, followed by a much appreciated fix for the long-standing bug of Gigaset DECT phones radically over-charging (and eventually killing) their NiMH batteries (see Gigaset_C430_Hacking).

Initially, this required un-soldering and re-programming the SPI flash. After the debug UART was identified on the two test pads accessible from the battery compartment, manawyrm and tobleminer have figured out how to load code into the processor (see also ChipsUsed). Some initial related tools have been created and collected in the https://github.com/TobleMiner/dialog-sc14441-uart-boot repository. Using this you can execute your own code on the Gigaset C430, C300 and likely many other DECT phones using the Sitel (formerly NatSemi, now Renesas SC14xxx chipset family. Those who have had an eye on DECT for a longer time will recognize that this family of chips was also used in both the deDECTed as well as the OsmocomDECT CoA driver. It is also used in the Aastra/Mitel RFP base stations (see this OsmoDevCon2019 talk on RFP base stations and the 36C3 #mifail talk).

It's yet unclear where this will lead to. But it definitely is nice to see some people excited about playing with DECT devices again. If you want to follow developments in real-time, join us on the #osmocom IRC channel on https://libera.chat/

Osmocom.org News: Retronetworking - 2022-12-07: RetroNetCall on ISDN B channel protocols

Wed, 30 Nov 2022 12:18:20 +0000

We're happy to announce the next incarnation of RetroNetCall, the retronetworking oriented spin-off of OsmoDevCall

This time, laforge will be presenting on ISDN B-channel protocols: V.110, V.120, X.75, H.221

Topics include (not limited to)

description of the respective protocol
look at a protocol trace
status of open source implementations

When: Wednesday, December 7, 2022 from 20:00 CET

Time	Topic	Who
20:00	Meet and Greet	everyone
20:10	ISDN B-channel protocols	laforge
21:00	USSE (Unstructured Supplementary Social Event)	everyone

Where: https://osmocom.org/RetroNetCall (Big Blue Button of https://franken.de/)

Osmocom.org News: Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-11-16: MS/BS power control support ...

Mon, 14 Nov 2022 18:30:37 +0000

we're happy to announce the next incarnation of OsmoDevCall. Based on the recent polls, the timing has shifted to every 3rd wednesday of the month.

This time, fixeria will be presenting on MS/BS power control support in OsmoBSC/OsmoBTS.

For those not entirely 3gpp-acronym-savyy: That's how the uplink (phone -> network) and downlink (network -> phone) transmit RF power level is adjusted during an active call in GSM.

When: Wednesday, November 16, 2022 from 20:00 CEST

Time	Topic	Who
20:00	Meet and Greet	everyone
20:10	MS/BS power control support in OsmoBSC/OsmoBTS	fixeria
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/)

Osmocom.org News: SIMtrace 2 - Video Recording of SIMtrace2 tutorial available

Mon, 14 Nov 2022 17:33:48 +0000

Some weeks ago, there was an OsmoDevCall presenting a SIMtrace2 Tutorial.

The video recording of this has now been edited and subsequently has been published at https://media.ccc.de/v/osmodevcall-20221019-laforge-simtrace2-tutorial

The PDF slides can be found at https://gitea.osmocom.org/laforge/laforge-slides/raw/branch/master/2022/osmodevcall-simtrace2/simtrace.pdf

We invite any new users of SIMtrace2 to have a look at this tutorial to get their setup going.

Osmocom.org News: Cellular Network Infrastructure - Osmocom to receive funding from OpenTechFund

Wed, 09 Nov 2022 17:39:16 +0000

We're happy to announce that sysmocom has achieved to obtain funding from Open Technology Fund for a variety of enhancements and improvemnts of the Open Source Cellular Network Infrastructure sphere.

The funded activities are in the following areas:

Better integration between the Osmocom 2G/3G core network elements and the open5gs 4G EPC (evolved packet core)
Improving the stability, quality and maturity of the open5gs EPC by implementing functional test suites in TTCN-3
Establishing interoperability with various base station hardware
Support three trial deployments in rural Mexico with our partner Rhizomatica
Organize a series of webinars for security researchers on how to use our tools for furthering their research projects

We'd like to thank OTF awarding funding to our proposal.

We'd also like to thank Rhizomatica and specifically Peter Bloom for all his help in putting together the proposal.

Osmocom.org News: Cellular Modem Information - Announcing Official Osmocom Fediverse account

Tue, 08 Nov 2022 17:25:22 +0000

Osmocom now has an official fediverse account

@osmocom@fosstodon.org

which we will be using to send updates on osmocom project developments, releases, events, etc.

Web interface is available at https://fosstodon.org/@osmocom

We'd like to thank fosstodon.org for providing a Mastodon instance catering to the FOSS community.

Osmocom.org News: osmo-e1d - osmo-e1d user manual has been released

Tue, 08 Nov 2022 12:05:55 +0000

It was recently noticed that years after first releasing the osmo-e1d software, we still didn't have a user manual for it.

We're happy to announce osmo-e1d now has at least a basic user manual has been merged into the repository

A pre-rendered PDF manual is available from https://downloads.osmocom.org/docs/latest/osmoe1d-usermanual.pdf

As a side-note, in addidition to the existing dpkg packages for various Debian and Ubuntu flavors, we're now also building osmo-e1d rpm packges for CentOS/AlmaLinux 8 and OpenSuse Tumbleweed, see https://obs.osmocom.org/package/show/osmocom:nightly/osmo-e1d

Osmocom.org News: Retronetworking - 2022-11-09: RetroNetCall with OCTOI project status update

Tue, 08 Nov 2022 11:14:25 +0000

We're happy to announce the next incarnation of RetroNetCall, the retronetworking oriented spin-off of OsmoDevCall

This time, laforge will be presenting a General status update on OCTOI (Osmocom Community TDMoIP)

Topics include (not limited to)

migation to co-located hub now fully completed
osmo-e1d status update
the new osmo-isdntap project for tracing/recording D and B channel data
Some initial research into H.221 / dissecting video calls
OCTOI BERT problems
4x new Octoi_Event_PBX for rapid deployment of ISDN+POTS at various events
yate troubles regarding missing call.answer when using record/playback
resuming work on the BRI interface

When: Wednesday, November 9, 2022 from 20:00 CET

Time	Topic	Who
20:00	Meet and Greet	everyone
20:10	OCTOI Project Status Update	laforge
21:00	USSE (Unstructured Supplementary Social Event)	everyone

Where: https://meeting5.franken.de/b/har-0y1-wch-et4 (Big Blue Button of https://franken.de/)

Osmocom.org News: Cellular Network Infrastructure - Osmocom binary package repository URLs have changed

Tue, 25 Oct 2022 11:45:35 +0000

This is a reminder to update the repository URLs. As previously announced:

The binary packages are being built on Osmocom's own OBS server now.
We will stop pushing packages to the openSUSE OBS server at the end of October (in one week).

If you are using Osmocom binary packages, please make sure that you have configured the new repository URLs.

See the wiki for details:
https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages

Osmocom.org News: Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - 2022-10-19: SIMtrace2 Tutorial

Mon, 17 Oct 2022 20:07:29 +0000

After a rather extended 2022 summer break, we're happy to announce the next incarnation of OsmoDevCall. Based on the recent polls, the timing has shifted to every 3rd wednesday of the month.

This time, laforge will be presenting a SIMtrace2 tutorial, showing SIM card protocol tracing, decoding with the new pySim-trace as well as the card emulation firmware.

When: Wednesday, October 19, 2022 from 20:00 CEST

Time	Topic	Who
20:00	Meet and Greet	everyone
20:10	SIMtrace2 Tutorial	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/)

Harald "LaForge" Welte: Deployment of future community TDMoIP hub

Sun, 18 Sep 2022 22:00:00 +0000

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

Harald "LaForge" Welte: Retronetworking at VCFB 2022

Thu, 08 Sep 2022 22:00:00 +0000

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

Running a retronetworking exhibit on Modem and ISDN dial-up
Giving a talk on the Osmocom Community TDMoIP netwokr

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.

Harald "LaForge" Welte: Progress on the ITU-T V5 access network front

Thu, 08 Sep 2022 22:00:00 +0000

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.

Harald "LaForge" Welte: Clock sync trouble with Digium cards and timing cables

Thu, 08 Sep 2022 22:00:00 +0000

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.

bursty bit clock changes until link is up

The first problem is that downstream port transmit bit clock was jumping around in bursts every two or so seconds. You can see an oscillogram of the E1 master signal (yellow) received by one TE820 card and the transmit of the slave ports on the other card at https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4

As you can see, for some seconds the two clocks seem to be in perfect lock/sync, but in between there are periods of immense clock drift.

What I'd have expected is the behavior that can be seen at https://people.osmocom.org/laforge/photos/te820_notimingcable_loopback.mp4 - which shows a similar setup but without the use of a timing cable: Both the master clock input and the clock output were connected on the same TE820 card.

As I found out much later, this problem only occurs until any of the downstream/slave ports is fully OK/GREEN.

This is surprising, as any other E1 equipment I've seen always transmits at a constant bit clock irrespective whether there's any signal in the opposite direction, and irrespective of whether any other ports are up/aligned or not.

But ok, once you adjust your expectations to this Digium peculiarity, you can actually proceed.

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).

Osmocom.org News: OsmoCBC - osmo-cbc 0.4.0 released, now with 4G (SBcAP) support

Tue, 09 Aug 2022 08:35:32 +0000

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

Osmocom.org News: Cellular Network Infrastructure - Binary packages moved to new location

Mon, 11 Jul 2022 11:26:53 +0000

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.

Osmocom.org News: Cellular Network Infrastructure - June 2022 Osmocom CNI releases

Thu, 30 Jun 2022 12:53:48 +0000

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

Osmocom.org News: OCTOI - Osmocom Community TDM over IP - Successful tests with HDLC over OCTOI TDMoIP

Sun, 24 Apr 2022 15:00:43 +0000

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.58/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¶

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

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

Fri, 22 Apr 2022 06:24:06 +0000

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/)

Osmocom.org News: Retronetworking - isdn4linux historical CVS archive

Mon, 18 Apr 2022 15:28:50 +0000

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:

capi4linux (original CVS name NC4Linux)
isdn4linux (original CVS name isdn)
idsn4k-utils (use cvsimport branch)
isdnfax
mISDN
mISDNuser (use cvsimport branch)
web

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

Osmocom.org News: Retronetworking - New Retronetworking Project: Software-Defined Uk0

Fri, 01 Apr 2022 08:16:54 +0000

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.

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).

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

Thu, 24 Mar 2022 15:05:46 +0000

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!

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

Thu, 10 Mar 2022 13:33:11 +0000

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

Osmocom.org News: OCTOI - Osmocom Community TDM over IP - First ISDN deployment over new OCTOI TDMoIP protocol

Mon, 28 Feb 2022 09:35:20 +0000

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:

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).

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

Thu, 24 Feb 2022 13:46:05 +0000

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

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

Thu, 10 Feb 2022 10:18:20 +0000

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!

Osmocom.org News: pySim - pySim user manual now also published as HTML

Wed, 09 Feb 2022 20:09:10 +0000

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.

Osmocom.org News: Retronetworking - German Historical FTZ Standards for ISDN, SS7 and more

Wed, 02 Feb 2022 21:19:48 +0000

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

Osmocom.org News: OCTOI - Osmocom Community TDM over IP - successful initial proof-of-concept of OCTOI TDMoIP

Mon, 31 Jan 2022 11:40:23 +0000

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.

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

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

Fri, 28 Jan 2022 13:00:01 +0000

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/)

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

Tue, 11 Jan 2022 21:13:07 +0000

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/)

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

Sun, 26 Dec 2021 20:07:00 +0000

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/)

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

Fri, 24 Dec 2021 16:46:00 +0000

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

Osmocom.org News: Cellular Network Infrastructure - binary package feeds for Raspbian 11

Mon, 20 Dec 2021 16:46:00 +0000

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

Latest_Builds (last tagged versions), and
Nightly_Builds (automatic current master builds).

For more information check the related pages linked above.

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

Thu, 09 Dec 2021 16:39:00 +0000

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/)

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

Tue, 23 Nov 2021 20:04:00 +0000

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/)

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

Tue, 23 Nov 2021 06:51:00 +0000

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)

Osmocom.org News: Cellular Network Infrastructure - November 2021 Osmocom CNI releases

Fri, 19 Nov 2021 15:39:05 +0000

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

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

Thu, 11 Nov 2021 07:32:00 +0000

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/)

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

Thu, 21 Oct 2021 08:15:00 +0000

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/)

Osmocom.org News: pySim - pySim-shell support for sysmoISIM-SJA2 key data / files

Sat, 16 Oct 2021 08:31:00 +0000

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" 
}

Osmocom.org News: pySim - pySim-prog critical fix against corruption of key material

Sat, 16 Oct 2021 08:22:13 +0000

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.

Harald "LaForge" Welte: First steps towards an ITU-T V5.1 / V5.2 implementation

Sun, 10 Oct 2021 22:00:00 +0000

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 ;)

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

Fri, 08 Oct 2021 05:49:47 +0000

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

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

Thu, 23 Sep 2021 18:49:14 +0000

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/)

Osmocom.org News: Cellular Network Infrastructure - Osmocom package feeds for Debian 11 + Ubuntu 21.04

Fri, 03 Sep 2021 15:57:56 +0000

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.

Osmocom.org News: Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #13 - osmo-remsim in practice

Tue, 24 Aug 2021 11:49:07 +0000

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/)

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

Thu, 12 Aug 2021 11:30:36 +0000

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/)

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

Thu, 22 Jul 2021 06:43:25 +0000

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/)

Harald "LaForge" Welte: Notfallwarnung im Mobilfunknetz + Cell Broadcast (Teil 2)

Mon, 19 Jul 2021 22:00:00 +0000

[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.

Harald "LaForge" Welte: Notfallwarnung im Mobilfunknetz + Cell Broadcast

Sun, 18 Jul 2021 22:00:00 +0000

[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

die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet
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
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.

Harald "LaForge" Welte: Notfallwarnung im Mobilfunknetz + Cell Broadcast

Sun, 18 Jul 2021 22:00:00 +0000

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

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.

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

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

die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet
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
die Gerätehersteller z.B. über Vorschriften des FTEG (Gesetz über Funkanlagen und Telekommunikationsendeinrichtungen) zu Verpflichten, die PWS-Nachrichten anzuzeigen

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

Osmocom.org News: Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #10 - setting up open5gs

Fri, 09 Jul 2021 14:47:14 +0000

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/)

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

Fri, 25 Jun 2021 15:54:42 +0000

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/)

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

Tue, 08 Jun 2021 13:26:19 +0000

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/)

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

Thu, 27 May 2021 17:04:29 +0000

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/)

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

Wed, 12 May 2021 21:58:43 +0000

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/)

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

Sun, 18 Apr 2021 17:21:23 +0000

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/)

Osmocom.org News: pySim - Video of pySim-shell presentation

Sun, 11 Apr 2021 12:53:03 +0000

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.

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

Wed, 07 Apr 2021 19:25:13 +0000

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/)