Get rid of this helper function, which is a remain of past epochs
(pre-FSM). In the current uses, there's only 2 real cases: the "if" path
upon SET BTS ATTR received (and even that one should be moved as per
what the code comment states), and the one happening when the TRX is
closed.
it really makes no sense to DISABLE the TRX as a result of SET BTS ATTR.
Change-Id: I48adfeecd722684152c589bcba827079b0a78c3a
In oml_rx_set_bts_attr, arfcn for C0 is assigned from NM_ATT_BCCH_ARFCN.
The rest of the TRX get their arfcn from oml_rx_set_radio_attr()
NM_ATT_ARFCN_LIST.
Change-Id: I8aa9652622107fe0a707b2cbcbe8be6c71e19087
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
There's no real use for this queue. If the link is gone, it makes no
sense to keep old messages. Instead, BTS should generate new messages
sharing current state when link becomes established (it actually does
so already).
Change-Id: Iecd3c7cb96f5fff3b4c7e04c74e031df0f7a6987
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
Do not exit if all BSCs in the list fail to connect, keep trying
forever. This commit still doesn't change the logic after BTS has
successfully connected to a BSC. In that situation, if the link goes
down, BTS will exit in order to reset all state and let the user/system
restart it.
Related: SYS#4971
Change-Id: I67bba3b7e2d9d62b98a59a74987ae55206a3ec51
The pointer was used as "struct bsc_oml_host" sometimes, and other times
as "struct llist_head". It just worked because bsc_oml_host->list is the
first item in the script. The code was really confusing, also because
the bts list of items has a name really similar to the one currently
assigned. Let's rename the currently assigned address to "current_bsc",
store it always as "struct bsc_oml_host*" and finally use llist_entry
helpers when needed.
The related code is also moved to a helper function to enclose there the
logic to get next BSC in list. This change actually changes the logic
where a remote address is removed from VTY, since now the next address
in list is picked at the time, and later when reconnecting the list is
forwarded another time, meaning one address will be skipped.
This could be considered a bug, but this situation is really special
and anyway the entire logic will be changed in new commits where we'll
keep reconnecting in loop without exiting when reaching the end of the
list, so we are fine with it. Think of this commit as a preparation
commit for next ones.
Change-Id: I3cc8a4148b3d63bc185b72dab8108105a6644910
This clarifies the different states and transitions between them:
OML LINK UP: CONNECTING->CONNECTED
ANY LINK DOWN: CONNECTING->CONNECTING, CONNECTED->FAILED
In follow up commits, support to reconnect instead of exit after the BTS
has already connected will be added, so only the last transition needs
to be changed.
Related: SYS#4971
Change-Id: I43e83b1b04fbaa1f87818c096e6ad3920801b1f6
This test showcases the current issue where the loop keeps bouncing
between 2 good MS Power Level values due to the loop "accepting" and
"reporting back" the previously considered good MS Power Level
announced/used by the MS. Hence, upon report back from the network, the
MS will switch to this new MS Power Level, and same thing will ocurr
over and over.
Related: SYS#4917
Change-Id: I16ed7fe8a123b99008e0c041d2f3e4232057d55c
This should simply not happen. If other event is received, something is
terribly wrong, so we should exit immediately instead of silently
failing.
Change-Id: I5f4953be735f526bb8b926979233b3c26ba67ce9
CONNECTING state comes first in logical order of states (as properly
seen in enum of states), however, the FSM struct definition and state
action functions are swapped. Let's put them in order.
Change-Id: I0cae561926b460dc5882390db969b7c925903e5d
abis_init() sets "g_bts = bts;", hence bts object is the same as g_bts
(since we only have 1 BTS object in osmo-bts). As a result, dropping
checking first bts->... and later g_bts->... makes no sense: the later
condition will always be false.
Change-Id: I5018199221fb3c3329a59d0b91e827f077cef85d
Similar to what is already provided for power control loops. However,
there's no existing way to communicate TA control parameters from the
BSC to the BTS, so implement them locally in BTS vty.
Related: SYS#5371
Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Change-Id: If6cb8945645a2031f2b2ee65d9b9f51e75cd9af1
Related: SYS#5371
As per 3GPP TS 45.010 sec 5.6.3 Delay assessment error:
"""
the delay shall be assessed in such a way that the assessment error
(due to noise and interference) is less than 1/2 normal symbol periods
for stationary MS. For MS moving at a speed up to 500 km/h the additional
error shall be less than 1/4 normal symbol period.
"""
Hence, required TA loop calculation should take into account an error of
up to 1/2 + 1/4 = 75% of a symbol. By changing the threshold variable
to that percentage we make sure we take into account bigger deviations
and update TA accordingly.
Related: SYS#5371
Change-Id: I4c5825df4291d3851a113027abf7566de343a190
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I00852cb37a3613606e37476c169f5a32d6b5d75e
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
From TS 45.010 5.6.1 (delay tracking for circuit switched channels):
"""
Restricting the change in timing advance to 1 symbol period at a time
gives the simplest implementation of the BTS. However the BTS may use
a larger change than this but great care must then be used in the BTS design.
"""
In general 1 TA at a time (every 480ms of SACCH block) should be enough,
since section 5.6.3 states:
"""
The control loop for the timing advance shall be implemented in such a way that it will cope with MSs moving at a
speed up to 500 km/h
"""
Which is ~140 m/s, and 1 TA step around 500m, so most of the time we
should be save and no steps of more than 1 TA should be required.
However, unlikely changes from reflected to direct signal or vice versa
could produce higher increments, so let's increase the maximum step size
allowed to 2 in order to give more room.
Change-Id: I9e48faabf3090588233e274b2b39065cf85fbec7
First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.
The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)
This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.
Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
Tests have shown that even a delay of 0, i.e. a simple defer until the
next select() loop, makes the difference from failing to working early
IA. So set the default to 0, achieving such defer.
Related: SYS#5559
Change-Id: I95365649edd51114bcf6028f0dc3bbe4186f96d2
During live testing, it has become apparent that some IMM ASS still fail
when sending the RR IMM ASS directly upon the target channel becoming
active.
Add a bit of delay after activation, to give some time for the channel
to light up for the MS. Default is 50ms.
Related: OS#5559
Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
The bug showed up in previous commit and is fixed in this commit. It can
be seen how rounding error is carried over time in the average
measurement, and affects final values.
Change-Id: I680d1c94bd4bae179b14b26662a819fa1462a5c8
Before this comits, averaging and delta calculation was done in RSSI,
but stored the averaging cached state in variables named "rxlev", which
was really confusing. Let's keeping averaging and delta calculations
based on RxLevels.
Some of the tests change results due to test passing RSSI -45, which is
an invalid Rxlev (only up to -47 is supported).
Others fail due to an unrelated bug showing up now. Basically the averaging algo
is doing rounding the wrong way when downscaling the values. It will be
fixed in a follow-up commit.
Change-Id: I4cff8394f22b5d47789163051364ff594b2bcd74
If RxQual is considered good enough, attenuation can be increased in
order to lower overall cross-channel noise among different MS.
Change-Id: Ie97898980acd152de15f6b4b619d492048855ef4
params->rxqual_meas.upper_thresh is left unchecked in
lchan_bs_pwr_ctrl() on this commit on purpose, to keep this
commit with old behavior wrt to algo logic.
Change-Id: If7e3987df89d680cfa443195ab2f225681d0e6cf
This commit reworks the code in function lchan_bs_pwr_ctrl()
and logging to look similar to that of lchan_ms_pwr_ctrl(), so that
reader can easily spot similarities between both and add simillar
features more easily.
This commit is also a preparation to add EWMA avg support for RxQual
measurements. Logging is also reworked now to look similar to that of MS
Power Control Loop, because having several parameters driving the algo
(RxLev and RxQual), it becomes more suitable to log all of them together instead
of intermediate info only aplicable to one param such as "delta".
Change-Id: Ida76b55f0da722135eb61ed06ea2b3a1862df600
Pau Espin
Philipp Maier
Neels Hofmeyr