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
|
|
Change-Id: I378fea4aefb2cc4253cdd99ebc9c4f01b21faf95
|
|
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
|
|
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
|
|
Change-Id: I44d079893d01946da703c4338a686795ced3cb00
|
|
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
|
|
This makes use of the newly-introduced lapdm_channel_init3() API,
which provides the user (BTS in this case) to provide a human-readable
string identifier for each LAPDm channel. This identifier is
subsequently used in all related log lines to provide context.
This means we will now get context information about which specific
SAPI in which sub-channel (ACCH/DCCH) on which lchan/ts/trx/bts a given
message originated from.
Example:
DLLAPD <0011> lapd_core.c:829 ((bts=0,trx=0,ts=0,ss=0)[DCCH][0]) SABM(E) received in state LAPD_STATE_IDLE
Change-Id: I17e3d4797ec71e31d0775330ae36d2e1fd70423f
Depends: libosmocore.git Ie6742843fff809edffcac24c4dce4edf66bc71be
Related: OS#1938
|
|
Related: OS#4438
Depends: libosmo-abis I41603db8c1286660ad57ac1c78a8fb393a2b080b
Change-Id: Icdef5d40243fefdeae23f3bcf9c6702e8487928a
|
|
It indicates whether BTS model supports managing an MS Power Control
Loop over HW/DSP instead of using the software based osmocom algorithm
present in osmo-bts.
osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one
since it acts on lower layers and interferes with osmocom algorithm
since it controls the same end variable "lchan->ms_power_ctrl.current",
this way we make sure both aren't enabled at the same time.
Old behavior in kept: if common upper-layer algo is not enabled
explicitly in VTY (ms-power-control osmo) and bts-trx specific lower
layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no
power control is done at all.
Related: OS#1851
Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
|
|
Thies field is used to store and retrieve whether MS power needs to be
calculated and updated by osmo-bts software or autonomously by lower
layers. Previous name was not clear
and may have been understood as indicating whether MS Power Control loop
is done or not in general, and the responsible for that is located under
lchan's ms_power_ctrl.fixed.
Related: OS#1851
Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
|
|
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
|
|
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Closes: OS#4047
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
|
|
The radio link quality is defined by C/I (Carrier-to-Interference
ratio), which is computed from the training sequence of each
received burst, by comparing the "ideal" training sequence with
the actual (received) one.
Link quality measurements are used by L1SAP to filter out "ghost"
Access Bursts, and by the link quality adaptation algorithms. One
can define minimum link quality values using the VTY interface.
On the VTY interface we expect integer C/I values in centiBels
(cB, 10e-2 B), while the internal structures are using float
values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy,
oc2g, and litecell15) expose C/I measurements in deciBels,
while on the L1SAP interface we finally send then in centiBels.
Let's avoid this confusion and stick to a single format, that
will be used by the internal logic of OsmoBTS - integer values
(int16_t) in centiBels. This will give us the range of:
-32768 .. 32767 centiBels, or
-3276.8 .. 3276.7 deciBels,
which is certainly sufficient.
Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
|
|
Otherwise t200_ms_dcch array values are left uninitialized with random
values, and passed later on to lapdm_channel_init2().
lapdm_channel_init2() will anyways fail during initial check on
get_n200_dcch() and return -EINVAL, so let's not print garbage or call a
function which will anyways simply return an error.
Catched due to some strange values seen in log (see D0 and D3):
osmo-bts/src/common/bts.c:421 (bts=0,trx=0,ts=0,ss=4) Setting T200 D0=1028672, D3=2, S0=520, S3=520 (all in ms)
Related: OS#4066
Change-Id: I3d7e1883811acf97aac97325739f2ff97fc2aa08
|
|
By using new libosmocore LAPDm API we can specify the GSM channel type
and hence enable the LAPDm code to use a per-channel-type specific N200
value.
At the same time, this new API also allows us to specify T200 values
when initializing the LAPDm channel, so we don't have to fiddle with
low-level lapdm data structures in what used to be oml_set_lchan_t200().
Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48
Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c
Closes: OS#4037
|
|
Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.
The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.
Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906
|
|
At the moment, bts_supports_cm() is only called on reception of
RSL Channel MODE MODIFY from the BSC. The idea is to check whether
the indicated RSL channel mode is supported by a BTS model.
RSL Channel MODE MODIFY message may indicate a channel in signalling
mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far.
Let's assume that signalling is always supported, as there is
no special BTS_FEAT_* definition to check that.
This change should make BTS_Tests.TC_rsl_modify_encr pass.
Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
|
|
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
|
|
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
|
|
The logic for Extended CBCH are the same as for the Basic CBCH, we just
need to
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429
Closes: OS#3535
|
|
Change-Id: I2170e400e47369e9171af4c7361aa2177fea1174
Related: OS#3701
|
|
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets
use only oml_tx_failure_event_rep() and remove oml_fail_rep()
Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6
Related: OS#3843
|
|
TRX0 is allocated in a different place than other TRX.
Commit that introduced the bug added an initialization step
(bts_trx_init) applied in VTY cmd "trx <0-254>", where TRX are allocated
since same commit, but doesn't initialize TRX0 for reasons explained in
first paragraph.
As a result, some parameters were not applied to TRX0, like
power ramping increment step, which prevented MS from finding the network in
osmo-gsm-tester tests.
Fixes: eebb6a4216f136132400831ca35ed70e7502e92a ("bts: Allocate TRX for BTS dynamically, deprecate -t")
Change-Id: I5afd66548634ff53e2af24dc7055d408ca8ca4e3
|
|
Related: OS#3692
Change-Id: I1ba32c162a8a98ed0fdd4190227de66270679e5a
|
|
No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
|
|
Convert the if-cascade to a switch().
For any unexpected pchan kind, reject the chan mode immediately instead of
going on to invoke gsm_bts_has_feature on feature = _NUM_BTS_FEAT, and log the
error.
Tweaked-by: neels
Change-Id: Ieaded9258554b15fcc4b7f05d5a8847175b7962f
|
|
This way we give the opportunity to the BSC to release the channel
quicker, otherwise it has to wait until T3101 expires.
Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return
an error (hard limit AGCH queue len reached) from bts_agch_enqueue().
Related: OS#2990
Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
|
|
We saw in a recent prod setup a BSC with saturated channels. Further
investigation lead to a AGCH queue of 1000 (previous hard_limit)
messages, most of them being regular IMM ASSIGN (non REJ). Hence, we
also want to get rid of other messages in the AGCH queue (like regular
IMM ASSIGN).
Furthermore, In this scenario, sending IMM ASS REJ is as important as other
messages given than nowadays we support dynamic wait indicatior
(calculated based on chan load), which means if we reach the MS, we can
tell it to wait for a long time to reach us again, which is desirable.
Change-Id: I022b8948da8be13fb8f4bc36e7c9dab11c35fddb
|
|
In a prod setup, complete channel saturation at the bsc was detected,
and Immediate Assignments were not being answered by the MS once sent by
the BTS.
Further investigation showed that the BTS was all the time printing
messages like this:
"bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10"
So it seems the AGCH queue was becoming incredibly full (1000, hard
limit triggered the log), while acgch_queue.max_length was set to 10.
As a result, most probably the Immediate Assignments being sent to the
MS are super old in time, and the MS doesn't known about them anymore
once they are receivied, so no answer is sent back.
Let's try to avoid that by decreasing the hard limit so we never reach
that big queue_len scenario.
The number 100 is selected from data gatherered in agch_test.c which
prints a table of max_length values based on different setups. Some
values can reach around 80 messages, so let's use a slightly bigger hard
limit.
Related: SYS#2695
Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
|
|
It seems I somehow mischecked that the required include for gsm48_rr_msg_name
was not yet present in the file.
Fixes: 44a35902adde70b4e4696640f09f448ba44d51d2
Change-Id: Ia82bc6a5ff7e3989cf0b85ee689d0c3344720eda
|
|
Change-Id: Ia35e132e0b6532dfbf09bb33fe9328a9e3e16885
|
|
The current implementation does not allow the user to specify a port
range in which the BTS is allowed to allocate a local RTP port. Also
the ports the BTS picks do not match the policy described in RFC3550.
An RTP Port must be at an even port number and the matching RTCP
port must be at the following (odd) port number. The BTS currently
picks random port numbers for both.
- Add a VTY command to specify a port range in which the BTS may
assign local ports.
- Pick ports as described in RFC3550.
Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87
Related: OS#2825 OS#2635
|
|
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
|
|
Rathert han have 11 direct members of gsm_bts_role_bts, group them
into a sub-struct as ew do for other parts like interference, laod, ...
Change-Id: Iefecf4b70c1b11c650913f2ae3783718ffb8a36c
|
|
PCU_SOCK_DEFAULT is defined in the pcu counterpart of the file pcuif_proto.h
To be consistent with the pcu move the definition pcuif_proto.h
The pcuif_proto.h will be exact the same in the pcu repo and bts repo.
Change-Id: I67f8ec036e219994cc296d0ed5409da7f3ec681e
|
|
When decoding RACH bursts, we should use a BER threshold in order to
help distinguish 'ghost' RACH bursts from real RACH bursts.
The theoretical ideal threshold according to some papers is 7 out of 41
bits qhich aquals to Eb/N0 of 0 dB = 0.1707 (17.07%)
We add a new 'ber10k' parameter to the RACH indication l1sap primitive
(needs separate change for libosmocore), and then fill this value from
osmo-bts-{sysmo,lc15,trx,octphy}. The common part above L1SAP then
applies the threshold, which can be changed from vty using the
"max-ber10k-rach <0-10000>"
command available at the BTS node. The unit is BER in 1/10000, i.e. a
value of 100 equals 1% bit error rate.
Change-Id: Ic41c11f6312a36baa2738547e8dcec80829457f8
|
|
Change-Id: I51e9938df0e05b8fdb12686b9a9bb6994546deed
|
|
Change-Id: Id6c833746150a3c2e32b00ea6604669f16b84bc4
|
|
osmo-bts has a table of pchan/channel mode combinations for every
bts. This table models the codec capabilitys of the BTS hardware.
However, having the speech codec apabilities modeled inside the
BTS feature list would be much more comfortable and since the
feature list is communicated back to the BSC we would get the
codec capabilities inside the BSC domain as well.
- remove the pchan/channel mode tables
- set speech codec variants for each BTS type
- fix bts_supports_cm so that it queries the feature list
Change-Id: I977dc729ba856631245aedf76afd48eac92166f7
|
|
When the BSC sends a MODE MODIFY request with an unsupported
codec, the BTS must respond with a negative acknowledge.
Currently the codec parameter is not checked at all, which may
lead into malfunction or crash of the BTS.
- Introduce a mechanism to check the codec/rate against a
table that is set up in the phy specific code.
- Add tables with supported codec/rate combinations for
octphy, sysmobts, and trx.
Change-Id: Id9b222b7ab19ece90591718bc562b3a8c5e02023
Related: SYS#3212
|
|
Since libosmocore Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2
we enforce that FSM names do not contain illegal characteers such as
spaces. Let's change the DL TX FSM for AMR to comply to this. Also,
actually do check the result of the FSM registration.
Change-Id: Ieccd1dc32c0faf5e544d17daca4a417d1d168c21
|
|
When a new TRX is allocated using gsm_bts_trx_alloc() (see gsm_data_shared.c in
openbsc.git), than it is added to the list in order. When octphy is shutting
down the BTS, it uses llist_for_each_entry() to iterate the tansceiver list to
shut all transceivers down. This means it starts the shut down process with
the primary TRX and then continues with the secondary transceivers in order.
However, octphy does not allow to close primary TRX if the secondary TRX is
open. The shutdown sequence must begin with the secondary transceivers and
finish with the primiary transceiver as last item.
The problem can be easily fixed by iterating the transceiver list in reverse
order using llist_for_each_entry_reverse() instead of llist_for_each_entry()
Since this is a change in the common code, all BTS models (not only octphy)
are affected, but from the logical perspective, this change makes sense
for all other BTS models too.
Change-Id: I18485de586b402610f9e98053d69e92bc9b18dc2
|
|
In case a system has a high-gain external PA (like a 40dB PA) connected
externally, we cannot simply switch the transceiver to 0 dBm in
trx_init() only to then start the ramping at much lower levels once the
PHJ completes in trx_init_compl_cb(). The result would be a short
0 + 40 dBm spike followed by later ramping. We want to avoid that
spike, particularly its associated inrush current, so let's bring up the
board with smething very conservative like -50 dBm, and then ramp from
there.
Change-Id: I0ad91fce64f65e0213c9fcfde3390ace519055db
Fixes: SYS#3259
|
|
* make oml_tx_failure_event_rep() static and use osmo_signal_dispatch()
wrapped into oml_fail_rep() to trigger event reports outside of oml.c
instead of directly calling into OML layer
* remove unnecessary formatting from text messages
Related: OS#1615
Change-Id: I738555c547926e97b325ab53763c0076c42309bc
|
|
Send OML Failure Report for unsupported BTS attributes and other errors.
Change-Id: Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e
Related: OS#1615
|
|
* Unlike in AMR FR, in AMR HR incoming ONSET have to be treated
differently depending on whether we've recently sent SID UPDATE or
EMPTY frame. Split ST_SID_U FSM state into 2 states to accommodate for
that and make sure that additional states specific to AMR HR are not
used for AMR FR.
* Avoid sending E_VOICE and E_SID_U in corresponding states
as those do not initiate FSM state transitions anyway. This decrease
extra load from FSM signalling which otherwise would be triggered on
per-frame basis.
* Introduce separate signal for SID First P1 -> P2 transition to avoid
confusion with E_COMPL and E_SID_U initiated transitions from P1
state.
* Don't init DTX FSM for SDCCH channels.
Change-Id: I229ba39a38a223fada4881fc9aca35d3639371f8
Related: OS#1801
|