aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2021-08-09fix gscon clear 1/n: store clear cause in gsconNeels Hofmeyr1-0/+2
Allows returning a context sensitive cause instead of a hardcoded one in gscon pre_term(). The conn->cause is needed to move message dispatch to an "onenter" function in patch I234b2a754d0c98031056981823cdbc187e977741 Split off as a separate patch for better readability. Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
2021-07-23Introduce VTY option to forbid use of TCH for non-voicecall signallingPau Espin Pedrol2-0/+9
Usual allocation mechansim, when some signalling channel is needed, first tries to reserve an SDCCH, and if all of them are exhausted, then attempts to reserve a TCH as a last resort. This, however, may cause TCH starvation under certain situations, for instance if there high load on other services (LU, SMS, etc.). Hence, it may be desirable for the operator to forbid reservation of TCH slots once SDCCH become exhausted. This commit is thus adding a VTY command which allows forbidding it. The default behavior (allow using TCH timeslots when SDCCHs are exhausted) is kept as before. The above mentioned prohibition is applied only to non-voicecall related signalling services. That's because voicecall services will end up requiring a TCH anyway, and forbidding reservation of TCH straighaway when SDCCHs are exhausted would mean no voice calls could be initiated while still TCHs would be available. Related: SYS#5548 Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
2021-07-23Split bts_vty.c creating bts_trx_vty.cPau Espin Pedrol1-0/+11
Change-Id: I15ec8f71a5d31915162cb3ad75ea77e934fa4887
2021-07-22Split bsc_vty.c creating bts_vty.cPau Espin Pedrol1-0/+40
Change-Id: I347e7da328fed0733af2eec10a3ca6e02a148308
2021-07-22bts: Clear BTS_STAT_CHAN_*_{TOTAL,USED} on bts disconnectDaniel Willmann1-0/+2
Adds gsm_bts_stats_reset() to clear the stats and calls it from the different models. Change-Id: Ic42687cd73e3546edaa99fb1268a5960ffa43b12 Related: SYS#5541
2021-07-20Add new lchan_select_set_type() API helperPau Espin Pedrol1-0/+1
It's an easy helper, but it helps in standarizing and finding similar places in code. Morevoer, it will be used in follow-up commit where we first use lchan_avail_by_type and finally we select it in a later stage. Change-Id: I025a40962a5e5d40543b297a0760e47618fb525c
2021-07-19handover_ctrl: add control interface for handover settingsPhilipp Maier2-0/+4
The VTY handover_vtc.c offers a large number of handover specific settings. Those settings are (with one exception) auto generated using macros. Lets add an equivalent for the control interface that uses the same auto generation mechanisms. Change-Id: I12f143906818fd6b16e8783157cbb1eb51e49ffc Depends: libosmocore I53fc207677f52b1dc748b01d58424839cdba807c Related: SYS#5369
2021-07-16separate 'interference-meas level-bounds' cfg and usedNeels Hofmeyr1-2/+4
The VTY defun already indicates BSC_VTY_ATTR_RESTART_ABIS_OML_LINK correctly, but so far we would immediately start using the new values internally, and wrongly interpret interference levels. Fix that. Have bts->interf_meas_params twice: interf_meas_params_cfg for the VTY configured values, and interf_meas_params_used for the values that the BTS actually knows about, after they were sent via OML. In a running BSC, when changing the interference level boundaries on the telnet VTY, the BTS is not immediately told about the change. That would require a BTS restart. Hence store the cfg values separately in interf_meas_params_cfg. For comparing/printing interference levels in a running BTS, only employ the values that were actually sent via OML and placed in interf_meas_params_used. Related: SYS#5313 Change-Id: Iad8cf4151ff7f86dc0549158ed5d91d788d40b1f
2021-07-15hodec2: add low-rxqual-assignment penalty timer (2/2)Neels Hofmeyr1-0/+7
Hold off re-assignment after an intra-cell re-assignment due to low rxqual. Adjust test_amr_tch_h_to_f_rxqual.ho_vty to show the changed behaviour. Related: SYS#5198 Change-Id: Id00a07313fe04eec509b336c0637b59c707760e0
2021-07-15ensure trigger_ho() returns zero only when HO or AS was indeed triggeredNeels Hofmeyr1-1/+1
In an upcoming patch, handover_decision_2.c will use this indicator to decide whether to start a penalty timer: "hodec2: add low-rxqual-assignment penalty timer (2/2)" Id00a07313fe04eec509b336c0637b59c707760e0 Related: SYS#5198 Change-Id: I5de385e0666f716184a62e6e70d656545ac5d2ee
2021-07-11RES IND: add VTY: bts / channel allocator avoid-interference (0|1)Neels Hofmeyr1-0/+4
Store the config option whether the channel allocator should try to avoid lchans with higher interference levels reported in RES IND. The actual implementation of avoiding interference follows in I844494092193811dfd9fa4d52983cbaed0fc9248 Related: SYS#5313 Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
2021-07-11RES IND: parse msg and store interference levels in lchansNeels Hofmeyr1-0/+11
Also show the current interference levels of unused lchans in the vty. Related: SYS#5313 Change-Id: Iccc1391e8419604bb09e464db8455e053dfbc982
2021-07-09hodec2: [2/2] implement automatic choice between FULL and SUBSET measurementsNeels Hofmeyr2-14/+11
Add TDMA_MEAS_SET_AUTO to indicate automatic choice between FULL and SUBSET measurements depending on DTX. So far use only in hodec2. TDMA_MEAS_SET_AUTO looks at each individual measurement report's DTX flag and for each report chooses FULL if DTX is not used, or SUB if DTX is used. The default setting for 'handover2 tdma-measurement' is still 'subset'. To use the automatic choice, users need configure handover2 tdma-measurement auto Change-Id: I67dce55ccf892c8679272ee5dfedc25620f0f725
2021-07-09hodec2: [1/2] implement automatic choice between FULL and SUBSET measurementsNeels Hofmeyr1-3/+21
Cosmetic preparation for enabling automatic choice between FULL and SUBSET measurements depending on DTX in handover decision 2. Change the internal API to pass separate enums for the choices {RXLEV, RXQUAL}, {UL, DL} and {FULL, SUB}. Change-Id: I283e03126a6bc1f5f1b35f9801e841053edd2947
2021-07-06Rename osmo dyn ts enums to contain SDCCH8Pau Espin Pedrol2-4/+4
They will gain support to be activated as SDCCH/8 soon too. Related: OS#5309 Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68 Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
2021-07-05power_control: constrain BS power reduction on BCCH carrierVadim Yanitskiy1-0/+3
BS Power Control is not allowed on the BCCH/CCCH carrier, unless the BTS is operating in the BCCH carrier power reduction mode. Allow constrained BS power reduction (up to 6 dB) on active logical channels iff BCCH carrier power reduction mode is enabled. Take into account that the maximum power difference between a timeslot used for BCCH/CCCH and the timeslot preceding it shall not exceed 3 dB. Change-Id: I2cc6a86731984f586ef35b43a8d3de631f7d8a2f Related: SYS#4919, SYS#4918
2021-07-05power_control: implement BCCH carrier power reduction operationVadim Yanitskiy1-0/+7
The BCCH carrier (sometimes called C0) of a BTS shall maintain discontinuous Downlink transmission at full power in order to stay 'visible' to the mobile stations. Because of that, early versions of 3GPP TS 45.008 prohibited BS power reduction on C0. However, starting from version 13.0.0 (2015-11) there is a feature called 'BCCH carrier power reduction operation'. This is a special mode of operation, where the variation of RF level for some timeslots is relaxed for the purpose of energy saving. In BCCH carrier power reduction operation, for timeslots on the C0 carrier, except timeslots carrying BCCH/CCCH, the output power may be lower than the output power used for timeslots carrying BCCH/CCCH. In this case the maximum allowed difference in output power actually transmitted by the BTS is 6 dB. Introduce a VTY command to turn on and off the BCCH carrier power reduction operation. Also introduce a CTRL command. On the A-bis/RSL, abuse the BS POWER CONTROL message by setting the Channel Number IE to 0x80 (RSL_CHAN_BCCH). Currently, only osmo-bts-trx is supported. A value greater than zero makes it reduce the power on *inactive* timeslots of the BCCH carrier. Sending zero disables the BCCH power reduction mode completely. For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926. Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783 Related: SYS#4919
2021-06-30Support proto IPAC_PROTO_EXT_PCU BSC<->PCUPau Espin Pedrol3-0/+36
Related: SYS#5303 Change-Id: I4b3919f3098b9468e5e024db1e45427af24c1ad4
2021-06-29gsm_data.h: remove declaration of non-existing ts_pchan()Vadim Yanitskiy1-1/+0
Change-Id: I2471d0f2825661e60539d9504632fc80145c603d
2021-06-25pcuif_proto.h: Add new container messagesPau Espin Pedrol1-0/+10
Related: SYS#5303 Change-Id: Icc50f903a7fe1464549537a24b2bd2befaf6f7e1
2021-06-22PCUIF protocol: add message definition for interference reportVadim Yanitskiy1-0/+10
Change-Id: I4bd5d4de695a1f9f202870cfd7e43caac9ce6d48 Related: SYS#5313, OS#1569
2021-06-22support A5/4 in inter-BSC HandoverNeels Hofmeyr1-0/+2
inter-BSC into this BSC: from BSSMAP Handover Request, parse and store Kc128. All else is already implemented: depending on the chosen encryption algorithm, Kc128 will end up in the Channel Activation. inter-BSC out of this BSC: nothing is needed to support A5/4, the BSSMAP Handover Required message does not contain any encryption related information. The MSC already knows the chosen algorithm. Related: SYS#5324 Change-Id: I7e9590e8c96aa50086148863ad9a2741b978e614
2021-06-18implement A5/4 in Ciphering Mode procedureNeels Hofmeyr1-0/+2
Receive and store the Kc128 key from MSC, and use as key sent to BTS if A5/4 is the chosen encryption algorithm. (A5/4 in handover will follow in a separate patch) Related: SYS#5324 Change-Id: I7c458c8a7350f34ff79531b3c891e1b367614469
2021-06-17Introduce counters to track SRVCC proceduresPau Espin Pedrol2-0/+22
Related: SYS#5337 Change-Id: I5c20da56d465dbcf4366130394f7c42635a24cc7
2021-06-17Introduce VTY command to disable srvcc fast-return on target BTSPau Espin Pedrol3-4/+12
Related: SYS#5337 Change-Id: I2ac91b5dffc9b6de60576aabe21a15f24fea38cb
2021-06-16handover_cfg: add missing VTY_CMD_PREFIX in commentPhilipp Maier1-1/+1
The comment that explains HO_CFG_ONE_MEMBER lacks VTY_CMD_PREFIX in the sample macro definistion. Change-Id: I80db198178cfd1e8669589eb3b468766f0c30ea2
2021-06-10gsm_data.h: add comments about immutable activ/modif/assign request infoNeels Hofmeyr1-0/+18
Change-Id: I7997b802d997073ae6a05db2f40e82cb8e83764f
2021-06-10VTY: add lchan re-assignment commandNeels Hofmeyr1-0/+1
Add VTY command to trigger an intra-cell re-assignment, also allowing to re-assign to a secondary VAMOS lchan. Related: SYS#5315 OS#4940 Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
2021-06-10RSL: rx and tx VAMOS Channel Number cbits for VAMOS lchansNeels Hofmeyr1-3/+3
Add the Osmocom-specific extension to indicate VAMOS shadow lchans in RSL, in lchan lookup and RSL message transmission. Note that RR messages containing cbits (Assignment Command, Handover Command, ...) must *not* send Osmocom specific cbits to the MS. Only the RSL messages directed to the BTS send Osmocom specific bits. Related: SYS#5315 OS#4940 Depends: If33c1695922d110c0d2c60d5c0136caf2587194e (libosmocore) Change-Id: I957eff0d2c33ec795eda75a4bff21965b0179f73
2021-06-10RSL chan_nr: replace OSMO_ASSERT with error handlingNeels Hofmeyr1-9/+9
It's bad to abort the program for an incompatible chan_nr. Instead of OSMO_ASSERT(), make sure that error handling happens all they way to the original callers of gsm_lchan2chan_nr etc. This is also preparation to add further error causes: Osmocom specific cbits needed for a non-Osmo BTS. Related: SYS#5315 OS#4940 Change-Id: I71ed6437c403a3f9336e17a94b4948fca295d853
2021-06-10update the lchan name to always reflect VAMOS shadownessNeels Hofmeyr2-1/+2
Change gsm_lchan_name_compute() to a function that in-place updates the lchan->name. That allows calling it numerous times with the talloc handled internally. Rename it to lchan_update_name(). Add 'shadow' to lchan_update_name() and lchan_fsm_update_id() for VAMOS shadow lchans, and also print the lchan index that it is a shadow for, instead of the index in the lchan array. When set_pchan_is() updates the VAMOSness of the lchans, call lchan_fsm_update_id(). From lchan_fsm_update_id() also call lchan_update_name(). This is a bit convoluted for legacy reasons. There are utility programs and C tests using bts_trx.c but not lchan_fsm.c. lchan_update_name() lives in gsm_data.c for that reason. This patch calls lchan_update_name() from lchan_fsm_update_id() and not vice versa to avoid having to add stubbed lchan_fsm_update_id() functions to all utility programs and C tests. We can't easily unify the lchan->name and lchan->fi->id without lots of refactoring rippling through all those little utility programs and C tests. Change-Id: I7c2bae3b895a91f1b99b4147ecc0e3009cb7439a
2021-06-10add VAMOS secondary lchans to timeslot structNeels Hofmeyr1-0/+3
So far there is a bunch of code setting a primary lchan in VAMOS mode. This patch now adds the actual secondary "shadow" lchans that may be combined with a primary lchan in VAMOS mode to form a multiplex. VAMOS lchans are put in the same ts->lchan[] array that keeps the primary lchans. They are at most two additional usable lchans (for a TCH/H shadow) added to either TCH/F or TCH/H. Keeping these in the same array allows looping over all lchans easily. The ts->max_primary_lchans indicates the index of the first VAMOS shadow lchan. Related: SYS#5315 OS#4940 Change-Id: I928af99498bba488d317693f3144d4fccbbe9af3
2021-06-10implement CHANnel ACTIVate to VAMOS modeNeels Hofmeyr1-0/+2
Related: SYS#5315 OS#4940 Change-Id: If3ac584e4223ef7656c7fedc3bf11df87e4309ec
2021-06-10lchan_fsm: introduce lchan.activate.ch_mode_rate to allow tweakingNeels Hofmeyr1-0/+1
lchan->activate.info.ch_mode_rate should remain unchanged, it is the immutable request data. However, for VAMOS, we will want to automatically see that the chan_mode is chosen correctly. As a first step, place a mutable ch_mode_rate copy at lchan->activate.ch_mode_rate, i.e. not in .activate.info, but in .activate. Use that everywhere. This is mostly a non-functional change, preparing for a subsequent patch that adds handling of VAMOS shadow lchans. As side effect of adding lchan_activate_set_ch_mode_rate_and_mr_config() after MODE_MODIF_ACK (enabling the voice stream after a channel mode modify), fix AMR config: the call to lchan_mr_config() was missing. Change-Id: Icc9cc7481b3984fdca34eef49ea91ad3388c06fe
2021-06-10add lchan->vamos.is_secondary flagNeels Hofmeyr1-0/+4
VAMOS shadow lchans do not exist yet, but add the indicator flag that tells whether an lchan pointer is a primary or a shadow lchan. In Mode Modify: based on the flag, choose a different default TSC Set for shadow lchans; do BTS type compat checking for shadow lchan use. Actual lchans with vamos.is_secondary == true will be introduced by patch: 'add VAMOS secondary lchans to timeslot struct' I928af99498bba488d317693f3144d4fccbbe9af3 Change-Id: I4072fc7703c592df699fe8e27c02df09acde0909
2021-06-10implement Channel Mode Modify to VAMOS modeNeels Hofmeyr1-0/+7
Put a (primary) lchan in VAMOS speech mode. This is not yet about activating shadow lchans, this merely puts any lchan in a VAMOS capable channel- and speech mode. Protocol: In RR Channel Mode Modify, send a spec conforming VAMOS channel mode as well as an Extended TSC Set, wich adds the TSC Set to the training sequence code value. In RSL MODE MODIFY, send Osmocom specific extensions to indicate the TSC Set and TSC, as well as the VAMOS channel mode; only to OsmoBTS type cells. - Set the Channel Mode's Channel Rate to Osmocom specific RSL_CMOD_CRT_OSMO_TCH_VAMOS_Bm / RSL_CMOD_CRT_OSMO_TCH_VAMOS_Lm - Add the Osmocom specific Training Sequence IE containing both TSC Set and TSC. (These are documented in the Abis manual.) Implementation: The internal API to request a Mode Modify is lchan_modify(info). Add to this info the 'vamos' bool, set to true when the modification should put the lchan in VAMOS channel mode or not. When info.vamos == true, make sure the channel mode value is a VAMOS one: in the copy of info->ch_mode_rate at lchan->modify.ch_mode_rate, convert to the right VAMOS/non-VAMOS equivalent channel mode. When the modification is through, set lchan->vamos.enabled appropriately. This patch also builds on Ic665125255d7354f5499d10dda1dd866ab243d24 'allow explixit TSC Set and TSC on chan activ / modif / assignment' placing tsc_set and tsc values in the TSC related IEs. Related: SYS#5315 OS#4940 Change-Id: Ibf53f4797d7491b17a33946fd7d920f038362b4c
2021-06-09vty: Drop unused old node enum fieldsPau Espin Pedrol1-2/+0
Change-Id: Ifccd1e477c36bee976a61760b0fedc395f675c1f
2021-06-05change bs_power to bs_power_dbNeels Hofmeyr2-2/+2
The RSL BS Power IE in measurement reports is encoded as dB / 2. Instead of using this coding all over the code, converting to dB and often printing confusing values in logging etc, store as plain dB. The conversions should be at the points where a "weird" format is defined: the RSL encoding needs divided-by-two, so apply it there. The meas_vis is (now unfortunately) defined as div-two, and so on. But internally we now just store the plain dB value and calculate with it without duplicating the wire decoding step everywhere. Rename to bs_power_db to clarify the unit of the stored value. Change-Id: I229db1d6bcf532af95aff56b2ad18b5ed9d81616
2021-06-04Make interference measurement parameters configurableVadim Yanitskiy2-0/+13
According to 3GPP TS 45.008, the BSS shall monitor the levels of interference on its IDLE traffic channels. The actual measurements are performed in the BTS and then reported to the BSC over the A-bis/RSL link(s) in RF RESource INDication messages. 3GPP TS 45.008 defines the following measurement parameters: * Intave: Interference Averaging period (see table A.1), * Interference level Boundaries (see table A.1). Both parameters are sent to the BTS over the A-bis/OML, and can now be configured via the VTY interface. Only those BTS models which 'speak' the OML protocol defined in 3GPP TS 52.021 will actually get the configured parameters, others will keep using the hard-coded parameters. Change-Id: I99ebf57aac1f3ca7e0497c3b4f6b0738c6ed7e47 Related: SYS#5313, OS#1866
2021-06-04drop unused func decl gsm_lchan_as_pchan2chan_nr()Neels Hofmeyr1-2/+0
Change-Id: I1c14e72d4387767349723ec8948149841b45d85a
2021-06-01Drop duplicated arfcn_range_encode.c available in libosmocoreNeels Hofmeyr3-29/+2
This code is available in libosmocore since ~3 years ago (fdf8b7b1beeb0cda262c5fb060a933aa7edb5e9a). Let's use it instead of maintaining duplicated code which diverges over time. Depends: osmo-bsc.git Iae058c35506bc25c9f4790889b89ac46aea664b6 (contains cherry-pick of bug fixed in osmo-bsc.git). Change-Id: I53ad3067623077b6a8737c2a0aecc8b46bf71a15
2021-05-31lchan_fsm: introduce lchan.modify.ch_mode_rate to allow tweakingNeels Hofmeyr1-0/+1
lchan->modify.info.ch_mode_rate should remain unchanged, it is the immutable request data. However, for VAMOS, we will want to automatically see that the chan_mode is chosen correctly. As a first step, place a mutable ch_mode_rate copy at lchan->modify.ch_mode_rate, i.e. not in .modify.info, but in .modify. Use that everywhere. This is a non-functional change, preparing for a subsequent patch that adds handling of VAMOS shadow lchans. Change-Id: I8a3daac0287f15a59d3688388bb13e55facb2cea
2021-05-31replace ts_*_for_each_lchan() with ts_for_n_lchans()Neels Hofmeyr1-30/+9
So far we have a couple of macros iterating a specific number of lchans, depending on dynamic timeslot state etc. With addition of VAMOS lchans, this would become more complex and bloated. Instead of separate iteration macros for each situation, only have one that takes a number of lchans as argument. That allows to more clearly pick the number of lchans, especially for non-trivial VAMOS scenarios. Related: SYS#5315 OS#4940 Change-Id: Ib2c6baf73a81ba371143ba5adc912aef6f79238d
2021-05-31add fields to reflect nr of lchans in ts structNeels Hofmeyr2-0/+8
So far the number of usable lchans is determined on-the-fly by the physical channel config. With VAMOS, this becomes more complex, namely determining whether the BTS is vamos capable. Instead of calling a function to determine the number of lchans for every use, rather place the number of valid lchans in int members of the timeslot struct, and initialize those during timeslot setup. Actual use of these new fields will follow in a subsequent patch, which introduces the ts_for_n_lchans() macro to replace current lchan iteration macros. Related: SYS#5315 OS#4940 Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
2021-05-31allow explixit TSC Set and TSC on chan activ / modif / assignmentNeels Hofmeyr2-1/+33
Activating / modifying to a VAMOS mode will require picking specific TSC Set / TSC. It is a bad idea to pick the TSC in each message encoding function, rather make this choice centrally. So far we pick the training sequence code to use based on the timeslot configuration, and this TSC is determined only upon encoding the RSL messages. Instead, pick the TSC to use upon the initial lchan activation / modification request; store this in the request structs and pass through the activation / modification code paths. For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ / modif request. Note that the TSC Set is not yet applied in this patch, it will be applied in upcoming VAMOS patches. The activ / modif request may pass -1 for tsc_set and/or tsc to indicate no specific choice of TSC Set and TSC, resulting in the same behavior as before this patch. For example, lchan->activate.info.tsc* may be passed as -1. The exact choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e. one level up (the .info sub-struct is considered as immutable input args). The lchan->activate.tsc* are the values actually encoded in RSL messages. After the ACK, the lchan->activate.tsc* is stored in lchan->tsc* to indicate the TSC actually in use. Same for modif. Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3 value. This is a weird discrepancy, odd choice made by the spec authors. For conformance with the spec wording, I decided to pass the TSC Set number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire format upon message encoding. So log messages and VTY output will indicate the first TSC Set as "1", but the first TSC as "0", as defined in 3GPP TS 45.002, even if that is somewhat weird. Related: SYS#5315 OS#4940 Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
2021-05-28gsm48_lchan2chan_desc(): expose TSC as paramNeels Hofmeyr1-2/+4
Expose the training sequence code used in the RSL Channel Description IE as an input parameter. So far the Channel Description IE is always composed with a training sequence code from gsm_ts_tsc(). For RSL commands enabling VAMOS mode, specific training sequence codes are required. So far, all callers still use gsm_ts_tsc(), making this a patch without any functional change. Upcoming patches will pass specific TSC as configured for VAMOS instead, in specific places. Related: SYS#5315 OS#4940 Change-Id: I49503a6f5d25bb3bc9a0505bd79ed1d5c4f50577
2021-05-28add chan_mode_to_chan_type()Neels Hofmeyr1-0/+1
Move the conversion from chan_mode to lchan type out of the lchan_select_by_chan_mode() function, so that the conversion can be used by other code paths, coming up in VAMOS patches. Related: SYS#5315 OS#4940 Change-Id: I296651ebadba81f8b3db0d9bb5b5377877a43677
2021-05-28RSL link: explicitly select rsl_link based on lchanNeels Hofmeyr2-2/+4
Prepare for VAMOS, where there will be secondary "shadow" lchans serving secondary MS on the same timeslots. For those, RSL messages will need to reflect a different stream ID aka TEI, via an rsl_link_vamos. Make sure that every code path that sends an RSL message for a specific lchan selects the RSL link via the new function rsl_chan_link(). When VAMOS is implemented, this function can select the proper RSL stream. Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not missing any uses of the RSL link, and clarifies the code. Related: SYS#5315 OS#4940 Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
2021-05-28hodec 2: do intra-cell congestion resolution by AssignmentNeels Hofmeyr1-0/+1
So far we do all channel reassignments by Handover Command. Since osmo-bsc now supports rassignment of ongoing voice calls, do intra-cell congestion resolution by Assignment Command. In effect, add support for expecting an Assignment Command in handover_test, and expect assignments instead of handovers for intra-cell congestion resolution test cases. Related: SYS#5330 OS#3277 Change-Id: Id56a890106b93fcee67ac9401b890e7b63bba421
2021-05-28assignment_fsm: allow assignment to a specific lchanNeels Hofmeyr2-0/+12
So far the assignment FSM always tried to satisfy the channel mode and rate by either re-using the current lchan or finding a new, unused lchan. For VAMOS however, we want to pick one specific lchan. Add target_lchan to struct assignment_request and skip all mode matching and lchan selection when a specific target_lchan is set. Related: SYS#5315 OS#4940 Change-Id: I71e0d4ff4746706e0be5266e4574d70ca432e3d7
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-16 06:23:08 +0000