aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/handover_fsm.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-04fix extraneous newlines in ho_fail() invocationsneels/2021q4Neels Hofmeyr1-3/+3
The ho_fail() macro includes a newline, so the callers should not add one. Fix these cases where the extra '\n' fragments the logged message. Related: SYS#5839 Change-Id: Ifdbce98be70c1aa127ae008d7a77b9795fd250d3
2022-03-04inter-BSC incoming HO: store Codec List (MSC Preferred)Neels Hofmeyr1-0/+17
So far we completely ignore the codec list from the MSC in Handover Request messages. This leads to error messages in subsequent handovers because there is no Codec List stored on the conn: DHODEC ERROR handover_decision_2.c:390 [...] No Speech Codec List present, accepting all codecs Besides the error log, in hodec2 we may subsequently take bogus or unexpected codec decisions, ignoring the MSC's choice of codecs, or in the worst case picking an unsupported codec. This also has implications on what type of lchan we choose for handover target in hodec2: say, if no half rate codec is supported as per the MSC's request, we normally avoid handover to a TCH/H, etc. Intra-BSC HO after an Inter-BSC incoming HO is the only case where this problem occurs, in every other scenario there is an Assignment Request from the MSC, from which we properly store the MSC's codec list. 3GPP TS 48.008 does indicate that on AoIP this codec list shall be included. So reject HO Request with missing Codec List, as we already do for Assignment Request on AoIP. This makes TTCN3 BSC_Tests for inter-BSC incoming HO fail, because our tests so far omit the Codec List (MSC Preferred) on AoIP. The related fix of the tests is If06de9c9b43d79f749447a4e2a340176eef75c79. Related: SYS#5839 Depends: If06de9c9b43d79f749447a4e2a340176eef75c79 (osmo-ttcn3-hacks) Change-Id: I117cc29d6d11db77d160de654f43f5993db6ee21
2022-02-22fix inter-BSC-in handover encryptionNeels Hofmeyr1-7/+21
In the field we saw Handover Requests without any Chosen Encryption Algorithm IE, and osmo-bsc completely failed on those. This made me understand my mistake from when I wrote this handover code. So far, from a BSSMAP Handover Request, we (I) used only the Chosen Encryption Algorithm IE to pick the encryption to use on the target lchan. That is very wrong. Instead, figure out the intersection of permitted algorithms MSC & BSC, and pick the best of those. Which means, actually, completely ignore the Chosen Encryption Algorithm IE. In the message, the permitted algorithms are passed as a bitmask. The current code using gsm0808_dec_encrypt_info() passes this on as an array. In order to select_best_cipher(), I could convert that array back to a bitmask. Instead pass the bitmask on from message decoding alongside the struct gsm0808_encrypt_info in req->ei_as_bitmask. In handover_end(), change the condition so that we can also pass HO_RESULT_FAIL_RR_HO_FAIL to emit a Handover Failure. Related: SYS#5839 Change-Id: Iffedc981b60d309ed2e5decd5efedee07a757b53
2021-11-06implement incoming_intra_bsc_ho:* rate countersNeels Hofmeyr1-0/+5
We have lots of counters for intra-BSC handover *away from* a given BTS, but still missing are counters indicating how many handovers *targeted* a given BTS. Also count incoming HO. Related: SYS#4878 Related: Iba229313d73fa20266f6d4eac5820579fb14c604 (osmo-ttcn3-hacks) Change-Id: Id9f2c6e2865ebe680879018fff08d283ce24c983
2021-11-06cosmetic tweaks on handover counting codeNeels Hofmeyr1-3/+25
I was a bit confused that grep did not find HO counters being used, so let's add some comments to better explain and provide a grep hook. Related: SYS#4878 Change-Id: I242de13e657286e09428a8ca6e583d8b5155faa2
2021-11-06for linter: s/while(0)/while (0)Neels Hofmeyr1-5/+5
Change-Id: Ib422e7d1a7d543dcd8738581839ce55bb8fc29d2
2021-08-30move BSC level stats and rate counters to new bsc_stats.[hc]Neels Hofmeyr1-0/+1
Instead of having static const structs in header files (which end up duplicated in each and every compile unit!), have one .c file with the rate_ctr and stat_item descriptions. Related: SYS#5542 Change-Id: I8fd6380b5ae8ed2d3347e7cfbf674c30b6841ed9
2021-07-15ensure trigger_ho() returns zero only when HO or AS was indeed triggeredNeels Hofmeyr1-2/+2
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-06-22support A5/4 in inter-BSC HandoverNeels Hofmeyr1-3/+19
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-17Introduce counters to track SRVCC proceduresPau Espin Pedrol1-0/+9
Related: SYS#5337 Change-Id: I5c20da56d465dbcf4366130394f7c42635a24cc7
2021-06-17Introduce VTY command to disable srvcc fast-return on target BTSPau Espin Pedrol1-3/+4
Related: SYS#5337 Change-Id: I2ac91b5dffc9b6de60576aabe21a15f24fea38cb
2021-06-04Use new stat item/ctr getter APIsPau Espin Pedrol1-4/+4
Generated with following and similar spatch snippets: """ @@ expression E1, E2; @@ - &E2->ctr[E1] + rate_ctr_group_get_ctr(E2, E1) """ Change-Id: I0b43f922a595d694ac0aeda80107ef9bf4e755e7
2021-05-31ensure chan_mode comparisons in non-VAMOS modeNeels Hofmeyr1-1/+1
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-27make sure channel mode and s15_s0 are updated only after an ACKNeels Hofmeyr1-8/+8
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-21cosmetic: rename FOR_* to ACTIVATE_FOR_*Neels Hofmeyr1-2/+2
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-04-24SRVCC: Parse Last Used E-UTRAN PLMN Id in Handover RequestPau Espin Pedrol1-0/+36
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-19Send EUTRAN neighs based on whether Common Id msg contained Last used ↵Pau Espin Pedrol1-3/+5
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
2021-03-24fix/refactor neighbor configNeels Hofmeyr1-10/+7
The neighbor configuration storage is fundamentally broken: it requires all local cells to be configured before being able to list them as neighbors of each other. Upon config write-back, the neighbor config however is placed back inline with the other config, and hence a written-out neighbor config no longer works on program restart. The cause of this problem is that the config is stored as explicit pointers between local cells (struct gsm_bts), which of course requires the pointer to exist before being able to reference it. Instead, store the actual configuration that the user entered as-is, without pointers or references to objects that need to be ready. Resolve the neighbors every time a neighbor is needed. Hence the user may enter any config at any place in the config file, even non-working config (like a BTS number that doesn't exist), and the relation to actual local or remote neighbor cells is made at runtime. Abort program startup if the initial neighbor configuration contains errors. Related: OS#5018 Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
2021-03-24refactor handover penalty timersNeels Hofmeyr1-0/+1
So far the list of penalty timers was stored for an opaque target pointer. That was either a gsm_bts pointer for a local BTS, or a cell identifier list pointer for a remote-BSS cell. Reasons to refactor penalty timers: - The cell identifier list pointer came from the neighbor configuration storage, but the way cell neighbor config is stored will change in a subsequent patch. There will be no more cell identifier lists there. - Storing object pointers is inherently unsafe -- if an object gets removed and another gets allocated, the penalty timer could theoretically remain in force for an unrelated object. Rather store penalty timers for specific Cell IDs. Since remote-BSS neighbors can be requested by a cell identifier *list*, use a gsm0808_cell_id_list2 as key in the list of penalty timers. Fix handover_test.c: have different CI for each local BTS. So far it was the same LAC+CI for all BTSes, which now would make the test fail, because any penalty timer would appear to apply to all local cells. Related: OS#5018 Change-Id: I72dd6226a6d69c3f653a3174c6f55bf4eecc6885
2021-02-05lchan activation: indicate whether TA is knownNeels Hofmeyr1-0/+7
On lchan activation, we already know the Timing Advance in most situations: from the Channel Request RACH, or from a previous lchan in the same cell. Place this information in lchan->activate.info.ta. So far, the lchan->last_ta (until recently called rqd_ta) was used to store the initial TA for channel activation -- move the initial TA to lchan->activate.info.ta, for proper scoping. Only an inter-cell handover does not yet know a Timing Advance (until the Handover Detection RACH is received), so indicate activate.info.ta_known = false for that case. If ta_known is false, do not include an Access Delay IE in the Channel Activation message, ensuring that the BTS does not use an arbitrary TA that is likely inaccurate. The effect for OsmoBTS is that we will *not* start the downlink SACCH on channel activation for inter-cell handover, but will wait for a HO RACH first, and then use the correct TA when enabling downlink SACCH. Related: OS#4008 SYS#5192 Change-Id: I986bf93e8acd6aef7eaf63ac962480b680aa894f
2021-02-03BS-11: Send proprietary MRPCI message after assignment + HO completeHarald Welte1-0/+9
This is a non-standard RSL message that must be sent after each traffic channel has been established. Without it, any voice call will be disconnected within seconds. This is a hack; we need to store the subscribers classmark2 value and use it here. Change-Id: I6cb6d25e405aa888c4df4022d897330a6af9e946 Related: OS#2389
2020-10-09LCS: implement the bulk of Location ServicesNeels Hofmeyr1-0/+5
Depends: I4d7302a4853518916b6b425e710c10568eb2ffe5 (libosmocore) Change-Id: I28314ba97df86a118497e9b2770e2e6e2484e872
2020-08-31handover_fsm: signal Clear from gscon, for proper HO result countsNeels Hofmeyr1-0/+2
An inter-BSC-OUT handover ends with a Clear Command, which HO_OUT_ST_WAIT_CLEAR waits for. Actually tell the handover_fsm.c about an incoming Clear Command, so that the inter-BSC-OUT success can be counted. Similarly, count failing handover results for an unexpected Clear Command from the MSC. Related: OS#4736 Change-Id: I0c489838a99f930e2104619ca745191d2a736f1b
2020-08-31add {BTS,BSC}_CTR_INTER_BSC_HO_OUT_FAILED for RR HO FailureNeels Hofmeyr1-0/+4
So far, during inter-BSC outgoing handover, when receiving an RR Handover Failure from the MS, it would be counted as 'error'. Instead, add the 'failed' counter like for all other HO types. It may make sense to omit the 'failed' counter for inter-BSC *incoming* handover, because then we won't receive an RR Handover Failure message. I probably got those two mixed up during initial development. Related: OS#4736 Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471
2020-08-31fix HO inter-BSC-IN target bts for countersNeels Hofmeyr1-0/+5
Related: OS#4736 Change-Id: Id38c69695c4ab93733571c0c288a2d5c10624ace
2020-08-31fix 'handover:*' counters: remove bogus incrementsNeels Hofmeyr1-10/+8
To handle cases of unknown handover type (like failure to find the target cell), return -1 as counter code; treat -1 as skipping in ho_count_bsc() and ho_count_bts(). The handover:* counters indicate overall counts, without knowing whether inter- or intra-BSC, or whether the target ARFCN even exists. So they need to be counted separately, and must not serve as fallback category in result_counter_bsc() and result_counter_bts(). Related: OS#4736 Change-Id: Ie311e599d7bd35d33cf471c6c63e649246e8396a
2020-08-30fix 'handover:*' counters: add missing / move incrementsNeels Hofmeyr1-0/+4
Move initial 'handover:attempted' counts from bsc_subscr_conn_fsm.c to handover_fsm.c, where all the other counters are handled. Add missing increments for the overall 'handover:*' counts. Related: OS#4736 Change-Id: I783bdedafc0eb8f2df9ea100792846fecc7ccbf7
2020-08-30ho counters: count invalid target cell as 'error', not 'no_channel'Neels Hofmeyr1-1/+1
Related: OS#4736 Change-Id: If6d6b7262536831ebb2b638efe521dd5a8153cdb
2020-08-30cosmetic: dissolve error-goto with single source in handover_start()Neels Hofmeyr1-5/+4
Change-Id: I9c7d10c36f3f868100c1aa2d0433ceed74161175
2020-08-30cosmetic: use local var in handover_start_intra_bsc()Neels Hofmeyr1-1/+1
Change-Id: I3ae079a2aa9ff3980acd5a212cb287a96a1dc0ed
2020-08-24Add bts counters to count BTS events where we don't have a btsDaniel Willmann1-0/+2
In some (error-) cases we might be unable to determine which BTS to use when counting handover events. We don't want to loose these events because then ctr(bsc) == sum(ctr(bsc->bts)) would not be true anymore. Those events are now counted by a counter in struct gsm_network which uses an index that is out of range for regular BTS (65536). Change-Id: Ic0f3edd5dc014c4eac5e8423133633a3e5d4c13e Related: SYS#4877
2020-08-24Count intra-cell and intra-bsc handover separatelyDaniel Willmann1-14/+19
Currently the counters don't distinguish between intra-cell and intra-bsc handover. Add _CTR_INTRA_CELL_HO_ and _CTR_INTRA_BSC_HO_ counters to track intra-cell/bsc handover separately. Change-Id: I3a1195640b99813036c9f1426ee5f07548e26547 Related: SYS#4877
2020-08-24Count handover per BTS as well as per BSCDaniel Willmann1-24/+81
Our current handover counters only count success/failures per BSC. It would be nice to also count which BTS is part of a (successful/failed) handover. This patch duplicates the BSC counters for the BTS and changes the ho_count and related macros to also count per BTS. If a BTS is NULL (when conn->lchan is NULL) counting for the BTS is ignored. Change-Id: I025ef14e2cfd2eea8880212c9406372ce0bf9296 Related: SYS#4877
2020-07-18Move struct gsm_bts: gsm_data.* => bts.*Pau Espin Pedrol1-0/+1
Place all code related to the object into the related file. Having all the data model in one file made sense in early stage of development to make progress quickly, but nowadays it hurts more than helps, due to constantly growing size and more and more bits being added to the model, gaining in complexity. Currently, having lots of different objects mixed up in gsm_data.h is a hole of despair, where nobody can make any sense were to properly put new stuff in, ending up with functions related to same object in different files or with wrong prefixes, declarations of non-existing functions, etc. because people cannot make up their mind on strict relation to objects in the data model. Splitting them in files really helps finding code operating on a specific object and helping with logically splitting in the future. Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
2020-05-11stats: Add counters for Tx BSSMAP messages.Alexander Chemeris1-0/+1
We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2019-11-13Fix some typosMartin Hauke1-1/+1
Fix typos and common misspellings in code comments and in the manual. Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-08-13neighbor config: allow re-using ARFCN+BSIC pairsNeels Hofmeyr1-10/+22
Fix neighbor config to match OsmoBSC manual: implement the plan for neighbor configuration that was so far only described in the manual without actually being in operation. This first allows re-using ARFCN+BSIC pairs in and across BSS. So far the handover_start() code always looked for handover target cells across *all* local cells, even if they were not listed as neighbors to a source cell. Imply all cells as neighbors only as long as there are no explicit neighbors configured. As soon as the first 'neighbor' line appears in a 'bts' config, only the listed neighbors are regarded as handover target cells. (The 'neighbor-list' commands are not related to this, only the relatively new 'neighbor (bts|lac|cgi|...)' commands affect actual handover procedures.) TTCN3 tests TC_ho_neighbor_config_1 thru _7 play through the various aspects of neighbor configuration: both the legacy implicit all-cells-are-neighbors as well as allowing only explicit neighbors by config. Related: OS#4056 Related: osmo-ttcn3-hacks Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc Change-Id: I29bca59ab232eddc74e0d4698efb9c9992443983
2019-07-13silence error for "invalid enum handover_scope value: none"Neels Hofmeyr1-0/+1
If no target cell got selected in a handover attempt, enum value NO_HANDOVER is used. In that case, do not log a lot of errors saying "invalid enum handover_scope value: none" -- they are misleading. Change-Id: I98e748bea58ebb02812b6aaa6431c7d4b813242d
2019-07-13comment and VTY doc tweaksNeels Hofmeyr1-1/+2
Clarify some in-code comments. Fix descriptions of some handover timers, which still talked of "MO" and "MT" handover -- which we now call "inter-BSC out" or "inter-BSC in" instead. Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
2019-05-07handover_fsm.c: fix: prevent possible buffer overflowVadim Yanitskiy1-0/+1
Change-Id: If51f8f82d3b2462cb7d7a531fe4411509344842b Fixes: CID#197643
2019-05-05fix inter-BSC-HO-incoming for AoIP (1/2)Neels Hofmeyr1-82/+101
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is done establishing. For AoIP, the local RTP address towards the MSC already needs to be known before the Handover Request Acknowledge is sent, so the AoIP Transport Layer Address IE can be included. This patch only modifies the handover FSM, a subsequent patch adds the IE. Change-Id: I00c18b78573386145af71c4b39f7f22aec24579b
2019-05-03assignment_fsm: Properly support assigning signalling mode TCH/xSylvain Munaut1-2/+3
To support the 3 possible preferences, the changes needed were: - Replace 'full_rate' bool with a 3 option enum to represent the channels types for signalling - Switch from _pref/_alt to using an array sorted in preference order Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3, reverted because the change broke voice calls. Re-submitting with the fix: don't forget to set conn->assignment.requires_voice_stream. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
2019-04-30move mgw endpoint FSM to osmo-mgw.gitNeels Hofmeyr1-4/+5
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example I92a9944acc96398acd6649f9c3c5badec5dd6dcc. Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
2019-04-23use libosmocore osmo_tdefNeels Hofmeyr1-5/+5
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API and use libosmocore's osmo_tdef* API instead. The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be able to use it in osmo-msc for inter-MSC handover. When adding osmo_tdef, the new concept of timer groups was added to the API. It would make sense to apply group names here as well, but do not modify the VTY configuration for timers. The future might bring separate groups (or not). Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore) Change-Id: I66674a5d8403d820038762888c846bae10ceac58
2019-04-19Revert "fix inter-BSC-HO-incoming for AoIP (1/2)"Daniel Willmann1-102/+81
This reverts commit 94c9324fe07cd0ba1277278270c8979d949e49ec. Multiple ttcn3 handover tests were broken due to this commit. Let's merge this once all the other commits pertaining to that fix can be merged as well. Fixes: OS#3942 Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
2019-04-08fix inter-BSC-HO-incoming for AoIP (1/2)Neels Hofmeyr1-81/+102
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is done establishing. For AoIP, the local RTP address towards the MSC already needs to be known before the Handover Request Acknowledge is sent, so the AoIP Transport Layer Address IE can be included. This patch only modifies the handover FSM, a subsequent patch adds the IE. Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
2019-04-08Handover Request: also parse Chosen Algorithm IE, pass to lchan activationNeels Hofmeyr1-0/+29
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the Handover Request message. Actually parse this Chosen Encryption Algorithm IE. Place the chosen algorithm and the CK into lchan_activate_info->encr so that the new lchan will use the same ciphering on this new BSS as it did on the old BSS. Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
2019-04-08lchan activation: add explicit encryption info to activationNeels Hofmeyr1-0/+1
For intra-BSC handover, the previous encryption is copied from the old lchan, which of course is not available during inter-BSC handover. Hence the lchan activation info needs to include an explicit encryption information, and we must not rely on the presence of the previous lchan to copy encryption information from. Add struct lchan_activate_info.encr to allow passing encryption info through lchan_activate() without requiring a previous struct gsm_lchan to be present. Instead of copying from the old lchan, always copy encryption info to lchan_activate_info, and during activation, just before sending the Channel Activation, copy the lchan_activate_info.encr to the new lchan. This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which obtains the encryption information from an intra-BSC-incoming Handover Request message. Related: OS#3842 Related: I5b269f50bd2092516bfdf87746196983d3ac49d1 Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
2019-03-14Revert "assignment_fsm: Properly support assigning signalling mode TCH/x"Neels Hofmeyr1-3/+2
This commit breaks voice channel assignment. It results in the Assignment Complete sent to the MSC for a voice lchan lacking AoIP Transport Layer Address, Speech Version and Speech Codec. Hence the MSC cannot complete the Assignment for a voice call. Let's revisit this patch, test thoroughly and re-merge later. This reverts commit 4d3a21269b25e7164a94fa8ce3ad67ff80904aee. Reason for revert: <INSERT REASONING HERE> Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
2019-03-14assignment_fsm: Properly support assigning signalling mode TCH/xSylvain Munaut1-2/+3
To support the 3 possible preferences, the changes needed were: - Replace 'full_rate' bool with a 3 option enum to represent the channels types for signalling - Switch from _pref/_alt to using an array sorted in preference order Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 12:11:27 +0000