Cell coverage of OsmoBTS B205mini-i
Hi, I am using osmo-bts-trx with a B205-mini-i, using only CS services. I am currently running the following elements on Ubuntu 22.04, all built from source from the latest version: - osmo-trx-uhd - osmo-bts-trx - osmo-bsc - osmo-msc - osmo-hlr - osmo-mgw - osmo-stp - osmo-sip-connector I have been testing the range of the cell, and I can't seem to get more than around 50 meters, even when I transmit at ~21 dBm using a power amplifier at TX. I find this range too low, since I am used to getting 200-300 meters out of the box when running 4G and 5G networks with the same device, so I suspect I am not configuring the network correctly. I've tried looking at every parameter, so far I've only noticed improvements when setting the min-qual-* to the minimum values and ms_max_power to the maximum. These are my configs for TRX, BTS and BSC: OsmoTRX: ``` log stderr ... ! line vty no login ! cpu-sched policy rr 18 trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 egprs disable tx-sps 4 rx-sps 4 clock-ref gpsdo chan 0 ``` ``` ! ! OsmoBTS () configuration saved from vty !! ! log stderr ... ! line vty no login ! phy 0 instance 0 osmotrx tx-attenuation 0 osmotrx rx-gain 50 osmotrx ip local 127.0.0.1 osmotrx ip remote 127.0.0.1 bts 0 band GSM900 ipa unit-id 1234 0 oml remote-ip 127.0.0.1 gsmtap-remote-host 127.0.0.1 gsmtap-sapi enable-all min-qual-rach -100 min-qual-norm -100 trx 0 phy 0 instance 0 nominal-tx-power 10 ``` ``` ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! log stderr logging color 1 logging print category-hex 0 logging print category 1 logging timestamp 0 logging print file basename last logging print level 1 e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 ! T3212 is in units of 6min, so below we set 5 * 6 = 30min timer net T3212 5 mgw 0 remote-ip 127.0.0.1 remote-port 2427 local-port 2727 bts 0 type osmo-bts band GSM900 cell_identity 1234 location_area_code 0x0001 base_station_id_code 63 ms max power 40 !default: cell reselection hysteresis 4 cell reselection hysteresis 14 radio-link-timeout 32 channel allocator mode set-all ascending rxlev access min 0 rach tx integer 9 rach max transmission 7 channel-description attach 1 channel-description bs-pa-mfrms 5 channel-description bs-ag-blks-res 1 early-classmark-sending forbidden ipa unit-id 1234 0 oml ipa stream-id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 ! 945M DL/900M UL arfcn 50 nominal power 10 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 ms-power-control mode dyn-bts rxlev-thresh lower 0 upper 63 msc 0 allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden bsc mid-call-timeout 0 ``` You might notice I am using the gpsdo as the clock-ref. That's because I've also tried with a B210 with the internal GPSDO, but the results are the same. Thanks in advance, Jonathan Pichel
First off, I notice that you have 'allow-emergency' enabled. * YOU SHOULD NOT DO THAT UNLESS YOU CAN ROUTE EMERGENCY CALLS * In your test setup you will probably not connect to the local emergency services. So a person having a real-life emergency may try to use your network to call an ambulance. Possibly you will essentially block emergency calls for that person, when the phone keeps trying on your cell. Then YOU could be responsible for someone's death. You should definitely set 'allow-emergency deny' in your osmo-bsc.cfg. Back to the question... I would have hinted at the max_power_red config, which I crank up when I want to limit the testing range. But I see you already have it set to zero. It seems unrelated to maximum TA settings -- even TA=0 reaches about 550m and AFAICT you have no maximum timing advance set. This is about as much as I know about GSM range -- I'm not one of the RF experts here, and i know next to nothing about the complexities of osmo-trx with UHD. I hope that someone else on this list has more insights for you. It goes along the lines: the software cannot possibly know the properties of the hardware amplifier, so you may need to configure the gain settings. They may be set very low by default to not blow up anything by accident. But I don't know how this works in detail, so don't listen to me =) Just some ideas: Are you able to measure the strength of the emitted signals, with a spectroscope, or an SDR? Maybe that gives some hints... Have you tried the power related settings found in section "1.14 trx" in https://ftp.osmocom.org/docs/osmo-bts/master/osmobts-trx-vty-reference.pdf Hope you find a solution! BTW, I notice that you have only TCH/F timeslots configured, and your AMR config allows only 5k9. That's a bit curious, because 12k2 is the best quality that you get from TCH/F, and if you want to be compatible with TCH/H you'd typically pick 7k95 or 7k4 instead. Normally you should just allow all rates and let codec negotiation figure out the AMR rates to use. ~N On Sun, Jun 30, 2024 at 07:53:51PM -0000, JPichel wrote:
Hi,
I am using osmo-bts-trx with a B205-mini-i, using only CS services. I am currently running the following elements on Ubuntu 22.04, all built from source from the latest version: - osmo-trx-uhd - osmo-bts-trx - osmo-bsc - osmo-msc - osmo-hlr - osmo-mgw - osmo-stp - osmo-sip-connector
I have been testing the range of the cell, and I can't seem to get more than around 50 meters, even when I transmit at ~21 dBm using a power amplifier at TX. I find this range too low, since I am used to getting 200-300 meters out of the box when running 4G and 5G networks with the same device, so I suspect I am not configuring the network correctly. I've tried looking at every parameter, so far I've only noticed improvements when setting the min-qual-* to the minimum values and ms_max_power to the maximum.
These are my configs for TRX, BTS and BSC:
OsmoTRX:
``` log stderr ... ! line vty no login ! cpu-sched policy rr 18 trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 egprs disable tx-sps 4 rx-sps 4 clock-ref gpsdo chan 0 ```
``` ! ! OsmoBTS () configuration saved from vty !! ! log stderr ... ! line vty no login ! phy 0 instance 0 osmotrx tx-attenuation 0 osmotrx rx-gain 50 osmotrx ip local 127.0.0.1 osmotrx ip remote 127.0.0.1 bts 0 band GSM900 ipa unit-id 1234 0 oml remote-ip 127.0.0.1 gsmtap-remote-host 127.0.0.1 gsmtap-sapi enable-all min-qual-rach -100 min-qual-norm -100 trx 0 phy 0 instance 0 nominal-tx-power 10 ```
``` ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! log stderr logging color 1 logging print category-hex 0 logging print category 1 logging timestamp 0 logging print file basename last logging print level 1
e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 ! T3212 is in units of 6min, so below we set 5 * 6 = 30min timer net T3212 5 mgw 0 remote-ip 127.0.0.1 remote-port 2427 local-port 2727 bts 0 type osmo-bts band GSM900 cell_identity 1234 location_area_code 0x0001 base_station_id_code 63 ms max power 40 !default: cell reselection hysteresis 4 cell reselection hysteresis 14 radio-link-timeout 32 channel allocator mode set-all ascending rxlev access min 0 rach tx integer 9 rach max transmission 7 channel-description attach 1 channel-description bs-pa-mfrms 5 channel-description bs-ag-blks-res 1 early-classmark-sending forbidden ipa unit-id 1234 0 oml ipa stream-id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 ! 945M DL/900M UL arfcn 50 nominal power 10 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 ms-power-control mode dyn-bts rxlev-thresh lower 0 upper 63
msc 0 allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden bsc mid-call-timeout 0 ```
You might notice I am using the gpsdo as the clock-ref. That's because I've also tried with a B210 with the internal GPSDO, but the results are the same.
Thanks in advance,
Jonathan Pichel
-- - Neels Hofmeyr <nhofmeyr@sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Neels, On 03.07.2024 21:36, Neels Hofmeyr wrote:
You should definitely set 'allow-emergency deny' in your osmo-bsc.cfg.
this remark made me check what we provide in the config file examples for osmo-bsc, and... in all of them emergency calls are allowed: $ git grep -n allow-emergency doc/examples/ doc/examples/osmo-bsc/osmo-bsc-4trx.cfg:168: allow-emergency allow doc/examples/osmo-bsc/osmo-bsc-minimal.cfg:40: allow-emergency deny doc/examples/osmo-bsc/osmo-bsc.cfg:87: allow-emergency allow Might be worth changing the default to 'deny'. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================== * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
On 03.07.2024 21:36, Neels Hofmeyr wrote:
your AMR config allows only 5k9. That's a bit curious, because 12k2 is the best quality that you get from TCH/F, and if you want to be compatible with TCH/H you'd typically pick 7k95 or 7k4 instead. Normally you should just allow all rates and let codec negotiation figure out the AMR rates to use.
I believe this comes from the example config file too: $ git grep -n amr doc/examples/ doc/examples/osmo-bsc/osmo-bsc-4trx.cfg:41: codec-support fr hr amr doc/examples/osmo-bsc/osmo-bsc.cfg:88: amr-config 12_2k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:89: amr-config 10_2k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:90: amr-config 7_95k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:91: amr-config 7_40k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:92: amr-config 6_70k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:93: amr-config 5_90k allowed doc/examples/osmo-bsc/osmo-bsc.cfg:94: amr-config 5_15k forbidden doc/examples/osmo-bsc/osmo-bsc.cfg:95: amr-config 4_75k forbidden Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================== * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
On 30/06/2024 13:53, JPichel wrote:
I have been testing the range of the cell, and I can't seem to get more than around 50 meters,
So many possibilities... :-/ What happens when your User Equipment reaches this 50 metre range limit? What are your Uplink and Downlink levels in the Measurement reports? Also, pay attention to Q. Is the spectrum clean? (on downlink AND uplink) k/
Hi, you are right I shouldn't be allowing emergency-mode. I copied most of the configuration from the example files and didn't notice that part. It turns out I was on a band with high interference, switching bands I have ~300 meters transmitting at ~20 dBm. I was indeed seeing very bad RxQual both in UL and DL. If anyone finds it useful, I have found using the internal clock on the B205mini works fairly well, Comparing it against using the LBE-1420 external reference from Leo Bodnar, which reports up to 0.000001 ppm, there isn't that much change in terms of frequency error. Checking the position of the FCCH on the spectrum analyzer (which should be fc + 67.7 kHz), in my case I have: - Internal clock -> Δf = 220-130 Hz. - External clock -> Δf ~= 130 Hz. I would recommend using a disciplined oscillator anyways because the internal clock experiences frequency drift, probably caused by changes in temperature. Thank you all for your help
On Thu, Jul 11, 2024 at 08:00:26AM -0000, JPichel wrote:
If anyone finds it useful, I have found using the internal clock on the B205mini works fairly well, Comparing it against using the LBE-1420 external reference from Leo Bodnar, which reports up to 0.000001 ppm, there isn't that much change in terms of frequency error. Checking the position of the FCCH on the spectrum analyzer (which should be fc + 67.7 kHz), in my case I have: - Internal clock -> Δf = 220-130 Hz. - External clock -> Δf ~= 130 Hz. I would recommend using a disciplined oscillator anyways because the internal clock experiences frequency drift, probably caused by changes in temperature.
If the B205mini's clock is anything like the B210... Just my twopence on this, when I started out with Osmocom, I used to work with a B210 for months and was completely happy. Randomly one day nothing worked anymore and I thought it was my fault. It was solved by a good clock source. (Another part of that journey was realizing that the B210 can have a GSPD0 connector even if it doesn't have a GPS receiver inside.) So the B210 is also not guaranteed to give you a non-working clock, if you catch my drift =) I mean that even if it seems reliable, it's still quite possible that the season is just right to go without a proper clock, but come wintertime... Reminds me of the XTRX project, that put a very precise internal clock on its SDR specifically for the selling point of not needing an external clock for mobile communications, like other SDRs do. (wow that was SEVEN years ago???) ~N
participants (4)
-
JPichel -
Keith -
Neels Hofmeyr -
Vadim Yanitskiy