We don't want to have duplicate EARFCNs in the config file.
The desired behavior is modifying existing EARFCNs.
Change-Id: Ia2fd8bd86d9f093967c1b0b0135151d2d5386dc1
Related: SYS#6401
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I37f078bdc17e128298b956f493ff5c03ef476f98
This was so far workarounded in tests by manually freeing the fields.
However, in follow-up patch the paging queue will also be properly
freed, so free of the counters needs to be previously fixed too so that
counters are freed at the right point of time.
Otherwise, during paging queue flush, counters are used and would crash
because they were freed before the BTS object in each test's bts_del().
Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I030c88545cdc71b3ad9e83f9c2ba7b27177c2ac8
According to 3GPP TS 44.018, section 10.5.2.1b.2, only ARFCN values
in range 1..124 can be encoded using the 'bit map 0' format. Before
this patch, ARFCN values belonging to E-GSM band (0, 975..1023) were
ignored in bitvec2freq_list(), and thus not present in the resulting
Cell Channel Description IE.
Change-Id: I17739e6845cd84e2a81bc406dd532541f7c52cb6
Related: SYS#5854
This commit demonstrates what happens when a cell has channels in
both P-GSM and E-GSM bands (case 'c'). As can be seen from:
Case a) only the BCCH carrier: 10
Case b) more carriers from P-GSM band: 1 3 10 64 99 124
Case c) more carriers from E-GSM band: 1 3 10 64 99 124
in both cases 'b' and 'c' we have the same set of ARFCNs. Carriers
from the E-GSM band are not present at all. This is wrong and will
be fixed in the follow up change(s).
Change-Id: Ied0519c70501f105673a9b36657101063d275058
Related: SYS#5854
The value ncc_permitted is preset in osmo_bsc_main.c from
bootstrap_bts(). It is a constant value that also cannot be changed via
the VTY. Therefore it should be set from bts_alloc(). This also fixes
the problem that when the BTS is added at runtime from the VTY. BTSs
added at runtime would have an all zero ncc_permitted until the next
restart of osmo_bsc.
Change-Id: I9f02277d7b4b4bcb383e749435416a0b22efd5e8
Related: SYS#5369
These are not needed anymore since we re-introduced libbsc, specially to
avoid all this churn.
Some specific methods are explicitly required to be overwritten by
tests, so we specificially mark those with __attribute__((weak)) in
order to be able to overwrite them.
This is the last step towards fixing interdependency mess of symbols and
stubs, and requires previous patches in order to have tests apssing
fine.
Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
This is used inside group of files forming libbsc (shared files used by
several apps). Let's instantie only once inside a file from libbsc
instead of doing so on each binary.
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I9b287aa492ca6aae5fc56133e1510aff3146fe25
Every time a new file is added in osmo-bsc, it ends up being a pain
because its .o file has to be included to other tests/util binaries, or
stubs need to be added.
Let's instead bundle all .o files together in an .la file and pass that
around.
Change-Id: If91dc589ea1e476da105b58846d1c3e720a439e1
This code is available in libosmocore since ~3 years ago
(fdf8b7b1beeb0cda262c5fb060a933aa7edb5e9a). Let's use it instead of
maintaining duplicated code which diverges over time.
Depends: osmo-bsc.git Iae058c35506bc25c9f4790889b89ac46aea664b6
(contains cherry-pick of bug fixed in osmo-bsc.git).
Change-Id: I53ad3067623077b6a8737c2a0aecc8b46bf71a15
Prepare for VAMOS, where there will be secondary "shadow" lchans serving
secondary MS on the same timeslots. For those, RSL messages will need to
reflect a different stream ID aka TEI, via an rsl_link_vamos.
Make sure that every code path that sends an RSL message for a specific
lchan selects the RSL link via the new function rsl_chan_link(). When
VAMOS is implemented, this function can select the proper RSL stream.
Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not
missing any uses of the RSL link, and clarifies the code.
Related: SYS#5315 OS#4940
Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
Firstly, do not store the encoded AMR length-value bits in gsm_lchan->*
before an activation/modify has actually succeeded.
And secondly, do not store the AMR LV structure in struct gsm_lchan at
all, but only generate the TLV exactly when a message is being composed.
In gsm48_multirate_config(), generate the LV directly to a msgb instead
of a static buffer first. gsm0408_test.c expected output verifies that
the generated LV bytes remain unchanged.
In lchan_mr_config(), introduce a target mr_conf argument, so that Chan
Act and Mode Modify may generate the filtered AMR config to different
locations (lchan->{activate,modify}.mr_conf_filtered).
Only after receiving an ACK for Activate/Modify, set
lchan->current_mr_conf from lchan->{activate,modify}.mr_conf_filtered.
Use the properly scoped lchan->activate.mr_conf_filtered for Chan Act,
lchan->modify.mr_conf_filtered for Mode Modify and
new_lchan->current_mr_conf for Handover Command as appropriate.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie57f9d0e3912632903d9740291225bfd1634ed47
In osmo-bsc, gsm48_multirate_config() is used in a way where the struct
amr_mode *modes always points at the full set of configured modes, and
only the AMR bits m4_75 thru m12_2 are unset to filter the used modes.
In the current test, the bits are unset to filter, but also the struct
amr_mode *modes is reduced accordingly. Instead, keep the modes fully
populated and unset only bits, like osmo-bsc does in practice.
The test results should not (and do not) differ.
Change-Id: I545de6fb66a4b74a3f08899795b4b4d9c4538f58
It's acceptable to verify an outcome by printing to an expected output.
It's unacceptable to commit those expected outputs without first
verifying that they are in fact correct!
In this case, the output has obviously not been even read, since the
length byte clearly indicates that one byte is missing from each buffer
dump.
I have now verified by hand against 3GPP TS 44.018 that each one of the
generated octets are indeed correct.
Change-Id: I92fcc7afe018a4a8dc91f0f2167e3a7835f623c9
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
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
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
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
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
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.
Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
The function initializes the struct owned by a bts, so it makes sense to
have it done there instead of somewhere else later.
It was most probably put in bsc_vty when it was initially introduced
because of all the data structure and object file mess I untangled
during last set of patches.
Change-Id: I66c4b208583e92070793183b83b3a7b7edf6ba00
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
Related: OS#4652
Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
Testing these functions is actually done in libosmocore. Also, with new
osmo_mobile_identity API, the functions being tested are marked deprecated. So
drop the test.
BTW, the test contained an IMSI of 16 digits, which is too long, yet was
expected to succeed. GSM23003_IMSI_MAX_DIGITS == 15. I first considered fixing
the test data, but the test is in the wrong place here anyway.
Change-Id: I902d31ecd72d71892fad7945f695a9f1fb403bf2
Lots of times, the MS power class is unknown until after the first
channel has been activated, at which point the MS power class is
received in messages such as LU update or CM Service Requet.
Since the MS Power level is sent upon CHAN ACT, the only way to
communicate the change of maximum MS Power (based on MS power class)
after CHAN ACT is to send a MS Power Control msg. Let's do that.
Related: OS#4244
Change-Id: I3d6b75578e5cb9b2ad474a0ad01362d846ebe135
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
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API
and use libosmocore's osmo_tdef* API instead.
The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be
able to use it in osmo-msc for inter-MSC handover.
When adding osmo_tdef, the new concept of timer groups was added to the API. It
would make sense to apply group names here as well, but do not modify the VTY
configuration for timers. The future might bring separate groups (or not).
Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore)
Change-Id: I66674a5d8403d820038762888c846bae10ceac58
3GPP TS 04.08 V7.21.0, section "9.1.34 System information type 2ter"
states:
"""
This message has a L2 pseudo length of 18. This message may be sent
by the network with either a L2 pseudo length of 18 or some other
value. A mobile station that does not ignore this message shall not
discard the message due to a received L2 pseudo length different
from 18.
"""
Change-Id: I45cb217ebdf89b82b0f37f38eef7a1e3a651f541
3GPP TS 04.08 V7.21.0, section "9.1.33 System information type 2bis"
states: "This message has a L2 pseudo length of 21.".
Change-Id: I623c64c446c0973e939e9f1cba0a4d4d2f4f7237
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
Harald Welte
Vadim Yanitskiy
Pau Espin
Philipp Maier
Neels Hofmeyr