This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Lorenzo,
On Tue, Sep 18, 2018 at 11:30:58AM +0200, Lorenzo Cavallini wrote:
> I've seen the latest commits and tested them. I can confirm that now SMSCBs
> are working in the CCCH+SDCCH4+CBCH configuration,
great!
> however the funny part is they're working on my extremely old, pre-iPhone era Samsung mobile
> phone, where I can receive the smscb message.
FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages here.
I mostly work with >= 10 year old feature phones during development, as their UI
is inside the baseband processor and closer to what happens on the GSM protocol side
than all the smartphones that go via AT-commands or QMI.
> Anyway, the location update procedure is
> successfully completed in all three phones I've tested.
that's great and confirms the related bug is fixed.
> I'll do other tests meanwhile and try to understand why they're not being
> displayed by "modern" phones, most likely they're being blocked in the
> baseband before reaching Android/iOS.
I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and also
to ensure that those very same phones with their firmware/software and configuration
will show SMSCB on other/production GSM networks (in 2G-only mode!!).
The OsmoBTS implementation of CBCH is very conservative.
* it doesn't use the optional DRX cycle
* it doesn't use the optional extended CBCH
* it definitely sends the blocks at the right time in the multiplex as per TS 05.02,
I verified this several times
The only things that I can imagine to still go wrong is message encoding, including
padding (see below)
> I can see some garbage text on my old Samsung, so it might be some issues
> with encoding.
The padding is IMHO not really fully specified. I read all relevant specs
several times, and I understand there is some 7-bit-GSM-alphabet-CR used.
However, the padding is specified primarily for SMS (point-to-point), and then
slightly adjusted for USSD, only to then be referred that SMSCB/CBCH should
also use that padding.
The difference is that SMS-PP and USSD work inside LAPDm, so you do have a "length"
field in a L2 header which tells you how many bytes L3 payload there are. Inside
that L3 payload you need to pad using the "CR" rules, but outside the L2/LAPDm
will pad with the usua 0x2B pattern.
In CBCH however, you have no L2/LAPDm, but always a fixed-length frame of 88 bytes,
split into four chunks of 22 bytes (each with a one-byte header as per TS 04.12).
If somebody has references or sample traces that show how SMSCB is padded in the real
world out there, we can try to mimic that.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)