This adds printing of remote RTP IP/Port, LAPDm SAPI information,
MS Timing offset, propagation delay, encryption algorithm+state,
loopback status and radio link failure counter to the "show lchan"
command. It also adds TODO comments fro those bits that are not yet
printed but which would make sense to print.
Change-Id: Ic4bc47638b7b402aee9344dc912745a9929c37f4
This is more or less a 1:1 import from the BSC side commands. Having
the commands on the BTS side will allow us to expose information that's
not visible to the BSC [in upcoming, separate patches].
Change-Id: I2a596938849a9c84fe6fedcac5d7f71ee97af575
This warning was included in commit
6d7b78bde1 from 2011, and nowadays I only
see this command used in osmo-bts, so I think we most probably drop it
as it doesn't make sense anymore.
Change-Id: Ie277dce00292c8f403b9a2b405efe4429e6af86a
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I5e8e9d7989ee20fe722bdd3109965d5bce9519fb
When printing BTS via 'show bts ..' let's also print each TRX, which phy
number and version it uses and its description. It's helpful in
troubleshooting low-level issues as it allows vendor-specific code to
easily expose firmware version.
Related: SYS#3884
Change-Id: Iabcc862566b40a9314f3e1d17fda61d8ab24a3cd
* remove leftover from copy-paste of corresponding OpenBSC code
* print OML link state
* print paging load
Change-Id: Ia5e3dc10efe2b5ab212cab1518a10d36b20b8bb2
OsmoBTS won't run without being connected to a BSC. The BTS wouldn't
start to transmit if the BSC doesn't properly initialize it. So if we
want to activate some channels manually for testing, we should do so
from the BSC, and not inside the BTS code. Doing this in the BTS means
that the BSC is not aware of it and might want to use that channel for
something else meanwhile.
Osmo{BSC,NITB} has gained ability to manually activate a channel from
the VTY in Change-Id I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d as can be
seen at https://gerrit.osmocom.org/2759
So let's remove the old/obsoleted code here.
Change-Id: I7ba0301b55cc283aa6a441899f84357e28a97321
Making use of the multi-trx feature requires to tell osmo-bts that
more than one transceiver are available. Otherwise it will complain
that not enough transceivers are available. This can be quite
confusing, even a correct config file will fail to parse if it
specifies more transcrivers than available.
This patch adds a hint to the error message so that the user knows
that he should check the -t commandline option
Change-Id: Ifbeacd9d43f7c6cd74a1e1b33288e66828fe843f
The vty write for phy/inst is broken, leading to a written-out config being
unparsable; fix all of these:
- in common/vty.c, actually call bts_model_config_write_phy_inst().
- in sysmo and lc15 write the phy instance elements in
bts_model_config_write_phy_inst() and not in bts_model_config_write_phy(),
which lead to writing the members above their parent 'instance'.
- sysmo, lc15 and oct omit the bts_model_config_write_phy_inst()
implementation. This did not cause a compilation problem because it
was in fact never called.
- sysmo writes 'clock-source None' when clk_src is zero, leading to unparsable
config (related: OS#1944). Instead omit the 'clock-source' when zero.
- osmo-bts-trx seems to be the only part that lacks nothing, yet it
also didn't work properly because bts_model_config_write_phy_inst()
was never called.
This problem existed since commit d784e50747
"Introduce new phy_link and phy_instance abstraction"
Change-Id: Icc54fa70045c8fa58e78cf9f788c21a437edfbd4
* add vty option to manually enable adaptive RTP jitter
buffering (disabled by default) on per-bts level
* use this setting on per-lchan level when setting jitter parameters via
vty at runtime
* check and log result of osmo_rtp_socket_set_param()
* note: older libosmo-abis will ignore this setting which will be
properly detected via return value
* if jitter buffer is disabled by configuring "rtp jitter-buffer 0" than
adaptive buffering is disabled as well but it will be used if jitter
buffer is set to different value for a givel lchan via vty
Change-Id: I489f3c419039f40b57c2ef0641c176478b8d3566
Typically, our VTY prompts have space after the '#', but some of the osmo-bts
VTY prompts don't:
OsmoBTS# configure terminal
OsmoBTS(config)# bts 0
OsmoBTS(bts)#gsmtap-sapi ccch
Add spaces after the '#' to yield e.g.
OsmoBTS(bts)# gsmtap-sapi ccch
Change-Id: If0591a359e77f01abb76c4113181af7a7733ddd4
This is the easiest way I found to make BTS level loopback to work.
Another way to implement this is to have BSC/NITB to send the OML command, but
it's a longer path with no clear benefits.
Note, that the current code hardcodes the channel to be TCH/F with v1 speech,
which is what we need for the basic BER testing. We may want to extend this
later to support more channel types.
Change-Id: Ia2734afeff023e5b3d6b934c7e8b1ed95a071b72
In some cases we'd like to run multiple instances of osmo-bts on a
single machine. This is the case where we a multi-TRX PHY is to be used
for several BTSs, or in case osmo-bts-trx has multple SDRs attached.
This wa currently prevented by having a hard-coded PCU socket path
and telnet port, which are now configurable via VTY / config file
itself.
It remains up to the individual BTS hardware models to decide
whether or not to register those commands (depending on whether they
support the feature) via cfg_bts_auto_band_cmd / cfg_bts_no_auto_band_cmd
At the time the phy link / phy instance level VTY configuration
commands are parsed, we did not yet call l1if_open() and thus
pinst->u.{lc15,sysmobts}.hdl == NULL.
PHY or PHY instance specific configuration must thus be stored inside
the phy_link or phy_instance itself, and not inside the (not yet
existing) handle.
We solve this by moving around some parameters:
* clk_use_eeprom/clk_cal/clk_src/calib_path get replicated in
phy_instance
* min_qual_{rach,norm} are moved into the generic part (which means
that osmo-bts-octphy and osmo-bts-trx should also implement them)
Instead of limiting the number of TRX at VTY to the actual number of
supported TRX, VTY allows to configure any possible number of TRX. If a
TRX is configured, which is not supported by BTS model, an error message is
returned, which states that the given TRX is not supported.
MS uplink power control is required in pretty much any BTS, and we
cannot assume that they PHY / L1 will always take care of it by
itself. So the correspondign code is moved to common/power_control.c
and called from the generic part of L1SAP.
The corresponding VTY paramter has been moved from the sysmobts-specific
trx VTY node to the common BTS VTY node.
Currently the DSP is instructed to achieve a given uplink
power target but there are circumstances (e.g. EMV testing)
where we need more control over it. The "manual/software/osmo"
power control can only be implemented per TRX and not per
lchan. Add a very very basic control that checks the MS Power
used by the phone, the actual receive level and then adjust
the power.
The code doesn't take the history into account, if the phone
can not reach the requested power level the code will be stuck
(e.g. no timeout based on multiframes). It has a mode for a
fixed power control but no way to set it yet.
The change of the mode requires a restart of the software.
We do not have the vty test script to do roundtrip testing. There
is no max-initinal-pout, then there was a typo inside 'initial' and
for the relative step size the unit is dB/mdB. Fix both of that.
In order to support transmit power reduction by thermal management
as well as the variety of new internal / external PA configurations
of BTSs, we need a slightly more complex system.
Also, as at high power a single dB can be quite a big difference,
we are now doing all computations in milli-dB(m), i.e. 1/10000 bel.
Ramping is now used both for up and down ramping, as that is useful in
cases where you want to gracefully shut down a cell by shrinking its
radius, gradually handing over subscribers to neighboring cells.
Furthermore, this code is becoming part of the 'common' codebase, as it
is not really specific to how sysmobts is working.
The user can specify a single aggregate value for external system
gain/attenuation. Let's say you have 1dB loss of antenna cable, so you
can put that as 'user-gain -1' into the config, which means that a
'transmit power of 20dBm' will be compensatet for that and the TRX is
instructed to output 21dBm to compensate the cable loss. Similarly,
external PAs can be described by a positive user-gain.
One of the next steps will be to communicate those values and the
nominal power capability of the specific BTS to the BSC, so the BSC will
automatically show correct signal levels in the VTY and log files.
The code includes provisions for future extensions regarding
* an external and an internal PA with calibration tables
* a thermal attenuation setting to be controlled by the site manager
This patch adds the following VTY commands to tune AGCH queue
handling:
agch-queue-management default
agch-queue-management threshold THRES low LOW high HIGH
Examples:
agch-queue-management default
Resets queue management to default parameters.
agch-queue-management threshold 0 low 25 high 75
Start dropping at 25%, drop all messages above 75% queue length
(relative to max queue length corresponding to T3126). Between
low and high, drop with a probability interpolated linearly
between 0 (low) and 1 (high).
agch-queue-management threshold 50 low 0 high 0
Start dropping at 50% and continue until all IMM.ASS.REJ have
been removed from the front (output) of the queue
Sponsored-by: On-Waves ehf
Counters are added for the following events (use VTY show to query):
- Dropped IMMEDIATE ASSIGN REJECT messages
- Merged IMMEDIATE ASSIGN REJECT messages
- Rejected AGCH messages
- Use of PCH (non-reserved) for AGCH messages
- Use of AGCH (reserved) for AGCH messages
Sponsored-by: On-Waves ehf
This patch removes the local 'end' and 'exit' implementations (which
aren't used anyway) and uses the generic ones provided by libosmocore
instead, which are enabled automatically when vty_install_default()
is used.
The prompt strings are modified to match those in
libosmocore/openbsc.
Ticket: OW#952
Sponsored-by: On-Waves ehf
Instead of explicitly having to specify the local IP address for RTP
sockets in the BTS, we just use "0.0.0.0" instead, which gets
translated to INADDR_ANY.
We still accept the configuration directive in old config files, but
when we write, the line will no longer be re-written to the file.
TODO: IMHO, the IPA RSL CRCX/MDCX actually permit the BSC to specify the
IP address on the BTS side, and we probably simply ignore this at this
point.
These attributes are saved in paging_state, we don't need to save them a
second time in struct gsm_bts_role_bts. Add get and set methods for
these attributes and use them consitently in the VTY code.
This may be adding bells and whistles that nobody wants to touch, but at
least for current analysis/optimiziation they are useful to have. Later
on they should probably be removed again and/or obsoleted by OML
messages for configuration of paging behaviour by the BSC.
This will make app -V print the copyright information like the other
applications of our universe. An BTS integration that want to list
additionaly copyright holders needs to access the vty_app_info and create
a new copyright string.
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
Harald Welte
Pau Espin
Neels Hofmeyr
Philipp Maier
Neels Hofmeyr
Alexander Huemer