aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bts-virtual
AgeCommit message (Collapse)AuthorFilesLines
2021-06-18osmo-bts-{trx,virtual}: get rid of dummy tx_idle_fn()Vadim Yanitskiy1-6/+0
This logical channel handler does nothing more than just logging. Change-Id: I438705f8dd902193e6c7b499d8ee55c56b6a1c2e
2021-05-19osmo-bts-{trx,virtual}: fix: pinst->trx may be NULLVadim Yanitskiy1-1/+3
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"
2021-05-18[VAMOS] Re-organize osmo-bts-trx specific structuresVadim Yanitskiy4-101/+82
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
2021-05-11[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}Vadim Yanitskiy1-94/+83
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
2021-02-16gsm_data: handle l1_info with structsPhilipp Maier1-1/+1
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
2020-11-03fixup: vty: call bts_model_vty_init() from bts_vty_init()Vadim Yanitskiy1-2/+0
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
2020-11-02vty: call bts_model_vty_init() from bts_vty_init()Vadim Yanitskiy1-5/+1
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
2020-10-20Introduce NM Channel FSMPau Espin Pedrol1-5/+5
Change-Id: I288cbfb4730b25a334ef1c3d6b9679d6f1d4cfc5
2020-10-20Introduce NM Radio Carrier and Baseband Transceiver FSMsPau Espin Pedrol1-15/+8
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
2020-10-20Introduce NM BTS FSMPau Espin Pedrol1-1/+3
Change-Id: Iae631bcc7acdf955296b124707e42d5e565af186
2020-10-20Introduce NM BTS Site Manager FSMPau Espin Pedrol1-1/+4
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
2020-10-20Change NM Channel availability Dependency->Offline when RadioCarrier becomes ↵Pau Espin Pedrol1-0/+13
enabled This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs, which expectes for non-nanoBTS types to follow TS 12.21 guidelines. Until now, BSC simply waited to received State Event Change Dependency for each TS and then sent all required commands (Set Chan Attr, Adm Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when in Offline state, so we need to transit to that state. For the above mentioned reason, since we pass through the Dependency state anyway after this patch, older osmo-bscs will work correctly too. Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
2020-10-19use osmo_fd_setup() everywhereHarald Welte1-3/+1
Change-Id: I9be55f791a15fae2362dc431dc778b9b9d8db349
2020-09-28vty: make most struct pointers const in show/write commandsVadim Yanitskiy1-4/+4
Change-Id: Iacc32f7982c150d84ea4df7affa1f9e07806928f
2020-09-16Improve logging around failing to (de)activate chan_nrPau Espin Pedrol1-4/+4
Change-Id: Ibc398eb5d50851cbe48f2c92f14e746938a68720
2020-08-03Constify the 'trx' argument of trx_get_hlayer1() everywhereVadim Yanitskiy1-1/+1
Change-Id: I44523d26f2f564932ea95c17b1041d0ca9cc2828
2020-07-09bts-virt: Don't rely on gsmtap_makemsg() returning NULL for ↵Pau Espin Pedrol1-1/+4
GSMTAP_CHANNEL_UNKNOWN commit d211c490cad38f2009943121d57bdb7df8eee9b0 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
2020-06-25Use libosmocore's TDMA frame number API (constatns & arithmetic)Vadim Yanitskiy1-10/+8
Depends: (libosmocore) Ic291fd3644f34964374227a191c7045d79d77e0d Change-Id: I61c97a62bd5dbbb4a984921ebdfc10ad6ed00f2a
2020-06-25Fix shutdown in osmo-bts-{omldummy,virtual}Pau Espin Pedrol1-0/+1
Change-Id: Idadb62ec25181b140d9061dc7470da00d47d8336
2020-06-23bts-virtual: Implement bts_model_trx_closePau Espin Pedrol1-1/+10
Change-Id: Id37562652b1ebc27d808d83342e4961b936dbcad
2020-06-23bts_model: Convert bts_model_trx_close() to return asynchronouslyPau Espin Pedrol1-2/+2
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
2020-06-15osmo-bts-trx: introduce and use struct trx_dl_burst_reqVadim Yanitskiy1-58/+54
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
2020-06-11Do not mix public and private BTS features, use libosmocore's APIVadim Yanitskiy1-7/+7
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
2020-06-06common/scheduler: use boolean for channel activation stateVadim Yanitskiy1-4/+4
Change-Id: I0cb1d915db8787050cdec1802894f66e885a9bf3
2020-06-06osmo-bts-virtual: cosmetic: use LID_{SACCH,DEDIC} macrosVadim Yanitskiy1-2/+2
Change-Id: Idd37ca9ebf0d483cbea6f0e992211b9c3e2af993
2020-05-20virtual/scheduler: log unknown GSMTAP chanHarald Welte1-0/+4
Related change in libosmocore will let gsmtap_makemsg return NULL if the channel type is unknown: Ib4147a33a75c3cf425c30da8b0678c7fba8a371d Related: SYS#4822 Change-Id: Ic22ab71e520ab44429a93724250d349d16250801
2020-05-09Use OSMO_FD_* instead of deprecated BSC_FD_*Pau Espin Pedrol2-2/+2
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
2020-04-21osmo-bts-virtual: Avoid rejecting AMR in uplinkHarald Welte1-41/+2
Change-Id: Ib527a9fe02c49f6129c376424480aa1004f9ee8f
2020-03-10osmo-bts-virtual: Fix "virtual-um net-device NETDEV"Harald Welte3-6/+21
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
2020-03-10osmo-bts-virtual: Add "virtual-um ttl <0-255>" VTY optionHarald Welte5-3/+38
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
2020-03-08osmo-bts-virtual: implement GSMTAP_CHANNEL_VOICEHarald Welte2-12/+79
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
2020-03-04osmo-bts-virtual: do not log GSMTAP message sending failure twiceVadim Yanitskiy2-2/+5
Change-Id: I39e9edf35240ef31e3432412b459c2b8fb0de054
2020-03-02osmo-bts-virtual: do not print redundant info in tx_to_virt_um()Vadim Yanitskiy1-13/+2
LOGL1S() already prints enough context information. Change-Id: I29adf9360b96544b7f58766d5cd26d97117884d9
2020-02-29osmo-bts-virtual: fix wrong endianness in gsmtap_hdr_stringify()Vadim Yanitskiy1-1/+3
Change-Id: Ic9e84dc4adc44df735cba102bdace2fb1993ac8e
2020-02-26virtual: Fix VTY commands to specify GSMTAP multicast groupsHarald Welte1-2/+2
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
2019-11-14Move and rename gsm_lchan.ms_power fieldPau Espin Pedrol1-1/+1
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
2019-10-17Fix common misspellings and typosMartin Hauke2-3/+3
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-10-05struct gsm_bts: Add model_priv pointer handing bts_model specific dataPau Espin Pedrol3-9/+21
Currently there's bts-virtual specific fields in gsm_bts which is not used by other models and are always allocated. An alternative would be having a union with different structs inside, one per model, but since we already have the bts_model abstraction, in this case it makes more sense to use that abstraction instead of filling code with preprocessor ifdefs to guard against non-defined types, etc. Existing model specific data is moved there. This new infra will be user further in forthcoming commits. Related: OS#4215 Change-Id: Ib17a752cdbaa7d5eb8c5dfa0b197f80a4f38b38e
2019-08-23virtual: set link quality for GSMTAP_CHANNEL_RACHOliver Smith1-0/+1
Don't ignore all incoming RACH requests anymore: 000881/00/23/14/09 Ignoring RACH request: link quality (0) below the minimum (50) Related: OS#3925 Fixes: b777c0f3ecb8b770f032db449e947f0f9731de11 ("Move Access Burst link quality handling to L1SAP") Change-Id: Ifcd576fed84346688e711a26a05c6d350588e83d
2019-08-23Cosmetic: virtual: l1sap.c: fix typosOliver Smith1-1/+1
Change-Id: Id24e75812bda17e99f17a37b367462533a5607f9
2019-07-16osmo-bts-trx/scheduler: pass trx_ul_burst_ind to lchan handlersVadim Yanitskiy1-15/+10
This change needs to be done in order avoid adding more and more arguments to the UL logical channel handlers (such as rx_rach_fn). Since we have different versions of the TRXD header, and may have other burst-based PHYs in the future, some fields of an Uplink burst indication have conditional presence. Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0 Related: OS#4006, OS#1855
2018-11-26bts_model: Allow TS connect to be processed asynchronouslyPau Espin Pedrol1-2/+1
This commit doesn't change internal logic of any model, only the API to be able to return result of connect TS asyncrhonously since some models (like osmo-bts-trx) require some time to process the result. This way PDCH ACT/DEACT (N)ACK can be sent once the result of this long process is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK before getting the result from SETSLOT on the TRX iface. With this new API, bts_model_ts_connect doesn't return any value synchronously. Instead, it is expected to always end up calling cb_ts_connected with the return code from the TS activation process. 0 is considered a successs, while any other value is considered an error. Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
2018-11-18bts: Allocate TRX for BTS dynamically, deprecate -tPau Espin Pedrol1-0/+5
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
2018-11-06prevent potential NULL dereference in virtbts's tx_tchh_fnStefan Sperling1-1/+1
If chan_state->ongoing_facch is set, this code's logic suggests that both msg_facch and msg_tch could be NULL. Don't dereference msg_tch unconditionally. Change-Id: Icf5584396c5b925d55ca9380dd4f869ae5d72da3 Related: CID#172047
2018-09-30sysmo, virtual: properly handle BS-AG-BLKS-RES as received from BSCHarald Welte1-1/+2
Change-Id: Ifd9a3be6189b3288526e12260d68a982b089404e
2018-09-30Fix computing CCCH block number from frame numberHarald Welte1-1/+1
The existing implementation used a simplistic macro, which was wrong in many ways: 1) it returned a negative value for "fn % 51 < 5" conditions without raising any error message or asserting 2) it returned a wrong block number for many different input frame numbers, as it didn't account properly for the FCCH/SCH gaps between the blocks Let's replace the simplistic macro with a proper lookup table based on TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH frame numbers. Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5 Closes: OS#3024
2018-09-09CBCH: Implement CBCH support for osmo-bts-{trx,virtual}Harald Welte1-0/+1
This patch adds scheduler support for the channel combinations that substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4. Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f Closes: OS#1617
2018-08-23osmo_mcast_sock: make sure SO_REUSEADDR is appliedPhilipp Maier1-2/+3
osmo-bts-virtual uses UDP multicast to communicate with its virtphy counterpart. At the momemnt SO_REUSEADDR is not applied for those multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This makes prevents the proper function of UDP multicast. - Make sure OSMO_SOCK_F_UDP_REUSEADDR is set Change-Id: I7f27758b7aa786c8dbae669cbcde10baab8e4845 Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874 Related: OS#3497
2018-08-01Clarify frame loss counter for l1sched_chan_stateVadim Yanitskiy1-1/+1
Each logical channel (e.g. SACCH, SDCCH, etc.) has a counter of lost L2 frames. Let's use a bit better name for it, and correct its description in the 'l1sched_chan_state' struct definition. Change-Id: I92ef95f6b3f647170cfd434a970701406b0a7c82
2018-07-02Remove unneeded direct libortp dependencyPau Espin Pedrol1-2/+2
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h), hence direct dependency is not needed. Fixes OBS warnings: dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols) Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de