AgeCommit message (Collapse)AuthorFilesLines
5 daysosmo_bsc_main: remove not longer needed fixme noteHEADmasterPhilipp Maier1-2/+0
It is not possible to operate a cell that has secondary TRXs in different bands. Especially considering that DCS1800 and PCS1900 have overlapping ARFCN numbers it would be hard for the MS to tell to which band it should switch. Also the ImmAss. message only contains the ARFCN number. It is impractical to have TRXs in different bands and probably this also violates the sepec. Change-Id: Icc2af9e2a9bca3897dbbb34d7b2c0fe6f843bedd
5 daysbts: set ncc_permitted from bts_allocPhilipp Maier3-3/+2
The value ncc_permitted is preset in osmo_bsc_main.c from bootstrap_bts(). It is a constant value that also cannot be changed via the VTY. Therefore it should be set from bts_alloc(). This also fixes the problem that when the BTS is added at runtime from the VTY. BTSs added at runtime would have an all zero ncc_permitted until the next restart of osmo_bsc. Change-Id: I9f02277d7b4b4bcb383e749435416a0b22efd5e8 Related: SYS#5369
5 daysdrop chan_load_samples_idx initalization from bootstrap_bts()Philipp Maier1-2/+0
The index counter bts->chan_load_samples_idx is initialized to 0 in bootstrap_bts. Since the bts object is allocated using talloc it is already guaranteed that everything is set to zero. So we do not need to initalize chan_load_samples_idx. Change-Id: Ia75e59c44c3ccd653a2614c2cda7519faf999f09
5 daysbts: set acs value in bts_allocPhilipp Maier2-2/+1
The acs value is currently set from bootstrap_bts() in osmo_bsc_main.c. The value is set to 0. Since the BTS object is allocated using talloc it is guaranteed to be 0 from the beginning. Lets set it from bts_alloc anyway so that we have a place holder that is easy to find. Change-Id: Idc4e08c471e15c36b4ea7eb3981254e179115765
5 daysbts: set pwrc value in bts_allocPhilipp Maier2-2/+1
The pwrc value is currently set from bootstrap_bts() in osmo_bsc_main.c. The value is set to 0. Since the BTS object is allocated using talloc it is guaranteed to be 0 from the beginning. Lets set it from bts_alloc anyway so that we have a place holder that is easy to find. Change-Id: Id76879a94cf8cf8c07e8fc7e8aa399cd50e04e9a
5 daysbts: set R99 MSC flag in SI13 in bts_allocPhilipp Maier2-3/+1
At the moment we set the R99 flag from bootstrap_bts() in osmo_bsc_main.c. However this constant flag should be set together with the many preinitalized chan_desc values in bts_alloc Change-Id: I5b78c4e25616ab552c37ba8b7c9948cf7052bad4
5 daysosmo_bsc_main: remove code dup in bootstrap_bts()Philipp Maier1-8/+0
The function gsm_set_bts_type() already takes care of setting the model->started flag to true. There is no need to do this in bootstrap_bts() again. Change-Id: Ia70943d96d466ab506fe368ef178a2ccc7483adc
6 daysstat: add bts.N.num_trx:rsl_connectedNeels Hofmeyr3-1/+8
Controversy: this duplicates bts.N.rsl_connected. I would like to add this duplication for consistency, since we now have these counters: bsc.0.num_trx:rsl_connected bsc.0.num_trx:total bts.N.num_trx:total and the old bts.N.rsl_connected which does not fit well with above naming scheme. Any user will be justified to expect a stat named bts.N.num_trx:rsl_connected as well. Determine bts.N.num_trx:rsl_connected in the new function bsc_update_connection_stats(), where the other num_trx:* are set. Related: SYS#5542 Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks) Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore) Change-Id: I55b55159fe13d937e441d8c2ed915734463e1154
6 daysstat: add bts.N.num_trx:totalNeels Hofmeyr4-0/+9
This is similar to bsc.0.num_trx:total but per single BTS. Related: SYS#5542 Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks) Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore) Change-Id: I283d38e7a8c032e274a5bd2fa150ec2c9a7157b4
11 daysrsl_lchan_lookup(): fix handling of ABIS_RSL_CHAN_NR_CBITS_OSMO_PDCHVadim Yanitskiy1-2/+2
If an RF Resource Indication message includes interference band(s) for 'pure' PDCH (i.e. not dynamic) timeslot(s), osmo-bsc logs: DRSL DEBUG abis_rsl.c:1515 (bts=0,trx=0) Rx Resource Indication DRSL ERROR bts_trx.c:236 (bts=0,trx=0) chan_nr 0xc7 cbits 0x18: (bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED) is not GSM_PCHAN_OSMO_DYN DRSL ERROR abis_rsl.c:141 (bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED) Abis RSL Rx Resource Indication: mismatching chan_nr=0xc7 Let's better check if a timeslot is capable of GSM_PCHAN_PDCH, rather than checking if it's GSM_PCHAN_OSMO_DYN. Change-Id: I2cac4acd4c5145c5c525c9952fdc754477ce0942 Related: SYS#5313
11 daysrsl_rx_resource_indication(): check result of rsl_tlv_parse()Vadim Yanitskiy1-3/+7
Change-Id: I3b4758f80f2cd87e22bd3617e189f12403461ea3 Related: SYS#5313
11 daysnm_channel_fsm: drop ipa link if SetChannelAttr failsPau Espin Pedrol1-10/+2
Now that we solved all the interdependency symbol mess, we can finally enable call to this function. Change-Id: Id4c724ef17beae4bb0918ebd1a809665b59e4861
11 daysGet rid of lots of stubs [4/4]Pau Espin Pedrol14-284/+23
These are not needed anymore since we re-introduced libbsc, specially to avoid all this churn. Some specific methods are explicitly required to be overwritten by tests, so we specificially mark those with __attribute__((weak)) in order to be able to overwrite them. This is the last step towards fixing interdependency mess of symbols and stubs, and requires previous patches in order to have tests apssing fine. Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
11 daysMove ts_fsm_init to static constructor [3/4]Pau Espin Pedrol4-5/+1
This allows having it initialized automatically, as we usually do with this type of code. As a result, tests or other apps importing libbsc don't need to take care of calling it. NOTE: This fix is required by follow-up patches where some stubs are removed and hence some tests start using FSMs internally. Since tests were not using those FSMs before, there was no need to call ts_fsm_init(). This is one further step towards fixing interdependency mess of symbols and stubs. Change-Id: I0e4b95b5e73fbb3844d83ba33e66786831088e1f
11 daysMove global var bsc_gsmnet into libbsc [2/4]Pau Espin Pedrol6-9/+2
This is used inside group of files forming libbsc (shared files used by several apps). Let's instantie only once inside a file from libbsc instead of doing so on each binary. This is one further step towards fixing interdependency mess of symbols and stubs. Change-Id: I9b287aa492ca6aae5fc56133e1510aff3146fe25
11 daysbts_trx: Fix timeslot_fsm not properly freed during trx free() [1/4]Pau Espin Pedrol3-0/+10
osmo_fsm_inst_free() must be called explicitly, otherwise the instance is kept in the llist of instances and produces heap-use-after-free. Note: This fix is required by follow-up patches where some stubs are removed and hence some tests start using FSMs internally. Due to this bug, tests will crash due to reason explain in previous paragraph. This patch itself may introduced failures to build due to some new interdependencies being introduced in same follow-up patches mentioned above, which are in turn fixed by this present patch. So they are expected to be merged together. Change-Id: Ib0e5560efe518833f76f846d7269e82d85c186a1
11 daysMS Power Control Loop: Use P_CON_INTERVAL=2 by defaultPau Espin Pedrol6-33/+69
Increase the reaction time at the expense of more stable loop with less temporary oscillations. See updated user manual documentation in this commit for a larger description. Related: SYS#5371 Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
13 dayscosmetic: Fix typo in commentPau Espin Pedrol1-1/+1
Change-Id: If95b653d9c31292f8e771f0d460fc8f008fd3e24
14 daysdrop obsolete commentNeels Hofmeyr1-6/+0
Change-Id: I7cc79e368512483ff4e1e56b49ad2b950f627c2f
14 daystsc fixup: tweak condition for coverityNeels Hofmeyr1-2/+3
Related: CID#240352 SYS#4895 Change-Id: Idbc6b47df0aeca9b6d870386b037dd6fb7c96c82
14 daysImplement MS Uplink Power Control LoopKeith11-5/+333
* Adds vty option dyn-bsc for ms-power-control -> mode * Imports power_control.c from osmo-bts project [at commit 2f3cd4b697972d8484f9a9d3b7ef634086f65fa5] * Removes unused C/I code from osmo-bts's power_control.c This patch then calls the power loop on receipt of measurement reports and updates the MS Power Level accordingly. Change-Id: Ibc307e758697eb5ca3fb86622f35709d6077db9e
14 daysAdd vty command to manually force MS Uplink PowerKeith2-0/+54
Change-Id: Ie2642299ea696358db5822571f1f722b5e8f76b9
2021-10-04fix TSC / TSC Set used for HandoverNeels Hofmeyr6-44/+68
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values. Handover code is one such instance that forgets to set -1. Change the semantics of tsc_set and tsc so that this kind of error can not happen again as easily: use a separate bool to flag whether to use the default config or explicit values. Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as well as abis_rsl_chan_rqd_queue_poll(). Related: OS#5244 SYS#4895 Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks) Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
2021-10-04assignment_fsm: Check for conn->lchanPhilipp Maier1-0/+9
When the SDCCH gets released while the TCH still beeing activated, then the ChanActivACK that is received after the TCH is activated will trigger a segmentation fault in the assignment_fsm. The reason for this is that conn->lchan, which holds the SDCCH at that point in time, is now NULL. To prevent osmo-bsc from crashing, the FSM should check for the presence of conn->lchan first. If it does not exist, the FSM should terminate. (Assignment failed) Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a Related: SYS#5627
2021-10-02fix comment in lchan_fsm.c: s/modification/activationNeels Hofmeyr1-2/+1
Change-Id: I1f2eaf636d4edc170e1608ab782f60028e2b1eb8
2021-09-29cosmetic: fix comment typos in signal.hPau Espin Pedrol1-2/+2
Change-Id: Ie0c0c75a62b460887f2c78efe043b9e11a76919e
2021-09-29MS Power Control Loop: Allow Turn off/on C/I independent from value settingPau Espin Pedrol6-62/+122
Improve the current VTY support to allow enabling/disabling C/I logic independent from value setting. This way C/I support can be quickly disabled & enabled. Reminder: changing power parameters still require VTY Command "bts NR resend-power-control-defaults" to be excuted prior to new parameters being applied on the BTS. Related: SYS#4917 Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
2021-09-29bts_vty: Print C/I power params for osmo-bts onlyPau Espin Pedrol1-3/+4
Those are osmo-bts specific extensions, so there's no point in printing related VTY config. Change-Id: Ie85d2aefa1ab7bf943479e18cc79a0f56e54d431
2021-09-28assignment_fsm: make assignment_fsm_allstate_action staticPhilipp Maier1-1/+1
assignment_fsm_allstate_action is only used in module assignment_fsm.c, so lets decalare it as static Change-Id: I90d6c11bd485e3be80efc7f146e0129d93e18458
2021-09-28assignment_fsm: make assignment_fsm_timer_cb staticPhilipp Maier1-1/+1
assignment_fsm_timer_cb is only used in module assignment_fsm.c, so lets decalare it as static Change-Id: Ibb3aa01d21b0a83600dc22382a5c8001debbe054
2021-09-28Fix MEAS parsing, as Ericsson RBS reports TA shifted by 2 bits.Keith1-2/+3
This fixes call setup issues when more than ~1km from the tower. NOTE: We use the last reported TA from the UE in the CHANnel ACTIVation. When the UE is more than 1km from the tower, (unshifted) TA in the measurement report can be 8 or greater. Once we send TA of 8 in the CHAN ACTIV message, the lchan is unrecoverable. Change-Id: I1c9bd5bf2fd126e62bcbec419f3499d2e0465559
2021-09-21MS Power Control Loop: Support turn off C/I based logicPau Espin Pedrol3-0/+77
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite cumbersome and end up in lengthy config files. Let's instead add a placeholder command to apply it to all channel types of a BTS at once. This is useful specially since a user disabling C/I capabilities probably does so because it may require a fair amount of fine-tuning parameters to have it working perfectly. Hence, a user not willing to spend time configuring those parameters correctly (and for which default ones doesn't work properly) will require quick way to get rid of C/I based MS Power Control Loop. By disabling C/I comparison, osmo-bts will rely on RxLev only when applying the MS Power Control Loop, which is fine for non noisy environments. Related: SYS#4917 Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
2021-09-15fixup comments for 'rf_states' CTRL commandNeels Hofmeyr2-8/+24
Completely describe the 'rf_states' string elements (in one place), and fix the missing <rsl_status> item in bsc_ctrl_commands.c comments. Related: SYS#5542 Change-Id: Ifc3610c344b3e270111e2f6c5155a6fb90d8f2ac
2021-09-15doc/mgwpool: update documentationPhilipp Maier1-14/+23
The mgw-pool now allows to set a decription for each MGW /MGCP client instance. Update the documentation so that it reflects the current state. Change-Id: I3026e027bba1a9a12ceca64e96df993b5957cb1d Related: SYS#5091
2021-09-14add CTRL bts.N.trx.M.rf_locked (RW)Neels Hofmeyr2-0/+33
Add per-TRX command to lock/unlock single TRX. (Besides the global root-node rf_locked command setting the global RF policy.) Corresponds to VTY command: 'bts N' / 'trx N' / 'rf_locked (0|1)'. Related: SYS#5542 Related: I2bb5096732f75a7341c7e83951e63c5a2038b469 (osmo-ttcn3-hacks) Depends: I4dac826aab00bc1780a5258b6b55d34ce7d50c60 (libosmocore) Change-Id: Ie46fd730797b64fb185d705c3507e36f5f23ef4b
2021-09-14add CTRL 'rf_states' and 'bts.N.rf_states'Neels Hofmeyr3-0/+119
These commands return a listing of OML state, RF policy as well as RSL connection status for each TRX in the form: <bts_nr>,<trx_nr>,<opstate>,<adminstate>,<rf_policy>,<rsl_status>;<bts_nr>,<trx_nr>,... For example, the root node 'rf_states' may return: 0,0,operational,unlocked,on,rsl-up;1,0,operational,unlocked,on,rsl-down;2,0,inoperational,locked,on,rsl-down; A 'bts.N.rf_states' returns the same form of string, but lists only the TRX for the given BTS nr. Note, there is already a CTRL command 'bts.N.rf_state' (singular 'rf_state', not plural 'rf_states'), which only reflects the overall status of all TRX combined. This new command has per-TRX resolution. The rf-policy is so far always looked up in the global gsm_network flag, as does the old 'rf_state' command; see osmo_bsc_rf_get_policy_by_bts() which does not depend on the specific BTS at all. This may be worth revisiting in the future, so I am already including the rf-policy in the rf_state string for each TRX, even though it is globally identical. Related: SYS#5542 Related: I01e6f391a5e71b0606c42be9b57f8a1687d59bcb (osmo-ttcn3-hacks) Change-Id: I14fa2678fc8f2c11a879c5e9615ac552782c5b7e
2021-09-13Power Control Loop: Set P_CON_INTERVAL to 1 by defaultPau Espin Pedrol4-14/+47
TS 45.008 section 4.7.1: """ Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes place or not. """ Since the reported MS_PWR in L1 SACCH Header is, according to specs, the one used for the last block of the previous SACCH period, it becomes clear the first SACCH block after a requested MS Power Level change by the network may contain mismatches between the announced MS_PWR by the MS and the measured Rxlev/RxQual. Hence, let's better use a P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second SACCH block. Related: SYS#5371 Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
2021-09-13Support Neighbor Address Resolution over PCUIF IPA multiplexPau Espin Pedrol6-48/+188
While NACC was initially developed, it became clear there was need for a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS for later RIM usage. Hence, this resolution was first (until today) implemented using an out of bands RPC system using the CTRL interface, which required specific config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port of the CTRL interface to use). However, this has several shortcomings: * As explained above, specific configuration is required * Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS may switch to a BSC other than first one. If that happened, that'd mean the CTRL interface would still point to the initially configured one, which may not be the same currently serving the PCU. During recent development of ANR related features, a similar need for PCU<->BSC was required, but this time it was decided to extend the IPA multiplex of the Abis OML connection to pass PCUIF messages, transparently forwarded to each side by the BTS. This has the advantage that connection PCU<->BTS is handled by BTS and both sides send messages transparently. Let's switch by default to using this new interface, while still maintaing the old way for a while (announcing them as deprecated) to avoid breaking existing deployments until they are upgraded to new versions of osmo-pcu and osmo-bsc. Change-Id: I9073a121564503f483c84263ac72476041e47c03 Related: SYS#4971
2021-09-09lchan_fsm: Avoid inheriting bs_power from old lchanPau Espin Pedrol1-15/+9
So far we were inherting the bs_power in used when activating an lchan for an MS for which we already had previous lchan. For instance, when an MS is first assigned an SDCCH, and later on, it is assigned a TCH to place a voice call. Doing so is, however, not correct because current and old lchans may be placed on different TS or even on different TRX, which means they will have different BS Power restrictions. In the scenario described above, for instance, an SDCCH could have been assigned on C0 and hence have a bs_power of 0, and later on, whenever the TCH lchan as created, it would have inherited the C0 bs_power despite it may have been possible to use a different (lower) max bs power. Furthermore, the lchan->bs_power_db basically stores the *maximum* bs power reduction. Hence it makes not sense at all to copy over the value, since it is anyway not updated from MS measurement reports so far anyway. Fixes: 997a257f8dabe5dd940a1271e56e676a871896d7 Related: SYS#4919 Change-Id: I4a7736aa9a1395e0cc118b98b69896bd0f1e94e6
2021-09-09lchan_fsm: Fix commentPau Espin Pedrol1-3/+2
A previous commit (Feb 05 2021) moved copy of TA value to some other place to fix some related issues, but forgot to update the comment. Fixes: b03e73f27b26449864296fdab84f6fb6e1978c45 Change-Id: Ia10038919b6650dff45b7233f58fea94e9808712
2021-09-09fixup for Early IMM ASS: use proper TSCNeels Hofmeyr1-16/+40
Testing has shown that the Training Sequence Code in pre-chan-ack mode is inaccurate (only worked with a BSIC that incidentally yielded the same TSC value as the wrong TSC value sent in the IMM ASS msg). Move the code setting the correct TSC and TSC-Set to the first stage of channel activation (lchan_fsm_wait_ts_ready_onenter()) so that it is available for both pre-chan-ack and pre-ts-ack Early-IA modes. Have a separate function for setting the preliminary values requested in Channel Activation (lchan->activate.*) into the accepted operative places (lchan->*). Call this early for early-IA modes. Hence the TSC and TSC-Set used in the early IMM ASS message is now the correct one, and the same as sent during Channel Activation. There shouldn't be any, but if there are other values besides TSC suffering from the same problem, they are now also set to the right values before sending IMM ASS early. Related: SYS#5559 Related: I4479244b0c53648e62e84e1ebf986f51d659484f (osmo-ttcn3-hacks) Change-Id: I9f26074154600d854a0b3baee2f38a6666f4cb56
2021-09-08lchan_fsm: Fix commentPau Espin Pedrol1-1/+1
bs_power_db, as its name suggests (also check vty code and rsl_tx_chan_activ()) contains value in dB, not in 2dB steps. Change-Id: I76bd6bb1b307ab75ba1292865747419228e0687a
2021-09-06doc: power_control.adoc: Add small time graph showcasing P_CON_INTERVALPau Espin Pedrol1-1/+16
Original graph made by Vadim Yanitskiy. Change-Id: I9b76088b2d46973b477deb555214d64fcc746754 Related: SYS#5371
2021-09-06MS Power Control Loop: Support set up of C/I parameters for osmo-btsPau Espin Pedrol8-41/+568
This commit extends existing VTY and RSL infrastructure to configure and manage MS Power Parameters used in MS Power Control loop, by adding support to set up Carrier-to-Interference (CI) parameters. Using C/I instead of existing RxQual is preferred due to extended granularity of C/I (bigger range than RxQual's 0-7). Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance" Table 10.3) provides detailed information about expected target values, even different values for different channel types. Hence, it was decided to support setting different MS Power Parameters for different channel types. These MS Power Parameters are Osmocom specific, ie. supported only by newish versions of osmo-bts. Older versions of osmo-bts should ignore the new IEs added just fine. The new IEs containing the MS POwer Parameters are not send for non osmo-bts BTSs, hence this commit is secure with regards to running osmo-bsc against an ip.access BTS such as nanoBTS. Related: SYS#4917 Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
2021-09-06doc: power_control.adoc: Improve VTY snippet foot notesPau Espin Pedrol1-8/+10
Change-Id: Ie5f129c418c187d4f331d6e92884f4f507fb018f
2021-09-06cosmetic: power_ctrl_params_def: Fix typo in commentPau Espin Pedrol1-2/+2
Change-Id: Ibbbb073fa674666f47d84d8e670790c4028ba874
2021-09-05add stat_items for BTS and TRX connection statiNeels Hofmeyr4-1/+80
So far we have stat items per BTS. Add stat items summing overall BTS status. Add stat items: - num_bts:oml_connected - num_bts:all_trx_rsl_connected - num_bts:total - num_trx:rsl_connected - num_trx:total Related: SYS#5542 Related: Ic1b35b7406547f92818afe399a2383d154576409 (osmo-ttcn3-hacks) Change-Id: I2057a798e681a169cc03243a09b3d6449734c010
2021-09-04osmo_bsc_msc: do not initalize MGCP proxy for AoIP MSCsPhilipp Maier1-0/+4
The MGCP proxy which is built into osmo-bsc is used to tunnel MGCP messages through an SCCP-lite link. This is an SCCP-lite specific implementation detail that is not present in SCCP/AoIP. Change-Id: Id3a8c45ae38d6b9d9c106a9e83b3cbfff919650d Related: SYS#5091
2021-09-03osmo_bsc_main: integrate MGW pooling into osmo-bscPhilipp Maier9-18/+330
Since the libosmo-mgcp-client now supports MGW pooling, lets use this feature in osmo-bsc. Large RAN installations may benefit from distributing the RTP voice stream load on multiple media gateways. Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0 Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d Related: SYS#5091
2021-09-02bty_vty: add VTY settungs for temporary overpowerPhilipp Maier3-0/+76
To configure temporary overpower, new VTY commands are added. This patch also addes the logic needed to attach the temporary overpower IE to the RSL CHANNEL ACTIVATE message. Change-Id: I488a91bb4ed86f630db56564a0cd293f39f0f690 Related: SYS#5319