Place a layer 3 handle into GSM L1 messages to better match up confirmations to
respective requests. This handle is a uint32_t transparently returned in the
confirmation messages, so a match-up is easy to add.
So far, a GSM L1 confirmation message received for a preceding L1 Request was
matched only by the prim_id. That meant that only one instance of the same
primitive could be waiting for a confirmation at any given time, or the
responses would get mixed up: the struct wait_l1_conf instances entered into
the fl1h->wlc_list queue would be returned to a possibly mismatching
confirmation handler. (Seen during testing of dyn pdch switching.)
Send the hLayer3 handle out via prim_init(), using new static functions to
produce handles on different scopes:
* l1p_handle_for_trx()
* l1p_handle_for_ts()
* l1p_handle_for_lchan()
(These could possibly move to a more general .h/.c file later.)
Remember the hLayer3 handle in
* struct wait_l1_conf.
Match the incoming confirmations' and stored hLayer3 handles up in, and remove
a now obsolete comment from:
* is_prim_compat()
Since the hLayer3 members are at different byte offsets in
GsmL1_Prim_t.u.*, use large switch statements to set/get the value:
* In prim_init(), extend existing switch statement to set in GsmL1_Prim_t.
* Add l1p_get_hLayer3() to retrieve from GsmL1_Prim_t (could possibly move to a
more general .h/.c file later).
Change-Id: Ie4533c6cbc160318917e7a672ab6f9a848f01d1b
We are using up to 48 (actually only 8) bytes to manage the boot
state of the device. Add it to the eeprom reservation. It turns out
the current padding was too large (37 + 84 don't end at 120).
Change-Id: I4c1de5925577f1d0b7b5cc08529642ffa333d7de
Store last SID received over RTP and repeat is if necessary (no new SID
or SPEECH frames) according to codec-specific scheduling rules.
Change-Id: I4d23846a27d3dbd2a6e75e481c1efcdb2a85f305
Related: OS#1563
Use libosmocodec function to parse RTP with AMR payload in sysmoBTS and
LC15. This replaces "manual" parsing of AMR frame with function covered
by test suite and makes adding DTXd support easier.
Related: OS#1563
Change-Id: I1464f9a12e3f92926d03d5dd5d18e8f0f7206dd9
Reviewed-on: https://gerrit.osmocom.org/204
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* set/clear DTXd activity indicator for measurement reporting
* set DTXd status based on information from RSL
Related: OS#1563
Change-Id: I148a75725c4e5089b6f2da6e9adcbe94170d3257
Depends-On: I4a033b03fcd0deb4db7a38273b5407511dbf1d6c
Reviewed-on: https://gerrit.osmocom.org/220
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Previously frame number was not saved in case of PRIM_TCH rendering many
debug statements with g_time useless.
Change-Id: Ib8d8c919862d0de8e2ebf7753c2592e0d91b09c5
Reviewed-on: https://gerrit.osmocom.org/195
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
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)
Due to the changes introduced by the phy_link API, it's not easy to set
the default DSP trace flags via a command line argument anymore. We now
rather introduce a persitent VTY configuration command, by which the
default DSP tracing configuration can be set (for each PHY).
The persistent trace flags are stored in the phy_instance, while the
current operational run-time flags are in fl1h->phy_instance.
During the L1SAP related changes, somehow an old version of
check_for_ciph_cmd() was re-introduced, which didn't store the N(s) as
part of the lchan. To make things worse, the old code was still present
in the sysmobts specific part, but never executed.
by using a talloc pool, we avoid having to go back to the libc
malloc pool all the time. The msgb allocations and libortp allocations
happen quite frequently during processing and show up as one of the
high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent
TCH/H calls (highest load scenario).
talloc still consumes significant CPU, this is mostly due to the
zero-initialization of all the associated buffers. Strictly speaking
we shouldn't need this, but any change there would require lots of
testing, as there might be hidden assumptions in the code?
In some percentage of cases, talloc still seems to fall back on malloc
for msgb allocations, which is currently a bit of a mystery. The pools
certainly are large enough, talloc_reprt() rarely reports more than a
few tens of kilobytes used by the msgb pool.
The way we recycle the msgb with a l1sap header when transforming a
PH-DATA.req L1SAP primitive into a PHY/L1 primitive was flawed in
several ways:
1) the way the L1SAP header was stored in the buffer didn't provide
sufficient tailroom for the L1 primitive
2) the alignment of the data in L1SAP is at a 32bit bounadry, but not
in the L1 primitive, causing unaligned accesses.
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.
There are three transitions:
1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF
It is used to enable ciphering in RX (uplink) direction only.
2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF
It is used to additionally enable ciphering in TX (downlink) direction.
3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ
-> LCHAN_CIPH_RXTX_CONF
It is used to enable ciphering in both TX and RX directions. This is used
when the channel is activated with encryption already enabled. (assignment
or handover)
In order to follow the order of these transitions, the RX direction must
always be set before the TX direction.
If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan cipher
state remains at LCHAN_CIPH_NONE.
This part moves control channel message primitives from osmo-bts-sysmo to
common part.
In order to control ciphering fo BTS model, CIPHER (MPH_INFO) messages are
used.
In case of a RACH INDICATION on CCCH, we need to set CHAN_NR to
0x88 (RSL_CHAN_RACH). In other cases, chan_nr needs to reflect
the actual logical channel (TCH/SDCCH) on whcih the handover happened.
... in an effort to avoid introducing new/more spaghetti code
Also, use offsetof() instead of pointer calculation to determine
the start of GsmL1_Prim_t.u.phDataReq.msgUnitParam.u8Buffer
This first part moves BCCH message primitives from osmo-bts-sysmo to common
part. A new file "common/l1sap.c" is introduced to implement handling of
layer 1 messages from/to BTS model.
Spotted by Ciaby while debugging an audio issue. Do not
send anything to port==0 to the BSC/NITB. Look at the
upper bits of the speech_mode to determine if sending is
allowed. 0x1 means recv_only and all other modes allow us
to send.
Manually verified with a single phone call with LCR bridge
mode to send a CRCX early but a MDCX sendrecv later. The
audio starts to flow after the MDCX message. Virtual Addr
space didn't increase over 10 calls. The l1p_msg is freed
by the caller.
The code might not re-set speech_mode from one call to
another but if it is ever != 0 it can be expected that
the BSC will always set it. This is because we do not
(and don't want to) allocate the lchan dynamically on
every usage.
Fixes: SYS#2111
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
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.
* Print the GPS FD that was opened (e.g. to see if it was
closed again)
* Print the state changes/expectations
* Print the correct to be applied. I wondered if I shouldo do
a cor = cor * -1.. cor = -cor.. or add CLOCK_CORR(err) macro
to use it inside the printf and correction and decided the
gain is not worth the risk.
Continously run the calibration process. Everytime we call the
reset function classify the outcome. In case of a failure schedule
the next command soon and otherwise wait several hours.
Remember if the process was started through the VTY or the run
loop. In case it can't be started immediately reset and schedule
a new run.
After a reboot the system might have been off for a long time
and the currently used value might be wrong. Remember that we
never ran the calibration and execute it on start.
We should only calibrate the clock if there is a GPS fix. Start
gpsd to determine if there is a fix or not. Work around trimble
decoding issues (sent an email upstream). We need to gain some
more experience to see if there memory leaks. We also need to
re-schedule the calibration depending on the outcome.
Change the sign before passing it as correction value. The error
is the difference between the TCXO and GPS. We need to correct by
the reverse of the error. This seems to be different depending on
the clock source we have.
This is a last minute untested change.
This runs the entire procedure for calibration with reasonable
error and success checking. It can be triggered from the VTY
of the sysmobts-mgr right now.
What is missing is to hook up with GPSD to check if the system
has a fix and provide a mode that will continously run the
calibration command.
The CTRL code should have used/extended the l1_if calibration
code. The sysmobts-mgr code first needs to determine if the
clock adjustment is necessary at all. This is done by first
resetting the counters, then waiting, then asking for the diff
and then applying the correction value. But the reference clock
is only set by the application comand.
Copy more code of l1if_rf_clock_info_reset to set the reference
clock as value. This is leaving some todos inside the code that
will be resolved as part of SYS#835.
Related: SYS#835
In the long run we will connect to GPSD and wait for a fix and
then run the calibration. The first step is to open (and re-open)
the control connection to the BTS.
As the connection is on localhost there should not be a computation
overhead to always have the connection open. When connecting assume
that the ASYNC connect worked directly as otherwise we get no
notification of the failure.
This looks like a "bug" of libosmo-abis that should check if the
socket has been connected or not.
This should handle OML channel combinations with CBCH and activate the
CBCH SAPI towards the DSP correspondingly. What is still missing is
sending any actual information over the CBCH in respons to the
PH-RTS.ind coming up from L1.
Read the serial number once and format it as a string. In
case no serial number is present -1 will be returned.
Manually tested with a slightly modified version. serial_nr
was the expected one.
Add new power actions for the sysmoBTS2050. This allows to
switch off the secondary/slave when the system temperature
is too high and back on when the normal level is reached.
Do not allow to switch off the master (so remove the enum
value), do not check if the slave is switching itself off.
Instead of keeping state to remember what was done and needs
to be undone this patch introduces actions that will be executed
when the system is back to normal.
By design the system is considered to be in the normal state
and these actions will be only executed after the system is
coming back to the normal state.
One advantage of this scheme is that an operator can decide
that an overheated systems hould be off duty and requires manual
interaction to be allowed back in service.
The change has only been smoke tested
Fixes: SYS#833
Read the clock calibration from the place that will be read by
the BTS process. Use the standard eeprom code for doing that.
The code assumes that this and the other eeprom code don't
write/invlidate the others reason. If that assumption would not
be true calls to eeprom_free_resources should be added.
For systems without direct access to the PA the best option
is to simply switch off the bts service. This will stop the
transmission which will take load from the DSP/FPGA/RF circuit
and indirectly from the PA as well.
We should introduce "pa-on and bts-on" that can be executed
as "normal" action.
Somebody could decide to switch off the PA in the warning level
already. Support this mode of operation. This means we could have
a config that:
* Enables the PA in the normal level
* Disables it in the critical level
With kdbus or better IPC we could even have the PA and other
parts be represented as service that talk to a bts manager and
then simply execute start/stop requests. This would make the
entire TODO entry irrelevant as state would be managed by
systemd and one can see the time the service was executed.
With "show bts 0" all objects were still listed as dependency.
Once the BTS has been started.. move all the other objects into
the enabled state. Our OpenBSC OML code doesn't care but people
using the VTY to inspect state will be more happy.
One day... we will create proper statemachines inside the BTS
and the BSC instead of changing the state in the BTS impl.
Fixes: ONW#1330
The service file will prevent a re-launch of the sysmobts.service
in case the main process exits with '1'. In case the ethernet is
not available yet the routine would fail and the sysmobts process
will not be restarted.
unable to connect/bind socket: Network is unreachable
<000f> input/ipaccess.c:885 cannot open OML BTS link: Network is unreachable
unable to connect to BSC
root@sysmobts-v2:~# echo $?
2
Fixes: SYS#736
We use the completion call-back from L1 to compare the instructed
TRX board output power with the actual value as reported back from
L1.
Right now we only print an error message in case the values disagree.
In the future we might want to either use that value as part of our
calculation or send an OML alarm report to the BSC.
This sysmobts specific control interface allows for clock calibration
from an external program by means of the "trx.0.clock-info" and
"trx.0.clock-correction" values.
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
The PA will be unconditionally turned. This makes it possible
that in case of a crash, the PA will be turned on and then we
will do the temperature measurement and turn it off again. There
are no known crashes with the sysmobts-mgr right now so the risk
seems to be okay. In case we can't switch off the PA we have no
way to escalate it right now. We have not seen a dead uc either
so the risk is okay as well.
We can't switch the PA back on once we reach the normal level
as the BTS might transmit with full power and we would need more
current than the power supply/rails can carry. So leave the
system off right now.
What is missing is to use the OML router to actually inform
the BSC that something bad has happened at the BTS.
Check the temperature and move between "NORMAL", "WARNING"
and "CRITICAL" state. We will only return from CRITICAL to
WARNING when the temperature has significantly changed, and
when being in state "WARNING" we enter an intermediate state
to allow an easy hysteris.
We haven't done anything with the result of the micro controller
query and querying every six hours for the temperature of the
system will not help us. We need to query the temperatures more
frequently but avoid writing to the eeprom too frequently so we
will start another timer for that.
The idea is that for different parts of the system we can define
thresholds for warning and critical (severe) temperate thresholds.
And once any of these temperatures is reached we will execute an
action. When crossing from NORMAL to WARNING or WARNING to SEVERE
we will need to apply some hysteris before switching back to the
lower level. E.g. when being SEVERE mode, at least wait until we
are below the warning level again. Besides being able to switch
off things we could start reducing the transmit power of the system
until the system is cold enough again.
No action is implemented so far, everything is varpoware!
We need to build a lot more code to be able to test these two
new routines. I didn't want to move the code to a utils file
as the check is called from a hot path. Add accessors to the
inlined variant to be used by the unit test.
While writing the unit tests I noticed that a re-transmission
of the ciphering command would lead to an attempt to enable
ciphering again. I am not sure that this MphConfig is idempotent.
The network is configured with early classmark sending. This means
that the phone might send a "classmark change" message at the same
time we send a ciphering mode command. When we received the CM
message we assumed we have just received the first ciphered message
and enabled ciphering for tx as well.
When we snoop the Ciphering Mode Command extract the N(S) variable
and when we receive an I frame from the MS see if it handled our
message by comparing the MS N(R) to BTS N(S) + 1.
I wondered if I should use the 'abstract namespace' feature
of Linux but just put the router into /var/run/ to make it
work out of the box. Change the signature to provide a sane
error message.
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.
Begin with the basics of a OML Router. This is currently only
capable of accepting a connection and read messages but it will
evolve into a router in multiple stages. The first usage will
be by the sysmobts-mgr. An OML Error Indication will be sent by
the sysmobts-mgr and it will be forwarded to the BSC. In the
second step we will set a relative power reduction from the
sysmobts-mgr.
In the long-term this code will be used to communicate with a
second TRX.
We need to patch the CMR due wanting to support systems that still
have Audiocodes hardware in their chain. I have manually tested
and could listen to my own voice on:
TCH/H & AMR 5.9 & PTSN & BSC
TCH/F & FR1 & Other subscriber & NITB
TCH/F & EFR & Other subscriber & NITB
TCH/H & HR1 & Other subscriber & NITB
TCH/H & AMR 5.9 & Other subscriber & NITB
The tests were done using the Nokia E71, a Blackberry curve and
for the PTSN a HTC 8S were used.
For systems with a bigger PA enabling the full output power at
once might draw more current than a power supply can provide. This
code will step up the output power in smaller steps to avoid this
situation.
The sysmoBTS2050 does not have a OCXO and we should not rely
on the GPS module to always have a fix. Instead use the TCXO
by default and from time to time (and we know we have a fix
calibrate the TCXO). This can be done by:
trx 0 rf-clock-info reset
wait...
trx 0 rf-clock-info correct
write
The output is currently only written to the log as the VTY
connection might go away during the operation. The reset will
set the approriate reference clock and the correct will attempt
to determine and apply the correction. The write terminal will
make sure that next on start a known good value will be used.
For LCR and other systems without out-of-band information we need
to indicate the CMR. Not every air message will include the mode
and we sent a stream that had the CMR set and not-set. This lead
to the AudioCodes MGW only playing every second frame.
Remember the last used mode and initialize it to _NONE when we
receive the multirate config. In case of a real error we will
still use AMR_CMR_NONE.
The initial patch is from Harald. I have added the initialization
and moving of the defines to amr.h.
Manually verified by enabling AMR5.9 and looking at two RTP
packages in sequence. In both cases the CMR was 2. I have looked
at "amr.nb.cmr != 2" in wireshark and only found the MGCP dummy
packet.
The code should only run for the sysmoBTS 2050 and TRX 0.
If the device is not marked as 2050 the code would attempt
to open /dev/ttyS0 and block forever.
Harald is right and that the code is generally not ready
for inclusion. I fell victim of trying to finish it while
the code is not ready at all. It is better to re-introduce
the patches in a smaller and more tested way.
The right way would have been a branch were ready things
are split-off the main/wip commit until everything is ready.
Revert "sysmobts: Have a common prefix for the enum"
This reverts commit 44980347f3.
Revert "utils: Used the enum manuf_type_id in the parameter of add_manufacturer_id_label"
This reverts commit 7d36e5ed46.
Revert "utils: Classify the OML message using the return type"
This reverts commit afee0b7929.
Revert "sysmobts: Do not access out of bound string"
This reverts commit f5f41e8051.
Revert "sysmobts: Separate IPA and OML check into two methods"
This reverts commit 13a224063d.
Revert "screenrc: osmobts-mgr now needs a config file"
This reverts commit 0a1699ff8a.
Revert "make sure osmobts-mgr.cfg file is included in tarballs"
This reverts commit 14c60b425f.
Revert "sysmobts-mgr: Add VTY support for configuring it"
This reverts commit c5fedd24c9.
Revert "sysmobts: Add beginnings of an OML router and create Failure Messages in the sysmobts-manager"
This reverts commit c6ab90b270.
Classify the OML message and return the manufacturer type
or an error. Currently ETSI, ip.access and Osmocom are known.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
I have split the function check_oml_msg, in two functions. One for
checking if the ipa header is well-formed and in check_oml_msg,
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Enable the previously commented-out logic to set the CMR (Codec Mode
Request) in AMR RTP frames based on the CMI (CMR Index) of the AMR
speech frame on the Um interface.
This is of course anyway the right thing to do, but also required for an
AMR receiver which doesn't have out-of-band information on the codec
mode, and which also doesn't determine the AMR codec mode based on the
size of the AMR frame (such as lcr as of current master).
We also move the entire CMR generation into the #ifdef section
which is only compiled-in if we do _not_ use the RTP mode of L1.
Make the sysmobts-mgr send a manufacturer O&M message with the power
reduction we want the sysmobts to apply. The sysmobts will handle
this message and set the new tx output power. An ACK/NACK will be
send as a response to the power reduction.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
This patch allows to configure the warning temperature threshold,
the severe temperature threshold of the board and the PA and the
actions like the relative value power that we want to reduce the
transmit power to and the part that we want to switch off or not.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Make the sysmobts listen for OML messages on a Unix Domain Socket.
Messages passing a sanity check will be forwarded to the BSC.
In case the sysmobts-mgr detects a temperature above or below
temperature threshold an OML failure message will be sent
to the BTS.
[moved confinfo into the #ifdef BUILD_SBTS2050]
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Initialize the libosmo-abis VTY nodes more early so we can parse
the config file that was created by "write". Introduce abis_init
to initialize the libosmo-abis and modify abis_open to re-use an
existing line. Update the comments. This has only been tried with
the sysmobts-remote on x86. A TCP connection is opened toward the
configured BSC.
Fixes: SYS#285
Include utils.h to have a declaration of sysmobts_get_nominal_power,
l1_if.c: In function 'l1if_activate_rf':
l1_if.c:1144:6: warning: implicit declaration of function
'sysmobts_get_nominal_power' [-Wimplicit-function-declaration]
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
In case the max power reduction has been changed through OML,
let us call the l1if_set_txpower routine to update the nominal
power. This has been manually verified with both BTS #1 and #57.
./bsc_control.py -d localhost -p 4249 -s bts.0.trx.0.max-power-reduction 0
The above command and GNUradio have been used to determine if
the power level has changed at all.
Fixes: SYS#268
These routines do not pass the gsm_abis_mo and parsing the FOM
header of the msg does not seem to be a good idea either. Pass
in the OML object so that the model code can determine what the
void pointer is.
Older hardware didn't have the external attentuator that was used
to control the wanted output power. So starting from the git commit
3c8ff3c70b older hardware was always
transmitting with 23 dBm regardless of the power reduction.
Remember the hardware revision returned by the SystemInformation
primitive, postpone the call to l1if_activate_rf until we know
the board revision.
Manually verified on BTS #1 and #57. On BTS#1 the external
attenuator has not been configured and on BTS#57 it was.
The DSP/FPGA appears to report bogus PhDataInd with hlayer2 == 0.
Currently this would match the TRX==0,TS==0 and SS=0 and then we
report bad measurement reports. Add a magic number to the lower
eight bit of the hLayer2 to differentiate valid numbers.
Addresses:
<0004> measurement.c:97 (bts=0,trx=0,ts=0,ss=0) measurement during state: NONE
<0004> measurement.c:102 (bts=0,trx=0,ts=0,ss=0) no space for uplink measurement
I have extended the principal function that we use for requesting
information to the microcontroller for switching off/on the board
and the PA. And I have extended it for requesting the power status
information of the board and the PA.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Add function for requesting the temperature information to the
microcontroller. I have added a function that we can extend
for requesting more information but in this case we only need to
know the temperature.
I have added to a microcontroller temperature handling function
in the manager for monitoring this information.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Currently a locked cell is actively broadcasting when it is being
bootstrapped after the lock.
This patch adds an initial update of the RF mute state when the TRX
is initialized.
Ticket: OW#1131
Sponsored-by: On-Waves ehf
When the lchan was activated for handover configure it to wait
for a RACH burst. On release make sure to always release the
RACH SAPI (in case it has been allocated). On the first frame
inform handover.c about it and forward the received access burst
to the handover layer.
Using an E71 it was possible to make a handover for SDCCH and
TCH/F from a nanoBTS but also from itself to itself. The vty
commands of OpenBSC and the silent-call have been used for that.
I didn't verify audio handling so far.
The BTS layer needs to inform the handover code when an access
burst has been received. In turn the handover layer will ask the
bts to modify the channel, it will schedule the physical information
inform the BSC with the HANDOVER DETECTION and waits for the BTS
layer to inform it about the first received frame to stop a timer.
Before, this patch the program tried to read the info
of the temperature sensor from a wrong location.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
This could lead to a BSC attempting to release the BCCH or a
PDCH. In the case of the BCCH this lead to a funny crash.
Log:
<0000> rsl.c:605 (bts=0,trx=0,ts=0,ss=4) Sending Connection Failure: cause = 0x01
<0000> rsl.c:1720 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
msgb_dequeue (queue=0x4007d2d8) at msgb.c:102
102 llist_del(lh);
(gdb) bt
#0 msgb_dequeue (queue=0x4007d2d8) at msgb.c:102
#1 0x4002ed28 in lapd_dl_flush_tx (dl=0x4007d220) at lapd_core.c:173
#2 0x40030cb4 in lapd_dl_reset (dl=0x4007d220) at lapd_core.c:307
#3 0x40030d00 in lapd_dl_exit (dl=0x4007d220) at lapd_core.c:321
#4 0x40033d80 in lapdm_entity_exit (le=<optimized out>) at lapdm.c:169
#5 0x40033d9c in lapdm_channel_exit (lc=0x4007d214) at lapdm.c:180
#6 0x0001a334 in rsl_tx_rf_rel_ack (lchan=0x4007d180) at rsl.c:505
#7 0x0000e908 in lchan_deactivate_sapis (lchan=0x4007d180) at oml.c:1427
#8 sapi_queue_exeute (lchan=0x4007d180) at oml.c:547
#9 0x0000ead0 in sapi_queue_send (lchan=<optimized out>) at oml.c:571
#10 queue_sapi_command (lchan=<optimized out>, cmd=<optimized out>)
at oml.c:609
#11 queue_sapi_command (lchan=0x4007d180, cmd=<optimized out>) at oml.c:601
#12 0x0000faf0 in enqueue_rel_marker (lchan=0x4007d180) at oml.c:1440
#13 lchan_deactivate (lchan=0x4007d180) at oml.c:1447
#14 0x0001004c in bts_model_rsl_chan_rel (lchan=<optimized out>) at oml.c:1647
#15 0x0001b948 in rsl_rx_rf_chan_rel (lchan=0x4007d180) at rsl.c:844
#16 rsl_rx_dchan (msg=0x75a88, trx=0x4007b038) at rsl.c:1727
#17 down_rsl (trx=0x4007b038, msg=0x75a88) at rsl.c:1853
#18 0x000154d4 in sign_link_cb (msg=<optimized out>) at abis.c:132
#19 0x400701c0 in ?? () from /usr/lib/libosmoabis.so.2
#20 0x400701c0 in ?? () from /usr/lib/libosmoabis.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Fixes: OW#1133
This patch adds a common function bts_ccch_copy_msg() that provides
and schedules AGCH and PCH messages. It is basically a frontend to
paging_gen_msg() and bts_agch_dequeue() and contains refactored code
from l1_if.c.
Sponsored-by: On-Waves ehf
Currently, the msg->data pointer is just set to the IMMEDIATE ASSIGN
message and the len is adjusted accordingly. Unfortunately, this
leaves l2h (pointing to the RSL header) and l3h (pointing to the
FULL_IMM_ASS_INFO IE) in an undefined state (outside of [data, tail]).
The code in bts.c accesses the message via msg->data.
This patch sets l3h and l2h correctly. msgb_l3() will point to the
start of the IMM ASS message and should be used instead of msg->data.
Sponsored-by: On-Waves ehf
Today we had the problem that multiple l1fwd-proxy instances ran
at the same time and not everything working all the time (some
packets were sent to a different host).
Another approach is to use flock on the message queues. This appears
to work fine as well.
Write the requested timing advance into the header. We are currently
using the u8AutoTA mode so the value will be overwritten by the DSP
before the bursts are sent to the MS.
When a frame is sent on the SACCH the LAPDm code will already
prepend two bytes for the tx_power and the ta. In the BTS we want
to use the values that were set by the BSC though. They currently
come from the RSL CHAN ACT but could also be set through the
RSL MS power control command. Update the comment as the space is
not empty.
At the 30C3 we had a NITB crash because of a RLL timeout on a
TCH/F. Jacob analyzed the problem and tracked it down to the
mismatch of LAPDm and the l1 interface to the DSP.
The sysmoBTS L1 has the TSC as a global value, we cannot have individual
per-timestamp or even per-lchan TSC, as the GSM specification would
suggest (and other BTSs support).
Rather than fail silently, write an error message to the log and
return NM_NACK_PARAM_RANGE or RSL_ERR_SERV_OPT_UNIMPL back to the BSC.
In the MPH ACTIVATE-RF.req, we need to specify the nominal maximum
transmit power, i.e. >= what we later request during MPH-INIT.req.
This field was first introduced in API version 2.2, but we never used
it so far. It may help fixing a bug related to excessive power
consumption of the sysmoBTS 2050.
Bind to port 3006 and listen to incoming IPA requests. Currently
we unconditionally respond with the MAC and IP Address of the unit.
To determine the IP Address the kernel is asked for thesource
address of the route for the destination. In contrast to a nanoBTS
we will reply to the port the initial request came from.
The sysmoBTS takes quite a bit of CPU time for the vfprintf that
is used by osmo_hexdump. Do not dump every single frame to improve
the performance a bit.
In the perf the ARM EABI ddiv operation showed up in the most
of expensive symbols. It doesn't really make much sense as the
calls should only be done on configuration.
calib_file.c: In function 'next_calib_file_idx':
calib_file.c:126:3: warning: implicit declaration of function 'band_femto2osmo' [-Wimplicit-function-declaration]
Use the lchan->rel_act_kind field for the BCCH activatiob by OML.
The lchan's should be marked as active but no event should be sent to
the BSC. This is mostly like the PCU. We can now remove the secnd
argument from lchan_activate.
There are existing deployments where the EEPROM either contains a
wrong value and/or the kernel can not be updated to support the
different EEPROM of revD. Revert to the old behavior that if no
nominal can be derived from the model_nr we assume that it is 23.
Currently it takes some time (around 30s) until it is detected that
the radio link is down after mute. Not till then the BSC is informed
and the call terminated.
This patch modifies this behaviour by sending a RSL_MT_CONN_FAIL
message with cause RSL_ERR_RADIO_LINK_FAIL for each muted and active
lchan immediately after the corresponding Change Administrative State
Request has been acknowledged.
Ticket: OW#976
Sponsored-by: On-Waves ehf
Currently only mute_state[0] (refers to ts[0]) is inspected to
determine, whether the Radio Carrier's state is set to LOCK.
This patch changes this by looking at all channels and using LOCK
if (and only if) all channels have been muted successfully.
Sponsored-by: On-Waves ehf
Currently the LEDs are being accessed directly from within the
l1_if.c file. So the handling of rf mute and activate/deactivate both
access LED_RF_ACTIVE directly. This may lead to an inconsistent LED
status.
This patch replaces these calls to sysmobts_led_set() by an abstract
equivalent bts_update_status(), that uses a set of independant status
ids. The associated values can than be combined into a visible LED
status. Currently LED_RF_ACTIVE is on iff BTS_STATUS_RF_ACTIVE is set
and BTS_STATUS_RF_MUTE is not set.
Sponsored-by: On-Waves ehf
Currently a Change Administrative State Request is just applied
unconditionally to the object's state object and then acknowledged.
This patch implements the special handling of setting the Radio
Carriers state to LOCK or UNLOCK. This is done by passing the
appropriate mute command to the L1 layer. Always all radio channels
are affected, it is not possible to lock single radio channels.
On success, an ACK is sent back to the bsc with the new state (based
on the state passed in the callback by the L1 layer). If something
went wrong or the firmware doesn't support RF mute, a NACK
(REQ_NOT_GRANTED) is sent instead.
Note that a NACK for such a request hasn't been sent by the BTS to
the BSC yet, so (albeit it's spec conformant to do so) the BSC must
be prepared to handle this correctly.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This adds a new function
l1if_mute_rf(femtol1_hdl, ch_mute[8])
to set the mute state for each radio channel. On completion and iff
l1if_mute_rf() returned 0 the callback
oml_mo_rf_lock_chg(mo, ch_mute_state[8], success)
is invoked when the response from the superfemto DSP is received.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This add the mappings for SuperFemto_PrimId_MuteRfReq and
SuperFemto_PrimId_MuteRfCnf to the arrays femtobts_sysprim_type,
femtobts_sysprim_names, and femtobts_sysprim_req2conf.
Sponsored-by: On-Waves ehf
Currently uninitialized elements of the femtobts_sysprim_type array
are mistaken as L1P_T_REQ (which is accidently the first element and
thus 0).
This patch adds a new element to the enum that has the value 0 to
detect uninitialized elements of the femtobts_sysprim_type array.
Those will then show up in the log as 'SYS Prim XXX is not a
Request!'.
This patch also adds missing definitions of the CalibTbl messages
in the femtobts_sysprim_type mapping so that the requests can still
be identified as such.
Sponsored-by: On-Waves ehf
This is used in the sysmoBTS 2050, where the maximum power is 40 dBm
We might want to add a safeguard of some kind to prevent people from
overdriving their transmitters.
The TRX nominal output power (as seen by OML) is the aggregate power
of any gain internal to the sysmoBTS (and managed by L1) and any
external PA. This is what is used in trx->nominal_power;
fl1h->l1_power is the transmit power to which we configure the sysmoBTS
L1. This is 23 dBm (200mW) by default in the sysmoBTS 1002, and 40 dBm
(5W) in the sysmoBTS 2050. However, if sysmoBTS 2050 is used in
single-TRX configuration, it may be used with higher power, which we can
now configure in the config file / vty.
TODO: A separate, additional field that keeps track of any gain added by
an external PA, e.g. if the sysmoBTS 1002 is used with a sysmoAMP.
If the clock is provided by an external (like GPS) clock, we should not
use the calibration value. The latter is only used in context of the
OCXO or VCTCXO.
If the EEPROM tells us that a given unit doesn't support a given band,
we shouldn't try to use it, even if the BSC tells us to use an ARFCN in
such an unsupported band.
The reason is simple: The given BTS unit might have band specific
filter / duplexer / PA.
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
By default read the clock calibration from the EEPROM. It is
still possible to set it using the cli.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
Coverity wants us to check that fscanf has scanned the amount of
variables we want to have. Initialize the scan result to 0/0.0f
and warn if the scan has failed.
Fixes: Coverity CID 1040774, CID 1040773
Coverity insists that we should check the return value of the
calls to fseek. In general this is a good idea.
Fixes: Coverity CID 1040770, CID 1040771, CID 1040772
Calling eeprom_write would either re-use g_file or newly open the
file and set g_file but it will close the file as well. This will
lead to other code using fseek/fread on a closed file.
On top of that the general rule for the eeprom code now is that
read and write may not be mixed (due caching and other bits).
The array has three elements but check was for > _NUM_TEMP_TYPES (3)
so an access at array[3] was possible. It is unlikely to have
happened due the usage of enums. Use ARRAY_SIZE and >= on the real
array to avoid this problem.
Fixes: Coverity CID 1040760
The current code has 26 fseek/fread. Only the minority really results
in a call to read. Nevertheless the time for reading during the bootstrap
can take up to 7.82 seconds. Caching the header (which is already done
by fopen/fread) will result in one call to fseek/fread and only
consumes 0.784 seconds.
Commit 5643130664 by Daniel changed
the ciphering to go through the command queue. In this commit the
direction for the ciphering got turned around and was not spotted
by review. It worked in testing due the usage of A5/0 and in that
case the direction did not matter.
sysmobts_vty.c: In function 'activate_lchan':
sysmobts_vty.c:373:3: warning: implicit declaration of function 'lchan_activate' [-Wimplicit-function-declaration]
sysmobts_vty.c:375:3: warning: implicit declaration of function 'lchan_deactivate' [-Wimplicit-function-declaration]
eeprom.c: In function 'eeprom_ReadEthAddr':
eeprom.c:305:5: warning: pointer targets in passing argument 3 of 'eeprom_read' differ in signedness [-Wpointer-sign]
eeprom.c:260:12: note: expected 'char *' but argument is of type 'uint8_t *'
This should fix:
calib_file.c: In function 'calib_eeprom_read':
calib_file.c:262: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:262: error: (Each undeclared identifier is reported only once
calib_file.c:262: error: for each function it appears in.)
This should fix:
calib_file.c: In function 'calib_fixup_rx':
calib_file.c:148: error: 'SuperFemto_SetRxCalibTblReq_t' undeclared (first use in this function)
calib_file.c:148: error: (Each undeclared identifier is reported only once
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3f. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
In case there is no transmitter the S counter might never be decreased.
This means that no radio link timeout will not be sent and the lchan will
remain open forever. There are several ways to resolve this.
The first would be to use the MphTimeInd and after each multiframe check
if there has been a SACCH message for the open lchan's. This could be
similar to the trx_meas_check_compute.
I decided to change fBFILevel to always receive SACCH frames and move
the code down to the PDTCH/PACCH handling and update the comment.
In most cases there are multiple messages ready to be read from
the queue and it is more efficient to read them in one go instead
of going through the select again.
Attempt to write multiple primitives at the same time instead of
the select/write, select/write that is currently done. The queue
size is big enough to hold several entries at the same time and it
is unlikely we get the -EAGAIN from the kernel driver.
The writev code works by assuming that each element in the queue
has the same size. This is not verified by the code and if this
assumption breaks at some point the code will drop primitives or
send some twice.
Make sure the l1msg is always freed in the callback. There were
several error conditions were the msgb would not have been freed,
in the case of the calib data and the system information the message
was not freed even in normal condition.
I will modify this code to __use a msgb. This allows to re-use
the allocated msgb across read operations.