Planet Osmocom

December 02, 2022

Osmocom.org News

Misc DECT hacks - New DECT research / playground

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/

by laforge at December 02, 2022 09:02 PM

November 30, 2022

Osmocom.org News

Retronetworking - 2022-12-07: RetroNetCall on ISDN B channel protocols

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

by laforge at November 30, 2022 12:18 PM

November 14, 2022

Osmocom.org News

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

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

by laforge at November 14, 2022 06:30 PM

SIMtrace 2 - Video Recording of SIMtrace2 tutorial available

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.

by laforge at November 14, 2022 05:33 PM

November 09, 2022

Osmocom.org News

Cellular Network Infrastructure - Osmocom to receive funding from OpenTechFund

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

See also the project description at the OpenTechFund website

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.

by laforge at November 09, 2022 05:39 PM

November 08, 2022

Osmocom.org News

Cellular Modem Information - Announcing Official Osmocom Fediverse account

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.

by laforge at November 08, 2022 05:25 PM

osmo-e1d - osmo-e1d user manual has been released

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

by laforge at November 08, 2022 12:05 PM

Retronetworking - 2022-11-09: RetroNetCall with OCTOI project status update

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

by laforge at November 08, 2022 11:14 AM

October 25, 2022

Osmocom.org News

Cellular Network Infrastructure - Osmocom binary package repository URLs have changed

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

by osmith at October 25, 2022 11:45 AM

October 17, 2022

Osmocom.org News

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

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

by laforge at October 17, 2022 08:07 PM

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

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