aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
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
2021-05-27AMR config cleanup step 3: generate AMR LV on msg compositionNeels Hofmeyr2-5/+5
Firstly, do not store the encoded AMR length-value bits in gsm_lchan->* before an activation/modify has actually succeeded. And secondly, do not store the AMR LV structure in struct gsm_lchan at all, but only generate the TLV exactly when a message is being composed. In gsm48_multirate_config(), generate the LV directly to a msgb instead of a static buffer first. gsm0408_test.c expected output verifies that the generated LV bytes remain unchanged. In lchan_mr_config(), introduce a target mr_conf argument, so that Chan Act and Mode Modify may generate the filtered AMR config to different locations (lchan->{activate,modify}.mr_conf_filtered). Only after receiving an ACK for Activate/Modify, set lchan->current_mr_conf from lchan->{activate,modify}.mr_conf_filtered. Use the properly scoped lchan->activate.mr_conf_filtered for Chan Act, lchan->modify.mr_conf_filtered for Mode Modify and new_lchan->current_mr_conf for Handover Command as appropriate. Related: SYS#5315 OS#4940 OS#3787 OS#3833 Change-Id: Ie57f9d0e3912632903d9740291225bfd1634ed47
2021-05-27move lchan->csd_mode into channel_mode_and_rateNeels Hofmeyr1-14/+14
The GSM48_CMODE_DATA_* rates are completely unused in OsmoBSC anyway, but there is some code in abis_rsl.c checking its value, and if we were to start using it that is the place where it should be. Related: SYS#5315 OS#4940 OS#3787 OS#3833 Change-Id: Ie0e065a5dca5f4a31d5d81e3528a539214a74170
2021-05-27eliminate lchan->rsl_cmodeNeels Hofmeyr1-1/+2
Related: SYS#5315 OS#4940 Change-Id: I1c167b22bb6638a929488d093bde0f1a5fb227ad
2021-05-27make sure channel mode and s15_s0 are updated only after an ACKNeels Hofmeyr1-19/+9
I noticed during testing that an lchan used as TCH/F in fact still had its channel mode set to Signalling -- because on Assignment, the Speech mode used to be placed in the *previous* lchan and the new lchan was never updated after the Activ ACK. This is unbearable confusion which I complained about numerous times, so far mostly for cosmetic reasons. But implementing re-assignment properly actually requires this to be cleaned up. Keep all volatile chan mode settings in lchan->activate.* or lchan->modify.*, and only update lchan->* members when an ACK has been received for those settings. So a failed request keeps a sane state. Make sure that those settings are in fact updated in the proper lchan, upon an ACK, so that subsequent re-assignment or mode-modify know the accurate lchan state. Related are upcoming patches that sort out the AMR multirate configuration in a similar fashion, see Iebac2dc26412d877e5364f90d6f2ed7a7952351e Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9 Ie57f9d0e3912632903d9740291225bfd1634ed47. Related: SYS#5315 OS#4940 OS#3787 OS#3833 Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
2021-05-27assignment_fsm: send BSSMAP response only after Assignment RequestNeels Hofmeyr1-0/+11
So far, only the MSC asked for Assignment via Assignment Request, which we answer with a BSSMAP Assignment Complete or Assignment Failure when done. When Assignment is triggered for any other reason (congestion resolution, VAMOS, VTY), we will not send any such messages to the MSC. Additional enum values will be added in subsequent commits: Id56a890106b93fcee67ac9401b890e7b63bba421 ASSIGN_FOR_CONGESTION_RESOLUTION If006f5caaf83b07675f57e5665cfa79328da55e6 ASSIGN_FOR_VTY Related: SYS#5315 OS#4940 Change-Id: Ie0cddbdb00abcec78e153f4ae6d04ce75080a111
2021-05-21lchan and assignment FSMs: make Channel Mode Modify more saneNeels Hofmeyr3-0/+28
The Channel Mode Modify procedure is currently implemented for changing a TCH lchan from signalling to voice mode. For that, however, it is re-using (abusing) the channel activation structs and state transitions, and thus always implies activating a voice stream when the mode modification is done. I will add a Channel Mode Modify to enable VAMOS mode soon, so I require separate structs and state transitions which also work on an lchan that already has a voice stream established: a struct lchan_modify_info and LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED. For the part where a Channel Mode Modify enables a voice stream after switching from signalling to speech mode, still use the channel activation code path, but only once the mode modification is done. General improvements: - To ask for a mode modification, emit an FSM event that ensures a mode modify only happens when the lchan state allows it. - The new lchan_modify_info struct reflects only those parts that have an effect during a mode modification (before the lchan_activate_info was fully populated, many values not having an effect). - More accurate logging, indicating "Mode Modify" instead of "Channel Activation" A TTCN3 test for the Channel Mode Modify procedure is added in Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both before and after this patch is applied. Related: SYS#4895 Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
2021-05-21cosmetic: rename lchan_activate_mode to lchan_activate_forNeels Hofmeyr1-3/+3
In subsequent patches, I will add enum lchan_modify_for and enum assignment_for, I prefer to have similar lchan_activate_for naming. Change-Id: Ia4420fcd1234dbee92e768e5a32eab13fba29ea9
2021-05-21cosmetic: rename FOR_* to ACTIVATE_FOR_*Neels Hofmeyr1-5/+5
Soon, there will also be enums with ASSIGNMENT_FOR_* and MODIFY_FOR_* naming. Add the ACTIVATE_ prefix to the existing enum to clarify. Change-Id: I12190d4d154a1da6a9ebc9a755ccc2fe382ff188
2021-05-21add missing arg braces in LOG_LCHAN macroNeels Hofmeyr1-2/+2
Change-Id: Ifd9f868636fda3298bb19c061d3ef194fd941fc3
2021-05-21log: show src file,line of lchan_set_last_errorNeels Hofmeyr1-2/+7
Change lchan_set_last_error() to macro so that the error log reflects where the error was encountered. Change-Id: I571fdf2d418c52d120215cf19e57a3c96d67af07
2021-05-04stats: add BTS uptime counterMichael Iedema2-0/+7
Change-Id: Ib17674bbe95e828cebff12de9e0b30f06447ef6c
2021-04-28gsm_lchan_name_compute with ctxNeels Hofmeyr1-1/+1
Use a talloc ctx directly without an intermediate static buffer. A subsequent patch will add a name tweak for VAMOS secondary lchans, so it felt appropriate to first clean this. Change-Id: Idb922605c15242a2cdc7c34668c845a179a15660
2021-04-27Lb: stop RESET FSM when sccp_user is unboundNeels Hofmeyr1-0/+1
A crash was reported in bssmap_le_tx_reset() sending a RESET with sccp_user == NULL. Looking at the issue I noticed that when the sccp_user is torn down, the RESET FSM should also be terminated. Add bssmap_reset_term_and_free() to the generic RESET FSM implementation and call from lb_stop() before sccp_user is set to NULL. Related: OS#5134 Change-Id: If412ef990fcdde8ff88098a5169e86f05cd1c7f0
2021-04-24SRVCC: Parse Last Used E-UTRAN PLMN Id in Handover RequestPau Espin Pedrol1-0/+2
Whenever SRVCC EUTRAN->GERAN is performed by the CN, it will set the Last Used E-UTRAN PLMN Id in order for the BSS to inform the MS about EUTRAN neighbors once the call is over. The last part (sending EUTRAN neighs) is already implemented, since same thing is done as per CSFB. However, we lacked the first part, where the EUTRAN PLMN Id is recorded for later use. Actually, in both cases, we end up building the list of neighbors without taking into accound the PLMN value (hence no filtering of configured neighs), but it only sends such a list if any PLMN was stored there, which means this patch is still necessary for a quick fallback to 4G after the call is over. Related: SYS#5337 Depends: libosmocore.git Change-Id I0e55e947b6fef6dad0cf1a6c16b781bef4cc76c5 Change-Id: Ia5008f11a4c36ef8085a2037d4abddd131086e6e
2021-04-23Revert "update neighbor ARFCNs on startup and config changes"Pau Espin Pedrol1-1/+0
This patch caused major breakage in my setup, with BSC printing at startup: "(bts=0,trx=0) Failed to generate System Information". And bts-trx printing all the time: "sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES value as SI3 is not available yet, fallback to 1" This reverts commit c1a5310a3ed75ff24dc2d6a48c09d8dfc89d944c. Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
2021-04-22update neighbor ARFCNs on startup and config changesNeels Hofmeyr1-0/+1
The effects of the neighbor configuration depend on the LAC, Cell Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that the neighbor ARFCN list in the System Information is updated. This may seem rather aggressive: updating the SI of all BTS if only one config item changed. But indeed even modifying one config item of one BTS may cause a change in the neighbor relations that many other BTS may have to the changed BTS. For example, if many BTS configure a 'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all of those other BTS need to update their neighbor ARFCNs. Also update the system information even before the BTS are connected and started up. The main benefit here is that the VTY 'show bts N' command then already lists the correct neighbor ARFCNs. In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg() spams the log with complaints that a message's dst == NULL. Still return an error rc in case a TRX is not connected, so that the CTRL command bts.N.send-new-system-informations accurately returns whether SI were actually sent to all TRXes. The desire to have the ARFCNs listed in the VTY before starting up BTSes came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1, which fixes a bug that is now much easier to verify being fixed. Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
2021-04-19Send EUTRAN neighs based on whether Common Id msg contained Last used ↵Pau Espin Pedrol3-9/+15
E-UTRAN PLMN ID From 3GPP TS 48.008 sec 3.1.30 "Common ID": """ If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports return to the last used PLMN after CS fallback, then it should send the COMMON ID message to the BSS including the Last used E-UTRAN PLMN ID information element if available at the MSC immediately following the successful SCCP connection setup. """ Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND", for field CSFB Indication, states: """ NOTE: This information element doesn't serve any useful purpose. MSCs should not send the information element unless it is required by the recipients (due to the need to interwork with older versions of the protocol). It is expected that in future versions of the present document, this information element will be deleted from this message. """ Hence, build up the EUTRAN neighbor list based on whether we received the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should probably filter the list while populating it based on the received IE. This change will also allow reusing same mechanism for SRVCC EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST. Related: SYS#5337 Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 22:03:07 +0000