Project

General

Profile

Bug #3063

OsmoBSC + nanoBTS 165AU (DCS1800): smartphone Samsung 4mini 5 unable to register (it can on osmo-nitb)

Added by pespin 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/13/2018
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

I have been having issues to successfully register my Samsung 4mini 5 with a nanoBTS 165AU (DCS1800) connected to a osmocom (split components) network running latest master as of today.

nanoBTS is correctly connected and I see it being configured and it can be seen by all mobiles phones. IMPORTANT: If I try with an old samsung feature phone, it can register correctly. I see the CHANnel ReQuireD packet received from the nanoBTS and all the channel allocation works successfully. However, if I do the same with any of my 2 Samsung 4mini 5, no CHANnel ReQuireD packet is received and the phone keeps in a while with the "Registering to network XYZ" before giving up, and not being able to register. So basically my BSC sees no related event.

However, we just tested with roh's old osmo-nitb setup, and in there both mobile phones (the old feature phone and the smart phone) can connect successfully, so there's seems to be some kind of regression from osmo-nitb->osmo-bsc here.

I changed my config to be very similar to roh's osmo-nitb one, but still same result. I attach both configs here for comparison.

I also attach a pcap trace showing the BTS<->BSC link in operation (after initial OML setup, sorry) while I try to register both the feature phone and the smart phone. Only the Location Update from the feature phone can be seen (and it's rejected because I don't have the IMSI in my HLR, but that's not important here, because at least the LU is received).

osmo-bsc-nanobts.cfg osmo-bsc-nanobts.cfg 3.44 KB pespin, 03/13/2018 06:38 PM
osmo-nitb.cfg osmo-nitb.cfg 1.39 KB pespin, 03/13/2018 06:39 PM
only-feature-phone-registers.pcapng only-feature-phone-registers.pcapng 107 KB pespin, 03/13/2018 06:47 PM
osmo-bsc-oml-setup.pcapng osmo-bsc-oml-setup.pcapng 30.7 KB pespin, 03/13/2018 06:52 PM
nanobts_bsc-oml-setup_nitb_roh.pcap nanobts_bsc-oml-setup_nitb_roh.pcap 42.2 KB roh, 03/14/2018 03:58 PM

History

#2 Updated by pespin 3 months ago

I attach the osmo-bsc OML seutp of nanoBTS with the previously provided config.

#3 Updated by laforge 3 months ago

  • Assignee set to pespin
I would suggest comparing the detailed contents of the following messages:
  • "SET [BTS/TRX] ATTRIBUTES" in OML
  • BCCH FILL in RSL

I suspect there's some difference that makes the phones refuse to consider the cell as eligible. This can be an encoding mistake of SI rest octets, for example.

Also check if all access control classes (part of SI) are enabled, as that's something we've touched recently.

#4 Updated by pespin 3 months ago

  • Assignee changed from pespin to roh

ASsigned to roh, I gave him back the nanoBTS to take a pcap trace while configuring it with his NITB setup. Once he has provided it, let's have a look at the differences.

#5 Updated by roh 3 months ago

i did a tcpdump with the said bts against my very old nitb and attached it here.

#6 Updated by pespin 3 months ago

  • Assignee changed from roh to pespin

#7 Updated by pespin 3 months ago

Differences found:

SET BTS ATTributes:
field nitb bsc
RACH Busy Threshold 0a 5a
BTS Air Timer 80 64
IP CGI 00:f1:10:00:01:00:00 32:f4:07:00:05:00:00

After that one, I see osmo-nitb sends a "OML Radio Carrier(00,00,ff) Set Radio Carrier Attributes" before setting up every channel. On the other hand, osmo-bsc sends that message AFTER setting all the 0-7 channels. The message looks the same in both traces (same content), but the order in which it is sent differs.

All (0-7) "Set Channel Attributes" from both traces are the same, no difference here.

BCCH INFOrmation (System Information Type 1) looks the same for both nitb and bsc.

"SACCH FILLing" messages can be found in nitb frame 184 and bsc frame 193:
- SI Type 2 is the same in both.
- The osmo-bsc messages contains more information Between SI Type 2 and SI Type3 that the nitb doesn't have:
-- IPA header + RSL with IE SI 2bis
-- IPA header + RSL with IE SI 2ter + Layer3 SI Type 2ter.
-- IPA header + RSL with IE SI 2quater
- SI Type 3 differences:
-- In Control Channel Description, osmo-bsc has MSCR=1 (MSC is Release'99 onwards) while nitb has MSCR=0 (MSC is RElease'98 or older).
-- Cell Selection Parameters: osmo-bsc has NECI=0, osmo-nitb NECI=1
-- SI 3 Rest OCtets: difference is osmo-bsc correclty marks SI Type 2ter as available, and osmo-nitb correctly marks it's not available.
- SI Type 4 differences: NECI=1 vs NECI=0
- SI Type 5 is the same in both.
- osmo-bsc sends SI 5bis, and osmo-nitb does not.
- osmo-bsc sends SI 5ter, and osmo-nitb does not.
- SI Type 6: Content of L3 message is different (not parsed by wireshark, only shown as hex).

#8 Updated by laforge 3 months ago

On Thu, Mar 15, 2018 at 11:57:45AM +0000, pespin [REDMINE] wrote:

Issue #3063 has been updated by pespin.

Differences found:

RACH Busy Threshold 0a 5a

this should only affect at how reports in CCCH Load Indication are structured

BTS Air Timer 80 64
IP CGI 00:f1:10:00:01:00:00 32:f4:07:00:05:00:00

Are you sure you're running the same MCC/MNC/LAC/RAC/CI on both setups? If not, then
of course the CGI will be different between the cells, as it includes all the above values.

If they are identical in both setups, then there appears to be an encoding bug.

After that one, I see osmo-nitb sends a "OML Radio Carrier(00,00,ff) Set Radio Carrier Attributes" before setting up every channel. On the other hand, osmo-bsc sends that message AFTER setting all the 0-7 channels. The message looks the same in both traces (same content), but the order in which it is sent differs.

It shouldn't make a difference, just as long as the attributes are set before bringing the channel into
operation. (opstart?)

"SACCH FILLing" messages can be found in nitb frame 184 and bsc frame 193:
- SI Type 2 is the same in both.

SI2 is BCCH. U presume you're refering to BCCH here...

- The osmo-bsc messages contains more information Between SI Type 2 and SI Type3 that the nitb doesn't have:
-- IPA header + RSL with IE SI 2bis
-- IPA header + RSL with IE SI 2ter + Layer3 SI Type 2ter.
-- IPA header + RSL with IE SI 2quater

those should all be empty. a zero-length SACCH/BCCH filling asks the BTS to disable transmitting the given
type. On a newly-started BTS it should be a no-op. You can trace on the radio interface (e.g. osmocomBB)
what is actually being broadcast, if you have doubts here

- SI Type 3 differences:
-- In Control Channel Description, osmo-bsc has MSCR=1 (MSC is Release'99 onwards) while nitb has MSCR=0 (MSC is RElease'98 or older).

this is true (OsmoMSC can e.g. do UMTS AKA, OsmoNITB cannot). But it may of course behave MS behaviour.

-- Cell Selection Parameters: osmo-bsc has NECI=0, osmo-nitb NECI=1

Every setup should run with NECI=1. NECI=0 is an ancient legacy setting. I suppose the osmo-bsc.cfg
is not set corectly then.

-- SI 3 Rest OCtets: difference is osmo-bsc correclty marks SI Type 2ter as available, and osmo-nitb correctly marks it's not available.

That's odd. Why is SI 2ter available? If you have no 3G neighbors configured, then osmo-bsc should
generate none and the BCCH INFO for 2ter should be an empty message.

- SI Type 4 differences: NECI=1 vs NECI=0

see above.

- SI Type 5 is the same in both.
- osmo-bsc sends SI 5bis, and osmo-nitb does not.
- osmo-bsc sends SI 5ter, and osmo-nitb does not.

Are you sure it's not again empty messages to disable any 5bis/5ter which the BTS has cached?

- SI Type 6: Content of L3 message is different (not parsed by wireshark, only shown as hex).

this is probably due to the l2_plen bug. Is the content shifted by one byte? The fix has been merged
very recently, to both osmo-nitb/openbsc.git ad well as osmo-bsc.git

#9 Updated by pespin 3 months ago

IP CGI 00:f1:10:00:01:00:00 32:f4:07:00:05:00:00

Are you sure you're running the same MCC/MNC/LAC/RAC/CI on both setups? If not, then
of course the CGI will be different between the cells, as it includes all the above values.

If they are identical in both setups, then there appears to be an encoding bug.

I am running different MCC/MNC/LAC, but I omited it in the report since I presumed it was not the issue. I didn't know this CGI field was related to those values, but then it makes it's different.

SI2 is BCCH. U presume you're refering to BCCH here...

Yes it's in BCCH but still the frame in wireshark is labeled as "SACCH FILLing". I couldn't find a "BCCH FILL" in any of the 2 traces as you suggested first.

- The osmo-bsc messages contains more information Between SI Type 2 and SI Type3 that the nitb doesn't have:
-- IPA header + RSL with IE SI 2bis
-- IPA header + RSL with IE SI 2ter + Layer3 SI Type 2ter.
-- IPA header + RSL with IE SI 2quater

those should all be empty. a zero-length SACCH/BCCH filling asks the BTS to disable transmitting the given
type. On a newly-started BTS it should be a no-op. You can trace on the radio interface (e.g. osmocomBB)
what is actually being broadcast, if you have doubts here

The 2ter one is not empty. It's actually sending a list of ARFCNS 100 and 200, which probably comes from the config I'm using and I think I should remove them:
neighbor-list mode manual-si5
neighbor-list add arfcn 100
neighbor-list add arfcn 200
si5 neighbor-list add arfcn 10
si5 neighbor-list add arfcn 20

- SI Type 3 differences:
-- In Control Channel Description, osmo-bsc has MSCR=1 (MSC is Release'99 onwards) while nitb has MSCR=0 (MSC is RElease'98 or older).

this is true (OsmoMSC can e.g. do UMTS AKA, OsmoNITB cannot). But it may of course behave MS behaviour.

Ok, I'll keep it as a pointer for future tests.

-- Cell Selection Parameters: osmo-bsc has NECI=0, osmo-nitb NECI=1

Every setup should run with NECI=1. NECI=0 is an ancient legacy setting. I suppose the osmo-bsc.cfg
is not set corectly then.

Hm yes after reading info about NECI it makes sense to set it to 1. I'll try if this makes a difference with the failing MS.

-- SI 3 Rest OCtets: difference is osmo-bsc correclty marks SI Type 2ter as available, and osmo-nitb correctly marks it's not available.

That's odd. Why is SI 2ter available? If you have no 3G neighbors configured, then osmo-bsc should
generate none and the BCCH INFO for 2ter should be an empty message.

It's probably related to the osmo-bsc config lines which have been probably there since I started using osmo-bsc. I'll remove them as they should not be there.

- SI Type 5 is the same in both.
- osmo-bsc sends SI 5bis, and osmo-nitb does not.
- osmo-bsc sends SI 5ter, and osmo-nitb does not.

Are you sure it's not again empty messages to disable any 5bis/5ter which the BTS has cached?

5bis is empty, but 5ter contains an L3 information of 19 bytes: 49 06 06 9e 05 00 20 00 00 00 00 00 00 00 00 00 00 00 00

- SI Type 6: Content of L3 message is different (not parsed by wireshark, only shown as hex).

this is probably due to the l2_plen bug. Is the content shifted by one byte? The fix has been merged
very recently, to both osmo-nitb/openbsc.git ad well as osmo-bsc.git

osmo-bsc: Len = 13 (0x000d) -> Message: 2d 06 1e 00 00 32 f4 07 00 05 27 ff 2b
osmo-nitb: Len = 12 (0x000c) -> Message: 2d 06 1e 00 00 00 f1 10 00 01 27 ff

So yes, it looks related to the bug you mention. However, as you said if the fix was applied I'd expect the len (2b?) to be in first place and then all other values after it and not this way. I'm actually not sure if I took the traces with osmo-bsc having the fix on it. I'll retry later and check this part better.

#10 Updated by fixeria 3 months ago

Hi Harald,

Every setup should run with NECI=1.
NECI=0 is an ancient legacy setting.
I suppose the osmo-bsc.cfg is not set corectly then.

Please see: https://gerrit.osmocom.org/7304
I am not sure about OsmoNiTB, where NECI=1 is used almost
everywhere, excluding both rbs2308 and sysmobts config examples.

#11 Updated by pespin 3 months ago

pespin wrote:

The 2ter one is not empty. It's actually sending a list of ARFCNS 100 and 200, which probably comes from the config I'm using and I think I should remove them:
neighbor-list mode manual-si5
neighbor-list add arfcn 100
neighbor-list add arfcn 200
si5 neighbor-list add arfcn 10
si5 neighbor-list add arfcn 20

This seems to be the actual issue. If I remove those lines, the MS can register without problems. If I put them back, then the MS cannot register anymore.
The config is indeed wrong as those neighbors doesn't actually exist, but I fail to see how can that extra SI 2ter information can prevent the MS from registering.

I tested with NECI=1/0 variations and it doesn't affect. It can register with both values when the neighbor related lines are removed.

#12 Updated by laforge 3 months ago

On Fri, Mar 16, 2018 at 05:11:11PM +0000, pespin [REDMINE] wrote:

neighbor-list add arfcn 100
neighbor-list add arfcn 200

This seems to be the actual issue. If I remove those lines, the MS can register without problems. If I put them back, then the MS cannot register anymore.
The config is indeed wrong as those neighbors doesn't actually exist, but I fail to see how can that extra SI 2ter information can prevent the MS from registering.

I think its most likely that the phone somehow "objects" to the encoding of the si2ter.

It certainly makes sense to look at the radio interface and not just at RSL. Maybe the nanoBTS
does something wrong [or different] when broadcatsing SI2ter.

"ccch_scan -a $ARFCN -i 127.0.0.1" is all you need with an osmocom-bb phone to get a dump of the BCCH/CCCH
messages on the ARFCN your cell is broadcasting them.

Also, make sure you look at the decoded output on a TEMS phone/tablet.

I'm sure something is wrong and the phone simply ignores the cell for that reason.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)