Age | Commit message (Collapse) | Author | Files | Lines |
|
When the FACCH is generated (while in SPEECH mode), there is also a
fake speech indication handed up to l1sap.c. We must make sure that only
one of the two indications carry a measurement value, so lets invalidate
the measurement values (RSSI in particular) for the generated TCH
indication.
Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b
Related: OS#4799
|
|
Change-Id: I744520199ef448ff095d0fe703d79ac08f08f7fe
Depends: Ie2022a7f9e167e5ceacf15350c037dd43768ff40
Related: SYS#4910
|
|
Change-Id: I9646a45d61153499ad3d580a03d930ed20e23cda
|
|
Otherwise it's hard to fit new options with long names.
Change-Id: If9a418545abff6d22602ba07cfd4447f5ace7742
Related: SYS#4910
|
|
Change-Id: I516a71124a49f6d6adb6db939a91da07576e63e7
|
|
Change-Id: Ib886115418939990ecfb6ecc1a4528f7a015b913
|
|
Otherwise, some objects are announced at startup of osmo-bts towards BSC
during State Changed Report as being "NULL".
According to TS 12.21:
"NULL(Operat. state not supported) FF"
Which doesn't make much sense in startup situation. They are in known
state Disabled until they are OPSTARTed.
Change-Id: I5ba6756ea069d0f995f453ee4b27e6839c914eb1
|
|
Previous commit 7810a917331b33b6cfab5259b5fb2df73b27b230 forgot to
introduce this line, though it was planned to be there.
Most of the time it worked fine anyway because the RSL link is not the last
event bb_transc waits for before switching to Enabled, so later events
would trigger inside the bb_transc fsm a recheck (polling) which wuld
allow to advance to Enabled state.
However, in the situation where RSL link UP is the last event to happen,
no more inside-FSM checks are triggered and hence BB Transeiver never
goes to Enabled state, and as a result no event is triggered towards
each RadioChannel which in turn don't go to Enabled state.
Fixes: 7810a917331b33b6cfab5259b5fb2df73b27b230
Change-Id: I8c777b946e7abcb4b607ec4d136c981a0716b120
|
|
80% (alpha=0.2) is clearly too much, let's use 50% (alpha=0.5).
Change-Id: Ib7aec6c7223ffb2d4a312eee77247925beb8c905
Fixes: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
|
|
Change-Id: I288cbfb4730b25a334ef1c3d6b9679d6f1d4cfc5
|
|
All the Operative State logic to manage a RadioCarrier//BBTransc NM objects is
centralized in these FSM, where other parts of the code simply send
events to it.
This allows keeping state consistent and offloading logic from each bts
backend, since they are only required to submit events now.
The idea in the long run is to also replace other NM objects with
similar FSMs.
This improved logic fixes bug where PHY + RSL link became available before
OPSTART and hence op state changed to Enabled before receiving any OPSTART message.
Change-Id: Ifb249a821c4270918699b6375a72b3a618e8cfbe
|
|
Change-Id: Iae631bcc7acdf955296b124707e42d5e565af186
|
|
This fixes old behavior mimicing broken behavior in nanoBTS (according to TS 12.21)
where BTS Site Mgr NM object was announced as Enabled despite no OPSTART
was sent by the BSC.
With this new FSM, BTS SiteManager will be announced as Disabled Offline
during OML startup conversation, instead of Enabled.
The new osmo-bsc OML management FSMs use this change in behavior to find
out whether it should use the old broken management states (without
Offline state, as per nanoBTS) or use the new state transitions (which
allow fixing several race conditions).
Change-Id: Iab2d17c45c9642860cd2d5d523c1baae24502243
|
|
enabled
This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs,
which expectes for non-nanoBTS types to follow TS 12.21 guidelines.
Until now, BSC simply waited to received State Event Change Dependency
for each TS and then sent all required commands (Set Chan Attr, Adm
Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when
in Offline state, so we need to transit to that state. For the above
mentioned reason, since we pass through the Dependency state anyway
after this patch, older osmo-bscs will work correctly too.
Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
|
|
We originally wanted to intrdouce an OML router which would permit
external proceses to implement certain OML MOs. However, that code
was never completed, and all the existing implementation (in three
copies) does is to create a unix domain socket and discard what
is received there.
Change-Id: I7fcbbd5d6b64ddc666ca836dc49abb430be0d5cb
|
|
Change-Id: I9be55f791a15fae2362dc431dc778b9b9d8db349
|
|
Sometimes the following messages appear in the logging output:
TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
TCH/F: Prim has wrong chan_nr=0xc2 link_id=00, expecting chan_nr=0x0a link_id=00
when a dynamic timeslot is switched from PDCH to TCH/F (or to TCH/H).
This means that the transmit queue of a timeslot still contains
PDCH frames, that were not properly cleaned on PDCH deactivation.
Let's finally do this in trx_sched_set_lchan().
Change-Id: Ic6560c660c658f36b84e7efa2f1d93e3a870962b
Related: SYS#5108, OS#4804
|
|
Change-Id: If2b68e3c7bf01badaaa4666198a4a4c5709f0040
|
|
Trying to (de)activate logical channels that are already (de)activated
is not something that we normally expect. Treat this as error.
Change-Id: I6256280cae35b2b4d7a8ba4b3913ca69cde22611
|
|
Change-Id: I476dabb059325058a4327bb96430ce6ade199580
|
|
Change-Id: I951ec9b02be674936fbd0bf2e75b004813e25197
|
|
In this function we already do check that a given timeslot is not
a PDCH slot, so checking if TRX_CHAN_FLAG_PDCH is redundant.
Change-Id: Ie73bdaf0f6bc76ed8d2e95d1fb995333bf617e7e
|
|
Both TRXC_PDTCH or TRXC_PTCCH are described in 'trx_chan_desc'
(defined as 'const'), and both have TRX_CHAN_FLAG_PDCH set. So
indeed, this condition can never be true.
Change-Id: Ie185a939b48eb859ac1c8ffa0a4f667fda0cb82b
|
|
Change-Id: I26fb115ce0a7c33453b05c8fcee8a21d1a2a97d5
|
|
Recently we've introduced EWMA based uplink power filtering, that
should reduce Uplink power oscillations. However, the power loop
is still quite sensitive to small deviations from the target power
level: even such an insignificant deviation like 2-5 dBm triggers
the loop to increase or decrease the MS power level. Even if the
EWMA based filtering is enabled with 80% smoothing (alpha = 0.2).
This change introduces a new configuration parameter - 'hysteresis':
uplink-power-target <-110-0> hysteresis <1-25>
that together with the 'uplink-power-target' defines a range:
[target - hysteresis .. target + hysteresis]
in which the MS power loop would not trigger any power changes.
This feature is now *enabled* by default, so given that:
- default 'uplink-power-target' is -75 dBm, and
- default 'hysteresis' is 3 dBm,
the default target Uplink power range is: -78 dBm ... -72 dBm.
Change-Id: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916
|
|
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
|
|
Change-Id: Ia73fd766ddce3fd03d0f45b72cb2d056fae781fc
|
|
Change-Id: I24597dbdaa692f855be014c536f5758b8e503688
|
|
Change-Id: I3dd2c90f510444cda38516bd9a1a207877bebadc
|
|
Change-Id: Ia2d1098e25d0bbe39fd7e98eb7c96d43a32073df
|
|
Change-Id: I709ba2394862fcb0f86484792b5f8d3b338b42cc
|
|
Sending INFO.ind unconditionally in pcu_if_signal_cb() provokes
a lot of warnings during OML bootstrapping / termination:
DPCU INFO pcu_sock.c:247 Sending info
DPCU INFO pcu_sock.c:262 BTS is up
DPCU INFO pcu_sock.c:205 (bts=0,trx=0) unavailable for PCU (op=Disabled adm=Unlocked)
DPCU INFO pcu_sock.c:205 (bts=0,trx=1) unavailable for PCU (op=Disabled adm=Unlocked)
Do not call pcu_tx_info_ind() if the PCU is not connected.
Change-Id: If8bc8bec5ad808be8d40e91278a4a4fde84920b0
|
|
So far the Uplink power control loop did not filter the Uplink RSSI
measurements (reported by the BTS) at all. The lack of filtering
makes our implementation too quick on the trigger, so in the real
deployments there will be unneeded Tx power oscillations.
In order to reduce this effect, let's implement a very simple EWMA
(also known as Single Pole IIR) filtering that is defined as follows:
Avg[n] = a * Pwr[n] + (1 - a) * Avg[n - 1]
where parameter 'a' determines how much weight of the latest UL RSSI
measurement result 'Pwr[n]' carries vs the weight of the average
'Avg[n - 1]'. The value of 'a' is usually a float in range 0 .. 1, so:
- value 0.5 gives equal weight to both 'Pwr[n]' and 'Avg[n - 1]';
- value 1.0 means no filtering at all (pass through);
- value 0.0 makes no sense.
This formula was further optimized with the use of '+=' operator.
The floating point math was also eliminated by scaling everything
up (by 100). For more details, see:
https://en.wikipedia.org/wiki/Moving_average
https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter
https://tomroelandts.com/articles/low-pass-single-pole-iir-filter
The EWMA filtering is now *enabled by default*, but can be disabled
or (re-)configured over the VTY at any time:
! Completely disable filtering
no uplink-power-filtering
! Enable EWMA smoothing with the given parameters
uplink-power-filtering algo ewma beta <1-99>
Note that the VTY command expects 'beta' instead of 'alpha':
alpha = (100 - beta)
and the value must be in %. This is done for simplicity:
1% means lowest smoothing,
99% means highest smoothing.
Let's say we have EWMA filtering enabled with alpha = 0.4, and get
-98 dBm on the input, while the last output value was -60 dBm.
The new output would be:
Avg[n] = 0.4 * Pwr[n] + 0.6 * Avg[n - 1]
Avg[n] = (0.4 * -98) + (0.6 * -60)
Avg[n] = -75.2 => around -75
Of course, this is not a silver bullet, but better than nothing.
Change-Id: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
|
|
Depends: libosmocore.git I9d6ed06731ae15fdcef1a1f397d6ac2b7b1ca980
Change-Id: I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa
Related: OS#3075
|
|
Change-Id: I821120bf5c3690f5b4c6b96c879e675b3d271c90
|
|
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
|
|
Change-Id: I96d8359f4ae13c9f47cc87d87fde6d2047169a49
|
|
Change-Id: Icd19f803dc69138bf2fb1b0e1389b7ce1c8a9b1f
|
|
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I895db6086748a5916874e779963caed589050109
Related: SYS#4937, OS#1601
|
|
The PCUIF is a 'brilliant' protocol: some fields are expected to
be in the network byte order, some in the host order. The NSVC
remote address and local/remote ports is a good example:
- byte order of the address must be the network order, and
- byte order of the ports must be the host order.
Change-Id: I383cab0b58b62734090023298da8c5a341c670d5
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
|
|
This is another regresion introduced by [1]. Both local and remote
port numbers recived in the network order, and must be stored as-is.
Change-Id: I3c21a2c27dcbf6de728ce2c7ccbae9e2f517c450
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
|
|
Change-Id: Ib0efa6e1e2a68ac9675a18487b79d9b14bdb22c5
Fixes: OS#4785
|
|
Using gsm_bts_trx_num() involves redundant iterations over the
list of transceivers - we definitely don't want them.
Change-Id: I4bd40ffcc1e925412a21b0a934bbfdeddbc6ad1f
|
|
in function rx_tchh_fn() the variable meas_avg is not initalized. This
is not always a problem, since most of the time trx_sched_meas_avg() is
populating the variable properly. In cases where a FACCH is transmitted
(chan_state->ul_ongoing_facch = true) the variable is left unpopulated.
In order to have at least stable values for those cases, initalize the
variable with zeros for the ongoing facch phase.
Change-Id: I5c3c1c41d22f9edaaf6bd4478dd04f090dca12a9
Fixes: CID#214480
|
|
Change-Id: I707bb75f15ccaee5c67fa4a7e87dc70c9b982973
|
|
Change-Id: I272ceb09a3e8cac0082dbec3a034776da71d9366
|
|
Change-Id: If53fb07ec38f6bbc368ce84d14e59fa8167691d3
|
|
Change-Id: I24fc66175f79fe64400371e27b23556054c48dfe
|
|
Change-Id: Ifcdfcd157e5067fa2e4296d7c7e93a74087f49ff
Related: SYS#4937, OS#1601
|
|
The address_family is 8 bit and have a padding byte afterwards.
By using osmo_load16be it's encoding it wrong and result in an
empty/invalid NSVC configuration.
Change-Id: Ie070b5745124d48e74a6dedd8903b74bfb3ce9d2
|