Project

General

Profile

Bug #3052

osmo-bts-sysmo fails to detect RACH bursts from osmocom-bb

Added by laforge 3 months ago. Updated 3 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
osmo-bts-sysmo
Target version:
-
Start date:
03/09/2018
Due date:
% Done:

80%

Estimated time:
Spec Reference:

Description

For some inexplicable reason, osmo-bts-sysmo doesn't show any of the RACH bursts sent by a OsmocomBB layer1.

In the exact same setup, osmo-bts-trx successfully detects each and every of those RACH bursts.

the PHY in sysmobts detects energy at the channel with a sufficiently high level, but claims there is an invalid burst type present:

Rach_DecodeBurst() => Wrong burst type ! [Fn = 3003, Tn = 0, RSSI = -101.6 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3004, Tn = 0, RSSI = -101.3 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3013, Tn = 0, RSSI = -42.6 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3014, Tn = 0, RSSI = -101.3 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3023, Tn = 0, RSSI = -101.9 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3024, Tn = 0, RSSI = -101.7 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3025, Tn = 0, RSSI = -101.2 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3026, Tn = 0, RSSI = -42.5 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3027, Tn = 0, RSSI = -102.0 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3028, Tn = 0, RSSI = -105.2 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3029, Tn = 0, RSSI = -104.9 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3030, Tn = 0, RSSI = -104.7 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3031, Tn = 0, RSSI = -105.2 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3032, Tn = 0, RSSI = -42.6 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3033, Tn = 0, RSSI = -104.8 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3034, Tn = 0, RSSI = -104.2 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3035, Tn = 0, RSSI = -103.4 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3036, Tn = 0, RSSI = -105.1 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3037, Tn = 0, RSSI = -42.7 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3038, Tn = 0, RSSI = -102.7 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3039, Tn = 0, RSSI = -103.7 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3040, Tn = 0, RSSI = -103.5 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3041, Tn = 0, RSSI = -103.5 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3042, Tn = 0, RSSI = -104.4 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3043, Tn = 0, RSSI = -42.3 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3044, Tn = 0, RSSI = -103.8 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3045, Tn = 0, RSSI = -104.3 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3054, Tn = 0, RSSI = -103.9 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3055, Tn = 0, RSSI = -105.4 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3064, Tn = 0, RSSI = -104.6 dBm]
Rach_DecodeBurst() => Wrong burst type ! [Fn = 3065, Tn = 0, RSSI = -54.7 dBm]

Where the ~ -100 dBm slots are those without RACH, and the ~ -45 dBm are those where the OsmocomBB MS transmitted RACH bursts.

This is very odd. I tried with different osmo-bts-sysmo versions and could reproduce this problem always. Simply switching to osmo-bts-trx always solved the problem as reliablyy as osmo-bts-sysmo failed.

I'm 100% sure I've used OsmocomBB with sysmoBTS many times before.

This can be very well reproduced with running the BTS_Test testsuite (and particularly the TC_rach_content and TC_rach_count tests) against a physical BTS.

sysmoBTS PHY correlates against all the three synch sequences indicated in TS 05.02 Section 5.2.7 and reports this up to osmo-bts. osmo-bts-trx only seems to know the standard sequence, so it actually does less but works better.

My assumption is that somehow we're doing something wrong in OsmocomBB in generating the burst.

I've validated that the BSIC is identical between network and MS, and I've used "printf debugging" in OsmocomBB layer1 as well as osmo-bts-sysmo to ensure 0x3F was used in both cases.

I've tried with a variety of receive levels / attenuation, and even played with timing advance of OsmocomBB: no success.

History

#1 Updated by fixeria 3 months ago

Hi Harald,

I recommend you to try GRGSM-TRX and FakeTRX/burst_gen.py.
This would allow you to modulate and send any possible sequences.

Also, what does "Wrong burst type" exactly mean? Is it possible
to observe both BER and ToA values?

BTW: I didn't know that there are more than one synch sequences.
I've used to refer the 5.1.0, while the latest V14.4.0 (2018-01)
defines even more than three sequences...

#2 Updated by fixeria 3 months ago

I also have a killed by statical electricity Motorola C118. I don't know which
part exactly was damaged: it's still capable to receive GSM signal, but the
transmitted signal looks like a noise. OsmoBTS reports 100% BER despite
relatively good RSSI values.

#3 Updated by laforge 3 months ago

On Sat, Mar 10, 2018 at 05:25:00AM +0000, fixeria [REDMINE] wrote:

I also have a killed by statical electricity Motorola C118. I don't know which
part exactly was damaged: it's still capable to receive GSM signal, but the
transmitted signal looks like a noise. OsmoBTS reports 100% BER despite
relatively good RSSI values.

I've tried it with several phones. Also, I can hear it loud and clear in the speaker
I use, depending on the configured transmit power.

I am feeling this is somehow related to timing. It seems that OsmocomBB is sending
the first RACH request already with a ToA of 19 bits (!) and this increases with every
RACH.

#4 Updated by laforge 3 months ago

I cannot find anything related in the OsmocomBB or TSM30 source code. There's nothing to configure in terms of RACH except the 8-bit RA value, timing and transmit power. No idea yet why the sysmobts PHY doesn't want to detect those access bursts

#5 Updated by laforge 3 months ago

On Sat, Mar 10, 2018 at 05:21:04AM +0000, fixeria [REDMINE] wrote:

I recommend you to try GRGSM-TRX and FakeTRX/burst_gen.py.
This would allow you to modulate and send any possible sequences.

Thanks. I was trying to avoid adding even more parts to the equation,
but maybe I'll try.

Also, what does "Wrong burst type" exactly mean?

that's the beauty of a proprietary PHY. I guess the correlator
determines that neither of the three training sequences for RACH bursts
was detected over the correlation window.

Is it possible to observe both BER and ToA values?

BER = 0.16666

BTW: I didn't know that there are more than one synch sequences.

I meanwhile figoured out TS1 and TS2 are used for 11bit RACH requests in EGPRS.

I've used to refer the 5.1.0, while the latest V14.4.0 (2018-01)
defines even more than three sequences...

well, those are probably EGPRS2 related (nobody uses that) or EC-GSM-IoT.

#6 Updated by laforge 3 months ago

the timing is not the problem, at least not when using osmo-bts-trx as reference.

When using L1CTL_PAR_REQ to set TA=0, osmo-bts-trx reports the bursts at toa256 of 7..15, which is as good as it gets. When using TA1, this goes to about toa256=-270, which is expected.

I've also tried older sysmobts firmware versions down to v2.4 with no change in behavior. I've used three different sysmoBTS boards and two different Motorola Phones. No change.

#7 Updated by laforge 3 months ago

I've not only tested current master with old firmware, but also tested osmo-bts version 0.7.0 - no change in behaviour.

#8 Updated by laforge 3 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80

#9 Updated by laforge 3 months ago

  • Status changed from In Progress to Stalled

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)