aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-06-10log: assignment_fsm: drop newline from assignment_failNeels Hofmeyr1-1/+1
Drop terminating newline from an assignment_fail() call which causes an erratic line feed in logging. Change-Id: Ib56e1f6a45c7e2c235f8ef0c8dea7151481677ab
2021-06-10VTY: add lchan re-assignment commandNeels Hofmeyr4-0/+129
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-10VTY: add 'vamos-subslot' to activate a secondary lchanNeels Hofmeyr2-10/+27
Related: SYS#5315 OS#4940 Change-Id: If44b6bdb78046502eb0b66529ae190a955d9978c
2021-06-10VTY: 'show lchan': show that lchan is in VAMOS modeNeels Hofmeyr1-1/+4
Related: SYS#5315 OS#4940 Change-Id: I9f38712f941d60531526cc3395875655455909d9
2021-06-10RSL: rx and tx VAMOS Channel Number cbits for VAMOS lchansNeels Hofmeyr7-42/+83
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 Hofmeyr8-59/+183
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-10rsl_lchan_lookup(): add comment explaining ts_is_capable_of_pchan()Neels Hofmeyr1-0/+4
Change-Id: Ie3699db496cfb690ac9302ccd177cdd77dc57ebb
2021-06-10rsl_lchan_lookup(): turn cbits if-cascade into a switch()Neels Hofmeyr1-7/+28
There is some odd repetition of macros with all possible subslot indexes, but now we are using the defined macros instead of magic numbers, making it easier to see that it is correct. Also this allows trivially adding VAMOS cbits cases to the existing switch() in a subsequent patch. Change-Id: I4c6ce2f4ca999c19a58909b9adb849a3b8b6ffc8
2021-06-10update the lchan name to always reflect VAMOS shadownessNeels Hofmeyr7-12/+25
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 Hofmeyr5-12/+105
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-10RR Assignment for VAMOS: send TSC SetNeels Hofmeyr1-0/+6
We already send the TSC Set in the RSL Channel Activation, telling the BTS about the TSC Set. The MS needs to be instructed of the TSC Set in the RR Assignment Command. The first code to actually do an Assignment to a VAMOS activated lchan will follow in If006f5caaf83b07675f57e5665cfa79328da55e6. Change-Id: Ibf3b6d276fadf724c16a5225c03e96a27a056153
2021-06-10implement CHANnel ACTIVate to VAMOS modeNeels Hofmeyr5-17/+54
Related: SYS#5315 OS#4940 Change-Id: If3ac584e4223ef7656c7fedc3bf11df87e4309ec
2021-06-10add missing AMR config for RTP activation after mode modifyNeels Hofmeyr1-11/+19
Add function lchan_activate_set_ch_mode_rate_and_mr_config() and call it for both plain channel activation and after a mode modify that needs RTP activation. The AMR config was missing after Mode Modify. Related: SYS#5315 OS#4940 Change-Id: I842fe7a14a91d1ec123cb4a3f52afe34456c03e3
2021-06-10lchan_fsm: introduce lchan.activate.ch_mode_rate to allow tweakingNeels Hofmeyr5-13/+20
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-10vty-test: osmo-bsc.vty: test doc of lchan activate cmdNeels Hofmeyr1-0/+56
A subsequent patch will add to this VTY command, so let's first test the current status as a baseline. Change-Id: I6379e306fb8fa6ec227125c6cf14893d674e7596
2021-06-10add lchan->vamos.is_secondary flagNeels Hofmeyr2-2/+9
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-10vty: add lchan modify '(vamos|non-vamos)' commandNeels Hofmeyr2-28/+113
Change-Id: If44c3483d4d3d86f5822c5ad882aaeeaff27e3af
2021-06-10implement Channel Mode Modify to VAMOS modeNeels Hofmeyr4-6/+53
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-09allow mode modify when RTP stream is activeNeels Hofmeyr1-9/+0
Get rid of this artificial barrier, because Modify with active voice stream is supported since commit "lchan and assignment FSMs: make Channel Mode Modify more sane" d5cb0eb8fda3ade89c7b2e23a626b68dfda96f46 I4986844f839b1c9672c61d916eb3d33d0042d747 Change-Id: I25f4a881fa32a07f97d7d6e6b812f8afc699d951
2021-06-08hodec2: fix is_upgrade_to_tchf() for requirement ANeels Hofmeyr1-1/+1
Add missing REQUIREMENT_A_TCHF to form a full REQUIREMENT_TCHF_MASK. That allows detecting TCH/F -> TCH/H upgrades also in the requirement A flags, where we look for any viable lchan. Prepares for upcoming patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438 which implements TCH/H to TCH/F upgrades within the same cell. Related: SYS#5198 SYS#5365 Change-Id: Ic44615b314782423bab0ceef5810311776f92754
2021-06-08cosmetic prep: hodec2: move is_upgrade_to_tchf() further upNeels Hofmeyr1-7/+7
Preparation for Id40d1cf8b58410c7d4eb87407fe8b8106e352438 Related: SYS#5198 SYS#5365 Change-Id: I3fd0e257e033c573017ce62e3efc19b094acf73c
2021-06-08hodec2: add handover_test cases for upgrade of TCH/H -> TCH/FNeels Hofmeyr6-0/+210
Add test_amr_tch_h_and_afs_bias.ho_vty test_amr_tch_h_to_f_rxlev.ho_vty test_amr_tch_h_to_f_rxlev_congested.ho_vty test_amr_tch_h_to_f_rxqual.ho_vty test_amr_tch_h_to_f_rxqual_congested.ho_vty Related: SYS#5198 SYS#5365 Change-Id: Ib88f7e00d8bd77e2b02a7242a0fab4dd79333037
2021-06-07src/utils/meas_vis.c: fix bs_power -> bs_power_dbOliver Smith1-1/+1
Fix build error: meas_vis.c:196:16: error: 'struct gsm_meas_rep' has no member named 'bs_power'; did you mean 'bs_power_db'? Output the value in the same format as before the change that introduced this regression (dB / 2). We didn't catch this regression with jenkins because meas_vis is only built if libcdk is installed. Related: OS#5173 Fixes: d9b7aedb ("change bs_power to bs_power_db") Change-Id: I9ba9b491ccbde9aa14cfb14ecc551acb2bfd7674
2021-06-05fixup: pass tsc = -1 for previous default training sequence codeNeels Hofmeyr4-1/+13
An unintended change in default behavior was introduced in patch: "allow explixit TSC Set and TSC on chan activ / modif / assignment" Ic665125255d7354f5499d10dda1dd866ab243d24 c33eb8d56943b8981523754b081967e6ff5f245d Set tsc_set and tsc = -1 for all lchan_activate_info and assignment_request requests to actually yield the default behavior of selecting the TSC based on the timeslot cfg or the BSIC value. By setting tsc = 0 implicitly, the patch caused all requests to ask for tsc 0 instead of calling gsm_ts_tsc(). For a Channel Mode Modify in assignment_fsm, pass the lchan's current TSC to keep it unchanged. osmo-ttcn3-hacks Id67a949e0f61ec8123976eb8d336f04510c55c01 adds a test to verify the expected TSC in all of the activation, assignment and modify messages. Current osmo-bsc master fails, this patch fixes. Related: SYS#5315 OS#4940 Ic665125255d7354f5499d10dda1dd866ab243d24 Change-Id: If12df11511fe22ea167782f776736a1a9c484b1f
2021-06-05meas rep logging: use log_check_level() to skip a logging loopNeels Hofmeyr1-6/+7
A side effect is that the final cleanup part of that function is now always called, also when num_cell == 7. (Whether we should really clear that logging context at that place is a different question, out of scope here.) Change-Id: I71a402a0940857bbedbaf25d293429934706a83c
2021-06-05meas rep logging: replace a dozen DEBUGPC() with one DEBUGP()Neels Hofmeyr1-24/+45
Instead of calling DEBUGPC() over and over, compose a string using osmo_strbuf and then log it once. Rationale: a) DEBUGPC() is a bad idea for gsmtap_log, because each DEBUGPC() dispatches a separate gsmtap_log packet, fragmenting the actual log line in wireshark. b) DEBUGPC() is a bad idea because it checks the logging categories for every DEBUGPC() invocation. c) using a separate function with osmo_strbuf and OTC_SELECT, we can actually skip the entire string composition in case the DMEAS logging category is disabled, with a single logging category check. Change-Id: I4cb607ff43a1cb30408427d99d97c103776b6e69
2021-06-05change bs_power to bs_power_dbNeels Hofmeyr8-18/+21
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-05handover: apply meas report BS Power to RXLEV, fix ho oscillationNeels Hofmeyr2-10/+9
This fixes handover oscillation in the presence of power reduction on the downlink: apply the reduced power to the cell's RXLEV in order to not rate the current cell as weaker than it actually is. Related: SYS#5339 Change-Id: Ifcf59964b5e2d550d79e4ba14d90962808f79dae
2021-06-04Make interference measurement parameters configurableVadim Yanitskiy8-5/+139
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-04bts_uptime(): do not spam logs with 'OML link uptime unavailable'Vadim Yanitskiy1-3/+1
This message periodically appears in the logs with subsys=DNM and level=INFO for every disconnected BTS. I find this message useless and even annoying, so I propose to remove it in this patch. Change-Id: I7e2498cc61d311ca08585b2f1c49de021b17a5a1
2021-06-04VTY: fix NULL-pointer dereference in lchan_act_single()Vadim Yanitskiy1-0/+4
Without this guard, a command like this can crash osmo-bsc: OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr when timeslot 0 is configured as non-combined 'CCCH'. Change-Id: I0197a6a2595ff9dade58e37383d44d2df3b03288 CLoses: OS#5170
2021-06-04Use new stat item/ctr getter APIsPau Espin Pedrol19-181/+179
Generated with following and similar spatch snippets: """ @@ expression E1, E2; @@ - &E2->ctr[E1] + rate_ctr_group_get_ctr(E2, E1) """ Change-Id: I0b43f922a595d694ac0aeda80107ef9bf4e755e7
2021-06-04drop unused func decl gsm_lchan_as_pchan2chan_nr()Neels Hofmeyr1-2/+0
Change-Id: I1c14e72d4387767349723ec8948149841b45d85a
2021-06-02fix rc handling in channel_mode_from_lchan()Neels Hofmeyr1-3/+5
chan_mode_to_rsl_cmod_spd() may actually return negative on error. To be able to check for that, handle the returned value as a signed rc before assigning to the unsigned spd_ind. Related: SYS#5315 OS#4940 CID#236231 Change-Id: I52e13b24ce67e288ff32dbdaa1c1759089926f5c
2021-06-02fixup for Mode Modify TSCNeels Hofmeyr1-5/+1
Use lchan->modify.tsc in gsm48_lchan_modify(). The TSC is chosen exactly once upon LCHAN_EV_REQUEST_MODE_MODIFY (lchan_fsm.c), and that should be the only place calling gsm_ts_tsc(). All other mode modify code should just use the final lchan->modify.tsc. This fixes an error in patch: Ic665125255d7354f5499d10dda1dd866ab243d24 "allow explixit TSC Set and TSC on chan activ / modif / assignment" Thanks to coverity for actually detecting this mistake. Related: SYS#5315 OS#4940 CID#236233 Change-Id: I87ecf7d9266f37f4c775d029e277b614671a9401
2021-06-01Drop duplicated arfcn_range_encode.c available in libosmocoreNeels Hofmeyr11-783/+18
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 Hofmeyr4-9/+13
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-31ensure chan_mode comparisons in non-VAMOS modeNeels Hofmeyr9-25/+25
Both VAMOS- and non-VAMOS speech modes should result in indentical voice handling. So make sure that all chan_modes are converted to non-vamos before comparing / evaluating in switch statements. Change-Id: I791e7966b1f8eaa3299a8a46abeb313cf5136e0b
2021-05-31replace ts_*_for_each_lchan() with ts_for_n_lchans()Neels Hofmeyr10-54/+28
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 Hofmeyr5-16/+35
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-31VTY: dump TSC Set and TSC for each timeslotNeels Hofmeyr1-3/+7
This is particularly interesting for VAMOS multiplexes, but also gives more prominence to this rather central aspect of GSM RF. Related: SYS#5315 OS#4940 Change-Id: I7842ff89bece6d88387dae056e350529bae6fc38
2021-05-31allow explixit TSC Set and TSC on chan activ / modif / assignmentNeels Hofmeyr8-14/+81
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 Hofmeyr6-16/+21
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 Hofmeyr2-15/+25
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 Hofmeyr15-62/+69
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 Hofmeyr16-50/+172
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-28vty: actually trigger Assignment for 'assignment', not HONeels Hofmeyr1-20/+32
Related: SYS#5315 OS#4940 Change-Id: Iee11f1ae0533d7db844e68a5c4c48d0fe3e27297
2021-05-28assignment_fsm: allow assignment to a specific lchanNeels Hofmeyr3-19/+97
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
2021-05-27assignment_fsm: tweak state transitions (prep for reassignment)Neels Hofmeyr1-16/+29
It is better design to take state change actions in the onenter function, instead of triggering a state change and then calling lchan_mode_modify() or lchan_activate(). The reason is that in principle, any state change may cause error handling to abort and deallocate FSMs. This is also preparation for reassignment to a specific lchan in an upcoming patch. Related: SYS#5315 OS#4940 OS#3277 Change-Id: I9a2e7eefd4196b80671311e5dfd275893ec0e275
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 02:14:11 +0000