cellular-infrastructure
/
osmo-bsc
mirror of https://gerrit.osmocom.org/osmo-bsc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-bsc/src/osmo-bsc/handover_logic.c

330 lines
10 KiB
C
Raw Normal View History

[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
/* Handover Logic for Inter-BTS (Intra-BSC) Handover. This does not
* actually implement the handover algorithm/decision, but executes a
* handover decision */
/* (C) 2009 by Harald Welte <laforge@gnumonks.org>
*
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* GNU Affero General Public License for more details.
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
*
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <time.h>
#include <netinet/in.h>
src: use new library libosmogsm and new path to headers in libosmocore libosmogsm is a new library that is distributed in the libosmocore. Now, openbsc depends on it. This patch gets openbsc with this change. This patch also rewrites all include path to the new osmocom/[gsm|core] Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
2011-03-22 15:47:59 +00:00
#include <osmocom/core/msgb.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/debug.h>
#include <osmocom/bsc/gsm_data.h>
src: use new library libosmogsm and new path to headers in libosmocore libosmogsm is a new library that is distributed in the libosmocore. Now, openbsc depends on it. This patch gets openbsc with this change. This patch also rewrites all include path to the new osmocom/[gsm|core] Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
2011-03-22 15:47:59 +00:00
#include <osmocom/gsm/gsm_utils.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/abis_rsl.h>
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
#include <osmocom/bsc/lchan_select.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/signal.h>
src: use new library libosmogsm and new path to headers in libosmocore libosmogsm is a new library that is distributed in the libosmocore. Now, openbsc depends on it. This patch gets openbsc with this change. This patch also rewrites all include path to the new osmocom/[gsm|core] Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
2011-03-22 15:47:59 +00:00
#include <osmocom/core/talloc.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/bsc_subscriber.h>
rename gsm_04_08_utils.[hc] to gsm_04_08_rr "utils" suggests thin helpers to aid using a proper API, while this .c file actually *is* the proper RR API. Rename from "utils" to "rr". Change-Id: I0ffff63d57f03cb324df8e40e41caea5b55a2c85
2018-07-24 14:18:15 +00:00
#include <osmocom/bsc/gsm_04_08_rr.h>
HO: add new_lchan_type arg to bsc_handover_start() Upcoming handover_decision_2 will want to be able to handover to a differing TCH type, hence add a parameter to bsc_handover_start(); adjust current callers to pass the old lchan type. Tweak the 'bts' argument to 'new_bts'. Change-Id: I4478ebcaada00897cc38c5a299e07661139ed3c5
2018-02-12 15:56:41 +00:00
#include <osmocom/bsc/handover.h>
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
#include <osmocom/bsc/handover_cfg.h>
introduce an osmo_fsm for gsm_subscriber_connection In the current implementation of osmo-bsc, the subscriber connection is not handled (very) statefully. However, there is some state keeping in the code that handles the mgcp connection, but there are still to much loose ends which allow odd situations to happen, which then lead severe error situations (see also closes tags at the end) This commit adds a number of improvements to fix those problems. - Use an osmo-fsm to control the gsm_subscriber_connection state and make sure that certain operations can only take place at certain states (e.g let connection oriented SCCP traffic only pass when an SCCP connection actually exists. Remove the old osmo_bsc_mgcp.c code. Use the recently developed MGCP client FSM to handle the MGCP connections. Also make sure that stuff that already works does not break. This in particular refers to the internal handover capability and the respective unit-tests. See also OS#2823, OS#2768 and OS#2898 - Fix logic to permit assignment to a signalling channel. (OS#2762) - Introduce T993210 to release lchan + subscr_conn if MSC fails to respond The GSM specs don't have an explicit timer for this, so let's introdcue a custom timer (hence starting with 99). This timeout catches the following situation: * we send a SCCP CR with COMPL_L3_INFO from the MS to the MSC, * the MSC doesn't respond (e.g. SCCP routing failure, program down, ...) The MS is supposed to timeout with T3210, 3220 or 3230. But the BSC shouldn't trust the MS but have some timer on its own. SCCP would have a timer T(conn est), but that one is specified to be 1-2min and hence rather long. See also: OS#2775 - Terminate bsc_subscr_conn_fsm on SCCP N-DISC.ind from MSC If the MSC is disconnecting the SCCP channel, we must terminate the FSM which in turn will release all lchan's and other state. This makes TC_chan_rel_hard_rlsd pass, see also OS#2731 As a side-effect, this fixes TC_chan_act_ack_est_ind_refused(), where the MSC is answering with CREF to our CR/COMPL_L3. - Release subscriber connection on RLL RELEASE IND of SAPI0 on main DCCH The subscriber connection isn't really useful for anything after the SAPI0 main signalling link has been released. We could try to re-establish, but our best option is probably simply releasing the subscriber_conn and anything related to it. This will make TC_chan_rel_rll_rel_ind pass, see also OS#2730 This commit has been tested using the BSC_Tests TTCN3 testsuit and the following tests were passed: TC_chan_act_noreply TC_chan_act_ack_noest TC_chan_act_ack_est_ind_noreply TC_chan_act_ack_est_ind_refused TC_chan_act_nack TC_chan_exhaustion TC_ctrl TC_chan_rel_conn_fail TC_chan_rel_hard_clear TC_chan_rel_hard_rlsd TC_chan_rel_a_reset TC_rll_est_ind_inact_lchan TC_rll_est_ind_inval_sapi1 TC_rll_est_ind_inval_sapi3 TC_rll_est_ind_inval_sacch TC_assignment_cic_only TC_assignment_csd TC_assignment_ctm TC_assignment_fr_a5_0 TC_assignment_fr_a5_1_codec_missing TC_assignment_fr_a5_1 TC_assignment_fr_a5_3 TC_assignment_fr_a5_4 TC_paging_imsi_nochan TC_paging_tmsi_nochan TC_paging_tmsi_any TC_paging_tmsi_sdcch TC_paging_tmsi_tch_f TC_paging_tmsi_tch_hf TC_paging_imsi_nochan_cgi TC_paging_imsi_nochan_lac_ci TC_paging_imsi_nochan_ci TC_paging_imsi_nochan_lai TC_paging_imsi_nochan_lac TC_paging_imsi_nochan_all TC_paging_imsi_nochan_plmn_lac_rnc TC_paging_imsi_nochan_rnc TC_paging_imsi_nochan_lac_rnc TC_paging_imsi_nochan_lacs TC_paging_imsi_nochan_lacs_empty TC_paging_imsi_a_reset TC_paging_counter TC_rsl_drop_counter TC_classmark TC_unsol_ass_fail TC_unsol_ass_compl TC_unsol_ho_fail TC_err_82_short_msg TC_ho_int Authors: Harald Welte <laforge@gnumonks.org> Philipp Maier <pmaier@sysmocom.de> Neels Hofmeyr <neels@hofmeyr.de> Closes: OS#2730 Closes: OS#2731 Closes: OS#2762 Closes: OS#2768 Closes: OS#2775 Closes: OS#2823 Closes: OS#2898 Closes: OS#2936 Change-Id: I68286d26e2014048b054f39ef29c35fef420cc97
2018-01-28 02:04:16 +00:00
#include <osmocom/bsc/bsc_subscr_conn_fsm.h>
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
#include <osmocom/bsc/neighbor_ident.h>
#include <osmocom/bsc/abis_nm.h>
Move struct gsm_bts: gsm_data.* => bts.* 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-07-15 18:53:16 +00:00
#include <osmocom/bsc/bts.h>
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
#include <osmocom/gsm/gsm0808.h>
#include <osmocom/gsm/gsm0808_utils.h>
const struct value_string handover_scope_names[] = {
{ HO_NO_HANDOVER, "HO-none" },
{ HO_INTRA_CELL, "AS" },
{ HO_INTRA_BSC, "HO-intraBSC" },
{ HO_INTER_BSC_OUT, "HO-interBSC-Out" },
{ HO_INTER_BSC_IN, "HO-interBSC-In" },
{ HO_SCOPE_ALL, "HO-any" },
{}
};
const struct value_string handover_result_names[] = {
{ HO_RESULT_OK, "Complete" },
{ HO_RESULT_FAIL_NO_CHANNEL, "Failure (no channel could be allocated)" },
{ HO_RESULT_FAIL_RR_HO_FAIL, "Failure (MS sent RR Handover Failure)" },
{ HO_RESULT_FAIL_TIMEOUT, "Failure (timeout)" },
{ HO_RESULT_CONN_RELEASE, "Connection released" },
{ HO_RESULT_ERROR, "Failure" },
{}
};
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
static LLIST_HEAD(handover_decision_callbacks);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
void handover_decision_callbacks_register(struct handover_decision_callbacks *hdc)
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
{
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
llist_add_tail(&hdc->entry, &handover_decision_callbacks);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
}
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
struct handover_decision_callbacks *handover_decision_callbacks_get(int hodec_id)
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
{
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
struct handover_decision_callbacks *hdc;
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
llist_for_each_entry(hdc, &handover_decision_callbacks, entry) {
if (hdc->hodec_id == hodec_id)
return hdc;
logging: introduce log levels at caller site This introduces a new LOGP() macro together with LOGL_* definition to support multiple log levels (severities) throughout the codebase. Please note that the actual logging system does not use them yet, in this patch we simply introduce the new macros at the caller site.
2009-12-17 22:10:46 +00:00
}
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
return NULL;
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
}
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
static void ho_meas_rep(struct gsm_meas_rep *mr)
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
{
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
struct handover_decision_callbacks *hdc;
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
enum hodec_id hodec_id = ho_get_algorithm(mr->lchan->ts->trx->bts->ho);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
hdc = handover_decision_callbacks_get(hodec_id);
if (!hdc || !hdc->on_measurement_report)
return;
hdc->on_measurement_report(mr);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
}
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
/* Count ongoing handovers within the given BTS.
* ho_scopes is an OR'd combination of enum handover_scope values to include in the count. */
int bts_handover_count(struct gsm_bts *bts, int ho_scopes)
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
{
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
struct gsm_bts_trx *trx;
int count = 0;
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
llist_for_each_entry(trx, &bts->trx_list, list) {
int i;
for (i = 0; i < ARRAY_SIZE(trx->ts); i++) {
struct gsm_bts_trx_ts *ts = &trx->ts[i];
struct gsm_lchan *lchan;
/* skip administratively deactivated timeslots */
if (!nm_is_running(&ts->mo.nm_state))
continue;
replace ts_*_for_each_lchan() with ts_for_n_lchans() 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-19 00:28:26 +00:00
ts_for_n_lchans(lchan, ts, ts->max_lchans_possible) {
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
if (!lchan->conn)
continue;
if (!lchan->conn->ho.fi)
continue;
if (lchan->conn->ho.scope & ho_scopes)
count++;
}
}
logging: introduce log levels at caller site This introduces a new LOGP() macro together with LOGL_* definition to support multiple log levels (severities) throughout the codebase. Please note that the actual logging system does not use them yet, in this patch we simply introduce the new macros at the caller site.
2009-12-17 22:10:46 +00:00
}
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
return count;
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
}
fix/refactor neighbor config 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-09 16:11:45 +00:00
/* Find out a handover target cell for the given arfcn_bsic,
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
* and make sure there are no ambiguous matches.
* Given a source BTS and a target ARFCN+BSIC, find which cell is the right handover target.
* ARFCN+BSIC may be re-used within and/or across BSS, so make sure that only those cells that are explicitly
* listed as neighbor of the source cell are viable handover targets.
* The (legacy) default configuration is that, when no explicit neighbors are listed, that all local cells are
* neighbors, in which case each ARFCN+BSIC must exist at most once.
* If there is more than one viable handover target cell found for the given ARFCN+BSIC, that constitutes a
* configuration error and should not result in handover, so that the system's misconfiguration is more likely
* to be found.
*/
int find_handover_target_cell(struct gsm_bts **local_target_cell_p,
fix/refactor neighbor config 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-09 16:11:45 +00:00
struct gsm0808_cell_id_list2 *remote_target_cells,
struct gsm_subscriber_connection *conn,
const struct cell_ab *search_for,
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
bool log_errors)
inter-BSC HO: add neighbor_ident API to manage neighbor-BSS-cells Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore) Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
2018-03-22 03:54:57 +00:00
{
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
struct gsm_network *net = conn->network;
struct gsm_bts *local_target_cell = NULL;
bool ho_active;
bool as_active;
fix/refactor neighbor config 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-09 16:11:45 +00:00
struct gsm_bts *from_bts = conn->lchan->ts->trx->bts;
*remote_target_cells = (struct gsm0808_cell_id_list2){};
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
if (local_target_cell_p)
*local_target_cell_p = NULL;
if (!search_for) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR, "Handover without target cell\n");
return -EINVAL;
}
if (!from_bts) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR, "Handover without source cell\n");
return -EINVAL;
}
ho_active = ho_get_ho_active(from_bts->ho);
as_active = (ho_get_algorithm(from_bts->ho) == 2)
&& ho_get_hodec2_as_active(from_bts->ho);
if (!ho_active && !as_active) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR, "Cannot start Handover: Handover and Assignment disabled for this source cell (%s)\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
fix/refactor neighbor config 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-09 16:11:45 +00:00
if (llist_empty(&from_bts->neighbors)) {
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
/* No explicit neighbor entries exist for this BTS. Hence apply the legacy default behavior that all
* local cells are neighbors. */
struct gsm_bts *bts;
handover: fix detection for ambiguous HO neighbor ident Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-29 23:29:11 +00:00
int i;
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
LOG_HO(conn, LOGL_DEBUG, "No explicit neighbors, regarding all local cells as neighbors\n");
handover: fix detection for ambiguous HO neighbor ident Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-29 23:29:11 +00:00
/* For i == 0, look for an exact 1:1 match of all ident_key fields.
* For i == 1, interpret wildcard values, when no exact match exists. */
for (i = 0; i < 2; i++) {
bool exact_match = !i;
llist_for_each_entry(bts, &net->bts_list, list) {
fix/refactor neighbor config 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-09 16:11:45 +00:00
struct cell_ab bts_ab;
bts_cell_ab(&bts_ab, bts);
if (cell_ab_match(&bts_ab, search_for, exact_match)) {
handover: fix detection for ambiguous HO neighbor ident Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-29 23:29:11 +00:00
if (local_target_cell) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR,
"NEIGHBOR CONFIGURATION ERROR: Multiple local cells match %s"
" (BTS %d and BTS %d)."
" Aborting Handover because of ambiguous network topology.\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for),
handover: fix detection for ambiguous HO neighbor ident Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-29 23:29:11 +00:00
local_target_cell->nr, bts->nr);
return -EINVAL;
}
local_target_cell = bts;
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
}
inter-BSC HO: add neighbor_ident API to manage neighbor-BSS-cells Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore) Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
2018-03-22 03:54:57 +00:00
}
handover: fix detection for ambiguous HO neighbor ident Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-29 23:29:11 +00:00
if (local_target_cell)
break;
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
}
if (!local_target_cell) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR, "Cannot Handover, no cell matches %s\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
if (local_target_cell == from_bts && !as_active) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR,
"Cannot start re-assignment, Assignment disabled for this cell (%s)\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
if (local_target_cell != from_bts && !ho_active) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR,
"Cannot start Handover, Handover disabled for this cell (%s)\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
if (local_target_cell_p)
*local_target_cell_p = local_target_cell;
return 0;
}
/* One or more local- or remote-BSS cell neighbors are configured. Find a match among those, but also detect
* ambiguous matches (if multiple cells match, it is a configuration error). */
LOG_HO(conn, LOGL_DEBUG, "There are explicit neighbors configured for this cell\n");
fix/refactor neighbor config 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-09 16:11:45 +00:00
if (resolve_neighbors(&local_target_cell, remote_target_cells, from_bts, search_for, log_errors)) {
LOG_HO(conn, LOGL_ERROR, "Cannot handover BTS %u -> %s: neighbor unknown\n",
from_bts->nr, cell_ab_to_str_c(OTC_SELECT, search_for));
return -ENOENT;
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
}
fix/refactor neighbor config 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-09 16:11:45 +00:00
/* We have found possibly a local_target_cell (when != NULL), and / or remote_target_cells (when .id_list_len >
* 0). Figure out what to do with them. */
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
fix/refactor neighbor config 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-09 16:11:45 +00:00
if (remote_target_cells->id_list_len)
LOG_HO(conn, LOGL_DEBUG, "Found remote target cell(s) %s\n",
gsm0808_cell_id_list_name_c(OTC_SELECT, remote_target_cells));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
fix/refactor neighbor config 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-09 16:11:45 +00:00
if (local_target_cell && remote_target_cells->id_list_len) {
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
if (log_errors)
fix/refactor neighbor config 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-09 16:11:45 +00:00
LOG_HO(conn, LOGL_ERROR, "NEIGHBOR CONFIGURATION ERROR: Both a local and a remote-BSS cell"
" match BTS %u -> %s (BTS %d and remote %s)."
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
" Aborting Handover because of ambiguous network topology.\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
from_bts->nr, cell_ab_to_str_c(OTC_SELECT, search_for), local_target_cell->bts_nr,
gsm0808_cell_id_list_name_c(OTC_SELECT, remote_target_cells));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
if (local_target_cell == from_bts && !as_active) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR,
fix/refactor neighbor config 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-09 16:11:45 +00:00
"Cannot start re-assignment, Assignment disabled for this cell (BTS %u)\n",
from_bts->nr);
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
if (((local_target_cell && local_target_cell != from_bts)
fix/refactor neighbor config 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-09 16:11:45 +00:00
|| remote_target_cells->id_list_len)
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
&& !ho_active) {
if (log_errors)
LOG_HO(conn, LOGL_ERROR,
fix/refactor neighbor config 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-09 16:11:45 +00:00
"Cannot start Handover, Handover disabled for this cell (BTS %u -> %s)\n",
from_bts->bts_nr, cell_ab_to_str_c(OTC_SELECT, search_for));
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -EINVAL;
}
fix/refactor neighbor config 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-09 16:11:45 +00:00
/* Return the result. After above checks, only one of local or remote cell has been found. */
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
if (local_target_cell) {
if (local_target_cell_p)
*local_target_cell_p = local_target_cell;
return 0;
}
fix/refactor neighbor config 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-09 16:11:45 +00:00
if (remote_target_cells->id_list_len)
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return 0;
inter-BSC HO: add neighbor_ident API to manage neighbor-BSS-cells Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore) Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
2018-03-22 03:54:57 +00:00
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
if (log_errors)
LOG_HO(conn, LOGL_ERROR, "Cannot handover %s: neighbor unknown\n",
fix/refactor neighbor config 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-09 16:11:45 +00:00
cell_ab_to_str_c(OTC_SELECT, search_for));
inter-BSC HO: add neighbor_ident API to manage neighbor-BSS-cells Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore) Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
2018-03-22 03:54:57 +00:00
neighbor config: allow re-using ARFCN+BSIC pairs 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-12 23:12:53 +00:00
return -ENODEV;
inter-BSC HO: add neighbor_ident API to manage neighbor-BSS-cells Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore) Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
2018-03-22 03:54:57 +00:00
}
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
static int ho_logic_sig_cb(unsigned int subsys, unsigned int signal,
void *handler_data, void *signal_data)
{
lchan: Every SS_LCHAN signal now sends a struct lchan_sig_data The SS_LCHAN signals now always include the lchan_sig_data. For the measurement report it will optionally include the measurement report as well. Attempt to update all handlers of this signal as well
2010-12-27 12:28:20 +00:00
struct lchan_signal_data *lchan_data;
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
struct gsm_lchan *lchan;
lchan: Every SS_LCHAN signal now sends a struct lchan_sig_data The SS_LCHAN signals now always include the lchan_sig_data. For the measurement report it will optionally include the measurement report as well. Attempt to update all handlers of this signal as well
2010-12-27 12:28:20 +00:00
lchan_data = signal_data;
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
switch (subsys) {
case SS_LCHAN:
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
OSMO_ASSERT(lchan_data);
lchan: Every SS_LCHAN signal now sends a struct lchan_sig_data The SS_LCHAN signals now always include the lchan_sig_data. For the measurement report it will optionally include the measurement report as well. Attempt to update all handlers of this signal as well
2010-12-27 12:28:20 +00:00
lchan = lchan_data->lchan;
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
OSMO_ASSERT(lchan);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
switch (signal) {
HO: introduce ho decision callbacks Instead of reacting on S_LCHAN* signals in the handover decision code, introduce callbacks for the handover decision to be invoked by handover_logic.c at the appropriate time. The rationale is explained in a comment to struct handover_decision_callbacks, quoting: " All events that are interesting for handover decision are actually communicated by S_LCHAN_* signals, so theoretically, each handover algorithm could evaluate those. However, handover_logic.c cleans up handover operation state upon receiving some of these signals. To allow a handover decision algorithm to take advantage of e.g. the struct bsc_handover before it is discarded, the handover decision event handler needs to be invoked before handover_logic.c discards the state. For example, if the handover decision wants to place a penalty timer upon a handover failure, it still needs to know which target cell the handover failed for; handover_logic.c erases that knowledge on handover failure, since it needs to clean up the lchan's handover state. The most explicit and safest way to ensure the correct order of event handling is to invoke the handover decision algorithm's actions from handover_logic.c itself, before cleaning up. This struct provides the callback functions for this purpose. For consistency, also handle signals in this way that aren't actually in danger of interference from handover_logic.c (which also saves repeated lookup of handover state for lchans). Thus, handover decision algorithms should not register any signal handler at all. " Also: - Publish struct bsc_handover to use it as argument to above callbacks. - Add enum hodec_id to struct bsc_handover, to be able to signal the appropriate hodec algorithm per event. - Add hodec_id argument to bsc_handover_start*() to be placed in the bsc_handover struct. - Publish the LOGPHO logging macros in handover.h along with struct bsc_handover, convenient for logging in callback implementations. Replace handover_decision.c's signal handler with a registered handover_decision_callbacks instance. (Upcoming handover_decision_2 will use all of the callbacks introduced here.) Change-Id: Id5b64504007fe03e0406a4b395cd0359232b77d2
2018-02-15 13:10:12 +00:00
case S_LCHAN_MEAS_REP:
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
ho_meas_rep(lchan_data->mr);
break;
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
}
large refactoring: use FSMs for lchans; add inter-BSC HO Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
2018-05-14 16:14:15 +00:00
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
default:
break;
}
return 0;
}
static __attribute__((constructor)) void on_dso_load_ho_logic(void)
{
src: use namespace prefix osmo_signal* Summary of changes: s/signal_cbfn/osmo_signal_cbfn/g s/register_signal_handler/osmo_signal_register_handler/g s/unregister_signal_handler/osmo_signal_unregister_handler/g s/dispatch_signal/osmo_signal_dispatch/g
2011-05-06 10:12:31 +00:00
osmo_signal_register_handler(SS_LCHAN, ho_logic_sig_cb, NULL);
[handover] Implement handover control logic Code to implement handover control logic. A yet-to-be-implemented handover algorithm will call bsc_handover_start(old_lchan, new_bts) to start the handover process.
2009-11-29 21:56:14 +00:00
}