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
Prepare to include gsm_08_08.h in more files in the following patch,
without wrapping these functions it won't build anymore. Remove the
unused stub for bsc_assign_compl() while at it.
Related: OS#4393
Change-Id: I6cb84f493204e393fd719148f54b8bbc173588a4
This patch affects *only* on osmo_fsm instance IDs, which are visible on
the CTRL and VTY interfaces to identify FSM instances, and in the log.
Why bother: An upcoming patch wants to replace gsm_pchan_ids[] with
osmo_fsm_inst_update_id_f_sanitize(gsm_pchan_name(x)), this is an
explicit step to match gsm_pchan_names[].
Change-Id: I4a540744cced466f0ca4fc605db4d0ec14ee8e87
Show the timeslot_fsm, lchan_fsm, assignment_fsm fi->id strings.
The IDs include the current pchan configuration. I want to tweak the
composition of these in an upcoming patch, so the test should show
whether any FSM IDs change from that.
Change-Id: If369f23fa140b9d7792f5a511815cbbd14b371e9
We already use "OSMO_DYN" as C name for "fully dynamic" timeslot config,
when working with osmo-bsc.cfg I dearly miss this short name, it is a
pain / has become ridiculous to write 'tch/f_tch/h_sdcch8_pdch'.
Introduce 'dynamic/osmocom' and 'dynamic/ipaccess' as default names for
our dynamic timeslots on VTY and CTRL. The old 'tch/f_tch/h_sdcch8_pdch'
and 'tch/f_pdch' are still supported.
Change-Id: I37719edd867c777d1ce944b8e2f1efffac38f00e
I'm going to add a regression test that probes lchan_fsm. I noticed that
I have to call lchan_fsm_init() for osmo_fsm_register(). Let's make this
implicit as we usually do now, to not have to register FSMs in tests.
Change-Id: I58760e743c78a370aedc9720f265c0f8da5c2045
Prepare some basic tests for 'timeslot' / 'phys_chan_config', because an
upcoming patch will add the 'osmodyn' alias, and this test shall show
the changes on the VTY.
Change-Id: I2c4aab90bcbc9019ca004fb1d4945476edbb7363
*.vty tests are picked up by the Makefile.am by means of a wildcard --
they are run when they are there. So when you forget to add it to
EXTRA_DIST, it will be run in your local build tree, but it will be
silently omitted from a distribution tar, and nothing will complain
about it gone missing.
Instead, also use a *.vty wildcard in EXTRA_DIST. So any *.vty test
added to the git source will both be run *and* included in distribution
tars implicitly.
Change-Id: I47c9011b5e0e2886d221e34e6aa281d1dd0495c7
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
Add a test that shows that the ARFCN of neighbors from the measurement
report is not parsed correctly for multi-band BSS. A follow-up patch
fixes it.
Related: OS#5717
Change-Id: Ie18e341f236bab5cf60d3a342c15c96cc848a7c2
New VTY commands have been added recently to the "mgw" node which drop
the redundant "mgw" prefix on each fo them.
Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
Related: SYS#5987
Change-Id: I71e49cb4d6c2fe54a895aab0b0ba5acc4e57c253
Let's avoid guiding users towards the old deprecated VTY interface.
Line "mgw endpoint-range" is removed since it's nowadays deprected and
implemented as a NOOP.
Related: SYS#5987
Change-Id: Iff74a9efca2a0a2c38d5ac39df704b2b211fd906
The LAC value currently configured is now printed as hexadecimal value
too.
It can still be entered as a decimal value in order to keep backward
compatibility, though the hexadecimal one is now preferred.
Related: OS#5631
Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4
Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
It is really difficult right now to find out where all the different
stuff relative to operation and lifecycle of an lchan is. Let's move
everything to its own file to have all the related defines and logic
together.
Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
It's of no use for the test. Furthemore, it was being created outside
the build direcory, being left there.
Change-Id: Iaeee14a01badb8439bc8893ba8be06b13e4318f3
This change implements an additional channel allocation mode, which
can be employed during a TCH channel allocation for assignment.
Selection between ascending and descending order is performed
depending on pre-configured parameters:
* Uplink RxLev threshold and number of samples for averaging,
* C0 (BCCH carrier) channel load threshold.
This is useful in setups where Tx power of the RF carriers cannot be
adjusted +dynamically at run-time and thus BS Power Control cannot
be performed. In such setups the BCCH carrier is transmitting at
relatively higher power than the other RF carriers. The key idea
is to allocate channels in a smarter way, so that UEs with poor signal
would get channels on carriers with high Tx power, while UEs with good
signal could use carriers with lower Tx power.
Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d
Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
A follow-up patch implements a special channel allocation mode, which is
only working for assignment (basically TCH selection for a voice call).
This mode cannot be employed for initial CHANNEL REQUEST or handover due
to the absence of an already established lchan.
Adding this mode to the existing VTY command syntax would be confusing:
channel allocator (ascending|desscending|dynamic)
^^^^^^^
so this patch extends the VTY syntax in a way that it becomes possible
to configure different channel allocator modes for different cases:
OsmoBSC(config-net-bts)# channel allocator mode ?
set-all Set a single mode for all variants
chan-req Channel allocation for CHANNEL REQUEST (RACH)
assignment Channel allocation for assignment
handover Channel allocation for handover
The old command syntax, which is basically 'set-all', is kept for
backwards compatibility, but marked as deprecated.
Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f
Related: SYS#5460
Current regex 'handover' is way too restrictive because it completely
forbids the use of word 'handover'. Adding new VTY commands with this
word in the syntax makes this VTY test fail.
Use regex '^\s+handover', which only matches lines starting with
some whitespace and the word 'handover'. Lines simply containing
the word 'handover' will be ignored.
Change-Id: I8a1550c6c97437832e05b6b4bebbcc33c2fa3d46
Related: SYS#5460
For statistical clarity and site tuning, it is sometimes
desirable to completely disable the use of TCH for signaling.
In the existing version of this VTY command, there is no way to
accomplish this. We can only restrict TCH for signaling non-voice
related actions.
This patch deprecates 'allow-tch-for-signalling (0|1)' and
adds 'tch-signalling-policy (never|emergency|voice|always)' to
provide more options.
Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
Drop "to this MSC" from the NRI_STR, as it is not only used for MSC
specific configuration, but also in cfg_net_nri_* which affect all MSCs.
Drop "for this MSC" from the description of cfg_net_nri_null_del, it
affects all MSCs (unlike cfg_msc_nri_del).
Change-Id: Ic8888775a965b6d607af51b9359bd8ffc2834e16
The all_allocated_update_bsc() does inefficient iterating to count
active/inactive lchans, which scales badly for high numbers of TRX
managed by osmo-bsc.
We need to update the all_allocated flags immediately (periodic counting
alone would suffer from undersampling), so, until now, we are calling
this inefficient function every time a channel state changes.
Instead of iterating all channels for any chan state changes anywhere,
keep global state of the current channel counts, and on channel state
change only update those ts, trx, bts counts that actually change.
A desirable side effect: for connection stats and handover decision 2,
we can now also use the globally updated channel counts and save a bunch
of inefficient iterations.
To get accurate channel counts at all times, spread around some
chan_counts_ts_update() calls in pivotal places. It re-counts the given
timeslot and cascades counter changes, iff required.
Just in case I missed some channel accounting, still run an inefficient
iterating count regularly that detects errors, logs them and fixes them.
No real harm done if such error appears. None show in ttcn3 BSC_Tests.
It is fine to do the inefficient iteration once per second; channel
state changes can realistically happen hundreds of times per second.
Related: SYS#5976
Change-Id: I580bfae329aac8d4552723164741536af6512011
This way we avoid triggering timers and doing extra poll loops for each
BTS which is configured but not up. It also has the effect of removing
logging about estimating paging buffers for BTS which are down, which
can be confusing.
Furthermore, since work is delayed until the TRX and cell in general is
configured, the first estimation is properly done now since the correct
configuration is in place at that time.
Related: SYS#5922
Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
Reaching this point will only make system load (CPU, mem) grow, making
it hard for the process to keep up with work to do, with no benefit
since the requests will anyway be scheduled too late.
Related: SYS#5922
Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
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
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Vadim Yanitskiy
Oliver Smith
Neels Hofmeyr
Max
Pau Espin
Harald Welte