aboutsummaryrefslogtreecommitdiffstats
path: root/doc/manuals/vty/trx_vty_reference.xml
diff options
context:
space:
mode:
authorPau Espin Pedrol <pespin@sysmocom.de>2019-12-21 00:40:09 +0100
committerPau Espin Pedrol <pespin@sysmocom.de>2020-01-07 16:04:04 +0100
commitfd99c6ce05e2b62dcba93201e2a2d1ac83b3673d (patch)
tree81cc56117b72c5695795eadd8d1e9f959d6e152e /doc/manuals/vty/trx_vty_reference.xml
parente947db8d98fc873b06e7b42abc51f0109810e640 (diff)
radioInterfaceMulti: Fail to tune on freq not following multi-arfcn restrictions
multi-arfcn feature uses a hardcoded disposition of logical channels on a physical channel. Logical channels in the phisical channel are separated by MCBTS_SPACING Hz, that is 4 GSM ARFCNs. As a result, multi-arfcn restricts the TRX ARFCN setup to the following: ARFCN(TRX0)=N, ARFCN(TRX1)=N+1*4, ARFCN(TRX2)=N+2*4, ... Let's make sure radioInterfaceMulti verifies the requested Rx/Tx frequencies for each logical channel over TRXC match the restriction explained above. It will check freq going to be set is indeed separated by MCBTS_SPACING from already set channels, making sure the ARFCN series is consistent. Otherwise, before this patch, one could set in osmo-bsc: ARFCN(TRX0)=N, ARFCN(TRX1)=N+2 and osmo-trx would silently ack the related Rx/TxTUNE TRXC commands, but actually still transmit on ARFCN N+4 instead. As a result, in this scenario TRX!=0 were unusable with multi-arfcn. Related: OS#4207 Change-Id: I2f3d66a611d3a489b3e4d9431994f4ec77b4460f
Diffstat (limited to 'doc/manuals/vty/trx_vty_reference.xml')
0 files changed, 0 insertions, 0 deletions