Both power_ramp_start() and power_ramp_force() are now small macros
around _power_ramp_start()
The new behavior is:
* ramp down power when stopping bts through Ctrl-C
* the other shutdown causes skip power ramping
This will cause the bts to reconnect faster when the oml link is
dropped and power ramping is enabled.
Change-Id: Ida1d7bbf094958b9142af306dbf84206729a609e
Related: SYS#6237
There is no reason why they should have different initial
states. Keep it consistent with the other MOs.
Change-Id: I9fd744ec79da9fc26d3ebe9857b2b0bbd5fcd1ff
This reverts commit c96d34f828.
Reason for revert: This breaks ramping up power since the power ramp logic still assumes the output is full power.
Change-Id: I47a16a4b3ba02d74473569c0f4350a41fc12a464
For the other shutdown causes power ramping doesn't make sense. Instead
shutdown quickly so we can reconnect faster
Change-Id: I71c46478b8f3b236dba3e959fc75e58c0409517f
Related: SYS#6237
The pointer variable l1sap is only used to determine the size of the
related struct but for nothing else. We can use the struct name in
sizeof also directly and get rid of it.
Change-Id: I93abdce1dec60d53ddceb1fce6e9e7451ba6283a
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Related: SYS#6161
Change-Id: I72803fb172accbabfc81923572890f8ecb06cefd
The parameter l3_len in rsl_tx_meas_res() is defined as int, even though
it can't be negative. Lets use unsigned int for l3_len.
Change-Id: I99068a36e74a557000f406154dce32300615086c
We request the length using msgb_l2len() in two locations where whe
cannot be sure that l2h is populated. Lets check this first.
Change-Id: Ie13d0724f183ff240714dcdbd24e5a21b4276bfe
Related: OS#5645
The function lchan_meas_handle_sacch() calls msgb_l3len without checking
if l3h is even populated. Lets add a check to be sure.
Change-Id: Ie5a9fe1ba880e68edb74f5f4ca559ac191330d4f
Lchans which are marked as non-connected have not yet received
information about its remote peer, hence they may not have some fields
available yet. Let's skip them to avoid accessing such fields
(lchan->abis_ip.osmux.in).
Related: SYS#5987
Change-Id: Id53822c4a0486b0090df2db3d185e047d14fc90a
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#598
Change-Id: I102047685b9b9f4cba43970945f955c4fe9c4c95
This way we have no more access to internal osmux structures.
If those counters are needed in the future they can be counted by
osmo-bts by means of adding rate counters to the caller of
osmux_xfrm_input() and deliver_cb.
Change-Id: Ib952437ea3aa2770c96bddb667491e7675a6a06e
Otherwise some shared variables used by both Osmux and RTP was left set,
like connect_ip and connect_port, and next time the lchan was selected,
those were already configured even if they didn't come in IPAC CRCX.
This is specially bad if the channel was reused to set up an Osmux call,
since the osmux code path relied on those fields being properly reset
until set by IPAC CRCX.
Change-Id: I414bd0bc801451357bb45b89197a95e51b7c97f1
when something fails in osmo-bts during startup and it goes into SHUTDOWN state,
it is desirable to close new RSL links (sockets) which are in progress to connect,
while it waits for a while to complete shutdown (power ramping down, etc.).
This way we don't end up with new interactions and new state against a BSC if we
are shutting down.
The new libosmo-abis API is used since the higher layer struct e1inp_sign_link assigned
to each struct gsm_bts_trx is not provided to the osmo-bts code layer by libosmo-abis API
until the TCP+IPA handshake in the socket becomes fully established (sign_link_up()
callback).
Depends: libosmo-abis.git Ia6418321f3b6f1f7274efd414625a4b10a09a362
Change-Id: I599d074f51f490b43c9a89b105d1823391926947
Previously osmo-bts created /var/run/osmo-bts.pid which
isn't used by anything and makes it hard to run as non-root
user. Let's get rid of this pre-systemd relic.
Related: OS#4107
Change-Id: I86bcaedbc8cb1297476ad741eaa45585fea3c380
This library will be used soon when adding Osmux support to osmo-bts.
Furthermore, it nice to have it available to make use of other general
interfaces to create connections, primitives, RTP and AMR related
functionalities, etc.
Related: SYS#5987
Change-Id: I49db4de715065c083e1249cbeae6298d6868e229
It will be used too by osmux code present in another file. This is a
preparation commit to simplify the one adding osmux support.
Change-Id: Ie7fa57bb04db9ad9b03971467e12ee7b8e4c190a
The function is long/complex enough, so having one extra struct in_addr
declared the function top only used in one specific small path to print
the variable is unnecesary.
Let's move it to the conditional path where it is used to print the
ip address.
Change-Id: I4c16bbca6a6779537517b6b196828b47eddaa516
There's no need to maintain a duplicate msgb_queue_flush(), which
returns the amount of freed messages (feature not used at all by the
callers).
Change-Id: I9841e18ca0b7b852130bbb02a510e43a3b3fd93f
The queue_limit_to method iterates the entire list of messages every
time a new message is added. Let's use msgb_{enqueue,dequeue}_count()
APIs to do that in constant time. It is true that since the queue is
limited to 1, there's usually at most 1 item in the queue so it's not a
real problem. However, when we add Osmux in the future, we may need to
tweak the amount of messages which can be in the list, due to Osmux
batching mechansim which may be more bursty sometimes.
In any case, this change doesn't make things worse for sure.
The patch also takes the chance to group the queue_limit_to + enqueue
into one function to avoid having the code spread several times.
Change-Id: I61818a3bb521c27bd21a8b6fa70581d27638ec9b
3GPP TS 45.008, section 8.3 defines active TDMA frame subsets for
TCH channels, which shall always be transmitted even during the
silence periods in DTX mode of operation. Each frame number
listed in this section corresponds to a single burst.
The Uplink measurements always contain TDMA FN of the *first* burst
of a block, so it does not make sense to match the given FN against
all FNs in the respective subset. Instead, we should match only
specific FNs in accordance with the block mapping rules defined in
3GPP TS 45.002, section 7, table 1.
In the active subset for TCH/F there is only one *complete* block
starting at FN=52. Incomplete blocks {52, 53, 54, 55} and {56, 57,
58, 59} contain only 50% of the useful bits (partial SID) and thus
~50% BER, so we don't treat them as SUB.
In the active subsets for TCH/H there are two *complete* blocks
for each sub-slot. Their respective first FNs can be efficiently
defined in a lookup table (see ts45008_dtx_tchh_fn_map[]). Note
that we can use a single lookup table for both sub-slots of TCH/H
because their TDMA FNs do not overlap.
This patch fixes unexpected SUB-RxQual values > 0 on TCH channels
with DTXu enabled and other than AMR (HR, FR, EFR) codec in use.
Change-Id: I8cc3a755a8ad4dc564439aab2298c1e97ac0592d
Related: SYS#5853
SACCH detection can be simplified by checking the RSL Link ID in
process_l1sap_meas_data(). This eliminates the need to lookup
the multiframe position by calling trx_sched_is_sacch_fn(), which
definitely takes more CPU time than just L1SAP_IS_LINK_SACCH().
Calling trx_sched_is_sacch_fn() is still required for BTS models
reporting the measurements via PRIM_MPH_INFO (legacy way),
separately from the related Uplink blocks.
This patch can be summarized as follows:
* detect SACCH and set .is_sub=1 in process_l1sap_meas_data();
** for PRIM_MPH_INFO use trx_sched_is_sacch_fn();
** for PRIM_PH_DATA use L1SAP_IS_LINK_SACCH();
* do not call trx_sched_is_sacch_fn() from ts45008_83_is_sub();
* modify the unit test - test_ts45008_83_is_sub_single();
** remove test_ts45008_83_is_sub_is_sacch().
Change-Id: I507e96ee34ac0f8b7a2a6f16a8c7f92bc467df60
Related: SYS#5853
Attempting to detect missing Uplink frames in the *Downlink* path
is an ugly hack, that was needed before we had proper per-lchan
detection of missing bursts and NOPE indications in TRXDv1.
* [1] per-lchan detection of missing bursts was fixed in Aug 2018.
* [2] TRXDv1 support was introduced in Jul 2019.
Today is 2022 and it makes no sense to keep this hack. Even if
the transceiver does not support TRXDv1, per-lchan detection
will compensate the missing Uplink bursts.
Change-Id: Ic292d180ba64206fb4d88adb284f9f9d058b4587
Related: [1] I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: [2] If61c71d20d590bf07bfd019afb33000a0b6135bd
The gitlog shows that these warnings were added in
744f745d7a by jolly (in 2012!).
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: Iebf9961cffbd7aa20b263f7dc0016a44782dec60
Related: osmo-bsc.git I9ef7e18f56aa86b48f0ffeec58406260736170f3
OsmoBSC assumed since If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28 that
OsmoBTS has CCN (NACC, Network Assisted Cell Change). With OsmoBSC
Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, instead of hardcoding some
features for OsmoBTS in OsmoBSC, only the features reported by the
BTS are used. Therefore report that BTS_FEATURE_CCN is supported in
OsmoBTS.
For previous OsmoBSC versions, this fixes the message:
Get Attributes Response: reported feature 'CCN' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ic407e3be82afe61ed64b1cecf3dc94d2caff380a
I did not realize with my previous patch that there's a common place
where features available for all backends should be enabled. So move it
there.
Related: SYS#5922, OS#5538
Change-Id: Id688ddae5cd714355fcc5324f33c9397fecae261
Currently (without this patch) if tch_dl_dequeue() yields nothing we're
scheduling dummy FACCH/H *regardless* if it's permitted to start at the
given TDMA FN or not. This may result in misaligned FACCH transmission,
so the MS will not able to decode anything and will report BER>0.
With this patch applied we schedule FACCH/H if it's allowed to start
at the current TDMA FN; otherwise send half-filled bursts with even
numbered bits contaning 232 encoded bits of the previous L2 frame
and 232 odd numbered bits all set to 0.
This patch does not guard against sporadic gaps in the Downlink TCH
queue. However when tch_dl_dequeue() constantly yields nothing, e.g.
when we end up with a codec mismatch, then this additional check saves
us from starting misaligned FACCH/H transmission. If we start at a wrong
TDMA offset, then all subsequent FACCH frames will be scheduled at wrong
offsets and thus none of them will be decoded by the MS.
Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b
Related: SYS#5919, OS#4823
Max
Daniel Willmann
Philipp Maier
Pau Espin
Harald Welte
Vadim Yanitskiy
Oliver Smith