Ensure that we check the PHY capabilities in both cases:
* RSL CHANnel ACTIVation, and
* RSL CHANnel MODE MODIFY,
by calling bts_supports_cm() from rsl_handle_chan_mod_ie().
Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode',
so we can handle VAMOS enabled channel modes and CSD later on.
Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91
Related: SYS#5315, OS#4940
For some reason, handling of the Channel Identification IE was done
in l1sap_chan_act(). This function is being called on reciept
of the CHANnel ACTIVation message, but not on MODE MODIFY.
Change-Id: I07f95e69e6230a1daca62cc0a7c64954f191fa8a
Related: SYS#5315, OS#4940
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
lower layer specific APIs require first to enable the TRX object
(GsmL1_PrimId_MphInitReq, which requires ARFCN received during Set
Radio Carrier Attributes) before enabling the per-TS structure.
Hence, OPSTART must happen in RCARRIER MO before OPSTART can be sent to
the Radio Channel MOs, otherwise the initialization of the TS objet will
fail and OPSTART for the RadioChannel MO will send back a NACK.
In order to avoid this, we need to keep the RadioChannel MO announced as
"Disabled Dependency" until RCARRIER is OPSTARTed.
Related: OS#5157
Change-Id: I8c6e5ff98c32a3cd5006f5e5ed6875bcabb1d85f
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
gsm_bts_trx_alloc() already does initialize some fields of the
allocated 'struct gsm_bts_trx' instance, and having an additional
function for initializing the other fields makes no sense.
Note that I intentionally didn't merge a call to bts_model_trx_init()
into gsm_bts_trx_alloc(), because this would break some assumptions
regarding the order of initialization and cause regressions.
This also allows us to not call bts_model_trx_init() from tests.
Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
We need curly braces becausee1inp_line_get2() is basically a macro
that calls OSMO_ASSERT(), which in its turn contains an 'if' stmt.
Change-Id: I41a5fd13a7fa40e16bcf1a8099624b654274cee3
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
In change [1] I added the missing 'default' branch to the 'switch'
statement in lchan_tchmode_from_cmode(). This caused massive
regressions in ttcn3-bts-test, because osmo-bts started to NACK
some RSL CHANnel ACTIVation messages.
What caused a lot of regressions in ttcn3-bts-test is actually the
missing branch for RSL_CMOD_SPD_SIGN in the 'switch' statement.
It was not a problem before [1], because the 'default' branch was
not there. I was about to add the missing 'cause' when I realized
that this function needs to be reworked first...
First of all, lchan_tchmode_from_cmode() does a bit more than just
deriving RR (TS 44.018) channel mode from RSL (TS 48.058) channel
mode. It additionally stores the 'Speech or data indicator' to
the logical channel state, and also changes some global DTXd related
flags in 'struct gsm_bts'. Let's use a more precise name.
lchan_tchmode_from_cmode() -> rsl_handle_chan_mod_ie()
Together with renaming, it becomes logical to have the IE presence
check in rsl_handle_chan_mod_ie(), so that we can reduce code
duplication in the calling functions a bit.
Finally, the main problem is that coding and interpretation of the
6-th octet 'Speech coding algor./data rate + transp ind' depends on
the 4-th octet of the Channel Mode IE. We cannot handle all values
in one 'switch' statement without proper discrimination:
a) If octet 4 indicates Speech, then octet 6 shall be interpreted
as the GSM speech coding algorithm (FR, HR, AMR, etc.).
b) If octet 4 indicates Signalling, then octet 6 shall be set
to '00'O, because this is the only value defined in version
16.0.0 of 3GPP TS 48.058. All other values are reserved.
c) If octet 4 indicates Data, then octet 6 shall be interpreted
as CSD data rate further discriminated by service transparency.
Therefore, we need take both values into account. This can be
achieved by mixing them together using the bitwise operators,
just like we do in L1SAP code.
Change-Id: Iba967f5bd0cc8ad6cd3ccd40cca38b15ffe96b2c
Related: [1] I67a70132999be6580a29e6b814763309a6df4ae9
Related: SYS#4895, OS#4941
In [1] I introduced a regression, so osmo-bts started to complain:
This PHY does not support lchan TSC 3 != BSIC-TSC 7
on channel activation, despite the TSC in RSL_IE_CHAN_IDENT was 7.
The problem is that this statement:
cd = (const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT) + 1;
is basically equivalent to:
cd = ((const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT)) + 1;
so we actually shift the pointer by sizeof(struct gsm48_chan_desc)
and skip 3 octets instead of just one (IEI octet). Fix this.
Change-Id: Ic3a81396b60577e03c541d32839d07dc6d45c838
Fixes: [1] Id100f4c56fd5c1adad5d925d97240bed82981b9b
Fixes: OS#5121
As the prefix in 'GSM48_IE_CHANDESC_2' implies, this IE belongs
to 3GPP TS 04.08 (or TS 44.018), so it can be used in the Radio
Resource assignment messages sent to the MS. While in this
function we're dealing with 3GPP TS 48.058, and thus the IEI
may be (and actually is) different for the RSL messages.
Also, according to 3GPP TS 48.058, section 9.3.5, the Channel
Description IE is included together with its element identifier,
so we need to skip one byte when doing the pointer casting.
Change-Id: Id100f4c56fd5c1adad5d925d97240bed82981b9b
Related: SYS#4895, OS#4941
Instead of blindly assuming what the PHY does support, and what
it does not, let's check the related feature vector.
Change-Id: I699cdddbfab111855998853548d9cfe956f7c60c
Related: SYS#4895, OS#4941
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I343c7a721dab72411edbca816c8864926bc329fb
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I0b04b013b7bad5ff53d6a969ff0128b37f7f62d5
At the moment osmo-bts is not looging much ACCH repetition related
information. This makes testing ACCH repetition difficult. Lets add some
debug output that informs the user when ACCH repetition is turned on or
off. Lets also add an ACCH repetition status display to the show lchan
VTY command.
Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e
Related: SYS#5114
The MS sets the SRR bit in the L1 SACCH header to request DL-SACCH
repetition from the BTS. At the moment we access the l1_info stored in
tle lchan struct each time we want to check the status of the SRR bit.
However, it is more convinient to do this once at reception and store
the status of the status of the flag in a separate struct member.
Change-Id: Ieddd45d7890343d64db14b9c726f6fa2f25714f6
Related: SYS#5114
The check in lchan_ms_ta_ctrl() breaks Timing Advance control on
SDCCH channels, because 'num_ul_meas' wraps and never reaches 4.
Neither this check makes any sense for other channel types,
because lchan_ms_ta_ctrl() is always called in the end of the
measurement period. Let's drop it.
Change-Id: I0b86d49ec00b38d0f309c56b2519e5d487f0b65b
Fixes: If7ddf74db3abc9b9872abe620a0aeebe3327e70a
Related: OS#5024
in struct gsm_lchan and also in other places l1_info is handled in its
binary form. Libosmocore now offers structs to handle l1 info, so lets
use those structs to get rid of all the manual decoding of l1_info.
Depends: libosmocore I23c1890b89d5a0574eb05dace9f64cc59d6f6df7
Change-Id: I5eb516d7849750f3dd174d48c9f07dabf2c80515
So far, the only way to configure GSMTAP Um logging is to use the
cmdline argument '-i'. Let's deprecate it, and add a VTY command
to allow setting the remote host from configuration file.
The legacy '-i' option, if provided, overrides the configuration
file option, and will also appear in 'write file'.
Change-Id: I17676a21c4e0c9cbc88f2c5c53a39c6c6c473ca1
Tweaked by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
The cfg_out macro is used like a function in the code below its
definition. This means a colon will follow after it is used. When
the vty_out call in the macro already has a colon the final result will
be vty_out(...);;. This works fine as long the macro is not used in one
line if/else if/else constructs without curly braces {}. The compiler
will interpret the double colon as two lines of code and run into an
error then. Lets fix this by removing the colon from the vty_cout in the
macro.
Change-Id: I2c23c38ce892067add0f95f3e504a9c559e24519
The only reason why it was not 'const' is that in lchan_new_ul_meas()
we may need to overwrite 'ulm->is_sub'. This can still be done after
memcpy()ing a new set of samples to the destination buffer.
Change-Id: I0cabf75f8e0bf793c01225a4a8433e994c93f562
Related: OS#5024
At the beginning of repeated_ul_sacch_active_decision() The UL-SACCH
repetition capability is tested. If no UL-SACCH repetition is enabled
the function exits. However, we should also make sure that the struct
member that enabled UL-SACCH repetition on the lower level is set to
false as well. Normally that should be the case because it was never
set to true before, but it is better to be sure.
Change-Id: I76a841514eb955b93f2114470b2c80402cf6883c
Related: SYS#5114
At the beginning of repeated_dl_facch_active_decision() the ACCH
repetition capabilitiy flags (command only or all LAPDM frames) are
tested. If no FACCH repetition is enabled, the function exists. However,
we should also make sure that the struct memeber that enables FACCH
repetition on the lower level is set to false as well. Normally that
should be the case because it was never set to true before, but it is
better to be sure.
Change-Id: Id07091cc89352281b41532d583a8bc004477c71a
Related: SYS#5114
The function checks meas_res->rxqual_sub against the lower threshold
value in order to decide when to turn FACCH repetition off. This is not
correct. It should compare against rxqual instead.
Change-Id: Id4ab101d52f419583c4f4c8a6cf69af6c9097d25
Related: SYS#5114
All IEs in the BSC originated message are optional, so we assume
default values for them. Let's reflect them all in the ACK/NACK.
Change-Id: I5c73e83daad0cea07b9cb674c393e0bfc6268a61
Related: OS#3791
This would allow to compose ACK/NACK messages with additional IEs
not present in the original message. Also, this change basically
eliminates unnecessary msgb_copy() / free().
Change-Id: I17f61636e9a144017e2c46b1540d152c21529391
Related: OS#3791
Both NM_ATT_IPACC_DST_IP and NM_ATT_IPACC_DST_IP_PORT are defined
as TLV_TYPE_FIXED, and NM_ATT_IPACC_STREAM_ID is TLV_TYPE_TV, so
the TLV parser already does check the length for us.
Change-Id: I1e493e552bb22bb42bb196ce71214e28d23fd19e
In function pcu_tx_si_all(), the variable rc is not initalized. If
pcu_tx_si() fails, then rc is populated with value -EINVAL, but if all
si transmissions succeed, which is the normal case, rc remains
uninitalized.
Change-Id: I571fdb4f175fb259b77f989554f569fc2230dfe6
Related: CID#216932
This patch PCUIF extends the SAPI 4 that is used
to transfer SI13 only, so that it can transfer SI1 and SI3 as well.
The system information SI1, SI3 and SI13 is needed by the NACC RIM
application which runs inside osmo-pcu.
Depends: osmo-pcu I5138ab183793e7eee4dc494318d984e9f1f56932
Change-Id: Ib7aeb41e634ad6fcab3766a4667b0267c749436a
Related: SYS#5103
GCC-4 doesn't like static const struct foo bar = (struct foo)...:
measurement.c:33:1: error: initializer element is not constant
Related: OS#5004
Change-Id: Iec5a4006dfc90abe240fcf8b6c2fefd4f7071a70
A channel activation for handover to another cell does not know the
Timing Advance until the handover RACH is received. It does not make
much sense to enable downlink SACCH without an accurate TA.
If the BSC omits the Access Delay IE (a.k.a. the Timing Advance), do not
enable downlink SACCH. This is expected to happen only for inter-cell
handover. In all other situations, the TA should be known either from a
Channel Request RACH for Immediate Assignment, or from the previous
lchan on the same cell upon Assignment / intra-cell handover.
Related: OS#4008 OS#4009 SYS#5192
Change-Id: I170b63c9856230d5f1a10654a9d950ada8e730d7
One part of the algorithm simply provides a _suggested_ 'delta' that
needs to be applied to the current power level, while the other part
ensures that this suggested value does not exceed the limits. Thus
it's possible that some logging messages would state that the power
reduction value remains unchanged, while the 'detla' != 0.
Change-Id: I7496a158b9ac6074a965056d708d8078a98cb1aa
Related: SYS#4918
These new commands are useful for debugging MS/BS power control
loops, e.g. one can change power control mode, overwrite the
current BS power reduction or MS power level at run-time.
Change-Id: I1ebb033b02c2bc3b1fa7de874e0035a07297f266
Related: SYS#4918
The loopback mode was added for testing, and may be dangerous if
enabled in production. Let's make it appear only in expert mode.
Change-Id: I3f68acd7f2b0231f78516f59fb5e8ef56fb69dbf
As far as I can see from my perf measurements, bitvec_fill() is called
quite often and takes 0.27% of the CPU. A more detailed look reveals
that it's indirectly called by fill_paging_type_1() in order to fill
the remaining octets with constant '2B'O padding.
Let's optimize this function:
- use memset() for padding *before* writing optional P1 Rest Octets;
- conditionally initialize the bit vector for P1 Rest Octets;
- use designated initializers instead of memset().
It's generally better to avoid using bitvec_fill() when using memset()
is possible, because the former operates on bits rather than bytes.
Change-Id: I90473356b396e5dd9326598aca025afacca4afc8
It does not make sense to trigger the BS power control loop on C0,
as it's only allowed to reduce power on additional transceivers.
Change-Id: I4fdfe097ae6f9edde5f39ed4da8a559a14b3b38f
Related: SYS#4918
At the moment only rxlev_sub is used to decide when the facch repetition
should be activated, regardless if DTX is used. Lets check if DTX is
actually used and use rxlev_full when DTX is not applied.
Change-Id: I01ba57cf661f0e41b8df209c905f8d135013e472
Related: SYS#5114
The table in repeated_ul_sacch_active_decision() is derived from the
second table in GSM 05.08 8.2.4 but the first table would be correct.
Also the lower threshold is not properly choosen. A lower threshold,
that derives from upper threshold shifted by 2 makes sense (BER must
improved by 2 RXQUAL steps before repetition is turned off.)
Change-Id: I1d9b5c8abb79938cdecdafed84ed2e5d47e0bd3a
Related: SYS#5114
This change makes BS power control loop:
- take the lower RxQual threshold (L_RXQUAL_XX_P) into account, so
the BS power is increased only if RxQual exceeds this threshold;
- apply the configured increase step size instead of reducing the
current attenuation by half.
MS power loop is not affected, it does not even handle RxQual yet.
Change-Id: Ib3c740b9a0f3ba5dfb027e144dc13f456cb26ae2
Related: SYS#4918
It makes more sense to use a reduce step size that is smaller than
the increase step size. This way both MS/BS power control loops
would be able to react quickly of the signal gets weaker, while
the good signal would not trigger radical power reduction.
Change-Id: Ie358fd828a68bfa1d23559197e8df8478fb4535e
Related: SYS#4918
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
MS/BS Power Control parameters have been recently moved to the BSC
and now signaled to the BTS over the A-bis/RSL link. Let's make
sure that the existing VTY commands for Uplink Power Control do:
- trigger deprecation warnings if present in the config file,
- not show up in the online VTY help nor VTY reference,
- affect the fall-back parameters in 'struct gsm_bts',
- still get printed by 'show running-config' command.
Change-Id: Icbd9a7d31ce6723294130a31a179a002fccb4612
Related: SYS#4918
It is expected that setting RxQual threshold to 0 would make the
L1SAP logic enable repetition for both Uplink SACCH and Downlink
FACCH unconditionally. However, this was only valid for the
later. Let's add the missing check and make it consistent.
Change-Id: Ia44a134e7f28ea990798d1b79c87b644504c0876
Related: SYS#5114
For the sake of simplicity, the old structures that are still used
by MS/BS power control loops are kept in place. Migration to the
new structures requires additional changes to the existing power
control logic, so it will be done in the follow-up changes.
The new parameters are integrated as follows:
+ struct gsm_bts - a BTS instance:
| Hard-coded default (fall-back) parameters for all transceivers.
|
+-+-> struct gsm_bts_trx - a TRX instance (transceiver):
| Default parameters for all logical channels inherited from
| 'struct gsm_bts' at start-up. May be overwritten by the
| BSC using ip.access specific 'Measurement Pre-processing
| Defaults' message on the A-bis/RSL interface.
|
+---> struct gsm_lchan - a logical channel (e.g. TCH or SDCCH):
Connection specific parameters inherited from 'struct
gsm_bts_trx'. May be overwritten by parameters sent
by the BSC in CHANnel ACTIVation and other messages.
Change-Id: I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
Related: SYS#4918
This is a follow-up fix for I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
get_si4_ro_offset() itself already checks if it's less than GSM_MACBLOCK_LEN,
so we must check if it's not negative.
Change-Id: Iba99e5de625af6bed6720a38fec26c2acc6251c0
In Change-Id I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa we introduced
patching of SI4 to indicate GPRS presence in terms of PCU connection
status. Unfortauntely this didn't account for optional IEs being
present in SI4, and hence overwrote any CBCH related information
elements, if present.
This in turn meant that since the above-mentioned commit, you could
have either a GPRS-capable, network, or a Cell Broadcast capable one.
Change-Id: I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
Related: OS#3075
Checking if a given RSL IE is present is a straightforward task,
so there is no need for a special boolean flag.
Change-Id: I6a12930314c79b9c3efabfa575b17f78105fea4c
It does not make sense to dump CCCH/CBCH as dedicated channels:
OsmoBTS# show lchan
BTS 0, TRX 0, Timeslot 0, Lchan 4: Type CCCH
State: ACTIVE
BS (Downlink) Power Control (autonomous):
Channel reduction: 0 dB (max 0 dB)
TRX reduction: 0 dB
Actual / Nominal power: 13 dBm / 13 dBm
MS (Uplink) Power Control (autonomous):
Current power level: 0, -39 dBm (max 0, -39 dBm)
Channel Mode / Codec: SIGNALLING
LAPDm SAPIs: DCCH --, SACCH --
Valid System Information: 0x00000060
MS Timing Offset: 0, propagation delay: 0 symbols
Radio Link Failure Counter 'S': 0
so let's only dump SDCCH, TCH/F, and TCH/H.
Change-Id: Id7880de56a93cc9fa4ca576b094cef35ee269822
During the initial implementation I used the wrong function to change
state. As a result, from BSC point of view the BTS was changing state
but the FSM internally was not. "Fortunately", while in state Dependency
the BTS still could cope with that in order to still be operative with
older osmo-bsc, so there was no major breakage, only some error log
message being printed.
Related: OS#4873
Change-Id: Ifd2eefc362fca0aa9e6ae102c7e6dbc1b4f295d6
struct lchan_power_ctrl_state actually contains more fields,
which also must be initialized on CHANnel ACTIVation.
Change-Id: Id9719088fc6e9479c13e9b327a3466d9e2810a3a
Related: SYS#4918
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Similar to I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87, this change
is another step towards separating the common delta calculation
logic from lchan_ms_pwr_ctrl(), since this function will loose
access to the averaged values.
On the one hand, the affected logging statements are getting
less precise; on the other, logging the averaged value as the
actual value ('rx-current') may be even more confusing.
Change-Id: I07007e45c859b4080fbbe520ffb5ccc0bb9c4244
Related: SYS#4918
This change would allow to separate the common logic from
lchan_ms_pwr_ctrl() and re-use it for Downlink power control.
The logging statement was quite useful during early stages
of development and testing of hysteresis and filtering,
but now we can sacrifice it.
Change-Id: I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87
Related: SYS#4918
This way EWMA based filtering logic can be used not only for
MS Power Control, but also for BS Power Control.
Change-Id: I16c2e1b997f2b8af44d47809420293f072335bbd
Related: SYS#4918
This would allow to pass only two pointers:
- 'struct bts_power_ctrl_params', and
- 'struct lchan_power_ctrl_state',
and get rid of 'struct gsm_lchan' dependency. The later is
exactly where all state variables are supposed to be kept.
Change-Id: Idfefca30f4944bc722b4e9d8f1685eb77670a9db
Related: SYS#4918
3GPP TS 44.006, section 11 describes a method how the uplink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
3GPP TS 44.006, section 11 describes a method how the downlink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I00806f936b15fbaf6a4e7bbd61f3bec262cdbb28
Related: OS#4794, SYS#5114
The SRR bit, which got specified in 3gpp release 6 to support repeated
ACCH capability is not yet included in the L1 Information IE on RSL
level. Also lets update the spec reference to more modern 3gpp spec ref
numbers.
Change-Id: I987c61608b737521ba36756dabf2f6215b34c2d6
Related: OS#4796 SYS#5114
3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114
This part adds the common lchan flags to indicate whether DL SACCH
should be activated.
Note that currently, osmo-bsc *always* sends the MS Power IE as well as
the TA IE, also for inter-cell HO, so in the osmoverse, nothing will
change until we also adjust osmo-bsc. See OS#4858.
Change-Id: Ibea973ccadf5d424213f141f97a61395856b76de
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ic3b7c223046a80b51f0bd70ef1b15e12e6487ad0
Fixes: OS#4865
The signal handler function was coded to expect SIGABRT but the signal
handler itself was never enabled for this signal.
Change-Id: Id95d64efe8765fcf19eb09cd3db7895166c6adab
Otherwise it ends up in the generated XML VTY reference:
$ head doc/manuals/vty/bts_trx_vty_reference.xml
((*))
|
/ \ OsmoBTS
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
<node id='_common_cmds_'>
<name>Common Commands</name>
Also, take a chance to move it below handle_options(), so it
will only be printed if all arguments are parsed successfully.
Change-Id: I5c35f36fdd2a8a80bd501b996f0b161c388d3510
Related: SYS#4937, OS#3036
Similar to bts_vty_init(), BTS specific bts_model_vty_init()
requires a pointer to 'struct gsm_bts'. Not only it's used
as a parent talloc context, but also stored locally, so then
it can be used by some VTY commands.
Let's expose the global 'struct gsm_bts' from main, and pass
the application's talloc context like was done in [1].
This finally makes the BTS model specific options appear in
the automatically generated VTY reference (--vty-ref-xml).
[1] Ic356a950da85de02c82e9882a5fbadaaa6929680
Change-Id: Iee7fee6747dd1e7c0af36f9b27326f651ae37aaf
Related: SYS#4937, OS#3036
The variables num_meas_sub_expect - num_meas_sub must not be subtracted
without prior checking. Depending on the input (which might be
errornous), num_meas_sub might be greater then num_meas_sub_expect. This
eventually leads into odd behavior, which can be difficult to debug.
Change-Id: I381cc637d1c125f279ccf88db114609946fe24fe
Related: OS#4799
Otherwise only those commands that are registered by libosmocore
appear in the generated XML VTY reference - change the order.
Instead of a pointer to 'struct gsm_bts', pass the application's
talloc context, as it's only used for dynamic command allocation.
Change-Id: Ic356a950da85de02c82e9882a5fbadaaa6929680
Related: SYS#4937, OS#3036
The logic in measurement.c checks the amount of collected measurement
values. This is done for the total amount of measurements and the amount
of SUB blocks measurements.
The functions that return the expected number of measurement values
currently do not take into account that the mode of a TCH/F or TCH/H has
an effect on the number of expected SUB blocks. (In signalling channels
all blocks count as SUB). Also a TCH/H in signalling mode generates only
half the amount of measurements because the blocks in signalling mode
are sepreded over 6 bursts instead of 4. This also needs to be taken
into account.
Change-Id: I01c7b6cc908c647263ab88f6b6281c4732f88779
Related: OS#4799
SUB frames exist only in voice (or CSD) channels. When a TCH/F is in
signalling mode, all blocks must be counted as SUB blocks. (for TCH/H
the current implementation is correct.)
Change-Id: I04be21200afa1d03afa0d7e476c66fa79cf42249
Related: OS#4799
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 7810a91733 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: 7810a91733
Change-Id: I8c777b946e7abcb4b607ec4d136c981a0716b120
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
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
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
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
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
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
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_averagehttps://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filterhttps://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
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
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
Using gsm_bts_trx_num() involves redundant iterations over the
list of transceivers - we definitely don't want them.
Change-Id: I4bd40ffcc1e925412a21b0a934bbfdeddbc6ad1f
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
Since I310699fabbfec4255f0474f31717f215c1201eca the BTS
can decode NM_ATT_OSMO_NS_LINK_CFG. This OML attribute will be
only used if the OML feature IPV6_NSVC is present.
Change-Id: I9910f2afb3ab94167938b0fd356f2f0a8c382130
With PCU interface version 10 it supports IPv6 NSVC. The new OML IE
NM_ATT_OSMO_NS_LINK_CFG allows to configure IPv6 NSVC.
Change-Id: I310699fabbfec4255f0474f31717f215c1201eca
There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
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
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
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
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
This reverts commit df93a448b7.
It was to early because the frequency hopping wasn't ready to be merged.
Change-Id: I6e67f4cd9828afa53ed4e783b83b039ee6a1d570
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
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
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
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
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
On receipt of either SIGTERM or SIGINT the shutdown FSM initiates
ramping down of the transmit power on Downlink. I noticed that
for some reason osmo-bts-trx stops sending Downlink bursts during
the process of ramping down.
I also noticed the following imporatant message:
DL1C NOTICE scheduler_trx.c:287 No more clock from transceiver
despite the transceiver is still powered on and keeps sending
the clock indications over the TRXC interface.
As it turned out, the problem is that on receipt of either SIGTERM
or SIGINT, we also raise the global 'quit' flag, so in the scheduler
trx_sched_clock() stealthy stops handling the clock indications.
Let's ensure that clock indications are handled regardless of the
state of 'quit' flag, so the ramping down would work as expected.
Change-Id: Ia71133d6f0b900e5e103595c83303a7cc5c06edf
Until now, power-ramp max-initial was only taken into account in order
to skip ramping if the desired target level was below it, in order to
forbid growin too quickly or applying directly to much power given power
amplifier requirements.
However, in the event that a higher tx power level is desired,
max-initial was not taking into account and ramping simply started from
current tx power level, which could be a lot lower than max-initial.
Allow shortcutting the ramping in that case so that max-initial is
applied directly, and ramping continues from there, in order to have a
more expected behavior (max-initial applied the same).
Since max-initial can since a few commits before handle a negative
value, this means One can for instance set max-initial to -10 and still
keep the old behavior of ramping step by step from -10 (rf-locked in
osmo-bts-trx) to 0 or 7 or whatever is the nominal power
(max_power_red).
Change-Id: I4e5742ecdbf66d77ff9445999f6fff43bbf4856a
This allows for instance ramping up from -10 dBm -> -4 dBm if NOMTXPOWER
of SDR is really low (below 0dBm) or because the max_power_red is >=
NOMTXPOWER.
Related: SYS#4920
Change-Id: I0f27fb7b86b58c5a80f5342b66ff4f5d1b775498
Ramping down was set up with a target of -10 dBm, but then the code only
waited for all TRXs to be at least 0dBm, meaning that if operating more
than 1 TRX, the FSM could transit to state ST_WAIT_TRX_CLOSED when one
TRX reached -10 and other were already equal or below 0 (but not yet
-10). As a result, later on, when other TRXs reached -10 dBm they would
trigger EV_TRX_RAMP_COMPL which was not expected (no use) in
ST_WAIT_TRX_CLOSED.
Related: SYS#4864
Change-Id: If7af0b138efe78ec591c199a19fc22b304416a13
the RSL link has nothing to do regarding the state of the Radio Carrier,
as in it being up is not enough to have a working (enabled) Radio
Carrier.
Change-Id: Iefb5c4e1097233b5c31e4d621c544d51516af678
Move all struct gsm_bts_trx references from bulky gsm_data to its own
file containing all related definitions and implementations. Also move a
few functions clearly related to that object which were placed in bts.*
Change-Id: Iebaf5b221c48b571f45408af867ce6f9c0cd9f4a
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
According to 3GPP 45.002, section 5.2.4, a frequency correction
burst is basically a sequence of zeros. Since br->burst is already
zero-initialized, there is no need to maintain and memcpy() another
sequence of zeros into it. Just set the length.
Change-Id: Ic4f6d550010da5caf4bc471ff1e184c9fab30c6d
Setting the phy link of a trx to SHUTDOWN sets operative state to
DISABLED, so we use operative state as a condition to know whether all
TRX are already powered off properly and we can exit.
Change-Id: I2bcd211d7edcc8486461a555d6c470a94b166ed7
Some backends like osmo-bts-trx require exchanging messages like
POWEROFF to close the TRX, and hence need some time. Switch the function
to expect result asynchronously by calling a callback.
This will be used later to wait until all TRX are really powered off
before exiting the process.
Change-Id: I7d76b600fc06e1114b35bf0c2d08eff5bbd1b69a
It makes more sense to first deactive RF on all TRX and finally close
them totally. This way we keep consistency between all TRXs and it's
easier for lower layers which may need to close them all at once. Also
in the event that we want to turn bts_model_trx_deact_rf to return
asynchronously.
Change-Id: Ib62358384e37a5cef692926439462042fab0138c
Upon BTS shutdown (for instance because the Abis link against BSC was
lost), stop the operation in an ordered manner (cell soft lock). This
means slowly decrease tx power so that MS have time to handover to other
neighbour cells.
Related: SYS#4920
Change-Id: I70e34dda8974ebd94aea33bd9fb1d99f9063cc55
Using an FSM here will allow for more complex ordered shutdown
procedures, like power ramp down, waiting for TRX deact asyncrhonously,
etc.
Current commit leaves everything in place already prepared to implement
ramp down, which will be implemented in next commit in the series.
Related: SYS#4920
Change-Id: I8f48f17e61c3b9b86342eaf5b8a2b1ac9758bde5
Together with previous counter L1SCHED_TS_CTR_DL_LATE, it allows
understanding which dl blocks are really lost (never queued) and which
were simply queued too late.
Change-Id: I456d0cfbef1e03b147ce7d968a3ec42dd728fe74
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Neels Hofmeyr
Oliver Smith