Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
Probably a leftover from openbsc times.
Change-Id: I0b62c41bcb992df376668c6feb6ac7ada35d471d
|
|
Change-Id: Iacc32f7982c150d84ea4df7affa1f9e07806928f
|
|
Change-Id: I1b290af115730ba16f4f9887fe316e2ed15659a2
|
|
Change-Id: Ic195cef2aafec55d37152045f7714335ded0a62b
|
|
Change-Id: I378fea4aefb2cc4253cdd99ebc9c4f01b21faf95
|
|
bts_internal_flag_get() expects a flag value, not an integer.
Change-Id: I88de79cc45fb64144df33b0ac3e3b91537039953
|
|
Currently the UL measurements (RSSI, ToA256, C/I) of the burst that
concludes a block are passed up to the higher layers. This means
that the measurement values of the other bursts are skipped.
Let's keep record of all UL measurements and average the values
before we pass them up to the higher layers. Use a simple ring
buffer to store the measurement history (up to 8 unique entries
for now). Remove *_num/*_sum variables from l1sched_chan_state.
Change-Id: I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
Related: OS#3032, OS#2978
|
|
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Change-Id: I6d60277eb5b8d938d9f38114c933d58ee1b884c9
Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973
Related: SYS#4915
|
|
Change-Id: I04782222b499d0488269544910fbd4ed9929c05d
Related: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4546, OS#4547
|
|
Otherwise they may be set to ENABLED before CHAN SET ATTR and OPSTART
are sent, and oml_rx_opstart will blindly OPSTART ack (because they are
already enabled) and avoid configuring the timeslots.
That can happen if phy_link & rsl link get ready before receiving all
the OML CHAN SET ATTR and OPSTART commands on all RadioChannels.
Fixes: OS#4757
Change-Id: I50722c4e82faae32371817c3878bb41bfd0175ba
|
|
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
|
|
This list is already a part of struct gsm_abis_mo.
Change-Id: I19b907bea500569c6e7e1b64b50e1c2ee2014f1c
|
|
Most likely, this part of the structure was copy-pasted from the
corresponding definition in osmo-bsc. In osmo-bts we always
establish a single per-BTS OML link, not per-TRX.
Change-Id: I1792372de484608e04211c9de4294b3c76173ead
|
|
If for whatever reason a TS stops being announced as available to the
PCU (for instance because the TRX became administratively locked), the
PCU will send a Release for that channel, but in that case we don't want
to send an RSL RF Channel Release ACK because it was not initiated by
related command from BSC.
In the case of a simple PDCH timeslot (no dynamic), the behavior is
already there but we don't print an error log since it's expected.
In the case of a dyn osmo TS, we only need to respond to RF Channel
Release when PDCH is deactivated here, but in other cases we don't need
to submit anything to BSC.
Change-Id: I8ae9ee450763a0e14edf950e38b64a32df14f44f
|
|
Avoid announcing to PCU as available a dyn TS not yet fully
configured in the phy. Otherwise when we receive the Chan Activation
over the PCU sock while pchan_is still is not PDCH, and we fail to fully
activate the channel at that time.
See previous commit description for more information on the issue.
We still want to check for pchan_want because we actually want to stop
announcing the TS when it is in progress of being changed to TCH. This
configuration change is continued/finished once we receive the resulting
Release from PCU.
Change-Id: I8e2b170c1f94e7dfe2576a1fc899bf9c8a826a44
|
|
configured
Something is wrong currently with dynamic TS and PDCH activation.
Apparently there's a race condition between activation in BTS lower
layers (example in TRXC) and against PCU.
Currently, when a GSM_PCHAN_TCH_F_TCH_H_PDCH is configured, we set
ts->dyn.pchan_want = GSM_PCHAN_PDCH and submit the async activation
through lower layers (CMD SETSLOT), and once the lower layer acks it we
set ts->dyn.pchan_is = pchan_want (when receiving RSP SETSLOT). However,
we seem to be advertising available TS to PCU based on pchan_want,
instead of pchan_is, which means we advertise channels not yet fully
configured. As a result, we may receive a Channel Act coming from PCU
for a given TS for which we didn't receive confirmation from upper
layers, meaning pchan_is is still GSM_PCHAN_NONE. This is by no means
expected in following code, so let's avoid going further over it.
Actual issue will be fixed in follow-up patch.
Change-Id: I9edb5b8a14ffaed3e24c10c2c7a3f618e05f3a01
|
|
It was spotted that sometimes chan_nr BCCH was printed for a TS
containing configured as GSM_PCHAN_TCH_F_TCH_H_PDCH, which was totally
confusing. Indeed the problem is somewhere else, but let's log an error
and return 0 in this case, which will be converted to "UNKNOWN" string
later on.
Change-Id: Ic455af39c668481a13d579f33ac09033fd5c4009
|
|
Change-Id: Ibc398eb5d50851cbe48f2c92f14e746938a68720
|
|
This reverts commit df93a448b7638f51786236fcabaa6246ebe4ff94.
It was to early because the frequency hopping wasn't ready to be merged.
Change-Id: I6e67f4cd9828afa53ed4e783b83b039ee6a1d570
|
|
Change-Id: Iec7c41741ed093df8c60a3cda548662492f56116
|
|
Introduce a address_type in the NSVC configuration pass the given
protocol.
The remote_ip is network byte order, the default encoding for in_addr and in6_addr.
Change-Id: I4067b1af041b2cdad60d6fb16c9caee98bc218dd
|
|
Operative state is mainly maintained based on 2 requirements:
* phy_link being in CONNECTED state
* RSL connection being up and ready
However, state change report triggered over OMl towards BSC was only
done upon the first event of the two. That means that if for whatever
reason the RSL connection was established AFTER the phy_link became
CONNECTED (ie receiving RSP POWERON in osmo-bts-trx), then the status
towards the BSC would not be updated and hence the BSC would still see
the Radio Carrier object as DISABLED.
The trx_set_available() function is renamed to trx_operability_update()
to keep the logic conditions in one place, and different events
triggering a change in state simply call the function and let it handle
the new state.
Related: SYS#5063
Change-Id: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
|
|
Change-Id: Ifa453e101c32ee211844becf4604f3e08198da73
|
|
Change-Id: Id31e82b6bbfdd8030612c78737c0aa7dd7e20bd0
|
|
In general, it is always set to 1 (Locked) in
st_open_poweroff_on_enter() right after initial POWEROFF, and once the
BSC unlocks it (based on VTY cfg "rf_locked (0|1)") by sending an OML
message, the bts_model_chg_adm_state() call will update it sending
RFMUTE.
This basically fixes the case where osmo-bsc.cfg is configured with
"rf_locked 1" to start with a TRX locked until manually unlocked.
Related: SYS#4920
Change-Id: I96b64cdc901d6f216df628d7be57a67af4a21e25
|
|
Since commit 221ee92551a3d34c4f61e99e5bf4aa718c4d6f88,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbff849ecf16b7c70de4c1c7786704b2e
be15a12c87983ef07fb133fedea4ef18d2213bc6
eef420d1ca2144682d3de3f4e5cc4a7458276a03
https://osmocom.org/issues/4694
https://osmocom.org/issues/4695
https://osmocom.org/issues/4696
https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
|
|
Change-Id: I494ea9eb64634a03575a52750273cee7c68a8b3a
|
|
It was reported that both osmo-bsc and osmo-bts-trx may end up
running in a half-broken state, when everything looks good and
the UEs can see the network, but all channel requests get
rejected due to "trx not usable" error:
lchan_select.c:173 (bts=0) lchan_select_by_type(SDCCH)
lchan_select.c:48 looking for lchan CCCH+SDCCH4: (bts=0,trx=0) trx not usable
lchan_select.c:48 looking for lchan SDCCH8: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select SDCCH channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_H)
lchan_select.c:48 looking for lchan TCH/H: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_H channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_F)
lchan_select.c:48 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_F channel
As was then figured out, this happens because the Radio Carrier
MO (Managed Object) remains Disabled even after the BSC has
sent OPSTART and the BTS ACKed it:
oml.c:986 OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
l1_if.c:614 Rx OPSTART for RADIO-CARRIER MO
l1_if.c:201 TRX_PROV(phy0-0)[0x1238c0]{OPEN_POWERON}:
Event TRX_PROV_EV_CFG_ENABLE not permitted
oml.c:144 OC=RADIO-CARRIER(02) INST=(00,00,ff): Tx Opstart Ack
It remains a mistery why the TRX_PROV FSM is already in state
OPEN_POWERON, while it's expected to be in state OPEN_POWEROFF,
but we definitely should not ACKnowledge the OPSTART if this
happens. Send a NACK instead with cause NM_NACK_CANT_PERFORM.
Change-Id: I8727460acbf850b84df67a9cbdc25b47dee1fadd
Related: SYS#5063
|
|
We already get quite informative message originated from oml.c:
OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
Change-Id: I3d4a4473541327488d3393b1fa7c6391afb3728a
|
|
Change-Id: I56d2777bcc43c96b9fa1672d3ad29bf9817208bb
|
|
Change-Id: Iff9f073ce65bc443109107bb895124ec38dbbb10
|
|
It's more convenient to use one command to enable/disable sending
of all kinds of UL/DL messages at once, rather than specifying
all of them individually.
Adjust config_write_bts_single(), so it would not print unknown
GSMTAP SAPI entries if gsmtap_sapi_mask is set to UINT32_MAX.
Change-Id: Icd7fce860ecdcf8ffa107bdfee7ec94ea9ea6cb2
|
|
Change-Id: I2030992da604f27fc8cd6f9695a8095fda801f82
|
|
Otherwise osmo-bts-omldummy would reject OML Set Channel Attributes
containing the hopping parameters. This change is needed for the
new BSC_Tests.TC_fh_params_* test cases.
Change-Id: I38692252baa7a9fc23078121db0a17557950e4d4
Related: SYS#4868, OS#4545
|
|
Change-Id: I63f0ba277318e254cfd9ad571899f3a45529ff16
|
|
Change-Id: I028ebb9faf68d084759fcfae3ea84f7bdd2d0364
|
|
Latest code relied on features from libosmocore master (> 1.3.0). New
libosmocore release 1.4.0 is now available, so drop the TODO and update
it now, since we can already refer to it.
Change-Id: I992f7e6d5884e53eab8da839d8e77736f9d751c3
|
|
See previous commit adding the unit test about the error description and
expected behavior.
The wrong behavior appeared due to step_size_mdB being unsigned and the
whole addition at the left side of the comparison being turned too as
unsigned, hence a small negative value turning into a big positive
value, and tpp->p_total_cur_mdBm not being updated to speed up the power
ramping.
Change-Id: I36a34362ebc90226fd8e1e190f898c3718fd923a
|
|
The test code is extended to support testing more than one ramping loop.
A new test ramping test is added, which shows buggy behavior, since
being in -10dBm and targeting 10dBm with max_initial_pout_mdBm=0 should
immediatelly jump -10->0 and then slowly ramp up (2dB) 0->10dB.
The issue will be fixed in next commit.
Change-Id: I5adc9008ac415eb23274755fc8270df8eebdc6fb
|
|
osmotrx fn-advance (which is the clock_advance variable here) and
osmotrx rts-advance together make up the minimum delay the BTS can react
to a channel request, etc.
The default of 20 are around 92ms which is clearly too much. With
modern hardware and using SCHED_RR a lower value should not be an issue.
See OS#4487 for some related measurements on more CPU-limited devices like a
LimeNet-micro3.
Fixes: OS#4487
Fixes: SYS#4885
Related: SYS#4881
Change-Id: I7da3d0948f38e12342fb714b29f8edc5e9d0933d
|
|
Change-Id: I4224989032ba1ae6da55370fa5d8f95899aa0e47
|
|
We gain other features from libosmovty for free, like configuring
cpu-affinity of the only thread in the process.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: Ice46e406b84fa11afcc7ba31e521e7677df73cf3
|
|
Change-Id: Icec43d7c1f3b99292fa87462ad65b2c19fdd3b5f
|
|
Change-Id: Id173f69705948aafe861ec36450b147deda95246
|
|
Change-Id: Icc642599d85a751a750b382674dea5614b6f9ee4
|