|Age||Commit message (Collapse)||Author||Files||Lines|
NULL or 0.0.0.0 should actually not be used upon connect() calls.
Whoever, it worked so far because osmo_sock_init2() calls getaddrinfo()
on it which does the 0.0.0.0->127.0.0.1 translation.
osmo-msc already passed 127.0.0.1 as default address, so let's do the
Its currently only used by bsc_compl_l3() in same file.
TTCN3 BSC_Tests.TC_ms_rel_ind_does_not_cause_bssmap_reset seems to
sometimes run into a race condition on the order of messages received by
osmo-bsc comming from MSC and BTS.
Usual (expected) scenario):
BTS->BSC EST IND
BSC->MSC CL3 Info
BTS->BSC REL IND
BTS<-BSC DEACT SACCH
BTS<-BSC RF Chan Release
BTS->BSC RF Chan Release ACK
Sometimes CC message and REL IND message are received swapped (because they
are sent by different components asynchronously in TTCN3).
As a result, osmo-bsc was failing to go into CLEARING state and was
unable to send the ClearRequest because CC was still not received.
So the idea is to stay in WAIT_CC until CC is received, then check if
the lchan was dropped and in that case go into clearing state.
In addition to transmission of the ETWS Primary Notification via all
dedicated channels, we also need to send it to the BTS for transmission
via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH
msc_is_connected() already checks against NULL.
Function fsm_reset_ack_timeout_cb() could be called directly from within
a_reset_alloc(), but it's still desirable to deferr the BSSMAP RESET to
be sent asynchronously by the timer upon next main loop step as soon as
possible, so whole process is already configured properly.
1ms needs to be set instead of 0 (immediate asynchronous) because value
0 actually disables the timer.
As a result, moving the state_chg() after the msc->a.reset_fsm
assignment is not really needed, but still makes it more clear that the
pointer will be set upon call of the timer callback.
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
When osmo-bsc receives a paging response via the A-bis interface it
tries to find the MSC which is in charge for the paging. This is due to
the fact that osmo-bsc supports multiple msc connections, which is not
specified by 3gpp specs.
In an MT-CSFB call the MSC pages the UE via the SGs interface. Then the
UE falls back to 2G. It then reports back as MS on the A-Bis interface
with the paging response directly. In those cases osmo-bsc will not be
able to determine an MSC in charge, so we will forward the paging
response to the first configured MSC.
If lchan_select_by_type() fails to find a suitable logical channel,
it would print a message using LOGL_ERROR. This can happen if all
logical channels of the requested type are busy, thus it is not a
error. Let's use LOGL_NOTICE for that.
The LOGPC() is usually used for continuation when printing complex
logging messages (e.g. where using format string is not enough).
In this case, nothing is being printed before calling LOGPC(), so
the logging messages appear without the meta info (time-stamp,
level, category, etc.), for example:
BTS 0 reported connected PCU version 0.7.0.1-2585-dirty
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: osmo-ttcn3-hacks Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
This is required for an upcoming TTCN3 test that plays through various neighbor
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.
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.
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.
Let's add deprecated aliases for backwards compatibility
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.
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.
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.
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.
bsc_clear_request() is in fact used only within gsm_08_08.c, make it static to
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
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.
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
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
Having different names for the same config setting is misleading, so
let's stick to the one used by osmo-bts.
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.
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
the 'p_val' variable should represent he 'probabl cause value' and
nothing else. Let's use other local variables for other things.
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.
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
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.
The log is about an unimplemented CChan message, not a TRX message.
Now that OsmoBTS is generating CBCH LOAD IND messages, let's avoid
spamming the BSC log with notices about receiving this unimplemented
Now that OsmoBTS understands about extended CBCH, let's at least
update the BSC side function to allow for other code to generate
Commit c997ceb750a67baef1a05590febe1c678b287d8f which added initial code
did use memset(0) on the structure. However, later commit
b407a8aca45ba8f3426003c4960ca8bd5cfe60e5 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.
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.
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
Depends on: libosmocore I28f83e2e32b9533c99e65ccc1562900ac2aec74e
Depends on: libosmocore I28f83e2e32b9533c99e65ccc1562900ac2aec74e
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.
For AoIP, the AoIP Transport Layer Address IE must be included in the Handover
Request Acknowledge message, so the MSC can send RTP to the right place. Add
this IE for AoIP.
Depends: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576 (libosmocore)
Depends: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.