Use a talloc ctx directly without an intermediate static buffer.
A subsequent patch will add a name tweak for VAMOS secondary lchans, so
it felt appropriate to first clean this.
Change-Id: Idb922605c15242a2cdc7c34668c845a179a15660
A crash was reported in bssmap_le_tx_reset() sending a RESET with
sccp_user == NULL. Looking at the issue I noticed that when the
sccp_user is torn down, the RESET FSM should also be terminated.
Add bssmap_reset_term_and_free() to the generic RESET FSM implementation
and call from lb_stop() before sccp_user is set to NULL.
Related: OS#5134
Change-Id: If412ef990fcdde8ff88098a5169e86f05cd1c7f0
Whenever SRVCC EUTRAN->GERAN is performed by the CN, it will set the
Last Used E-UTRAN PLMN Id in order for the BSS to inform the MS
about EUTRAN neighbors once the call is over.
The last part (sending EUTRAN neighs) is already implemented, since same
thing is done as per CSFB. However, we lacked the first part, where the
EUTRAN PLMN Id is recorded for later use.
Actually, in both cases, we end up building the list of neighbors
without taking into accound the PLMN value (hence no filtering of
configured neighs), but it only sends such a list if any PLMN was stored
there, which means this patch is still necessary for a quick fallback to
4G after the call is over.
Related: SYS#5337
Depends: libosmocore.git Change-Id I0e55e947b6fef6dad0cf1a6c16b781bef4cc76c5
Change-Id: Ia5008f11a4c36ef8085a2037d4abddd131086e6e
This patch caused major breakage in my setup, with BSC printing at
startup: "(bts=0,trx=0) Failed to generate System Information".
And bts-trx printing all the time:
"sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES
value as SI3 is not available yet, fallback to 1"
This reverts commit c1a5310a3e.
Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
The effects of the neighbor configuration depend on the LAC, Cell
Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that
the neighbor ARFCN list in the System Information is updated.
This may seem rather aggressive: updating the SI of all BTS if only one
config item changed. But indeed even modifying one config item of one
BTS may cause a change in the neighbor relations that many other BTS may
have to the changed BTS. For example, if many BTS configure a
'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all
of those other BTS need to update their neighbor ARFCNs.
Also update the system information even before the BTS are connected and
started up. The main benefit here is that the VTY 'show bts N' command
then already lists the correct neighbor ARFCNs.
In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only
sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg()
spams the log with complaints that a message's dst == NULL. Still return
an error rc in case a TRX is not connected, so that the CTRL command
bts.N.send-new-system-informations accurately returns whether SI were
actually sent to all TRXes.
The desire to have the ARFCNs listed in the VTY before starting up BTSes
came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1,
which fixes a bug that is now much easier to verify being fixed.
Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""
Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""
Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.
This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.
Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
sysmoBTS is a BTS model sold by Sysmocom, which runs osmo-bts.
The later may also work with some other back-ends, including
the genaral purpose SDR hardware. Therefore, it's more
logical to call it 'osmo-bts'.
Change-Id: I93ab4dbf483e0786c35685b75ee4ea83bd591f7b
Calculating the Cell Allocation (basically a bit-vector of all the
frequencies allocated to a cell) on the OML link establishment has
several downsides and potential problems:
* Theoretically, more than 64 ARFCNs can be allocated for a cell
via the VTY interface. The problem here is that the Mobile
Allocation IE cannot contain more than 64 channels.
* The BSC's operator will neither be warned by the interactive
VTY shell during configuration, nor during the startup.
* The BSC will accept such a configuration, but then will be
unable to encode the Mobile Allocation IEs at run-time.
This change aims to improve the situation by separating part of
the logic from generate_cell_chan_list(), and invoking this
part directly from the VTY commands. This way it will become
impossible to configure more than 64 ARFCNs, neither via the
config file, nor interactively from the VTY.
Change-Id: I98211fb0684a973239f5760e1de52a24a1f4c33c
It is observed that a CHANnel ReQuireD with access delay
greater than 63 can be received from the Ericsson RBS.
This results in osmo-bsc sending back a CHANnel ACTIVation with
a Timing Advance IE containing the access delay value.
The RBS NACKs this, leading to a BORKEN Channel.
This patch makes the maximum acceptable access delay vty-configurable
and Ignores CHANnel ReQuireD RSL Messages with Access Delay IE greater
than that configured. Default value is 63.
Related: OS#5096
Change-Id: Ie8987bcc0e43921bc753162b77a0efc68799b3ce
The neighbor configuration storage is fundamentally broken: it requires
all local cells to be configured before being able to list them as
neighbors of each other. Upon config write-back, the neighbor config
however is placed back inline with the other config, and hence a
written-out neighbor config no longer works on program restart.
The cause of this problem is that the config is stored as explicit
pointers between local cells (struct gsm_bts), which of course requires
the pointer to exist before being able to reference it.
Instead, store the actual configuration that the user entered as-is,
without pointers or references to objects that need to be ready. Resolve
the neighbors every time a neighbor is needed.
Hence the user may enter any config at any place in the config file,
even non-working config (like a BTS number that doesn't exist), and the
relation to actual local or remote neighbor cells is made at runtime.
Abort program startup if the initial neighbor configuration contains
errors.
Related: OS#5018
Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
So far the list of penalty timers was stored for an opaque target
pointer. That was either a gsm_bts pointer for a local BTS, or a cell
identifier list pointer for a remote-BSS cell.
Reasons to refactor penalty timers:
- The cell identifier list pointer came from the neighbor configuration
storage, but the way cell neighbor config is stored will change in a
subsequent patch. There will be no more cell identifier lists there.
- Storing object pointers is inherently unsafe -- if an object gets
removed and another gets allocated, the penalty timer could
theoretically remain in force for an unrelated object.
Rather store penalty timers for specific Cell IDs. Since remote-BSS
neighbors can be requested by a cell identifier *list*, use a
gsm0808_cell_id_list2 as key in the list of penalty timers.
Fix handover_test.c: have different CI for each local BTS. So far it was
the same LAC+CI for all BTSes, which now would make the test fail,
because any penalty timer would appear to apply to all local cells.
Related: OS#5018
Change-Id: I72dd6226a6d69c3f653a3174c6f55bf4eecc6885
Allow selection of RX diversity from VTY
Options are a,ab,b
Default is 'a' so there is no change from previous behavior
Change-Id: I430762b8cfa51060841d90ba4446de73bd557c6c
This commit adds support for Selection of syncronization source.
Options are internal for E1 and external for GPS
Change-Id: Ia3d1acd6b3442238b35fc911092e12a6ac989adb
The function is not really handover specific, and will be used in other
places in subsequent patches.
Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
On lchan activation, we already know the Timing Advance in most
situations: from the Channel Request RACH, or from a previous lchan in
the same cell. Place this information in lchan->activate.info.ta.
So far, the lchan->last_ta (until recently called rqd_ta) was used to
store the initial TA for channel activation -- move the initial TA to
lchan->activate.info.ta, for proper scoping.
Only an inter-cell handover does not yet know a Timing Advance (until
the Handover Detection RACH is received), so indicate
activate.info.ta_known = false for that case.
If ta_known is false, do not include an Access Delay IE in the Channel
Activation message, ensuring that the BTS does not use an arbitrary TA
that is likely inaccurate.
The effect for OsmoBTS is that we will *not* start the downlink SACCH on
channel activation for inter-cell handover, but will wait for a HO RACH
first, and then use the correct TA when enabling downlink SACCH.
Related: OS#4008 SYS#5192
Change-Id: I986bf93e8acd6aef7eaf63ac962480b680aa894f
Originally, the lchan stored only the Timing Advance from the initial
channel request, hence it was called rqd_ta.
Since quite a while now, rqd_ta also stores the most recent Timing
Advance from each received Measurement Report. So rename to last_ta.
This is cosmetic preparation for an upcoming patch that clarifies
whether the Timing Advance is already known for Channel Activation.
Change-Id: I1049526a173819baeb4978db5bf018ba3f1006a0
This is required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Other BTS are not enabled by default since NACC support is not known to
work nor tested there.
Depends: libosmocore.git Change-Id I61991266b95d0c13d51b47906cc07846e9cf1390
Related: SYS#4909
Change-Id: If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28
Add bool log argument to lchan_avail_by_type() and omit logging when
passed as false. From handover_decision_2.c, pass 'log' as false, from
all other callers pass true, i.e. for unchanged behavior.
Rationale:
Usually, we use lchan_avail_by_type() to select a new lchan to initiate
actual service. For that, it is interesting to see how osmo-bsc decides
which lchan will be used.
For handover decision 2, we since recently call lchan_avail_by_type()
for each and every handover candidate, to determine whether it will
occupy a dynamic timeslot or not (to know whether we would congest the
other TCH kind). So this happens for each permutation of source lchan
and target cell. That produces a lot of logging, out of proportion of
being useful to the maintainer.
Change-Id: Ia403f8fc853ca9ea9e81f7a7395df6b23845ebed
This new CTRL interface allows users of this BSC (such as attached PCU)
to gather neighbor information.
This interface is needed for PCU to translate ARFCN+BSIC keys provided
by MS in the Um side into CGI + RAC keys used to identify target cells
in RIM procedures against SGSNs on the Gb interface.
This patch extends the already existing neighbor information storage in
the VTY by allowing storage of CGI + RAC (RAC couldn't be stored
beforehand).
Related: SYS#4909
Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
The existing code uses short-lived FSMs which are allocated straight
before START, and which are free'd after DONE state is reached.
While that works, it makes state introspection a bit hard, as one
cannot show the FSM states, etc.
Let's change to a different model where the per-OM2k-MO FSMs are
always around (in state INIT after object creation). While at it,
also introduce a RESET event that can reset each FSM instance back
to INIT state, i.e. in case of OML link failure.
Change-Id: Ia37cffff5c451e1d79a52ccae41ab5718b4661d4
This allows a given BTS model driver to initialize data structures
specific cor this BTS instance (or a TRX for this BTS instance).
Change-Id: Icbad9cdc12221c9ad997267d77e5414edcbac538
This change introduces two optional function pointers:
- power_ctrl_enc_rsl_params() - this function will be called by the
A-bis/RSL code in order to encode MS/BS Power control parameters
for CHANnel ACTIVation and MS/BS POWER CONTROL messages.
- power_ctrl_send_def_params() - this function will be called for
each transceiver on A-bis/RSL link establishment in order to
send default MS/BS Power control parameters.
Change-Id: Iba3ad5d8d549a6676050272f85b21c9b4c219d21
Related: SYS#4918
libosmocore > 1.4.0 is required (master, not yet released) since some
fixes done in osmo-bsc code where not cherry-picked to libosmocore APIs.
Depends: libosmocore.git I2bf5635b8536b11d69774d17ac1908019633e3af
Change-Id: I7d5e5ddd174463c2a3d957c8245d2911ce013681
Steve Langasek <steve.langasek@ubuntu.com> submitted some patches
against downstream osmo-bsc 1.3.0 because some possible null derefences
were detected by the compiler on Ubuntu s390x. Code has eveolved since
then and patch doesn't apply directly anymore, since related code
changed (we now use osmo_count in bsc_subscr_get).
The compiled allegedly claimed some null dereference in gsm_lchan_name.
In general code using that function seems to be doing checks for
existing lchan before calling it, or assuming the lchan pointer is not
null, so I couldn't find any major issue.
However, let's add a OSMO_ASSERT to make sure we can easily identify the
issue if an issue ever happens there, since the gsm_lchan_name should
clearly only be called on non null pointers.
Change-Id: If4d12cb1d95ee2a89244bb8f27df839871667387
This is needed in order to to proper feature support verification for
IPv6 when configuring the NSVC.
Before this patch, there could be a race condition where NSVC FSM
checked for BTS feature BTS_FEAT_IPV6_NSVC before it was negotiated
through BTS Get Attributes (Ack).
Fixes: OS#4870
Change-Id: I7c207eee0e331995ae04acec014fbd13d4d16280
Before this patch, Get Attributes was sent quicklyafter the OML link
became up, even if the BTS/BB_TRANSC objects were still powered off,
which is wrong since attributes should only be available after the
objects transition out of the Power off state.
Furthermore, information about get attr response already received will
be required in future patches to delay NSVC setting.
Related: OS#4870
Change-Id: I8ec39c7e1f956ffce9aecd58a5590c43200ba086
The only real 1-1 relationship between BTS NM objects is the one between
GPRS Cell and BTS (which is actually a BTS cell).
In our current osmo-bts implementation we don't care much since we only
handle 1-cell BTSses, but let's make the data structure organization
more generic.
Implementation notes:
The gsm_bts_sm is moved to its own file, APIs to allocate are added and
the new public object is hooked correctly in the allocation process of
osmo-bsc.
Change-Id: I06461b7784fa2a78de37383406e35beae85fbad8
In order to activate FACCH/SACCH repetition on the BTS, the classmark 3
IE in the CLASSMARK CHANGE message must be parsed and depending on the
Repeated ACCH Capability bit the RSL_IE_OSMO_REP_ACCH_CAP is added to
the RSL CHAN ACT und RSL CHAN MODE MODIFY. Since
RSL_IE_OSMO_REP_ACCH_CAP is a propritary IE, it may only be added for
BTS type osmo-bts.
Change-Id: I39ae439d05562b35b2e47774dc92f8789fea1a57
Related: OS#4796 SYS#5114
To be able to control the FACCH/SACCH repetition behavior inside the
BTS a one byte flag is sent to the BTS together with the
RSL_IE_OSMO_REP_ACCH_CAP IE. This patch adds the necessary VTY commands.
The sending of the flag is implemented in a follow-up patch.
See also: I39ae439d05562b35b2e47774dc92f8789fea1a57
Related: SYS#5114, OS#4796, OS#4794, OS#4795
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Change-Id: I083eaa2c30478912426e9c24a506f0b88836e190
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
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Keith Whyte
Harald Welte
Philipp Maier