Hello GSM community,
I am pleased to announce the first release of Themyscira GSM codec
libraries and utilities package:
ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-r1.tar.bz2
The two principal libraries contained in this package, libgsmefr and
libgsmfrp, continue the tradition that was started back in 1990s with
the first release of libgsm, a Unix-oriented, C-library-embodied, Free
Software implementation of GSM 06.10 speech transcoder. The original
libgsm was written and released long before anyone in the hacker
community even dreamed of running their own GSM network or building
their own GSM MS, but it is now used somewhere deep under the hood
(under lots of higher layers) by every GSM network-side implementation
that includes an RTP transcoding gateway to other voice networks,
activated whenever a GSM voice call is connected using good old FR
codec rather than AMR, and is likewise used for the same purpose by
anyone seeking to achieve working voice in an SDR-based GSM MS
implementation.
The present gsm-codec-lib release - a public works project of the
Women's Republic of Themyscira - continues in the spirit of libgsm by
offering two more similar libraries:
1) libgsmefr is a librified (turned into a library) version of the EFR
reference code from ETSI, with all state variables converted from
global vars into proper state structures, and with additional code
clean-up to make it function as a speech encoder and decoder library
on the same principle as libgsm, but for EFR codec instead of FR1.
All beyond-speech functions of the original EFR reference code (VAD,
DTX, comfort noise, error concealment) are included in libgsmefr,
allowing this library to be used to implement a *proper* speech
transcoder for GSM-EFR voice service.
I have previously noted that the general trend in the FOSS GSM
community is to use the popular AMR library libopencore-amrnb not only
for AMR, but also for EFR. However, this approach is incorrect: the
SID and comfort noise mechanism of EFR is different from AMR, and if
you feed the uplink of a GSM-EFR call, containing SIDs and BFI skipped
frames, to libopencore-amrnb decoder, there will be strange noises in
the output in places where the GSM MS sent SID. Decoding EFR from a
GSM call uplink requires a proper EFR library, not AMR, and I wasn't
able to find any workable pre-existing implementation prior to
producing Themyscira libgsmefr.
2) libgsmfrp is a preprocessor intended to be called prior to
gsm_decode() from libgsm, implementing Rx DTX handler functions of GSM
06.11, 06.12 and 06.31. This preprocessor is required for anyone
seeking to implement GSM FR service in the traditional way depicted in
Figure 1 in 3GPP TS 46.001, as opposed to the "cut corners" way that
seems to be favored in the land of Osmocom.
When used as part of GSM network deployment, as opposed to lab
experimentation on the mobile side of GSM, the two just-released
Themyscira libraries work best together with this patch to osmo-bts:
https://www.freecalypso.org/hg/themwi-system-sw/file/tip/osmo-patches/osmo-…
implementing this extension to RTP transport format:
https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extens…
The "go along to get along" community appears to operate on a consensus
that the RTP stream should be paused when the uplink is in DTX, or
when a traffic frame was stolen for FACCH or lost to radio errors -
but I disagree with that approach, and instead operate my GSM network
on the principle of sending an RTP packet in *every* 20 ms slot, be it
rain or shine. In the "consensus" approach the speech decoding path
in the transcoding MGW never executes at all during frame stream pauses
(when no RTP packets are sent), but in my "traditionalist" approach
(mimicking the ways of TDM) that decoding function does get called
every 20 ms, and it must produce *some* output toward PSTN in every
20 ms window, whether the MS was transmitting or not, and whether this
MS output was received or lost. The Rx DTX handler becomes essential
in such operation: when there is no speech traffic from the MS,
libgsmfrp fills in comfort noise or previous speech frame substitution
and muting as appropriate per the rules of GSM 06.31. In the case of
EFR this functionality is integral to the original reference code from
ETSI and thus appears in libgsmefr, but in the case of FR1 codec this
functionality takes the form of a preprocessor, implemented in
libgsmfrp.
In any case, the two newly released libraries are intended to sit on
the same "rank" in the software integration hierarchy as classic libgsm
from 1990s, and higher-level projects by various parties should feel
free to use them in the same manner how they currently use libgsm and
libopencore-amrnb. I encourage gapk and various people's transcoding
MGW implementations to take advantages of these newly available
production quality GSM codec libraries.
With devotion to GSM Forever,
(Hasta la Victoria, Siempre,)
Mother Mychaela
I'm trying to clean up the connection management in osmo-hnbgw.
For that purpose I'd like to be notified of the SCCP RLC message:
I'd like to free a HNB-to-CN / RUA-to-SCCP context mapping when the SCCP local
reference becomes invalid.
I kind of thought I would receive a OSMO_SCU_PRIM_N_DISCONNECT PRIM_OP_CONFIRM
up the user_sap, but that's not happening.
I see the SCCP RLC logged like this:
20230216042453894 DLSS7 DEBUG 0: asp-asp-clnt-OsmoHNBGW: xua_cli_read_cb(): sctp_recvmsg() returned 40 (flags=0x80) (osmo_ss7.c:1906)
20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: Received M3UA Message (XFER:DATA) (m3ua.c:714)
20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: m3ua_rx_xfer (m3ua.c:543)
20230216042453894 DLM3UA DEBUG 0: asp-asp-clnt-OsmoHNBGW: m3ua_rx_xfer(): M3UA data header: opc=188=0.23.4 dpc=189=0.23.5 (m3ua.c:566)
20230216042453894 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=189=0.23.5 as local (osmo_ss7_hmrt.c:276)
20230216042453894 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:RELCO,V=0,LEN=0), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Source Reference,L=4,D=0073dcf0) (sccp_scrc.c:472)
20230216042453894 DLSCCP DEBUG Received CO:RELCO for local reference 1008 (sccp_scoc.c:1799)
20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{DISCONN_PEND}: Received Event RCOC-RELEASE_COMPLETE.ind (sccp_scoc.c:1833)
20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{DISCONN_PEND}: state_chg to IDLE (sccp_scoc.c:1309)
20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) (sccp_scoc.c:539)
20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Freeing instance (sccp_scoc.c:539)
20230216042453894 DLSCCP DEBUG SCCP-SCOC(1008)[0x612000008da0]{IDLE}: Deallocated (fsm.c:568)
but nothing arrives at sccp_sap_up() in hnbgw_cn.c
Is my idea flawed somehow, or is the prim dispatch missing in libosmo-sigtran?
Thanks!
~N
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
February 15, 2023 at 20:00 CET
where:
https://osmocom.org/OsmoDevCall
This time, @rafael2kwill be presenting on
Long range communications in the HF band
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all
I am new bee into pysim and python too. I have successfully installed all dependenceis and my code start running. I was too delighted and connected my card reader and ran the following command
$python4 pySim-read.py -p 0
and the responce is like below.
qt5ct: using qt5ct plugin
Using PC/SC reader interface
Card reader initialization failed with exception:
Exception was not showing any reason for failure but an empty string.
Can someone please help me
Hi all,
I am happy to announce that a new version 202302 of the Osmocom CNI
(Cellular Network Infrastructure) software has been released this week.
For further information, please visit: https://osmocom.org/news/207
Regards,
Pau
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Welcome to Quanking Electronics Limited, the industry leader in selling obsolete Avago Technology parts as an Avago technologies distributor. You can count on Quanking, a well-known Avago distributor, to give you the best prices and products available.
https://quanking.com/product/avago-technologies/
I'm currently stumped here, thanks for any hints what to try next:
All of a sudden, all attempst to run the MSC_Tests.ttcn locally, from
osmo-ttcn3-hacks/msc, are failing with the same error. This happens regardless
of the selection of tests to run, i.e. even if not related to SMPP at all.
Our jenkins doesn't seem to encounter that error.
It seems that titan is sending an invalid SMPP packet, then something happens
that SMPP_Emulation does not expect to happen, and the entire run of tests is
aborted.
I've already tried to 'make clean' in the osmo-ttcn3-hacks root dir, 'make
deps', and re-ran the gen_links and regen_makefile scripts in msc/.
I'm still getting the same error:
none -> fail reason: "Unexpected SMPP from peer"
[...]
terminate called after throwing an instance of 'TC_Error'
./MSC_Tests: Abort was called
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7f1e319950a3]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7f1e3085af90]
[...]
/usr/lib/titan/libttcn3-parallel-dynamic.so(+0x24c077)[0x7f1e3164c077]
Error: Receiving of data failed from the MTC at 127.0.0.1 [127.0.0.1]: Connection reset by peer
MC@x43: The control connection to MTC is lost. Destroying all PTC connections.
MC@x43: MTC terminated.
ttcn3_start: error: the MTC terminated unexpectedly
exit
MC@x43: Shutting down session.
MC@x43: Shutdown complete.
Comparing expected results './expected-results.xml' against results in 'junit-xml-1051482.log'
--------------------
pass MSC_Tests.TC_cr_before_reset
Summary:
pass: 1
skip: 202
So when encountering the SMPP failure, titan exits and stops running the remaining tests.
osmo-msc logs:
20230201010116947 DSMPP DEBUG [] smpp_pdu_rx(00 00 00 2e 00 00 00 09 00 00 00 00 00 00 00 01 6d 73 63 5f 74 65 73 74 65 72 00 6f 73 6d 6f 63 6f 6d 31 00 4d 53 43 5f 54 65 73 74 73 00 ) (smpp_smsc.c:718)
20230201010116947 DSMPP ERROR [] Error ([command_length:0000002E(OK)][command_id:00000009(OK)][command_status:00000000(OK)][sequence_number:00000001(OK)][system_id:msc_tester(OK)][password:osmocom1(OK)][system_type:MSC_Tests(OK)][interface_version:00(Value length exceed buffer length)]) in smpp34_unpack() (smpp_smsc.c:513)
20230201010116948 DSMPP ERROR [] length invalid 872415232 (smpp_smsc.c:805)
Attached is a pcap showing an SMPP from titan that seems to cause the trouble.
Could a debian dist-upgrade have caused this error?
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Version: 8.2.0
Build date: Sep 10 2022 11:52:51
Compiled with: GCC 12.2.0
Using OpenSSL 3.0.7 1 Nov 2022
FYI, I have this in my apt/sources.list.d:
deb https://downloads.osmocom.org/packages/osmocom:/nightly/Debian_Unstable/ ./
~N
Hi,
I am a new bee into pysim and python too. I successfully installed all dependencies and was able to run my pysim-read. Then connected my sim reader and gave the following command
$python3 pySim-read.py -p 0
The response is like
qt5ct: using qt5ct plugin
Using PC/SC reader interface
Card reader initialization failed with exception:
The response is a exception with empty string. any hint ?
if i run pcsc_scan, the output is like
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau(a)free.fr>
Using reader plug'n play mechanism
Scanning present readers...
Waiting for the first reader...
and dosenot come out of the waiting.
Hi all!
I'm currently adding unit tests for the various pySim encoder/decoder classes
for the variouus SIM/UICC/USIM/ISIM files. [1]
In order to increase the test coverage, I would appreciate any help in obtaining test
data, particularly for the more "exotic" (or recently introduced) files, related to DF.5GS,
ADF.ISIM or even DF.WLAN or the like.
So if you have any SIM cards with related files populated, I would appreciate some test
data. You can simply send me a copy+paste of the respective 'read_binary' / 'read_records'
command, or a partial 'export'. In the latter case, please make sure to redact/remove your
IMSI/ICCID/MSISDN/Kc data to prevent leaking privacy related information.
Thanks in advance.
Regards,
Harald
[1] https://gerrit.osmocom.org/c/pysim/+/24012
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello GSM community,
I have a question for those who operate their own GSM networks (be it
for fun or for research or for any other purpose) in places that DO
have regular commercial cell service, i.e., NOT ship-at-sea, middle of
desert or Rhizomatica-type environments: how do you deal with, and
ideally prevent, the highly undesirable situation of other people's
phones, not related to your operation, "jumping ship" from being
registered to their regular commercial network to trying to register
to your test network instead?
I live and operate in an area where ONE commercial operator still
provides GSM/2G service (although only to "grandfathered" customers,
closed to new subscribers), plus there are super-strong 4G and 5G
signals from all 3 USA-wide carriers. I also operate my own "pirate"
GSM network on a test/experimental basis, meaning not always on, but
only turned on for brief intervals when I am playing with it.
When I do turn on my test GSM network, I squat on an ARFCN in the
middle of a 5 MHz wide "dead" spot (SA shows noise floor over the
whole 5 MHz block in question), and most of the time I set my power
output to the lowest possible setting: I set max_power_red to the
maximum of 20, which should result in 3 dBm output from the sysmoBTS
box. I also recently changed my MCC-MNC from 310-222 (an unallocated
MNC within MCC 310) to 001-325 (MCC meaning test network, MNC is a
feeble attempt to indicate that it's me - I got 00440325 as my test
IMEI range in my "other" capacity as ME manuf), but the problematic
behaviour of at least some phones erratically "jumping ship" from
T-Mobile GSM to the test network still occurs.
Here is a concrete example of inexplicable erratic behaviour I am
seeing:
* Last night I powered up my test network at around 19:41 local time.
My wife was with me the whole evening; her primary personal phone is
Nokia C3-00 (circa 2011, late in GSM terms, but still 2G-only in terms
of RAN support) with service on T-Mobile.
* About 3.5 hours later, at around 23:14 local time, my wife noticed
that her phone "went into the black hole" (our term for times when
phones show "no service" even though T-Mobile GSM signal is there just
fine), and she alerted me. I looked at OsmoCNI logs in syslog, and I
saw that just a little earlier, at around 22:38 local time, there was
an attempt from my wife's phone (her T-Mobile IMSI) to register to our
test network. Of course that registration attempt failed - I don't
have a roaming agreement with T-Mobile, there is no MAP roaming support
in OsmoCNI, I don't have any T-Mobile or other operators' IMSIs in my
OsmoHLR, and I am NOT running with "create sub on demand" feature.
* At around 23:14 local time, when my wife noticed that her phone went
into the black hole, she immediately proceeded to reboot it - such
reflexive reboots are now an "autopilot" action for her - and on its
next boot cycle, it immediately proceeded to make another attempt to
register to our test network instead of T-Mobile, as evidenced by
OsmoCNI logs!
* At that point I turned off the test network GSM signal, as there did
not appear to be any other way to convince my wife's Nokia phone to go
back to its rightful network of T-Mobile.
Now let me add some noteworthy details:
* The ARFCN on which I squat for my test network is NOT listed in the
neighbor cell list advertised by the sole and single commercial GSM/2G
operator we have around here.
* When I mentioned this issue previously in an OsmoDevCall USSE, I was
asked if perhaps the ARFCN I squat on might be listed as a 2G neighbor
in the neighbor list of some newer-G cell. I don't have any direct
way to disprove this idea, but my wife's phone, the one that exhibits
this inexplicable behaviour, is a 2G-only model, NOT supporting LTE or
even UMTS. And the last 3G/UMTS service in our area was shut down
last summer, leaving only LTE+5G for the masses and GSM for the tiny
sliver of "grandfathered" users who won't give it up until we die.
* In last night's episode, my wife's phone sat quite happily within
our dwelling, mere meters from the sysmoBTS antenna putting out its
3 dBm, for almost 3 hours before it made its first attempt to jump
ship. During the entirely of this almost-3-hours interval, the signal
from our test network as received by the phone was overwhelmingly
stronger than the commercial signal (being meters away from the BTS),
yet the phone behaved like it should (listened to its serving cell and
advertised neighbor cells, no searching around) for almost 3 h.
* The location update interval set by T-Mobile's network is 1 hour -
thus periodic LU could not have been the trigger that told Nokia's
bugger to abandon its serving cell and go into open-ended search of
all possible ARFCNs. So what in the world could have been the trigger
then, that caused the bugger to misbehave after almost 3 hours of
behaving properly and correctly?
* Aside from whatever the trigger might be, once that Nokia bugger
attempts to register to the test GSM network and fails, why in the
bloody hell is it not going back to the weaker (in terms of RSSI) but
working T-Mobile network, why does it "park" itself in no-service
state instead?
I have heard of other people operating test GSM cells/networks in
areas where commercial services do exist: I have heard that Neels, of
Sysmocom team, operates a test cell under a test license, and when
Keith gave an OsmoDevCall presentation on Rhizomatica back in 2021,
that presentation was done from an office in some "big" city in Oaxaca,
a place where test signals had to coexist peacefully with commercial
operators' signals. So how do you guys do it? What additional magic
are you doing, which I must be missing, to prevent the situation of
phones jumping ship from commercial networks to the test network when
the signal from the test network is much stronger due to proximity?
Perplexed,
Mother Mychaela