Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
... which is now defined in libosmocore
|
|
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
|
|
We can use this on both slave and master. But only have the
master switch on the PA.
|
|
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!
|
|
|
|
|
|
Fix the build (provide empty stubs) when the header file is not
present.
|
|
We want to know which componets are enabled and the voltage and
current used by the components.
|
|
Read the sensors that are always present and the ones that
are only present on the sysmoBTS 2050.
|
|
|
|
Use it for the ipaccess-find response and for the sysmobts
classification code. This can be used by the vty in a second.
|
|
Initialize the ucinfo with an invalid fd to prevent writing
on fd=0 by accident.
|
|
|
|
Move the init and polling into the sysmoBTS related part. In the
future we should have _one_ temperature control.
|
|
|
|
Move the code to a separate file to keep things nicely apart
of each other.
|
|
Add VTY support to the manager. This way we can interactively
inspect the state of the system and trigger events.
|
|
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.
|
|
Seen while implementing a new functionality in the code.
|
|
Make it more easy to find the right BTS model and know what is
the master/slave.
|
|
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 44980347f308fe5bbe48a933dbc81b82b53d310a.
Revert "utils: Used the enum manuf_type_id in the parameter of add_manufacturer_id_label"
This reverts commit 7d36e5ed46b630203167fc9d5d28e0087fdbd394.
Revert "utils: Classify the OML message using the return type"
This reverts commit afee0b7929a00500f9c204f3bc7e12f72451e832.
Revert "sysmobts: Do not access out of bound string"
This reverts commit f5f41e805195c8c3294a9e6a68b10f975fbabbbd.
Revert "sysmobts: Separate IPA and OML check into two methods"
This reverts commit 13a224063dfcee0be529fba1c8fb9be9c1fb261e.
Revert "screenrc: osmobts-mgr now needs a config file"
This reverts commit 0a1699ff8a5462c167c24e8b28186abb26331698.
Revert "make sure osmobts-mgr.cfg file is included in tarballs"
This reverts commit 14c60b425f8146f6a392d2d3de2979c817cd975e.
Revert "sysmobts-mgr: Add VTY support for configuring it"
This reverts commit c5fedd24c96a4ef6d7a0c0ed3c70d6ef0abd5c17.
Revert "sysmobts: Add beginnings of an OML router and create Failure Messages in the sysmobts-manager"
This reverts commit c6ab90b27006ff2d1fdfb0b1d7fc01e1dd4a696d.
|
|
|
|
Rely on optarg pointing to an address that will be valid for
the run of the entire application.
Fixes: CID 1206578
|
|
Make the manuf_type_id enum have a common prefix for the
symbols.
|
|
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
|
|
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>
|
|
One can either use "strlen(str) + 1" but not add one to the
result of the sizeof.
|
|
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>
|
|
This reverts commit c64d42573894d8295b58b268a64541c914b69bcd.
There are unfrtunately still too many problems with this patch to be
merged at this point.
|
|
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.
|