During OML link start-up, osmo-bts now requests a OML route for each
of the managed objects that it currently implements. This is done via
the 'ORC' (OML Router Control) protocol, which is encapsulated in
the extended IPA_PROTO_OSMO multiplex.
The responses (ACK/NACK) are not yet processed inside osmo-bts.
The idea of this OML router is to be the entity that connects
the OML link to the BSC. osmo-bts as well as other programs like
sysmobts-mgr and possibly more will then connect to the OML-router
rather than the BSC.
The point is that those "OML clients" can then register for certain
OML messages (particularly the managed objects like TRX, etc.) which
then get routed to them.
This is particularly useful in the context of 'stacked' multi-TRX
BTSs, where we will have two osmo-bts processes, one on each of the
TRX, both connecting OML to the oml-router. Through their respective
subscription of the baseband transceiver OML object, they will get
routed the IPA CONNECT RSL message from the BSC, and both osmo-bts
processes will establish independent RSL connections to the BSC.
Using this control interface, an external program can request
attentuation of the transmitter for thermal management reasons. The
external application doesn't have to know anthing about the actual
transmit power, but it can just configure a certian value of milli-dB
(1/10000 bel) and update (increase/decrease) that value depending on
the thermal environment.
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
Extend the router to verify that the message received is
properly encoded. The code can deal with the basic structure
of ETSI OML and vendor specific messages for ip.access and
the osmocom project.
Right now osmo-bts requires access to one OpenBSC header file and
this requires that openbsc and osmo-bts git are in the same directory.
Begin with making the location of the OpenBSC sourcecode configurable.
This approach will allow to build osmo-bts on our Jenkins installation
but now has the risk of more code including the openbsc/*.h header files.
This only implements creating, binding, connecting and free'ing RTP
sockets, not yet anything regarding receiving or transmitting codec
frames on them.
You will need the rtp branch of libosmocore for libosmotrau
* gather measurements from each PH-DATA.ind
* check every TDMA frame about meas period expiration
* compute averages after period expired
* put MS DL MEAS REP into RSL MEAS RES messages, include UL meas
bugs:
* L3 INFO content seems to have some offset
* is_sub is not set anywhere
* measurement periods might have up/downlink offset
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
Holger Hans Peter Freyther
Alexander Huemer