This code contains the following code:
* receive/parse/interpret LCLS specific BSSMAP IEs and PDUs
* osmo_fsm handling the various states and their transitions
* call leg correlation (finding the other subscr_conn with same GCR)
* communication between the two call-leg LCLS FSMs
* detection of supported / unsupported LCLS configurations
* display of GCR / LCLS information in "show conns"
* switch the media streams locally using MDCX to the MGW
Closes: OS#1602
Change-Id: I614fade62834def5cafc94c4d2578cd747a3f9f7
It's not a good idea to keep extern declarations copied over
half a dozen C files. Let's move it to a header.
Change-Id: I6f643f1393ba0955d9c0cf1cf78d5c604e7b9451
The bsc_msc_connection dates back to the old pre-libosmo-sigtran
days, and 90% of the field members weren't used at all (even the
new sigtran specific ones!). Let's merge what remains into struct
bsc_msc_data.
As a side effect, the already dysfunctional "dest A.B.C.D" VTY
command has been removed from the MSC node.
There's quite a bit of fall-out in the CTRL interface, which was
the code with strongest ties to bsc_msc_connection. This was
resolved by properly porting CTRL handling over to libosmo-sigtran,
meaning that an IPA/SCCPlite connected MSC can now again send CTRL
GET/SET commands, and can also receive those selective few TRAPs
that old osmo-bsc-sccplite also sent to its MSC[s].
Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f
Related: OS#2012
osmo-bsc_nat is too heavily tied into legacy SCCPlite code, as it
is not using libosmo-sigtran/osmo_ss7 so far. It's also full of
customer-specific code and it's shared use of some libbsc code here
has been complicating osmo-bsc development.
The current plan is to continue to use osmo-bsc_nat from openbsc.git
for those legacy users that need it, and not use osmo-bsc_nat in
new 3GPP AoIP setups. Should we ever get a strong demand for an AoIP
based bsc_nat, we can still revisit this later.
Change-Id: Ia05dc76336a64a7f08962843b9a7cc19f2c83387
Also: Move mgcp_timeslot_to_port() next to it, as they are
more or less the inverse transformation of each other.
Change-Id: Ica908e2bb8fc4e59e0d146b428c93a9efc385688
We used to have hard-coded M3UA. Let's allow the user to configure
this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command.
For SUA this should just work 1:1 without any trouble. For IPA,
this of course only changes the underlying transport without reflecting
the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling,
etc.
Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13
Related: OS#2544
The state ST_WAIT_MODE_MODIFY_ACK can never be reached by the
current FSM model.
- Remove ST_WAIT_MODE_MODIFY_ACK and all related code
Change-Id: Iacaae2ee50ca1956066b7dce4517bbc9c2b0897e
Related: OS#2762
bsc_api.c notoriously lacks log context. Provide gsm_lchan_name() and/or
bsc_subscr_name() in roughly a million instances, using new LOGPLCHAN macro.
Add LOGPLCHAN() to gsm_data.h, to encourage use of it in other .c files.
Change-Id: If469defcc6fe8950dac5df61db3f39d297893318
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node.
This commit is a forward-port of openbsc.git Change-Id
Ibf3932adc07442fb5e9c7a06404853f9d0a20959.
Depends on osmo-mgw.git Change-Id Ie19a64ac09f9d51f2434ad0d7925610fc919a90e.
Change-Id: Ie07b8a577caf731d59d68e3b3510ae2f9fd3dc93
Add a global counter to the BSC which shows the number of failed
connections attempts due to a unit_id mismatch between the BSC
and the BTS.
Change-Id: I58866aff36a1c8463bf84b4392a5124ffeaa32ea
Related: OS#3245
The 'show statistics' VTY command was not showing all counters
maintained by osmo-bsc. Instead of printing just two counters
related to paging, print all available counters in a generic way.
Adjust descriptions of some counters for nicer display.
After startup (all counters are zero) is now looks like this:
OsmoBSC# show statistics
handover:attempted: 0 Received handover attempts.
handover:no_channel: 0 Sent no channel available responses.
handover:timeout: 0 Timeouts of timer T3103.
handover:completed: 0 Received handover completed.
handover:failed: 0 Received HO FAIL messages.
paging:attempted: 0 Paging attempts for a subscriber.
paging:detached: 0 Paging request send failures because no responsible BTS was found.
paging:responded: 0 Paging attempts with successful response.
OsmoBSC#
Change-Id: I58ae04e1960774d760e3ebb54a4f307c9f753655
Related: OS#3245
The function a_reset_free() is not used anywhere at the code. The
reason for this is that a BSC instance is never cleared once it
is started up. Also the timer number is not according to the spec.
- Remove a_reset_free()
- Fix timer identification number (T4)
- use fi->priv to hold context info
- Fix sourcecode formatting
Change-Id: I72095d52304c520e383755eee6c889bce492cbd4
Related: OS#3102
Recent Icf6e25ff068e8a2600562d52726ead65e864ec02 changed the dyn_ts_init() hook
from bootstrap_rsl() to the Channel OPSTART ACK, but this is not sufficient.
Now RBS2k never calls dyn_ts_init(), and we may need to wait for RSL:
Dyn TS should actually be initialized only when *both* OML opstart and RSL link
are established. To that end, introduce a generalized API to query OML and RSL
status and to trigger a timeslot init at the appropriate time.
Add gsm_ts_check_init() to be called both when RSL and OML opstart are
established: trigger gsm_ts_init() only when both are given.
Add gsm_bts_trx_ts->initialized flag to mark whether initialization has already
taken place. Add gsm_bts_mark_all_ts_uninitialized() to conveniently clear this
flag for all TS in a BTS.
Add gsm_bts_model.oml_is_ts_ready() callback so that each BTS implementation
can return the OML status of a timeslot in its own OML implementation.
Actually, currently all BTS models that need this init mechanism store the TS'
OML status in ts->mo.nm_state. While we would in practice correctly init dyn TS
by just looking at ts->mo.nm_state, semantically, the decision whether the TS
is ready is up to the BTS models' specific OML implementations.
From bootstrap_rsl(), call gsm_ts_check_init(), in case the TS OML Opstart has
happened before RSL is established -- applies to all BTS models.
For all BTS models:
- call gsm_{bts,trx}_mark_all_ts_uninitialized() when OM is torn down, to make
sure the TS init mechanism will work a second time.
For all BTS models supporting dyn TS, i.e. osmo-bts, nanobts and RBS2k:
- implement oml_is_ts_ready().
- call gsm_ts_check_init() when a Channel OM is taken into operation.
Any BTS models that don't set oml_is_ts_ready() will see a ts init as soon as
RSL is bootstrapped (incidentally, the old dyn TS behavior before recent
Icf6e25ff068e8a2600562d52726ead65e864ec02).
This firstly fixes dyn TS for RBS2k by re-adding the initial switch to PDCH,
and furthermore does so only after both OML TS opstart and RSL are through.
This fixes the ttcn3-bsc-tests around dyn TS, since for the osmo-bts-virtual,
the RSL is established only after OML opstart on the TS, which was broken by
Icf6e25ff068e8a2600562d52726ead65e864ec02.
Nokia Site and Siemens BS11 practically do not require this init mechanism,
since all that happens there so far is dyn TS init, and these BTS models do not
support dyn TS of any kind. A future patch may add oml_is_ts_ready().
Related: OS#3205
Change-Id: I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
Sending PDCH activation upon RSL bootstrap is too early. Introduce OPSTART ACK
handling to call dyn_ts_init() only when the dynamic timeslot is indeed ready
to receive a PDCH activation.
Related: OS#3205
Change-Id: Icf6e25ff068e8a2600562d52726ead65e864ec02
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
Change-Id: Ia25bff85d9e5c277da76bffa11d31972e9fdc323
Related: OS2591
It can be obtained from cmd field, so no need to store it in pending.
This way we simplify the ad-hoc struct bsc_cmd_list.
Change-Id: I6de64fc128ad623ca30b9e6cebebaff8de18f95d
There is a lot of dead code in osmo_bsc_msc.c that used to handle
the IPA multiplexed SSCP lite A interface.
- remove portions of the dead code
- remove IPA Ping related VTY commands
Change-Id: I5cf3fec31cc774c902f3cfe6d16fb85ef301694a
Correctly compute the TS 48.008 "speech mode" (codec) for AMR on TCH/F.
There are way too many different ways how to express a given voice
codec. There are two different schemes in TS 48.008 alone, plus one
on TS 48.058 and one in 04.08 / 44.018. Let's avoid unneeded
conversion (that we might get wrong) and avoid storing information in
a sub-struct of the lchan if we can simply derive it from the lchan
at the time we need it.
Also, move BSSAP related encoding/conversion functions closer to the
user (osmo_bsc_bssap), rather than in libbsc.
Without this patch, TCH/F with AMR was erroneously reported as TCH/H
with AMR in the BSSMAP ASSIGNMENT COMPLETE. After this patch, it's
reported correctly.
Change-Id: I6feebfae77fdc93a7ce333a25dd9b9267c5a4a2e
Related: OS#3094
Related: OS#3095
Related: OS#3096
Instead of a local redefinition, use osmo_cell_global_id.
This change is cosmetic because the decoded PLMN is currently actually never
used.
Change-Id: I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8
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
In order to avoid code duplication the feature list (bit masks) and
the desciptive value strings as well as the function to set and get
the feature bits have been moved to libosmocore.
- use feature list functionality provided by libosmocore
Depends: libosmocore Change-Id Id0c35aef11aa49aa40abe7deef1f9dbd12210776
Change-Id: I3e80517539cc5d0e5d8189d434a5e3cc0fdea1a0
Add the mnc_3_digits member to the info_ind.
Instead of changing to e.g. osmo_plmn_id, add the flag separately, and instead
of bool use a uint8_t, to not raise any struct packing issues and clarify the
flag's size beyond any doubt.
Bump the PCU interface version to 9.
This is one part of the three identical pcuif_proto.h patches:
- I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts)
- I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
- I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc)
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore)
Change-Id: I78f30aef7aa224b2e9db54c3a844d8f520b3aee0
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
The changes to abis_test and gsm0408_test show that this code now handles
3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded
PLMN.
Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the
presence of the third digit of the MNC. Always reply with all leading zeros.
Adjust the expected results in ctrl_test_runner.py, to show that it works.
In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use
of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters
and detect errno returned by strtol() (in contrast to atoi()).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore),
I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore)
Change-Id: I8e722103344186fde118b26d8353db95a4581daa
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ic16bc0bab3f2d4721e86a1a04f9d9f988d777df2
Move from using deprecated gsm48_construct_ra(), which uses a buf, to
gsm48_encode_ra(), which uses a gsm48_ra_id argument. Pass struct gsm48_ra_id
around instead of a buf.
struct gsm48_ra_id is the "encoded" representation of the bytes in a typical
MCC-MNC-LAC-RAC (04.08 Routing Area Id IE, 3GPP TS 24.008 § 10.5.5.15). Using
the struct spares using magic numbers for byte offsets.
In the process, fix a sanitizer warning for unaligned access by using memcpy()
instead of pointer assignment:
osmo-bsc/src/libbsc/abis_nm.c:2857:27: runtime error: store to misaligned address 0x7ffe8e0d6695 for type 'uint16_t', which requires 2 byte alignment
Note that (besides removing a now unnecessary cast) the gsm0408_test and
abis_test tests of RAI / CGI encoding remain stable, which indicates that the
new code is still correct.
Change-Id: I0d3908fb8ca1e2e669d257b5d59b40675fa85d06
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Change-Id: I0a5ac3a08f992f326435944f17e0a9171911afb0
Related: OS#2591
Handover decision 2 arguments are now configured by 'handover2 foo'. To match
that scheme, rename the previously 'handover foo' args for handover decision 1
to 'handover1 foo'.
For backwards compatibility, still provide aliases of the original VTY
commands. Writing back the config will result in 'handover1' though.
Change-Id: I7305ae7c04cc70082cd80d42b2ba32ffa399f51a
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
The conn's penalty timers will be used only for handover decision 2, make it
clear by a sub-struct.
hodec2 will also initialize the penalty timer list on demand only, so no need
to always initialize.
Change-Id: Ie6c2bc2b10dc424dfd94a9e11a9a62f51c48aa10
Handover decision 2 will also store the last seen mr nr for neighbor cell
measurements and hence can tell whether a neighbor's measurement is outdated.
Change-Id: Ic1148364597f91b5a55666c80c758b61fa56f582
Do not share config items between the current handover decision and the
upcoming handover_decision_2.
Rename current handover config items to hodec2_* and duplicate the ones
relevant to handover decision algorithm 1 with name prefix of hodec1_*.
I considered moving hodec2 parameters to an entirely separate .c file and
struct, but that causes considerable code bloat. Rather use the nice
handover_cfg net/bts level mechanism as-is, and simply prefix the names.
In the VTY, the hodec1 parameters are configurable by 'handover foo 23'
commands, while the hodec2 parameters are by 'handover2 foo 23'. The generic
VTY commands to enable/disable handover and to choose the algorithm are still
'handover (0|1)' and 'handover algorithm (1|2)'.
(Note, a subsequent commit will rename the 'handover foo' for hodec1 to
'handover1 foo' and add backwards-compat aliases.)
For example, the 'window rxlev averaging 5' command now exists both for
handover decision 1 and handover decision 2, and its values are independent.
This is valid config:
network
# set up handover decision algorithm 1
# (pending rename of these items to 'handover1 ...')
handover window rxlev averaging 5
handover window rxlev neighbor averaging 5
# set up handover decision algorithm 2
handover2 window rxlev averaging 7
handover2 window rxlev neighbor averaging 7
handover2 penalty-time max-distance 10
# enable handover
handover 1
bts 0
handover algorithm 1
bts 1
handover algorithm 2
In this example, bts 0 uses algo 1 with rxlev averaging of 5, while bts 1 uses
algorithm 2 where rxlev averaging of 7 is in effect.
Change-Id: I6475b2543b18d21710a6d774b214cb484f36ec8e
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
The bit-mask of permitted ciphers from the MSC (sent in ASSIGNMENT
COMMAND) is intersected with the vty-configured mask a the BSC.
Finally, the best (highest) possible cipher is chosen.
Change-Id: I1d1c8131855bcab2392b4f27f6216bdb2fae10e0
Closes: OS#2461
About half of our log categories/subsystems were inherited from
OsmoNITB, and are no longer used but may confuse the user.
Change-Id: I8b39429f71c0faefdf8158a82093cfb19f44809e
There was always a 1:1 correspondence between gsm_subscriber_connection
and osmo_bsc_sccp_con, so there's really no point in having two separate
dynamically allocated data structures with pointers back and forth and
another linked list around.
Let's merge osmo_bsc_sccp_con into gsm_subscriber_connection for
simplicity.
The resulting code might not be elegant in places, but I've tried to
do only the most simple changes in this patch, while further
simplifications can be done in later subsequent patches.
As a side-effect, this patch also fixes lchan clearing if the MSC
(or the local SCCP provider) hard-disconnects the SCCP connection.
Change-Id: Idd2b733477ee90d24dec369755a00f1c39c93f39
Have expicitly named vty write functions for bts and net levels, so that it is
trivial to add commands that exist only on one of each (like the upcoming
congestion check timer config for hodec2).
Change-Id: Ibea4c20abc50c3d655f6bbb1a643477dfc722c8e
On BSSMAP Assignment Request received from the MSC, store the Speech Codec List
in the subscr conn, so that we may evaluate available codecs during handover
decision. (Will be used, e.g., by handover_decision_2.)
Change-Id: I8222d73085eb777696e365c94214c05d56e6d129
Separate penalty timers API from specific struct members and move to own .h/.c
file, so that future code may re-use the API arbitrarily.
Change-Id: Ife975a1c7c17a500b1693be620475a8bea72f86f
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
This leaves common_cs.h practically empty. Leave its removal to the next patch,
which removes libcommon-cs entirely
(I07d4a48af3154ee4d904686f230a51b8b8a94ff9).
Change-Id: Ic3233f03580aa8c0ab178dfd33e68ecab5b9f042
The gsm_network VTY was partly shared between libmsc and libbsc in the old
openbsc.git; now osmo-bsc.git has its own copy, so merge all of it into
bsc_vty.c.
This leaves common_cs_vty.c practically empty; leave removal of the file to
later, when we drop the entire libcommon-cs in
I07d4a48af3154ee4d904686f230a51b8b8a94ff9.
Note that gsmnet_from_vty() is also already declared in bsc/vty.h.
Change-Id: I6f3a596f31762b48afed39a85a343c400826300f
These functions were originally shared between libmsc and libbsc in the old
openbsc.git; now osmo-bsc.git has its own copies, so move them into libbsc.
Change-Id: Ie411c2ce8008accee54782a442d6361e50777a54
Some part of the network init was common between libbsc and libmsc in the old
openbsc.git repository. Now osmo-bsc.git is independent with its own copy of
the gsm_network initialization. So move it over to libbsc.
Change-Id: I8968787a5f0b078619264f0cb42349a9bc7943af
The separation of gsm_data_shared.* from gsm_data.* historically allowed
compiling parts of it into osmo-bts, which we have dropped since (osmo-bts has
its own copy now). Even though gsm_data.* now becomes rather large by it,
remove the legacy separation to get rid of the "shared" naming, which is no
longer meaningful. A future patch might separate into meaningful smaller bits,
if we get the time.
Change-Id: Ie247bc492efb331871d970c56700595ad3f7e201
Replace calls to make_sock() with osmo_sock_init_ofd().
Shame on me for not testing every single one in practice, I hope for peer
review to confirm that this should be correct... Read closely please!
The IPPROTO_GRE define seems to be unused (at least in osmo-bsc.git), drop it
completely.
Change-Id: Ia6e4e0e1eed3328fa25b3b90be376d532ad0e56b
Provide concise log categories for each main scope.
Move the complete log categories 1:1 to osmo_bsc_main.c.
In bsc_nat.c, omit obviously unused log categories.
In tests, omit almost all log categories, except for those explicitly tested as
the expected output.
Note: should any logging occur for a log category that is omitted by accident,
such will end up being logged as DLGLOBAL, so it will show up and we can fix
it, and it will not get lost silently.
Change-Id: Ib524e49ec211662e0dfde8161495a72aa8ad76cf
Move bsc_vty_go_parent() to osmo_bsc_main.c and bsc_nat.c, and drop those nodes
that aren't used in the respective main scope.
Change-Id: I22ebb76742e9c5ab9dd608ac089a5c558aceeb36
If a BTS/TRX does not respond to the "IPA RSL Connect" command,
pretend that the BTS has sent a NACK for the connection.
To ensure that osmo_timer_del(&trx->rsl_connection_timeout) is not called
before this timer is initialized with osmo_timer_setup(), the E1 layer now
drops incoming RSL messages from a BTS/TRX in LOCKED administrative state.
We cancel the timeout if we receive an RSL Connect ACK or NACK from the BTS,
and if the underlying E1 link does down.
While here, add a missing message buffer free() in bts_isdn_sign_link().
The callers do not free it.
Change-Id: Ia72b65a0f15f47dcb8a6f944f6c3695a4a64b923
Related: OS#2716
In addition to logging the current values of a BTS's channel load
average and T3122 override, maintain stat items for these values.
This allows for plotting these values over time, for instance.
These values show up in the VTY under 'show stats' like this:
base transceiver station:
Channel load average.: 25 %
T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.: 32 s
Change-Id: Icace0176e8b1d23d7c7b4816f7c67c65312844fa
Suggested-by: laforge
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which
tells an MS requesting a channel to wait for a specified amount of
time before trying to request a channel again, i.e. the wait indicator
controls the T3122 timeout value in the MS.
Previously, the wait indicator was fixed to 10 seconds.
This is not sufficient if there are a lot of MS requesting channels
because the MS will retry too soon. Instead of using a fixed value,
maintain a dynamic wait indicator value based on average channel load.
The load (used vs. available channels on a BTS) is sampled once per
second, and once 8 samples have been collected we update a BTS-specific
T3122 wait indicator based on the measured load.
While the wait indicator could go up to 255 seconds, this initial
implementation keeps it in the range from 10 to 128 seconds.
Further experimentation and testing will show whether higher wait
indicator values are desirable, if the sampling rate needs to change,
or if the function mapping the load measurement to a wait indicator
value should change (currently we map the load average linearly into
the range [10, 128] inclusive).
Change-Id: I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
Related: OS#2592
This member was merely a cache for conn->lchan->ts->trx->bts,
so let's avoid having to keep copies of the same data (which needs
to be kept up to date).
Change-Id: Id3bff8b18425ef5d45eb460ac9eb620023013ba0
This penalty timer is used to temporarily block cells where handover
or assignment failed or where handover is not allowed. This is usefull
to prevent repeated handover attempts to broken cells or cells that have
limited allowed distance.
Change-Id: I95cb7e3211b2470b773965e7aa94d8eb6c8c1a3a
Add ho_dtap_cache to gsm_subscriber_connection, a stock msgb queue to be used
with msgb_enqueue() and msgb_dequeue().
Keep a counter of queue length, to enforce a sane maximum counter for cached
messages. So far a hardcoded maximum of 23 messages will be cached.
Have balanced ho_dtap_cache_add() and ho_dtap_cache_flush() functions.
The original patch was by jolly, but I have basically completely replaced it
with the simpler msgb queue pattern.
Change-Id: I6e4d93628befb3d97e5cee0343cd9f8ba0b8620c
This is needed for handover algorithm to balance free slots and to prevent
congestion of one cell, while other cells still have free capacities.
Change-Id: Ic8bee8a515ee8aa9a99af71756fe60b8dd8f868b
If we want to average over up to 10 measurement reports (as configurable
at VTY), we need a history of at least 10 measurements.
Change-Id: Ia7cfac073bdc464092ca3e51dec319ac30401dd1
get_meas_rep_avg will return -EINVAL, if the required number of
measurements are not reached. There will be no handover possible until the
given number of measurements are available.
Change-Id: Ibc4410b4e162cdb6c070128d2c63946bb79d6d65
In order to keep processing power at BTS at a defined level, the handover
decision might want to limit maximum number of slots that require RACH
detection.
Change-Id: I8908e37fe0d8d2eda906cc6301ba0969b25a5575
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
Do not instruct the MGW to move the RTP to the new lchan before we have
received a HANDOVER DETECT.
Before:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
MGCP MDCX --> MGW
...
HANDOVER DETECT
Call continues on new lchan
In above sequence, if the HANDOVER DETECT times out, the MGW has moved to the
new lchan which never becomes used and is released. Furthermore, from the IPACC
MDCX until the HANDOVER DETECT, the RTP stream would break off momentarily.
After:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
...
HANDOVER DETECT
MGCP MDCX --> MGW
Call continues on new lchan
If the HANDOVER DETECT times out, the call happily continues on the old lchan.
This change is inspired by Ivan Kluchnikov's HO work, who implemented a similar
fix in the openbsc.git codebase (branch fairwaves/master-rebase): his patch
moves ipacc_mdcx() to connect RTP to the new lchan from switch_for_handover()
(which triggered on S_ABISIP_CRCX_ACK, i.e. creation of the new lchan) to later
on in ho_detect() a.k.a. the S_LCHAN_HANDOVER_DETECT signal handler:
http://git.osmocom.org/openbsc/commit/?h=fairwaves/master-rebase&id=9507a7a1ea627e07370c9d264816bb190b3b91b8
This patch does essentially the same: remove the mgcp_handover() call from the
MDCX-ACK handling (creation of the new lchan), and add a signal handler for
S_LCHAN_HANDOVER_DETECT to osmo_bsc_mgcp.c to effect the MGW switchover.
Note, it would have been possible to call mgcp_handover() directly from rx of
the HANDOVER DETECT message, but that produces linking fallout in some utils/
projects, which then need to link the mgcp code as well. That is because those
aren't properly separated from the more complex parts of libbsc. Using the
signal is a bit bloaty, but saves the linking hell for now. I've faced a
similar problem twice recently, it would pay off to separate out the simpler
utils/ and ipaccess/ tools so that they don't need to link all of libbsc and
osmo-bsc, at some point (TM).
Change-Id: Iec58c5fcc5697f1775da7ec0111135108ed1fc8f
A subsequent patch will add registration of a signal; cosmetically prepare by
creating a common mgcp_init() function. It makes sense for the FSM registration
to move to it.
Change-Id: I510e1081171706eb3d9fb2db50a9aa4f768929b5
We can now either page an invidual BTS directly or page several BTS in a
given location area. This decision is taken based on the contents of the
cell identifier list in the paging request. Select a set of BTS for paging
while processing the cell identifier list, rather than requiring the
paging layer to loop over all BTS in the MSC.
This change requires some adjustment in bssap_test. In particular,
this test must now add a BTS to its network in order to pass.
The purpose of this change is to make the layering a bit cleaner.
There is one functional change: We no longer abort paging if paging fails
for a particular BTS. Instead, we keep trying to page on other BTS.
Change-Id: Ic1c72c7f83e53988eb9fedf314b1dc459836833d
Suggested-by: Harald Welte
Depends: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Related: OS#2753
The stow-enabled jenkins builds are currently failing like below:
make[3]: Entering directory '/build/src/libcommon'
CC bsc_version.o
CC common_vty.o
CC debug.o
CC gsm_data.o
In file included from debug.c:34:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from common_vty.c:27:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from gsm_data.c:37:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
Let's make sure the common gsm_data.h have all required CFLAGS to compile.
Change-Id: I30b75db6ffba227b05b5413b84b15f69e0c213f2
This builds upon https://gerrit.osmocom.org/#/c/5698/ which implements
support for paging by LAI.
The ttcn3 test TC_paging_imsi_nochan_ci passes with this code when
run in isolation. It does not pass if another paging test (such as
TC_paging_imsi_nochan_lai) is executed beforehand. This problem
looks similar to the scenario tested in TC_paging_imsi_a_reset.
Change-Id: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Depends: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e
Related: OS#2753
This change removes a few USSD specific declarations, which are
not actually used now, and probably accidentally migrated from
legacy OpenBSC.
Change-Id: I060223349971a7fce169a018bf16eb91f0e20342
Add a new control command 'msc.N.connection_status' which can be used
to query the connection status of a particular MSC with number N.
Keep the old control command 'msc_connection_status', which always
queries MSC 0, for backwards compatibility.
Change-Id: Ibd41474a1be80e782b19ec337c856b5efc593fa8
Related: OS#2729
T3109 is started when the BSS sends a RR CHAN REL to the MS and stops
downlink SACCH generation. Stopped when the MS successfully releases the
LAPDm link. After stop or timeout, the radio channel is released using
RSL RF CHAN REL.
Recommended values in literature are 1-2s + RadioLinkTimeout*0.48s or
5s, while we had the absurdly high 19s timeout. This means we occupy
the radio channel way longer than needed in situations where the MS is
no longer able to properly release Layer2 (LAPDm DISC) due to loss of
signal or the like.
See also: https://osmocom.org/projects/osmobsc/wiki/Timers
Change-Id: I7416b4118e5b73c6ffb98e3546bc62a36c7a967a
Closes: OS#2734
This is a new inline function that hides all accesses to conn->bts.
A follow-up patch will then point this to conn->lchan->ts->trx->bts
to get rid of the bts field.
Change-Id: Ib6cf7097ced34eebe80441c29ab1534f21956a33
when a transaction to the MGW times out, then the context
information is freed. Unfortunately the client is not informed
about this and will try to execute the callback anyway.
explicitly cancel the transaction in order to prevent access
to already freed data structures.
Change-Id: I40794dff7d10e2b6a96863a2da7e9fbd5662a1bf
libosmo-sccp is the old sccp-lite-focused SCCP implementation that we
used before libosmo-sigtran was created. The new osmo-bsc in this
repository is using libosmo-sigtran and shouldn't be using parts of
libosmo-sccp anymore.
We only keep it around in configure.ac and Makefile.am for osmo-bsc_nat,
which is not even built in this repository anymore (or 'again yet'?)
Change-Id: I8f274be7d196cd7a5b1ec9ada949130fb06e984d
RRLP is handled in OsmoMSC after the split from NITB, so let's remove
any bogus VTY commands left over in the BSC.
Change-Id: Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38
Harald Welte
Philipp Maier
Neels Hofmeyr
Pau Espin