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
Make them more easy to read and edit by splitting to one element per
line when several elements are present.
Change-Id: I24ecfa1167b806dcb3a5a0c00343299df842a78b
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
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
According to osmo-bsc I0e80ca5afc06737273b6699bde6e325e454b57f6, the
PAGING_COORDINATION feature should be well supported in osmo-bts. Adjust
the bts_model_init functions to report this to the BSC, so it properly
sets this in SI13 and so we can avoid this notice in the log:
Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ib06829501f4221a7f7b0344ec7991ceba74e7641
Looks like this structure was copied from openbsc/osmo-bsc as-is.
The ms_mode[] makes no sense in the context of BTS, so remove it
and rename bts_mode[] to mode[] for the sake of brevity.
Change-Id: I7442360ed857554440a0b9854f2d2bbab9dc5a71
Related: SYS#5917, OS#4984
This check is redundant because it's guaranteed in rts_tchh_fn()
that FACCH/H is always scheduled at the correct frame offset.
Change-Id: I2f0c26f6007455aa1e3e8b27bc9d173f6b1f8c38
Related: SYS#5916, OS#5518
DSUM is somewhat similar to DMAIN, generic logging category used
in other Osmocom projects. This category is rarely used in a few
places, where the other categories could fit better. Remove it.
Change-Id: Ia9db783bc92b23ba87b4fdf1e4ed07d59ea6bbce
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
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
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
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
Now bts_model_vty_init() must be called only once, otherwise the
process would crash when bts_model_init() is called from main().
Change-Id: I262c39896b5db86c54ad9aa7042c7ca6657815d9
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
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
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
commit d211c490ca avoided sending
GSMTAP packets on the virtual Um interface with type
GSMTAP_CHANNEL_UNKNOWN by relying on gsmtap_makemsg returning NULL.
But that's not the corect approach since it's totally fine to be sending
GSMTAP_CHANNEL_UNKNOWN on some GSMTAP cases (for instance when the
program fails to infer the type when decoding a message), since then
this way one can study pcap files and find the offending encoded
messages which failed to be decoded.
This patch goes togehter with revert patch introduced in libosmocore as
explained in the commit referred above.
Change-Id: I233afd930d3e43f7b120d40192c7c192102e38d9
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
This change is similar to what we did for Uplink bursts:
- group all Downlink burst parameters into a single structure,
- allocate it once and pass a pointer to lchan handlers,
- pass a pointer to trx_if_send_burst().
Given that the structure is allocated and (zero-)initialized in
trx_sched_fn(), we can get rid of some memset() calls in lchan
handlers and thus improve the overall performance a bit.
Change-Id: If3014e69746559963569b77561dbf7b163c68ffa
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
Related change in libosmocore will let gsmtap_makemsg return NULL if the
channel type is unknown: Ib4147a33a75c3cf425c30da8b0678c7fba8a371d
Related: SYS#4822
Change-Id: Ic22ab71e520ab44429a93724250d349d16250801
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_READ symbol when
copy-pasting somewhere else.
Change-Id: Id51ccb2c273c5f0fa4986f28bbd69a72d2dbaa0e
The VTY option to bind the virtual Um multicast to a specific
network interface has existed ever since osmo-bts-virtual was
first merged to the repo. However, embarrassingly, until today
it never did anything, i.e. the code to actually perform the bind
was missing.
Depends: libosmocore.git Ib52d22710020b56965aefcef09bde8247ace4a9c
Change-Id: I303f2e616d2d32b5a8005c3dcf0f5fad19ad3445
Related: OS#2966
This can be used to determine the multicast TTL packet and hence
how far the packet will propagate in the network. If you want to
operate the virtual Um only on your own machine, a TTL of 0 would
prevent the packets from ever being transmitted on your local
ethernet segment.
Change-Id: I18a9f93b764aee4e1dc68a1c6ac4d078e52ca61d
Related: OS#2966
GSMTAP_CHANNEL_VOICE is the mechanism by which GSMTAP can [finally!]
be used to transport circuit-switched voice codec payload, and not
just signalling.
Original patch by Neels Hofmeyr, heavily extended by Harald Welte.
Depends: libosmocore.git I952044a17334f35712e087dc41781805000aebc1
Change-Id: I1cd9a251ce0b87181a0822d7940bbfc9f1428543
osmo-bts-virtual uses GSMTAP over multicast groups to communicate
with one or more virtphy instances. There are some well-known default
multicast groups, but those can also be overridden via the VTY.
The problem is: If you actually try that, osmo-bts-virtual will abort,
as we try to talloc_free() when using osmo_talloc_replace_string()
on the constant default string.
The proper solution is to talloc_strdup() the constant default string
when setting the default value in bts_model_phy_link_set_defaults().
Change-Id: Ia96fea891a22e5a3c47ce658eda130ba8d4fc411
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
Pau Espin
Vadim Yanitskiy
Oliver Smith
Philipp Maier
Harald Welte
Vadim Yanitskiy