|Age||Commit message (Collapse)||Author||Files||Lines|
This is way too large, yet the typical tangle of modification onto
modifications needs to be squashed to make sensible bits of them later for
If multiple BTS are configured with identical ARFCN+BSIC, handover cannot
possibly work. Add warn_on_arfcn_bsic_collisions() and when collisions are
- exit right away on program startup.
- warn on vty bts node-exit (go_parent_cb()), i.e. when ARFCN+BSIC collide
implicitly from default values.
- warn on vty bts/base_station_id_code cmd coming from telnet vty,
i.e. when the user actively configures colliding BSIC.
- warn on vty trx/arfcn cmd coming from telnet vty,
i.e. when the user actively configures colliding ARFCN.
When warning, warn on all of:
- DHO log,
- vty_out() in case a vty instance is passed (i.e. from interactive vty).
It's better to log this once too often than let the user miss it.
Rationale: when I started to implement ttcn3 tests for inter-bsc HO, I saw that
the new code based on ARFCN+BSIC would cause a handover request intended to go
from BTS 0 to BTS 1 to instead go from BTS 0 to back to BTS 0 -- because of
identical ARFCN+BSIC in the config of ttcn3-bsc-tests. Such a config badly
confuses handover: measurement reports interpreted to come from the wrong cell,
all handovers attempted to go to the first BTS (sometimes correctly, sometimes
wrongly), in short, non-obvious failure across the handover board. The network
would appear to work well, but occasionally a handover would kill a call
without apparent reason. It seems worthwhile to prevent such misconfiguration
as early as possible, and even allow previous ARFCN+BSIC misconfiguration that
used to work to instead break now (only upon reading config during program
startup, to not cause program exit just because a user introduces a temporary
collision in an interactive vty session).
Provide different sets of counters for intra-cell assignment, intra-BSC
handover, and inter-BSC MO and MT handover.
These will get triggered in an upcoming refactoring of handover code paths (to
accomodate inter-BSC handover).
Commit "dyn ts, bts_ipaccess_nanobts.c: init PDCH on Chan OPSTART ACK"
introduced signal S_NM_OPSTART_ACK and passed the FOM header to identify the BTS
by. But the FOM header's BTS number is zero on each Abis/IP link, and the BTS
and TRX are actually identified by msgb->dst == e1inp_sign_link, member trx. So
the initial implementation associated *all* Channel OPSTART ACKs with BTS 0.
Pass the entire msgb as S_NM_OPSTART_ACK signal argument, implement a
abis_nm_get_ts() to retrieve the proper timeslot and use that during timeslot
Related: OS#3351 OS#3205
When we receive a RSL CONN FAIL IND, it may be that this happens
before any RLL is established (and hence a lchan->conn exists),
or after the RLLs have been shut down (and hence a lchan->conn doesn't
So in this function, it is not legal to unconditionally dereference
3GPP TS 48.006 section 9.2 states clearly that any SCCP connection
release must be initiated by the MSC.
for bsc_subscr_conn_fsm, this means that even after sending the
BSSMAP CLEAR COMPLETE, we must not terminate the FSM, as this would
cause a N-DISCONNET.req to be sent to the stack for the associated
The bsc_subscr_conn_fsm instances will hence stay alive until the MSC
eventually decises to release them.
We use the newly-introduced logging_vty_add_deprecated_subsys() from
libosmovty to make sure old config files will still parse even after
In Change-Id OSI6b7354f3b23a26bb4eab12213ca3d3b614c8154f we introduced
a function called osmo_ss7_asp_rx_unknown() which was supposed ot
override a weak symbol in libosmo-sigtran. However, the related change
in libosmo-sigtran (I8616f914192000df0ec6547ff4ada80e0f9042a2) was
modified later on to use explicit registration of a call-back function
instead of weak symbol override.
Let's adopt the osmo-bsc code to make use of this explict call-back
In Change-Id I6b7354f3b23a26bb4eab12213ca3d3b614c8154f we removed
the "dest" vty command, but we should simply ignore it and print
a related warning during start.
Will be used in upcoming inter-BSC handover.
Do not invoke OSMO_STRINGIFY() with arbitrary names, just quote instead.
The idea was that OSMO_STRINGIFY() avoids typos by ensuring well-defined names
are stringified, but this highlights that OSMO_STRINGIFY() is in fact usable
with completely arbitrary arguments and actually lacks the validation part :/
Add lchan and timeslot FSM charts to illustrate planning of how osmo-bsc should
handle lchan assignment and release.
Modify assignment, handover, lchan-release charts according to the new plan.
Another small step towards being aware of the subscriber identity.
Any connection initiated by paging will subsequently log the subscriber's
identity -- of course not necessarily the IMSI, if paging was done by TMSI.
This is only for Paging, not the Paging Response; for that see, L3 Complete.
This is a tiny step towards being aware of a connection's subscriber identity.
Iff the Layer 3 Complete message contains an IMSI, associate a bsc_subscr with
the conn, so that subsequent logging and possibly meas_feed contains the IMSI.
For any L3 Complete using TMSI, this has no effect whatsoever.
Keep the bsc_subscr associated with the conn as long as possible, to benefit
logging, which then contains the subscriber identity (if any).
Instead of silently setting the use count to 1, instead increment with an
explicit bsc_subsct_get(), which then logs the event along with the place that
created the subscriber.
The guts of bssap_speech_from_lchan() and lchan_to_chosen_channel() have been
moved to libosmocore; call those instead.
The return value of bssap_speech_from_lchan() used to be -1 on error, now the
error value is 0. The only caller did not handle -1 properly, but fed it
directly to a uint8_t.
On gsm0808_chosen_channel() error, log the error. Proper handling is missing.
Fixing the error handling in send_ass_compl() is a separate issue: currently it
is limited to logging, there is no way to return an error yet, nor any actions
to take on error.
Depends: Icca23940791f97fa64dbc3f2734270b99f9550c1 (libosmocore)
In each code path within rsl_rx_chan_act_nack(), do separate logging of the
NACK to ensure proper termination of each log line.
When receiving a Chan Act NACK, we possibly mixed a LOGP() within an
unterminated other LOGP() that had not been ended with a LOGPC() yet.
When the BTS responds with a Chan Act NACK, i.e. the lchan could not be
activated, immediately signal Assignment Failure to the MSC (in
In handle_chan_nack(), adjust log: instead of waiting for timeout, we now
signal Assignment Failure.
Drop misleading logging from bsc_assign_fail(): instead of transmitting the
Assignment Failure message, it actually signals an FSM event. Leave logging of
that to the FSM logging.
Call one common function to signal Assignment Failure and transition back to
struct bsc_api was used to provide an abstract API for both osmo-bsc and
osmo-msc, between BSC and MSC. That's no longer needed, so get rid of it, to
prevent code turbulences it creates for no reason.
Move all of libbsc/ into osmo-bsc/, and separate/move some implementations to
allow linking from utils/* and ipaccess/* without pulling in unccessary
Some utilities use gsm_network and gsm_bts structs, which already include data
structures for fairly advanced uses. Move initialization that only osmo-bsc
needs into new bsc_network_init() and bsc_bts_alloc_register() functions, so
that the leaner tools can use the old gsm_* versions without the need to link
everything (e.g. handover and lchan alloc code).
In some instances, there need to be stubs if to cut off linking "just before
the RSL level" and prevent dependencies from creeping in.
- abis_rsl_rcvmsg(): the only program currently interpreting RSL messages is
osmo-bsc, the utils are merely concerned with OML, if at all.
- paging_flush_bts(): ip.access nanobts models call this when the RSL link is
dropped. Only osmo-bsc actually needs to do anything there.
- on_gsm_ts_init(): the mechanism to trigger timeslot initialization is related
to OML, while this action to take on init would pull in RSL dependencies.
utils/ and ipaccess/ each have a stubs.c file to implement these stubs. Tests
implement stubs inline where required.
From src/utils/, src/ipaccess/ and tests/*/, link in .o files from osmo-bsc/.
In order for this to work, the osmo-bsc subdir must be built before the other
source trees. (An alternative would be to include the .c files as sources, but
that would re-compile them in every source tree. Not a large burden really, but
unless linking .o files gives problems, let's have the quicker build.)
Minor obvious cleanups creep in with this patch, I will not bother to name them
individually now unless code review asks me to.
1) libbsc has been separate to use it for osmo-nitb and osmo-bsc in the old
openbsc.git. This is no longer required, and spreading over libbsc and osmo-bsc
2) Recently, ridiculous linking requirements have made adding new functions
cumbersome, because libbsc has started depending on osmo-bsc/*.c
implementations: on gscon FSM and bssap functions. For example, neither
bs11_config nor ipaccess-config nor bts_test need handover_cfg or BSSMAP
message composition. It makes no sense to link the entire osmo-bsc to it, nor
do we want to keep adding stubs to each linking realm.
The TEST_SCAN_TO_MSC is completely unused, but still the code linked
bsc_scan_bts_msg() for the unused code path. This is unlikely to ever be
expanded. Remove TEST_SCAN_TO_MSC and reduce linking requirements.
(I am this close to dropping the test entirely to avoid continuous linking
annoyance, but ok, since nothing else tests timezones AFAIK, keeping it.)
Rationale: channel_test is trivial and useless, probably only exists as a
legacy from openbsc.git.
- it tests two printf()s of "(bts=45,trx=0,ts=3,ss=4)", hardly useful.
- it tests ts_subslots() behavior for dyn ts, which will soon be replaced by a
most trivial mapping that does no longer need complex dyn ts state
evaluation (when introducing the new timeslot FSM to handle dyn TS switchover).
- All it does is compose four Paging Requests and feed it into the osmo-bsc
bssap_udt, and expects the cell identifier to be decoded properly.
- To do so it employs a comparatively huge linking effort. This linking effort
is becoming annoying in my ongoing work and is just not worth it.
- We have comprehensive cell identifier tests in ttcn3, verifying that the
proper cells are paged, and that actually for *all* cell identifier types.
Only count paging responses which can be mapped to an active paging.
Unsolicited paging responses which do not correspond to an active paging
would increment the 'paging response' counter. This means the number of
paging attempts could be smaller than the number of paging responses,
which can look confusing in the 'show statistics' VTY command.
If we receive a BSSMAP ASSIGNMENT REQ for a speech channel
containing only a CIC but no AoIP transport layer address, then that's
illegal and must be rejected.
In Change-Id If362a0084de452727cd063063dfb645eca2f9beb we re-introduced
accepting CIC-only ASSIGNMENT REQ, but we failed to verify that this
actually only happens over a SCCPlite A interface.
This fixes the BSC_Tests.TC_assignment_cic_only testcase.
The user might not want to enable LCLS support for administrative
reasons. So let's keep it disabled by default, until somebody
explicitly enables it with "lcls-mode mgw-loop".
In the future, we may want to introduce a "lcls-mode bts-loop" where we
don't loop at the BSC-colocated MGW, but where we instruct the BTSs to
feed the RTP directly to each other. This would require a
falt/transparent IP routing between the BTSs in the RAN.
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
We now print information such as
* SCCP connection ID
* MSC number
* handover decision2 fail count
* channel mode (SIGN/SPEECH)
* MGW endpoint
* secondary lchan (if any, e.g. during assignment)
* don't crash if conn->lchan == NULL