This is a (late) update about the September/October 2019 activities regarding improvement of OsmoPCU and OsmoSGSN functionality and reliability.
Work has been done, among others, on #4111, #3828, #4228, #3827, #4247, #4102, #3995, #3969, #4029, #1977, #4024, #2406, #4204, #2857, #3922, #4048, #4173, #3727, #43, #4058, #2408, #2955
Unfortunately, OsmoPCU is still one of the least loved projects in the Osmocom universe. Not many people contribute to it, and there are very few commercial users wanting to contribute either financially or by helping with closing some more of the open issues :/
OsmoSTP has received a variety of new features over the last few weeks.
This includes:
- operation of STP in M3UA ASP role (normally a STP operates in SG role): #2005
- operation as STP in STCP client/connect role (normally a STP operates in SCTP server/bind): #2005
- support for SCTP multi-homing with configurable IPs on local and remote end: #3608
- make point-code insertion into SCCP optional at for IPA ASPs: #4219
- dynamic creation of ASPs within an IPA/SCCPlite AS: #4218
- support traffic-mode load-share (in M3UA and IPA): #4220
We also discovered a number of drive-by bugs which were encountered while working on the implementation of the above, see #4247, #4236, #4238, #4234, #4239, #4233, #4235, #4232 - most of which are already fixed.
We furthermore have created a
TTCN-3 test suite for OsmoSTP covering those parts that the existing nplab m3ua and sua test suites don't cover. Test results of all STP related test suites can be seen (as usual) in our jenkins:
Related developments have been funded by a commercial user of OsmoSTP and implemented by pespin and laforge at sysmocom. We rely on funding for maintenance, feature development and bug fixing.
We had recently received the prototype v2 of the m.2/NGFF WWAN modem breakout board and are happy to report that it immediately worked for both USB 3.0 super-speed as well as for PCIe. All debug results and reworks from v1 have been incorporated in this v2.
Design validation has completed, which means a first manufacturing batch is in up in the pipelnie, and we expect boards to become available from the sysmocom webshop in some 4-6 weeks (maybe a bit later due to christmas holidays).
As usual, as the project is an Open Source Hardware, and anyone can go ahead and build their own boards, see http://git.osmocom.org/osmo-small-hardware/tree/ngff-breakout for the design files.
fun fact: The part most difficult to source is the M2x3 wide-flat-head screw that holds the M.2 card in place.
At 36C3, the Osmocom Retro-bBS project will be running a PBX with analog lines and ISDN S0 ports as well as a RAS Server in order to host multiple BBSs and enable attendees to connect modems/ISDN-TA to their computers and dial in to the local BBSs
Current status and plans are summarised at http://lists.osmocom.org/pipermail/bbs-revival/2019-October/000014.html - please do join us if you'd also like to revive the good old BBS days!
The SIMtrace project has from beginning on been designed to not only monitor the communication between a card and the reader (e.g. a SIM and a phone), but also to emulate cards. This card emulation functionality has never been implemented, at least not by the osmocom community, and the project has been hibernating for quite some time. A year ago, the SIMtrace project has been revived. The now old and deprecated micro-controller has been replaced with ARM Cortex-M, but the initial design remains. This change forced us to rewrite the code from scratch, and this is now the SIMtrace 2 project. Monitoring the communication is still available, even with increased stability, but this fresh start was to opportunity the also implement the other long awaited features.
Card emulation is finally there. Is it currently in it's beta phase, but has already been successfully tested. It can even be used in combination with the recent osmo-remsim project, allowing to use multiple cards at remote locations. While it is not completely emulating a card since it only forwards the traffic to a card present in another reader, we are currently working on also providing this functionality. So, feel free to try it out yourself, and let us know using the SIMtrace mailing list if you find any issues. The card emulation wiki article will be updated as we continue on our journey to make SIMtrace the tool it was intended for from beginning on.
It seems we forgot the release announcement in early August:
The Osmocom project has released new version of the CNI (Cellular Network Infrastructure) software, including OsmoTRX, OsmoBTS, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN.
Those new tagged/released versions contain four months of work since the previous versions released during April 2019. The primary focus was on bug-fixing and stabilization as well as some major new features, such as inter-MSC-handover support in osmo-msc.
You can find pre-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at Latest_Builds.
List of tagged versions and link to related ChangeLog¶
Noteworthy Changes¶
Misc / Common¶
- debian packages now have
-doc sub-packages containing the corresponding user and VTY reference manuals of each program.
- various robustness fixes
- support LAPDm payloads with more than 200 bytes
- fsm: Allow millisecond granularity in osmo_fsm built-in timer
- CBSP (Cell Broadcast Service Protocol) implementatin in libosmogsm
- vty parser fixes: don't pass incomplete arguments to vty funcs
- work around gcc bug with gcc < 7.3.0 on ARM related to thread-local storage
- shared IPA keep-alive FSM in libosmocore; use it wherever possible
- libosmo-netif Stream client: fix disconnection logic
- new protocol (TRXDv1) support, mainly for passing C/I value from TRX->BTS->PCU for rate adaptation
- proper counting of under/overruns
- LimeSuite stability improvements (recovery / re-synchronization after drop-outs)
- various internal refactoring / code de-duplication
- fix ARM VFP4 convolution
- LimeSuite: automatic detection of device type and device specific gains
- Various Abis OML protocol conformance fixes
- handling of GPRS SUSPEND (from DCCH -> PCU)
- Full CBCH (Cell Broadcast Channel) support, both basic and extended
- RSL CBCH LOAD INDICATION for CBCH flow control
- RSL BS POWER CONTROL support
- Fix RACH load percentage computation
- clear GPRS indicator form SI3 when PCU is not connected
- fix (so far ignored) MS power control in RSL CHANNEL ACTIVATION
- osmo-bts-oc2g specificx
- systemd service file + example config installation
- status LED fixes
- nominal transmit power fix
- generate failure event report if calibration data missing
- osmo-bts-trx specifics
- TRXDv1 protocol support
- 11-bit RACH support
- Various AMR rate handling related fixes between AoIP and Abis
- AMR: Signal usage of octet-aligned or bandwith-efficient mode to MSC
- various inter-BSC hand-over related fixes for AoIP
- various manual updates, including documentation for 3G/4G neighbor cells, OSMUX, ...
- always default to octet-aligned AMR mode
- keep per-BTS statistics about RACH utilization
- re-introduce support for IPA-encapsulated MGCP (used with osmo-bsc_nat)
- OSMUX support with AoIP (we only supported it with SCCPlite so far)
- support assigning TCH/x in signaling mode
- Add SGs interface for CSFB (circuit switched fall-back) and SMS-over-SGs
- various SMS and USSD handling related fixes
- include libsmpp34 memory allocations in talloc reports
- Fix SMS transmission over Iu (use SAPI3)
- allow user to disable retrieval of IMEISV early
- allow transmission of IMEI to HLR (for subscriber-create-on-demand)
- support inter-BSC hand-over
- support inter-MSC hand-over
- do not force encryption on UTRAN/Iu
- OSMUX support with AoIP
- document
--db-upgrade command line argument
- optionally store IMEI in subscriber table (for non-standard subscriber-create-on-demand)
- support routing of GSUP messages between clients (MSCs) for inter-MSC hand-over
OsmoMGW (and libosmo-mgcp-client)¶
- Add config option to use RFC5593 for GSM HR frames (we normally use ETSI TS 101318 format)
- SDP parsing related fixes
- Support OSMUX configuration via MGCP (activated via BSC and MSC)
- support international Caller-ID
- support emergency calling
- handle SIP re-invite
- support MNCC HOLD/RETRIEVE
OsmoSTP (and libosmo-sigtran)¶
- enable statsd export
- fix bug when saving config file (pointcode+mask of route)
- enable memory usage debugging via talloc introspection
- various parser correctness imporvements for LLC
- send Iu Release Command upon Attach Complete
- send Service Reject when no PDP contexts available
- fix GTP echo behavior
- require GMM authentication by default
- various PCO handling related improvements/fixes
- minimalistic PAP support during PDP context activation
- fix missing GTP-C re-transmission
- Introduce new pdp APIs (and deprecate old ones) to support multiple GSN
The original author and maintainer of gr-osmosdr (Dimitri horiz0n Stolnikov) has lost time and/or interest in maintaining gr-osmosdr. That's very sad, but it is a fact that people have a limited amount of time, and priorities change. We'd like to thank Dimitri and all other gr-osmosdr developers/contributors for what they have done so far.
We're publicly calling for some other community member[s] to step up and become maintainer[s] of gr-osmosdr.
Who is interested in gr-osmosdr and willing to maintain it, possibly in a team with other interested folks?
The original related mailing list post can be found at http://lists.osmocom.org/pipermail/osmocom-sdr/2019-September/001983.html - it is best to follow-up there in case you are interested and/or have comments.
On September 10, 2019 Osmocom founder Harald "LaF0rge" Welte gave a presentation as part of the Datengarten series of lectures at the Chaos Computer Club Berlin.
The abstract of the talk is:
In today’s hyper-connected society, everyone constantly uses their smartphone, which in turn uses the commercial cellular networks (from 2G/GSM to 4G/LTE) in order to achieve connectivity. However, contrary to WiFi technology, even most technology-minded people don’t have much of an idea how the infrastructure behind those cellular networks looks like. This talk does not cover the architecture and protocols of underlying cellular systems, but focuses on the physical side of things: what are the typical components of cellular base stations? what are their key functionalities? how did cellular base station technology evolve during the past 20 years? how do we expect cellular base stations to change in the [near] future? We will not cover DIY or hobbyist projects here, but the actual technology deployed in the field by real-world commercial operators.
If you're interested in the presentation, feel free to check out:
