would be nice if logging of the BTS number in osmo-bts matched the BTS number used in osmo-bsc
Looking at a GSMTAP-logging trace where osmo-bsc sends a channel activation to bts 1, followed by osmo-bts reporting the channel activation request received by bts 0 is confusing.
Of course the osmo-bts process has only one BTS and thus refers to it as "bts 0", the only indication which BTS the logging came from is the source IP address of the GSMTAP.
Theoretically, osmo-bsc could (in some osmocom-specific way) let the osmo-bts process know which bts number it is in osmo-bsc's perspective, and then the GSMTAP logging from each osmo-bts process would match up with the osmo-bsc GSMTAP logging BTS numbers.
Alternatively, the osmo-bts process could refrain from logging any BTS number at all.
Example: the last message here makes you stop and think: "what, bts=0? that must be wrong" ... not
10535 127.0.0.1 127.0.0.10 GSMTAP 201 52530 4729 (bts=1,trx=0,ts=4,pchan=TCH/F) Allocating lchan=0 as TCH_F 10537 127.0.0.1 127.0.0.10 GSMTAP 201 52530 4729 (bts=1,trx=0,ts=4,ss=0) state NONE -> ACTIVATION REQUESTED 10541 192.168.0.10 192.168.0.125 RSL 112 CHANnel ACTIVation 10542 192.168.0.125 192.168.0.10 GSMTAP 184 48167 4729 (bts=0,trx=0,ts=4,ss=0) Rx RSL CHAN_ACTIV
#1 Updated by laforge over 1 year ago
On Fri, Jan 12, 2018 at 01:10:20AM +0000, neels [REDMINE] wrote:
Feature #2827: would be nice if logging of the BTS number in osmo-bts matched the BTS number used in osmo-bsc
I think what you're asking is impossible within the 3GPP protocol speficiations.
Basically, in Abis, you have a "link" between the BSC and any number of BTSs (could be
a daisy-chained multi-drop link connecting through multiple BTSs). This is the standard
case as normally you have three-sector sites, so you have a single site with three BTSs,
and all of them connected via one link.
All numbers/addresses are local to that link. So you have BTS 0/1/2/3/... on such a Link,
just like each of the BTSs has TRXs 0...N and each TRX has timeslots 0..7.
For sure we could introduce any other numbering / naming scheme on higher levels,
but the RSL/OML protocol level would continue to state the per-link BTS number,
and not anything else.
We could change it for OsmoBTS, but then it would be OsmoBTS specific, and not work with
ip.access, Ericsson, Siemens, Nokia,...