3 Jul
2024
3 Jul
'24
4:36 p.m.
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(a)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