If a channel activation ack comes in late from a BTS, the borken state has a
transition back to a channel recovery. This only fails because of a missing
state transition in the lchan_fsm. Allow the transition.
We've seen this happening at cccamp2019, where a particular BTS for unknown
reasons sends its Chan Act ACK a second after the activation times out in
osmo-bsc. This patch should allow it to recover.
Change-Id: I73139033ae44abb383ccce956c1c9683db8c8816
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
This is required for an upcoming TTCN3 test that plays through various neighbor
configurations.
Related: OS#4056
Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc (osmo-ttcn3-hacks)
Change-Id: I8623ab581639e9f8af6a9ff1eca990518d1b1211
The struct member struct bsc_msc_data->is_authenticated is set to true
permanently. This is a leftover from the sccplite implementation and can
be removed now.
Change-Id: I966a48b383c85345c92c9a1fec791150e96cd7b9
Related: OS#3112
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: Ic3c578347864fa225feb6d2dbe14798b9c19ace0
Related: OS#4138
When we add an EARFCN to to the SI2quater struct we do not add Serving
Cell Priority Parameters. This essentially causes to MS to ignore the
EARFCN because it is still undefined under which conditions the MS
should change to LTE.
Related: SYS#4510
Change-Id: I7eaf7de4386fe8aea404e8a187d8a1f5ed596ead
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
Related: OS#4123
Change-Id: I571a85b6ea53af7661248afd84e61cf34b7b5641
It's quite ugly to have manual "bts=%d" printf-statements all over
the BSC code. Let's change this to use shared logging helper functions
all over the place, whenever we need to log something related to one
BTS or one TRX.
This can also help us as the first step to later add alternative logging
of BTS identities, e.g. by printing the Cell Global Identifier or
LAC+CI, or even a human-readable/vty-defined 'name' of the BTS, rather
than its numeric bts number. With this change in place, we can
introduce such changes at a single location in the code.
Change-Id: I4a7814d164384eecfb6913c31802cf2faead6e6c
If no target cell got selected in a handover attempt, enum value NO_HANDOVER is
used. In that case, do not log a lot of errors saying
"invalid enum handover_scope value: none" -- they are misleading.
Change-Id: I98e748bea58ebb02812b6aaa6431c7d4b813242d
Clarify some in-code comments.
Fix descriptions of some handover timers, which still talked of "MO" and "MT"
handover -- which we now call "inter-BSC out" or "inter-BSC in" instead.
Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
Run "make maintainer-clean" after publishing manuals, not the other way
around. Otherwise jenkins.sh fails when running for the master branch,
because docs/manuals/Makefile gets deleted although it is still needed
to publish the manuals.
Related: OS#3047
Fixes: 471fd92170 ("contrib/jenkins.sh: run "make maintainer-clean"")
Change-Id: I8ba5369b0948b61c68f43d807312c52465119aa5
If a handover fails when the new lchan is already fully established, osmo-bsc
so far caused two BSSMAP Clear Requests to be sent out to the MSC: one caused
by detaching the lchan from the gscon, one from returning the gscon back to
ST_ACTIVE, which detects that no lchan is present and Clears. In fact only one
of those is necessary.
Checking for the presence of an lchan when entering ST_ACTIVE is an earlier
attempt to catch insane situations. Since then, osmo-bsc has acquired other
logic that will ensure sending a Clear Request in all cases, see
gscon_forget_lchan(). Sending another BSSMAP Clear Request in ST_ACTIVE's
onenter is simply not necessary. Drop gscon_fsm_active_onenter() entirely.
Note: the double Clear Request is currently hit by
TC_ho_out_fail_no_ho_detect(), which currently fails and will pass again after
this patch; however, osmo-bsc should actually not release the lchan at all
during this test, see OS#4093. In other words, osmo-bsc behavior for this
scenario as well as TC_ho_out_fail_no_ho_detect() need to be changed, and the
test will, once fixed, not be useful to trigger this issue anymore.
Related: OS#4078
Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
bsc_clear_request() is in fact used only within gsm_08_08.c, make it static to
that file.
Since the gscon FSM, "real" BSSMAP Clear are sent only by gscon_bssmap_clear().
bsc_clear_request() remains in use for legacy code paths in gsm_08_08.c:
- the bsc_filter, i.e. for IMSI filtering;
- in move_to_msc(), from handle_cc_setup(), a code path that is in fact not
entirely clear to me. It seems to be an old functionality to serve multiple
MSCs?
Both of which I personally haven't seen in use, are not tested and should
probably be completely removed.
For now contain legacy code in the static context.
Adjust comment.
Change-Id: Ic89d0afad42e4b11183a13d2dc6b7bbf0b822fd9
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.
We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket. Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.
Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
The library has the declarations since 2011, so it's time to
get them removed from here.
Depends: libosmocore d61d517a2e35f482519561bd325652ee7144679a
Change-Id: I5c8d02605a78c6792f616ad423b4491b83f42545
Run it like this:
COMMIT=master DOCKER_PLAYGROUND=~/scm/osmo/docker-playground OSMO_INTERACT_VTY=~/scm/osmo/osmo-python-tests/scripts/osmo_interact_vty.py ./regen_doc.sh
COMMIT will default to current HEAD.
Change-Id: Iedd1f55d021231d86c19b6f14ff296e3a55148c8
Related: OS#1700
Having different names for the same config setting is misleading, so
let's stick to the one used by osmo-bts.
Change-Id: Ide5ceb5db7403a70313405752579e30d7bb94eac
Since in SCCPlite the BSC-attached MGW is controlled by the MSC, we
don't need this kind of signalling. It's only needed for AoIP.
Related: OS#2551
Change-Id: I802fc65c593e42aaa7a15cecab7a2f2b77ade3ea
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
the 'p_val' variable should represent he 'probabl cause value' and
nothing else. Let's use other local variables for other things.
Change-Id: Ie79279fc1d42cd57e7478820493b250fe38c2f4f
Add a new VTY command "ccch load-indication-threshold <0-100>"
by which the user can configure the threshold after which the BTS
shall send CCCH LOAD IND. It used to be hard-coded to a
default value of 10.
Change-Id: I059fe4627438e26a06e00d84e342b736ab7af440
When displaying the channel (lchan) load, we are interested in the
dedicated channels as available for communication with mobile
stations. If CBCH is enabled, it "steals" one of the SDCCH slots,
so we have to exclude this channel from the count of available
dedicated channels.
Before this patch, A CBCH would show up as "in use" dedicated channel
(so both the total and the in_use count were incremented).
After this patch, neither "total" nor "use" are affected; The CBCH
slot is completely excluded from load statistics.
Change-Id: I606962e4977f122ff05a2d4e756c04c7f38bdaa0
Now that OsmoBTS is generating CBCH LOAD IND messages, let's avoid
spamming the BSC log with notices about receiving this unimplemented
message.
Change-Id: Ida5045ec7a18c1062a3b80a381db52d5c98e9966
Now that OsmoBTS understands about extended CBCH, let's at least
update the BSC side function to allow for other code to generate
such messages.
Change-Id: I77a16b75ce311d63fb022475c8ff25fbbcee7f55
Commit c997ceb750 which added initial code
did use memset(0) on the structure. However, later commit
b407a8aca4 modifying the code forgot to
initialize it, and as a result most of its fields contain garbage.
This results in an MDCX with strange/incorrect values sent when LCLS
loop breaks, breaking TTCN3 test BSC_Tests_LCLS.TC_lcls_connect_break.
Change-Id: Ib1a7d825690db782a5d14f2d8817acf6cb6a52ea
The CID is sent back to the MSC so it can configure its MGW to send
Osmux frames to the BSC MGW using this CID.
Change-Id: I77dfdd965ae828c39a9818669177aefd22bc02f2
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW
to configure the MSC-side MGW conn of a call leg.
Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de
Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
In Change-Id If6d40b2407b87aad2227ea7f15533ef01a3771b3 we introduced
the support for both octet-aligned and bandwidth-efficient mode, and
added a related VTY option about it.
However, we accidentially also changed the default behavior. Without
any explicit configuration, we should behave just like we behaved all
those years before: Continue with octet-aligned mode.
Change-Id: I8b6fd8bec05b35d84ad16275d84f9d363e238d2b
Closes: OS#4002
Neels Hofmeyr
Philipp Maier
Pau Espin
Oliver Smith
Eric Wild
Harald Welte
Daniel Willmann