Hello everyone, I was going to add support for CBCH to osmo-bts-trx for a project, then just by chance I looked at this ticket: https://osmocom.org/issues/1617 and I've seen that the issue was reopened 13 days ago. Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and work on it in whatever state the code is now, still better than starting from scratch. Thanks for the awesome work anyway!
Best regards,
Lorenzo
Hi Lorenzo,
On Wed, Sep 05, 2018 at 05:04:01PM +0200, Lorenzo Cavallini wrote:
I was going to add support for CBCH to osmo-bts-trx for a project, then just by chance I looked at this ticket: https://osmocom.org/issues/1617 and I've seen that the issue was reopened 13 days ago.
this is currently undergoing development.
Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and work on it in whatever state the code is now, still better than starting from scratch.
It's available in the laforge/cbch-trx branch of osmo-bts.git
hey, thanks for the quick reply!
I think the branch is not upstream yet, on osmo-bts.git I can see only these ones:
laforge/avoid_ramp_spike laforge/bands-eeprom laforge/ciph-fix fix laforge/fsm-name laforge/gprs-suspend laforge/late_l1ifreset laforge/meas256 laforge/oml-router laforge/omldummy laforge/power_control laforge/sob-bts-pa-ctrl laforge/virt-new
am I missing something? thanks!
On Wed, 5 Sep 2018, 18:40 Harald Welte, laforge@gnumonks.org wrote:
Hi Lorenzo,
On Wed, Sep 05, 2018 at 05:04:01PM +0200, Lorenzo Cavallini wrote:
I was going to add support for CBCH to osmo-bts-trx for a project, then just by chance I looked at this ticket: https://osmocom.org/issues/1617
and
I've seen that the issue was reopened 13 days ago.
this is currently undergoing development.
Any chance on getting some pre-pre-pre-alpha patch? I would gladly test
and
work on it in whatever state the code is now, still better than starting from scratch.
It's available in the laforge/cbch-trx branch of osmo-bts.git
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Lorenzo,
On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote:
I think the branch is not upstream yet, on osmo-bts.git I can see only these ones:
this is very odd. the branch had been pushed to gerrit, and I can verify exists on gerrit when cloning using git clone https://gerrit.osmocom.org/osmo-bts
Still, gerrit doesn't seem to be replicating this to git.osmocom.org. Odd.
yes I cloned it now from gerrit and the branch is definitely there.. that's fine for me anyway, thanks!
On Thu, Sep 6, 2018 at 11:10 AM Harald Welte laforge@gnumonks.org wrote:
Hi Lorenzo,
On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote:
I think the branch is not upstream yet, on osmo-bts.git I can see only these ones:
this is very odd. the branch had been pushed to gerrit, and I can verify exists on gerrit when cloning using git clone https://gerrit.osmocom.org/osmo-bts
Still, gerrit doesn't seem to be replicating this to git.osmocom.org. Odd.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Thu, Sep 06, 2018 at 11:12:29AM +0200, Lorenzo Cavallini wrote:
yes I cloned it now from gerrit and the branch is definitely there.. that's fine for me anyway, thanks!
After restarting gerrit, it appears to have replicated to git.osmocom.org now, too: http://git.osmocom.org/osmo-bts/log/?h=laforge/cbch-trx
so after all, restart is always the solution to every problem... :) thanks for looking into this anyway!
On Thu, Sep 6, 2018 at 11:20 AM Harald Welte laforge@gnumonks.org wrote:
On Thu, Sep 06, 2018 at 11:12:29AM +0200, Lorenzo Cavallini wrote:
yes I cloned it now from gerrit and the branch is definitely there.. that's fine for me anyway, thanks!
After restarting gerrit, it appears to have replicated to git.osmocom.org now, too: http://git.osmocom.org/osmo-bts/log/?h=laforge/cbch-trx --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Lorenzo,
there were many bugs in the generic CBCH/SMS-CB support of both OsmoBTS and OsmoBSC. It was working once but has bit-rot over time. Due to a lack of related regression tests, this went unnoticed so far.
The fixes are now all merged, so if you build current master of osmo-bts and osmo-trx, you should get working CBCH support.
I've also put an example at https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast#How...
Please let me know if it works for you.
Hi, thanks for the update! I'll check as soon as I can and I'll let you know.
Hi Lorenzo,
On Mon, Sep 10, 2018 at 08:14:49AM +0200, Lorenzo Cavallini wrote:
thanks for the update! I'll check as soon as I can and I'll let you know.
Any news yet?
I've meanwhile developed a related test suite for osmo-bts (see http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/cbch&id=7048dc...) as well as discovered + fixed a wireshark RSL dissector bug related to RSL CBCH (https://code.wireshark.org/review/29683).
Hi, yes I have some updates. I tested with two different timeslot configurations: CCCH+SDCCH4+CBCH on ts0 and SDCCH8+CBCH on ts1. In both cases I'm using an iPhone8 to test. With the first ts configuration, the iphone could not perform the location update procedure, so basically I had no connectivity to the basestation. With the second, the location update procedure goes through, I'm connected, I can send/receive sms and phonecalls, but smscb are not being delivered, at least that's what I think. I can definitely see the smscb messages on the gsmtap interface and I can see the smscb request coming from RSL link. However, I don't get any broadcasts on the phone itself. But this last part is till not very clear, I need to investigate a bit more on what's going on. As a side note, when using CCCH+SDCCH4+CBCH ts0 configuration, both my iPhone8 and my Huawei Honor9 cannot perform the location update procedure. Apparently they can only get the BCCH channel but the location update procedure never starts. I tested as outlined here: https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast#How... . Let me know if this helps and what kind of debug I can provide you, as you may guess getting debug out of mainstream smartphones is not really easy, so what I can do is limited on that side. Thanks!
Lorenzo
On Sun, Sep 16, 2018 at 10:00 PM Harald Welte laforge@gnumonks.org wrote:
Hi Lorenzo,
On Mon, Sep 10, 2018 at 08:14:49AM +0200, Lorenzo Cavallini wrote:
thanks for the update! I'll check as soon as I can and I'll let you know.
Any news yet?
I've meanwhile developed a related test suite for osmo-bts (see http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/cbch&id=7048dc... ) as well as discovered + fixed a wireshark RSL dissector bug related to RSL CBCH (https://code.wireshark.org/review/29683).
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Lorenzo,
On Mon, Sep 17, 2018 at 10:41:16AM +0200, Lorenzo Cavallini wrote:
yes I have some updates. I tested with two different timeslot configurations: CCCH+SDCCH4+CBCH on ts0 and SDCCH8+CBCH on ts1.
In both cases I'm using an iPhone8 to test.
iPhones are generally known to have (together with at leats older Blackberries) the most "critical" protocol stacks out there, i.e. they will bail out the first time they see any single bit that is not like they expect it.
So in general, it might be worth to also test with other phones and compare.
With the first ts configuration, the iphone could not perform the location update procedure, so basically I had no connectivity to the basestation.
the qeustion is which particular commit you were using at the time.
There is one fix that might be related to this:
commit 526b4a5f350725d312c6739cf6abdcef040b698c Author: Neels Hofmeyr neels@hofmeyr.de Date: Tue Sep 11 00:47:29 2018 +0200
ts,lchan_fsm: do not attempt to allocate CBCH subslots
Also, please noe that as per GSM spec, if you use the CBCH on SDCCH/4, you *must* advertise BS_AG_BLKS_RES >= 1 to achieve a valid configuration.
Let me know if this helps and what kind of debug I can provide you, as you may guess getting debug out of mainstream smartphones is not really easy, so what I can do is limited on that side.
I think particularly the big trouble in the SDCCH/4 case should be possible to debug with traces only from the network side. If you can provide pcap files with * GSMTAP (containing at least BCCH,CCCH,SDCCH,CBCH SAPI) * Abis OML and RSL (tcp port 3003 + 3002) during the time where you tried to register the phone unsuccessfully, it would help. Also, please double-check if the commit above by Neels makes a difference.
I'll also try to reproduce this here today using a LimeSDR-USB and current osmo-bts / osmo-bsc master and a couple of phones.
Regards, Harald
Hi, I've seen the latest commits and tested them. I can confirm that now SMSCBs are working in the CCCH+SDCCH4+CBCH configuration, 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. On my iPhone8 and Honor9 I still can't get anything, but that's not an issue, I just wanted to be sure that SMSCBs are being delivered. Anyway, the location update procedure is successfully completed in all three phones I've tested. 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, but again this is not a problem. I can see some garbage text on my old Samsung, so it might be some issues with encoding. Anyway, thanks for the support!
Regards,
Lorenzo
Hi 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.
Hi,
On Tue, Sep 18, 2018 at 10:10 PM Harald Welte laforge@gnumonks.org wrote:
Hi Lorenzo,
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.
I think the main issue is that Samsung switched baseband after the S5. I tested just now on the S7 and it's not working.
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.
You can add iPhone7 and Galaxy S7 to the list of phones that can successfully complete the location update procedure, with the SDCCH4+CBCH configuration. On the other hand, on a very old Huawei LUA-L21 I'm not even able to receive the BCCH, my cell is not present in the list. I'm not 100% sure that's related to osmocom stack here, this phone is in a really bad shape overall, but it works without CBCH.
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!!).
I'm pretty much sure that my iPhone8, Honor 9 and Galaxy S7 can receive broadcast notifications, because I get them during network tests for floods and other calamities in my country. However, I never checked if they're delivered through Paging Type 1 rest octets or through SMSCB, so this might make a difference. And to be honest I don't remember if I was in 2G only mode or not, but they test them once per month, so in about 2 weeks I can check this :)
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
I'm going to retest all my mobile phones with the SDCCH8+CBCH configuration and see if this makes a difference. I will let you know. Unfortunately I don't have any pre-iPhone era phones that still work beside my Samsung, so I cannot test anything else for a "positive" result. Thanks!
Regards,
Lorenzo
Hi Lorenzo,
Try, if possible, to put a Qualcomm chipset based phone with some kind of tracing (e.g. Snoopsnitch) under testing. It might yield some results looking into the PCAP file. Wireshark dissectors can help sometimes catching wrongly coded messages - at least they helped me in the past.
Good luck!
Cheers, Domi
2018. szept. 19. dátummal, 13:40 időpontban Lorenzo Cavallini lorenzo.cavallini@gmail.com írta:
Hi,
On Tue, Sep 18, 2018 at 10:10 PM Harald Welte laforge@gnumonks.org wrote: Hi Lorenzo,
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.
I think the main issue is that Samsung switched baseband after the S5. I tested just now on the S7 and it's not working.
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.
You can add iPhone7 and Galaxy S7 to the list of phones that can successfully complete the location update procedure, with the SDCCH4+CBCH configuration. On the other hand, on a very old Huawei LUA-L21 I'm not even able to receive the BCCH, my cell is not present in the list. I'm not 100% sure that's related to osmocom stack here, this phone is in a really bad shape overall, but it works without CBCH.
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!!).
I'm pretty much sure that my iPhone8, Honor 9 and Galaxy S7 can receive broadcast notifications, because I get them during network tests for floods and other calamities in my country. However, I never checked if they're delivered through Paging Type 1 rest octets or through SMSCB, so this might make a difference. And to be honest I don't remember if I was in 2G only mode or not, but they test them once per month, so in about 2 weeks I can check this :)
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
I'm going to retest all my mobile phones with the SDCCH8+CBCH configuration and see if this makes a difference. I will let you know. Unfortunately I don't have any pre-iPhone era phones that still work beside my Samsung, so I cannot test anything else for a "positive" result. Thanks!
Regards,
Lorenzo
-
Harald Welte -
Lorenzo Cavallini -
Tomcsányi, Domonkos