osmo-bsc is pretty useless without osmo-mgw these days. Let's not
make it a strong dependency, as the mgw could of course be running
on different machines.
Change-Id: I17711c6abdab0fc2d5d3afe1976d4248fd010e83
Event NM_EV_OML_DOWN in allstate will transition to Disabled
NotInstalled state. In the case where that is the current state, there's
really no change but we didn't allow the transition. Let's allow it
since it doesn't hurt and get rid of error messages when a BTS
disconnects.
Fixes: OS#4831
Change-Id: Ia5b7c88ff89e68ec5086d24f6ee20a8b3b2d994d
A header file should only contain declarations, not entire definitions.
The fact that we have 'static const struct ...' definitions in a header
file means that very C file including this header file will get its own
private copy of the entire definition.
The header file should only include declarations, while the actual
non-static definitions should go to a *.c file. Let's fix this.
Also, take a chance to improve readability and apply more consistent
formatting (similar to 'struct hf_register_info[]' in Wireshark).
Change-Id: Ib5949879902acbe1edda577477d9d51a2cc425d1
Closes: OS#4816
This feature apparently assigned a fixed LAC and CI to a specific MSC, but
looking at the implementation was obviously not useful.
Keep the vty commands for legacy compat, now without effect besides logging an
error via vty_out().
Related: OS#4751
Change-Id: I6bee704e7e5d5b6b86473323bae1fa9fce9241ee
Older osmo-bts versions (before FSMs) tended to mimic broken behavior
from nanoBTS. As so, we detect it because SiteMGr becomes Enabled by
default as in nanoBTS, and hence we can manage them also by expecting no
Offline state and sending Opstart (and hence finally transitting to
Enabled) during Dependency state.
Change-Id: Iaa036a2936f609b9b9721b2b4ad8d6deaf023f42
Before they were set with a value of 0, which had no related enum field,
but since in general all comparsions are done against NM_STATE_UNLOCKED
they also hold valid.
The major change in behavior with this patch is upon OML link down,
where gsm_bts_mo_reset() is called on all objects. This way, upon OML
re-establishment we have again all objects as Locked again, which is the
expected default value as per TS 12.21.
Change-Id: I68ae0bc51a565f903b47cf72f3e3dd6f1a2d2651
This bit of code was borrowed from MSC handling, where multiple MSC might tap
on the same SCCP user. There is only one remote SMLC, so there is no need to
osmo_sccp_user_find(), just bind it and be done.
Change-Id: Ia05c27c13dfb9df4f89c87b8477eea4e62fbe349
Previous commits to generalize the a_reset FSM prepare for this commit: use the
same reset FSM for the Lb interface.
Change-Id: I8c03716648f8c69d12d8f0a0bcec14f040d7cff2
To not modify previous SCCP behavior of OsmoBSC, keep the Lb interface disabled
by default. The following configuration enables the Lb interface:
smlc
enable
Change-Id: I01314a29a2cad6f325d9f4687a9dedca6b90a3ce
We don't really expect connection attempts during ST_DISC, but if the user
happens to dispatch those events for whatever obscure reasons, treat them
instead of erroring about an unallowed event.
Change-Id: Ic7c60a40ff25ae647ee659259dfea769bc4592e4
It is not particularly interesting to see a periodic "Sending RESET" to an
unconnected MSC in the logs. De-escalate to LOGL_INFO to make it easier to
configure away these logs.
Sending a RESET ACK is much more interesting, because it indicates that a
connection has been established.
Note that additionally, there will be a log on DMSC LOGL_NOTICE whenever a link
goes up or down, so the RESET logging does not add much crucial information for
operation maintenance, see a_reset_link_up() / a_reset_link_lost().
Change-Id: I86d67d19e20135c4944613c8e99580ef0e22ea8d
So far we would cancel ongoing Paging for a given MSC only after receiving a
RESET message from that BSC. However, the typical operation would be that
OsmoBSC *sends* a RESET and receives a RESET-ACK.
Instead, move the call to within osmo_bsc_sigtran_reset(). This is also called
when OsmoBSC considers the A-interface link to be lost, from the a_reset.c
code, after multiple SCCP connection failures.
Change-Id: Ia14b916be56563d18632c69a833084e71799a468
Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that
it can be re-used on the Lb interface.
Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we
have generally established in our osmo_fsm implementations.
Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c.
A difficulty is setting a proper logging category: the FSM definition allows
only one fixed logging category for FSM state transitions and events. Ideally,
the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log
on DLCS. Since that is not possible, introduce a separate DRESET logging
category. This in fact matches an item on my wishlist, because if a given MSC
is configured but currently not connected, the previous RESET FSM would
continuously "spam" log LOGL_NOTICE messages indicating that it is resending
RESET, and I often want to silence those messages without silencing the entire
DMSC category. This is now easily possible by setting DRESET logging to
LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all
interesting info is still visible on DMSC.
Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
If an A-interface conn is already active (for Location Services), an RSL EST
IND may arrive during GSCON_ST_ACTIVE. Pass it on instead of rejecting. This
allows establishing Layer 3 on an already active A-interface conn.
Change-Id: Ib18a12f8b8bcfb356188b2c0d97d555c1850f23e
The function parse_powercap() contains a nested switch case statement
that is used to populate the variables lu and pwr_lev. Those variables
are used at the bottom of the function later. Unfortunately the (outer)
switch case that consumes the pdisc variable does not put a break; at
the end of its only case "GSM48_PDISC_MM", which eventually causes a
fall through to the default case, which simply returns. Since this can
not be intended, lets add a break to make the bottom code reachable in
case lu and pwr_lev are successfully populated.
Change-Id: I48331cca784d8fa3a5904f2c4cf1555622b319e8
Fixes: CID#214886
When adding the Lb interface, it is necessary to determine an unused conn id
across *all* SCCP users. Prepare adding Lb by moving conn id creation out of
the gscon code and generalizing.
Change-Id: I12fcb18f6e4380f72929cfe7681bac05330a8c9a
Data Link Connection Identifier (DLCI) is defined in 3GPP TS 48.006,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
CC.. .... - control channel identification:
00.. .... - indicates that the control channel is not further specified,
10.. .... - represents the FACCH or the SDCCH,
11.. .... - represents the SACCH,
other values are reserved.
RSL Link Identifier is defined in 3GPP TS 3GPP TS 48.058,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
...P P... - priority for SAPI0 messages;
CC.. .... - control channel identification:
00.. .... - main signalling channel (FACCH or SDCCH),
01.. .... - SACCH,
other values are reserved.
As can be seen, CC bits in both DLCI and RSL Link Identifier
are coded differently. Therefore, we cannot just assign
one identifier to another, we need to do conversion.
I noticed that osmo-bsc indicates DLCI '01000011'B for SMS
messages sent over SACCH/F (SAPI3), and this is wrong because
'01'B is reserved. Let's fix this.
P.S. Interesting coincidence: section 9.3.2 in both documents.
Change-Id: If4d479a54cad467f53b49065c1c435a4471ac7d2
Related: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716
Location Services brings a new scenario to OsmoBSC: the MSC may create an
A-interface conn for a subscriber without an lchan being established (N-CONNECT
from MSC to BSC, so far only for an incoming inter-BSC handover).
If an MS becomes active while an A-interface conn is already established,
associate with an existing conn.
Change-Id: I42290f519a419ed7e8dd02a5ed0a5261b30a51e6
The N-CONNECT.req on the A interface is a possible *consequence* of the event
being handled, namely the incoming RSL ESTablish INDication containing the
Complete Layer 3 message: dispatched by bsc_compl_l3().
If an (LCS related) connection is already present on the A-interface when the
lchan is established, there will be no N-CONNECT but an N-DATA sending the
Complete Layer 3. See BSC_Tests.TC_cm_service_during_lcs_loc_req().
Change-Id: Ic43aabeb0d3c58ac62249ad9d3718363d32508f9
During LCS development, I'm getting use count bugs and would like to see use
token strings to figure it out.
Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
To distinguish between the CN requiring a Complete Layer 3 response, or just
the BSC requiring a TA, allow recording a separate for-LCS paging reason.
Change-Id: Ib28d1599ae4e483727398859d07de4490fbc31f0
Allow starting a paging from elsewhere than a BSSMAP Paging Request. For
upcoming Location Services (LCS), a BSSLAP TA Request from the SMLC may require
triggering a Paging.
Change-Id: Iaff91584699d163bd1963927280ff3a8ddd43073
For LCS, I would like to add an enum indicating the paging reason. Instead of
modifying extremely many function signatures to pass the reason across all
levels of paging, introduce a struct combining these.
Change-Id: I27ca78fc6ff8ef1101554c0a8429e34945ca6f3c
I lost count of how many times the gsm48_hdr got parsed from the msg in the
same compl l3 code path. Here is one less.
Change-Id: I9f15b3e5e7352ef90b4598dadf2ebc0d2665f069
Instead of iterating the llist of gsm_paging_requests first to find an MSC, and
then again right away to mark the paging as served, do both in the same step.
Change-Id: I447e61afc9934f3a5a82f6076e41c155d3328041
Set conn->bsub as indicated by the Mobile Identity. Now the
'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);' becomes useful.
Upcoming patch to support Perform Location Request will use the subscriber to
retrieve an already established conn via the bsub.
Drop fixme in gscon_fsm_init(), MI now extracted and id updated.
Change-Id: I00d4c7e8284b745368a432a7ec176aa99f79db47
Move conn allocation to bsc_compl_l3(), from gsm0408_rcvmsg().
Drop dispatch of GSCON_EV_A_DISC_IND, because a) we did not receive such
DISC.IND, and b) the lchan release will discard the conn in the regular
fashion.
In upcoming LCS patch, bsc_compl_l3() will decide whether to allocate a new
conn or whether a conn from a Perform Location Request already exists for the
subscriber.
In this patch, it becomes clear that the conn->bsub is always NULL in
bsc_compl_l3(), and that the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);'
never has the intended effect. An upcoming patch will change that.
Change-Id: I92af0f0d54c4282d782f2b29d524a64006c3b674