Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I97a59d06e408776e223cb5fc582e29f1608ba85d
|
|
When the SDCCH gets released while the TCH still beeing activated, then
the ChanActivACK that is received after the TCH is activated will trigger
a segmentation fault in the assignment_fsm. The reason for this is that
conn->lchan, which holds the SDCCH at that point in time, is now NULL.
To prevent osmo-bsc from crashing, the FSM should check for the presence
of conn->lchan first. If it does not exist, the FSM should terminate.
(Assignment failed)
Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a
Related: SYS#5627
|
|
Change-Id: I0afcb06f8a7466f98cac26ff939a3813d4add1cc
|
|
Change-Id: Id298d547a90bb5d8e40f2cd300b7e1303bb43fdc
|
|
Change-Id: I68f64e6cae061a49733c4885ba383d2b9b4cfca9
|
|
Change-Id: I4e0eb8842333c89d15fb6728a34716ea1eb4935d
|
|
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I4d48c0c0aa46065560a020369e3b0544385f173e
Related: OS#5034
|
|
Changing the BTS type is not supported, so don't allow it.
For example, Changing from type sysmobts to type rbs2000
may hit an OSMO_ASSERT in om2k_bts_fsm_alloc()
The default BTS type if osmo-bsc is started with an empty
configuration and the operator issues config terminal->network->bts 0
will be "unknown". This type and only this type can be
changed from the vty config node.
Change-Id: I0df97ef128a1bbd84c787654d1d842dce4dad819
|
|
The EGPRS bits are anyway conditionally enabled by egprs_supported.
Change-Id: Ie7a438419eb416ce3d29794febab5f952661e5c5
|
|
Change-Id: I73f4dab6edb0951180f2bbcfc352ff34de647679
|
|
Change-Id: I217e3550aa6d7f3c3cab4e545641d790ae12b23f
Related: SYS#4909
|
|
The function is not really handover specific, and will be used in other
places in subsequent patches.
Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
|
|
The manual currently does not mention ACCH repetition yet. Lets
add some info on how to set up ACCH repetition correctly.
Change-Id: I1e27ac955882497bbeefac0c830708dd18ad46b3
Related: SYS#5114
|
|
Change-Id: Iecc2395efab703cf3de8f8e16b9e4bc8c8baf260
Related: SYS#5114
|
|
Related: SYS#5358
Change-Id: I8b97ea11bad5fe05f2f634945b5703ee9abde81d
|
|
Many years prior to the implementation of osmo-cbc, we introduced
a way how raw RSL SMSCB COMMANMD can be injected from the VTY.
These days, people should use the CBSP interface with osmo-cbc or any
other CBC. We should not advertise the VTY command hack
as a standard feature anymore.
Change-Id: If5ddc3db989763a1f47d4cbc026e293e3134d8ef
Related: OS#4753
|
|
Change-Id: I6e0fae81cc60f708e49d5eb8dfc0bbcad926b18f
Related: SYS#4918
|
|
So far osmo-bsc would enable Uplink DPC (Dynamic Power Control) only
for osmo-bts, and the 'static' mode for all other BTS models. This
decision dates back to the time when ip.access specific encoding for
dynamic power control parameters was not implemented, and the MS
Power Parameters IE was sent empty in the RSL messages.
Let's make a step forward by enabling Uplink DPC by default for
all BTS models which declare the API for vendor-specific encoding
of the power control parameters. Currently this includes osmo-bts
and nanoBTS, both supporting ip.access specific format.
Change-Id: If86d27d4332af3d82f862737340d061e42e34eba
Related: SYS#4918
|
|
Change-Id: I1c454f447d37cbc4d44b242dc4b2c62297ee3f67
Related: SYS#4918
|
|
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
|
|
Change-Id: I06d3f35fcc71d77e1f30c2b15ab221ef7d5f7f27
|
|
Change-Id: Ic42db1a2d768c8ee7e07406ac5f77af757e52cdb
|
|
Change-Id: I036f2d895e3569bd050ce574759f8371bd19cec9
Fixes: CID#216933
|
|
This is a non-standard RSL message that must be sent after each traffic
channel has been established. Without it, any voice call will be
disconnected within seconds.
This is a hack; we need to store the subscribers classmark2 value and
use it here.
Change-Id: I6cb6d25e405aa888c4df4022d897330a6af9e946
Related: OS#2389
|
|
Related: SYS#5301
Change-Id: I332477cbddf32cf6f057007b45cda8477227f0b1
|
|
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 additional counters to track TCH and SDCCH RF failures in separate subcategories.
Change-Id: I91fe6659fe9df33763f4070b4f505561b2005d38
|
|
We cannot simply use the highest 'x' in A5/x codecs.
For A5/7 through A5/3, larger 'x' means better.
But: A5/1 is better than A5/2, so we need to prefer the former
over the latter.
Change-Id: I399fff8d07d1bfcbc6b385e90914ff6d9e00eb73
Closes: OS#4975
|
|
Name both new tests with suffix '_2' even though the first h_to_f does
not exist (yet?), to indicate the complementary nature of those two
tests.
Related: SYS#5301
Change-Id: I8c8d9d5936f713f7d02e4246eeb373916e62510b
|
|
Change-Id: Ia4594d8a98aee19f14e75449cfdfdc0fbcaf6e9f
|
|
Change-Id: I2da6f58d84521289f86840b1da191a9faf76a1a8
|
|
Change-Id: I61ee711de5303691c2f8881b66d4614d11850be2
|
|
If an emergency call arrives at the BSC while all TCH are busy, one TCH
is cleared in favor of the emergency call. However, if emergency calls
are disabled (system information), it is still possible that an MS might
try an emergency call anyway or that due to interference a regular call
might look like an emergency call (channel request reason). In those
cases the preemption must not happen and the emergency call must be
rejected.
Change-Id: I1af1f4fefcbe6a886bb5396901ce0cb2368a0e19
Related: OS#4976
|
|
When setting the BER threshold for ACCH repetition the VTY displays
wrong threshold values in the online help.
Change-Id: I4c89ad130da328aba99663e5a2931a4007772bca
Related: SYS#5114
|
|
When balancing congestion, not only look at TCH/F or TCH/H separately,
but also to take into account the effects on the other TCH kind from
using/freeing dynamic TS.
Related: OS#5298
Change-Id: I433df6f343650f9056b1bab926bc19ac1d867ad5
|
|
Related: SYS#5298
Change-Id: I34471fbd490a95253bd0709308a42cde2af6481c
|
|
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
|
|
Change-Id: Ib11d10f35f72a3dff65bb0c5e185fdda602ccd63
|
|
For handover algorithm 2, properly figure out what effects the target
cell will see for the *other* TCH kind when a handover would occupy a
dynamic timeslot.
Before this, only TCH/F or TCH/H would be regarded at a time. This
introduces detection of whether a dynamic timeslot would be occupied by
a handover, and how losing one unused dynamic timeslot affects the
congestion situation for the TCH kind that is not targeted by the
handover.
In other words, if a handover to TCH/F causes congestion in TCH/H
because of a dynamic timeslot becoming occupied, the handover will not
be performed. Before this, oscillation situations could occur.
A subsequent patch will do the same for congestion balancing.
Related: SYS#5297
Change-Id: I1536b60f03cb0aeb6ba14a72b518aec82fa572fe
|
|
The test shows a cascade of failures. When we fix the first failure, it
will change the sequence of events that follow after that. But it will
still be interesting to evaluate all the situations currently shown.
Hence fixate each stage's initial situation, by duplicating the
expect-ts-use with an identical set-ts-use. Then, when each individual
scenario gets fixed, subsequent scenarios still remain unchanged.
Change-Id: Ifeaec39ecb64b476ff1438cf987ba0403489c43b
|
|
Related: SYS#5297
Change-Id: I3002797dea02dd0c10cfdd091ce73834a753e3a6
|
|
The idea is to avoid confusion between the static PDCH and the dynamic
timeslots. The PDCH is always in 'pdch' mode, while the dynamic
timeslots are 'pdch' when they are not occupied by any TCH.
Change-Id: I1a12518d85ed891c491723e7f03f5bdd4fad980f
|
|
So far, the test only works because osmo-bsc fails to notice that
occupying the dynamic TS 1 as TCH/F does, overall, not free a TCH/H, but
reduces available TCH/H from 5 to 4 (one TCH/H freed, but two TCH/H lost
from occupying a dynamic TS). An upcoming patch will make osmo-bsc
sensitive for these cross effects between TCH/F and TCH/H when dynamic
timeslots are involved, hence this test needs to be stabilized.
By using a static TCH/F for TS 1 instead of a dynamic timeslot, the dyn
TS cross effect does not occur and this test actually makes sense.
Change-Id: I492ea095cf3e3c3fd186c889166c4ed93ab3a007
|
|
On -u, update the handover_tests.ok file that lists all tests that are
expected to run. This is necessary for the regression tests to succeed.
Update all the numerous test_*.ho_vty.{err,ok} files only when the
update arg is a captial -U, because those are usually not interesting,
except for manual comparison of test runs.
Change-Id: Id280a8d084fd84b0b7486a5c8022e5b7a26f6095
|
|
Change-Id: I4df275e4770c5ff3643c79ba828e736986f8bb47
|
|
The following message makes no sense:
DRLL DEBUG gsm_data.c:844 MS Power class update: 4 -> 4
because nothing really changed, MS Power class remains 4. Neither
it makes sense to call lchan_update_ms_power_ctrl_level().
Change-Id: I519d2d1575cbb5352cc381a60513db8e0e2cb0a0
|
|
Allocating a new list of supported codecs *before* checking the
command arguments is a bad idea. The operator may simply mistype
one of the codecs and will end up with a list of NULL pointers.
The functions calling audio_support_to_gsm88() assume that this
list always does contain valid pointers, so if a new subscriber
connection gets established, or the operator simply invokes
'show running-config', osmo-bsc would crash due to NULL pointer
dereference.
Steps to reproduce:
1. In the VTY, do: 'en' -> 'configure terminal' -> 'msc';
2. Configure any invalid codec list, e.g. 'codec-list Boom!';
3. Invoke 'show running-config', boom!
Let's check the input before changing the internal structures.
Change-Id: I35b740a39c9cf3716d286e717486ef505bc61522
Fixes: OS#4946
|
|
My assumption that lchan_reset() is called on CHANnel ACTIVation
was wrong - it's actually called on CHANnel RELease. Therefore
(re)setting per-lchan BS power value must be done in the other
function that is responsible for channel activation.
Change-Id: I056c448ce017458dc4a004374ddca86d44dc35b4
Related: SYS#4918
|
|
Related: OS#4912
Change-Id: If655798bb47c332f7decb74ed19524b3014f69b4
|