AgeCommit message (Collapse)AuthorFilesLines
6 hoursosmo-bts-trx/scheduler: ensure no DL power attenuation on C0HEADmasterVadim Yanitskiy1-2/+5
When [baseband] frequency hopping is in use, Downlink bursts from additional transceivers may end up being transmitted on TRX0/C0. In this case, we must not apply per-lchan attenuation, because the BTS shall maintain constant power level on that TRX. Change-Id: Id171df70447283b00da965e1f81dfac20e35495c Related: SYS#4918
3 daysl1sap: add repeated uplink SACCHPhilipp Maier4-0/+80
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
5 daysl1sap: add repeated downlink SACCHPhilipp Maier3-3/+49
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
5 daysl1sap: also include SRR bit in RSL l1 info field.Philipp Maier1-3/+4
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
5 daysrsl.adoc: update documentation for RSL_IE_OSMO_REP_ACCH_CAPPhilipp Maier1-4/+20
The recently added IE (RSL_IE_OSMO_REP_ACCH_CAP) has been extended with more options, update the documentation as well. Change-Id: I3d95da588e863185bb62e92898c285d52bce9af4 Related: SYS#5114, OS#4796, OS#4794, OS#4795
5 daysl1sap: add repeated downlink FACCHPhilipp Maier6-7/+170
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
6 dayspart 5 of: fix SAPIs for handover, osmo-bts-oc2gNeels Hofmeyr1-18/+12
Change-Id: I2f1fd6e4620eec198912148cdc59fb4f02786c4d
6 dayspart 4 of: fix SAPIs for handover, osmo-bts-lc15Neels Hofmeyr1-18/+12
Change-Id: I2ac6b0d498edb8facfac4feea7fccbba725d16e8
6 dayspart 3 of: fix SAPIs for handover, osmo-bts-trxNeels Hofmeyr1-0/+6
Change-Id: I0b34855f0374e9ee7071ce14c1472eb3ead50970
6 dayspart 2 of: fix SAPIs for handover, osmo-bts-sysmoNeels Hofmeyr1-21/+20
Change-Id: I30e2ca003a3b15766d9d9dcf529fb2157523758f
6 dayspart 1 of: fix SAPIs for handover to match 48.058 4.1.{3,4}Neels Hofmeyr3-0/+31
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
6 daysrename to release_sapi_ul_rach(), simplifyNeels Hofmeyr3-36/+12
The sapis_for_ho have only one member, so it's silly to iterate. A subsequent commit will drop sapis_for_ho. Change-Id: I896fbca9876fd274ff9c426250b18b50faebfa89
6 dayslc15-mgr: generate coredump and exit upon SIGABRT receivedneels/pre_sapi_fixPau Espin Pedrol1-4/+15
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: I6ddc04c5815858c7dfab04ffdac52bce2e7940a1 Fixes: OS#4865
6 daysoc2g-mgr: generate coredump and exit upon SIGABRT receivedPau Espin Pedrol1-4/+15
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: I7a5756e106ac1061d37b42c22cc127fdacd87ce7 Fixes: OS#4865
6 dayssysmobts-mgr: generate coredump and exit upon SIGABRT receivedPau Espin Pedrol1-3/+14
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: I35ae930b59c48892e5ad9a2826e05d6c5d415abc Fixes: OS#4865
6 dayscommon: generate coredump and exit upon SIGABRT receivedPau Espin Pedrol1-3/+13
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
6 dayscommon: Enable SIGABRT signal handlerPau Espin Pedrol1-1/+1
The signal handler function was coded to expect SIGABRT but the signal handler itself was never enabled for this signal. Change-Id: Id95d64efe8765fcf19eb09cd3db7895166c6adab
12 daysl1sap: pre-initalize pointer with NULL to avoid gcc warningPhilipp Maier1-1/+2
Change-Id: Ibfd18ed5268740cc73fffdb950b96c7f0fad3164
2020-11-10rsl.adoc: add info about RSL_IE_OSMO_REP_ACCH_CAPPhilipp Maier1-0/+10
The RSL documentation should reflect some explanatory info about the recently added RSL_IE_OSMO_REP_ACCH_CAP IE. Depends: libosmocore I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b Change-Id: I1d70846c2c184f7a189074c51137bc1f38fb3859 Related: OS#4796 SYS#5114
2020-11-05doc/manuals: move osmobts-vty-reference.xml to vty/Vadim Yanitskiy3-2/+1
This way we have everything VTY specific in a single directory. Change-Id: Iaba5c42b39fa764cd38c903486617c3d9f9cdebb Related: SYS#4937, OS#3036
2020-11-05doc/manuals: also generate VTY reference for osmo-bts-virtualVadim Yanitskiy1-1/+2
Change-Id: I12ac8cc13ce0caea2b63f94c407c01b4f00845e5 Related: SYS#4937, OS#3036
2020-11-05doc/manuals: generate XML VTY reference at build-timeVadim Yanitskiy5-2022/+74
Unfortunately, we cannot re-use the existing Makefile rules from: $(OSMO_GSM_MANUALS_DIR)/build/Makefile.vty-reference.inc because they do not allow to generate the list of $(DOCBOOKS) from a template, and require the project to store everything in separate folders with specific names. Also, those rules expect that the target PDFs contain only a single word in their names (for example, 'osmoapp-vty-reference', not 'osmo-app-vty-reference'), while in a project with multiple similarly named targets this would reduce readability (imagine 'osmotrxuhd-vty-reference'). Change-Id: Idba84164b90e3d183a20b5eb69cbfe15745e447c Depends: I6aac73d998c5937894233631e654a160d5623198 Related: SYS#4937, SYS#4910, OS#3036
2020-11-05osmo-bts-lc15: use consistent name for containing directoryVadim Yanitskiy46-6/+6
The binary is called 'osmo-bts-lc15', while the containing folder is named 'osmo-bts-litecell15'. This inconsistency complicates automatic generation of the XML VTY reference - fix it. Change-Id: I55c073fbd01aee42871101401d76d87e7c91832e Related: SYS#4937, OS#3036
2020-11-04main: do not print asciiart to stdout, use stderr insteadVadim Yanitskiy1-2/+2
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
2020-11-03fixup: vty: call bts_model_vty_init() from bts_vty_init()Vadim Yanitskiy6-12/+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 Yanitskiy10-89/+67
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-11-02measurement.c: fix integer overflow problemPhilipp Maier1-1/+1
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
2020-11-02vty: fix missing / wrong documentation for some commandsVadim Yanitskiy1-8/+18
Change-Id: Ie2f9e401c0f8f55307d98fa5afe5eb4182add43a Related: SYS#4937, OS#3036
2020-11-02vty: fix double '%' in description of some commandsVadim Yanitskiy1-5/+5
Command description is not a format string => no need to escape. Change-Id: Ib2e339efccec1fc5416ab4b9460a27fa1f8e8044
2020-11-02main: move general options from bts_vty_init()Vadim Yanitskiy2-4/+6
These are not BTS specific options, so register them in main(). Change-Id: Ib6be66537791d489cb709d4d653c4cb434896f77 Related: SYS#4937, OS#3036
2020-11-02main: register VTY commands before handle_options()Vadim Yanitskiy3-13/+13
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
2020-10-30osmo-bts-trx/scheduler: fix comments related to FACCH/H and BFIVadim Yanitskiy1-3/+5
Change-Id: I1c1d81ba5a54946089da6c32b0d42141ffe71ed8 Related: OS#4799
2020-10-26measurement: fix expected number of measurementsPhilipp Maier2-7/+25
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
2020-10-26measurement: count all blocks as SUB for TCH/F in signalling modePhilipp Maier1-1/+4
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
2020-10-26sched_lchan_tchf: count measurements for FACCH/F only oncePhilipp Maier1-0/+10
When the FACCH is generated (while in SPEECH mode), there is also a fake speech indication handed up to l1sap.c. We must make sure that only one of the two indications carry a measurement value, so lets invalidate the measurement values (RSSI in particular) for the generated TCH indication. Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b Related: OS#4799
2020-10-24main: add --vty-ref-mode, use vty_dump_xml_ref_mode()Vadim Yanitskiy1-10/+32
Change-Id: I744520199ef448ff095d0fe703d79ac08f08f7fe Depends: Ie2022a7f9e167e5ceacf15350c037dd43768ff40 Related: SYS#4910
2020-10-24main: separate model-specific arguments in helpVadim Yanitskiy4-3/+6
Change-Id: I9646a45d61153499ad3d580a03d930ed20e23cda
2020-10-24main: increase spacing between commands and descriptionVadim Yanitskiy5-20/+22
Otherwise it's hard to fit new options with long names. Change-Id: If9a418545abff6d22602ba07cfd4447f5ace7742 Related: SYS#4910
2020-10-24main: do not print deprecated '-r' / '--realtime' in helpVadim Yanitskiy1-1/+0
Change-Id: I516a71124a49f6d6adb6db939a91da07576e63e7
2020-10-23cosmetic: add missing semicolon after OSMO_ASSERT()Philipp Maier1-1/+1
Change-Id: Ib886115418939990ecfb6ecc1a4528f7a015b913
2020-10-21oml: Set NM_OPSTATE_DISABLED by defaultPau Espin Pedrol2-4/+4
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
2020-10-21bts_trx.c: Dispatch missing NM_EV_RSL_UP/DOWN to the bb_transc objectPau Espin Pedrol1-0/+1
Previous commit 7810a917331b33b6cfab5259b5fb2df73b27b230 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: 7810a917331b33b6cfab5259b5fb2df73b27b230 Change-Id: I8c777b946e7abcb4b607ec4d136c981a0716b120
2020-10-20power_control: fix default EWMA smoothing coefficient (80% -> 50%)Vadim Yanitskiy1-1/+1
80% (alpha=0.2) is clearly too much, let's use 50% (alpha=0.5). Change-Id: Ib7aec6c7223ffb2d4a312eee77247925beb8c905 Fixes: Ib6dcadbf14ef59696c6a546bd323bda92d399f17 Related: SYS#4916
2020-10-20Introduce NM Channel FSMPau Espin Pedrol18-138/+385
Change-Id: I288cbfb4730b25a334ef1c3d6b9679d6f1d4cfc5
2020-10-20Introduce NM Radio Carrier and Baseband Transceiver FSMsPau Espin Pedrol19-160/+632
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 Pedrol11-24/+194
Change-Id: Iae631bcc7acdf955296b124707e42d5e565af186
2020-10-20Introduce NM BTS Site Manager FSMPau Espin Pedrol15-15/+284
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 Pedrol7-0/+83
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-19remove dead oml_router codeHarald Welte12-468/+6
We originally wanted to intrdouce an OML router which would permit external proceses to implement certain OML MOs. However, that code was never completed, and all the existing implementation (in three copies) does is to create a unix domain socket and discard what is received there. Change-Id: I7fcbbd5d6b64ddc666ca836dc49abb430be0d5cb
2020-10-19use osmo_fd_setup() everywhereHarald Welte10-62/+18
Change-Id: I9be55f791a15fae2362dc431dc778b9b9d8db349