VAMOS shadow lchans do not exist yet, but add the indicator flag that
tells whether an lchan pointer is a primary or a shadow lchan.
In Mode Modify: based on the flag, choose a different default TSC Set
for shadow lchans; do BTS type compat checking for shadow lchan use.
Actual lchans with vamos.is_secondary == true will be introduced by
patch: 'add VAMOS secondary lchans to timeslot struct'
I928af99498bba488d317693f3144d4fccbbe9af3
Change-Id: I4072fc7703c592df699fe8e27c02df09acde0909
Put a (primary) lchan in VAMOS speech mode.
This is not yet about activating shadow lchans, this merely puts any
lchan in a VAMOS capable channel- and speech mode.
Protocol:
In RR Channel Mode Modify, send a spec conforming VAMOS channel mode as
well as an Extended TSC Set, wich adds the TSC Set to the training
sequence code value.
In RSL MODE MODIFY, send Osmocom specific extensions to indicate the TSC
Set and TSC, as well as the VAMOS channel mode; only to OsmoBTS type
cells.
- Set the Channel Mode's Channel Rate to Osmocom specific
RSL_CMOD_CRT_OSMO_TCH_VAMOS_Bm / RSL_CMOD_CRT_OSMO_TCH_VAMOS_Lm
- Add the Osmocom specific Training Sequence IE containing both TSC Set
and TSC.
(These are documented in the Abis manual.)
Implementation:
The internal API to request a Mode Modify is lchan_modify(info). Add to
this info the 'vamos' bool, set to true when the modification should put
the lchan in VAMOS channel mode or not.
When info.vamos == true, make sure the channel mode value is a VAMOS
one: in the copy of info->ch_mode_rate at lchan->modify.ch_mode_rate,
convert to the right VAMOS/non-VAMOS equivalent channel mode.
When the modification is through, set lchan->vamos.enabled
appropriately.
This patch also builds on Ic665125255d7354f5499d10dda1dd866ab243d24
'allow explixit TSC Set and TSC on chan activ / modif / assignment'
placing tsc_set and tsc values in the TSC related IEs.
Related: SYS#5315 OS#4940
Change-Id: Ibf53f4797d7491b17a33946fd7d920f038362b4c
Get rid of this artificial barrier, because Modify with active voice
stream is supported since commit
"lchan and assignment FSMs: make Channel Mode Modify more sane"
d5cb0eb8fd
I4986844f839b1c9672c61d916eb3d33d0042d747
Change-Id: I25f4a881fa32a07f97d7d6e6b812f8afc699d951
Add missing REQUIREMENT_A_TCHF to form a full REQUIREMENT_TCHF_MASK.
That allows detecting TCH/F -> TCH/H upgrades also in the requirement A
flags, where we look for any viable lchan.
Prepares for upcoming patch Id40d1cf8b58410c7d4eb87407fe8b8106e352438
which implements TCH/H to TCH/F upgrades within the same cell.
Related: SYS#5198 SYS#5365
Change-Id: Ic44615b314782423bab0ceef5810311776f92754
Fix build error:
meas_vis.c:196:16: error: 'struct gsm_meas_rep' has no member named 'bs_power'; did you mean 'bs_power_db'?
Output the value in the same format as before the change that introduced
this regression (dB / 2).
We didn't catch this regression with jenkins because meas_vis is only
built if libcdk is installed.
Related: OS#5173
Fixes: d9b7aedb ("change bs_power to bs_power_db")
Change-Id: I9ba9b491ccbde9aa14cfb14ecc551acb2bfd7674
An unintended change in default behavior was introduced in patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Ic665125255d7354f5499d10dda1dd866ab243d24
c33eb8d569
Set tsc_set and tsc = -1 for all lchan_activate_info and
assignment_request requests to actually yield the default behavior of
selecting the TSC based on the timeslot cfg or the BSIC value.
By setting tsc = 0 implicitly, the patch caused all requests to ask for
tsc 0 instead of calling gsm_ts_tsc().
For a Channel Mode Modify in assignment_fsm, pass the lchan's current
TSC to keep it unchanged.
osmo-ttcn3-hacks Id67a949e0f61ec8123976eb8d336f04510c55c01 adds a test
to verify the expected TSC in all of the activation, assignment and
modify messages. Current osmo-bsc master fails, this patch fixes.
Related: SYS#5315 OS#4940 Ic665125255d7354f5499d10dda1dd866ab243d24
Change-Id: If12df11511fe22ea167782f776736a1a9c484b1f
A side effect is that the final cleanup part of that function is now
always called, also when num_cell == 7.
(Whether we should really clear that logging context at that place is a
different question, out of scope here.)
Change-Id: I71a402a0940857bbedbaf25d293429934706a83c
Instead of calling DEBUGPC() over and over, compose a string using
osmo_strbuf and then log it once.
Rationale:
a) DEBUGPC() is a bad idea for gsmtap_log, because each DEBUGPC()
dispatches a separate gsmtap_log packet, fragmenting the actual log line
in wireshark.
b) DEBUGPC() is a bad idea because it checks the logging categories for
every DEBUGPC() invocation.
c) using a separate function with osmo_strbuf and OTC_SELECT, we can
actually skip the entire string composition in case the DMEAS logging
category is disabled, with a single logging category check.
Change-Id: I4cb607ff43a1cb30408427d99d97c103776b6e69
The RSL BS Power IE in measurement reports is encoded as dB / 2.
Instead of using this coding all over the code, converting to dB and
often printing confusing values in logging etc, store as plain dB.
The conversions should be at the points where a "weird" format is
defined: the RSL encoding needs divided-by-two, so apply it there. The
meas_vis is (now unfortunately) defined as div-two, and so on. But
internally we now just store the plain dB value and calculate with it
without duplicating the wire decoding step everywhere.
Rename to bs_power_db to clarify the unit of the stored value.
Change-Id: I229db1d6bcf532af95aff56b2ad18b5ed9d81616
This fixes handover oscillation in the presence of power reduction on
the downlink: apply the reduced power to the cell's RXLEV in order to
not rate the current cell as weaker than it actually is.
Related: SYS#5339
Change-Id: Ifcf59964b5e2d550d79e4ba14d90962808f79dae
According to 3GPP TS 45.008, the BSS shall monitor the levels of
interference on its IDLE traffic channels. The actual measurements
are performed in the BTS and then reported to the BSC over the
A-bis/RSL link(s) in RF RESource INDication messages.
3GPP TS 45.008 defines the following measurement parameters:
* Intave: Interference Averaging period (see table A.1),
* Interference level Boundaries (see table A.1).
Both parameters are sent to the BTS over the A-bis/OML, and can
now be configured via the VTY interface. Only those BTS models
which 'speak' the OML protocol defined in 3GPP TS 52.021 will
actually get the configured parameters, others will keep using
the hard-coded parameters.
Change-Id: I99ebf57aac1f3ca7e0497c3b4f6b0738c6ed7e47
Related: SYS#5313, OS#1866
This message periodically appears in the logs with subsys=DNM and
level=INFO for every disconnected BTS. I find this message useless
and even annoying, so I propose to remove it in this patch.
Change-Id: I7e2498cc61d311ca08585b2f1c49de021b17a5a1
Without this guard, a command like this can crash osmo-bsc:
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr
when timeslot 0 is configured as non-combined 'CCCH'.
Change-Id: I0197a6a2595ff9dade58e37383d44d2df3b03288
CLoses: OS#5170
chan_mode_to_rsl_cmod_spd() may actually return negative on error. To be
able to check for that, handle the returned value as a signed rc before
assigning to the unsigned spd_ind.
Related: SYS#5315 OS#4940 CID#236231
Change-Id: I52e13b24ce67e288ff32dbdaa1c1759089926f5c
Use lchan->modify.tsc in gsm48_lchan_modify().
The TSC is chosen exactly once upon LCHAN_EV_REQUEST_MODE_MODIFY
(lchan_fsm.c), and that should be the only place calling gsm_ts_tsc().
All other mode modify code should just use the final lchan->modify.tsc.
This fixes an error in patch:
Ic665125255d7354f5499d10dda1dd866ab243d24
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
Thanks to coverity for actually detecting this mistake.
Related: SYS#5315 OS#4940 CID#236233
Change-Id: I87ecf7d9266f37f4c775d029e277b614671a9401
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
lchan->modify.info.ch_mode_rate should remain unchanged, it is the
immutable request data. However, for VAMOS, we will want to
automatically see that the chan_mode is chosen correctly.
As a first step, place a mutable ch_mode_rate copy at
lchan->modify.ch_mode_rate, i.e. not in .modify.info, but in
.modify. Use that everywhere.
This is a non-functional change, preparing for a subsequent patch that
adds handling of VAMOS shadow lchans.
Change-Id: I8a3daac0287f15a59d3688388bb13e55facb2cea
Both VAMOS- and non-VAMOS speech modes should result in indentical voice
handling. So make sure that all chan_modes are converted to non-vamos
before comparing / evaluating in switch statements.
Change-Id: I791e7966b1f8eaa3299a8a46abeb313cf5136e0b
So far we have a couple of macros iterating a specific number of lchans,
depending on dynamic timeslot state etc. With addition of VAMOS lchans,
this would become more complex and bloated.
Instead of separate iteration macros for each situation, only have one
that takes a number of lchans as argument. That allows to more clearly
pick the number of lchans, especially for non-trivial VAMOS scenarios.
Related: SYS#5315 OS#4940
Change-Id: Ib2c6baf73a81ba371143ba5adc912aef6f79238d
So far the number of usable lchans is determined on-the-fly by the
physical channel config. With VAMOS, this becomes more complex, namely
determining whether the BTS is vamos capable.
Instead of calling a function to determine the number of lchans for
every use, rather place the number of valid lchans in int members of the
timeslot struct, and initialize those during timeslot setup.
Actual use of these new fields will follow in a subsequent patch, which
introduces the ts_for_n_lchans() macro to replace current lchan
iteration macros.
Related: SYS#5315 OS#4940
Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
This is particularly interesting for VAMOS multiplexes, but also gives
more prominence to this rather central aspect of GSM RF.
Related: SYS#5315 OS#4940
Change-Id: I7842ff89bece6d88387dae056e350529bae6fc38
Activating / modifying to a VAMOS mode will require picking specific TSC
Set / TSC. It is a bad idea to pick the TSC in each message encoding
function, rather make this choice centrally.
So far we pick the training sequence code to use based on the timeslot
configuration, and this TSC is determined only upon encoding the RSL
messages.
Instead, pick the TSC to use upon the initial lchan activation /
modification request; store this in the request structs and pass through
the activation / modification code paths.
For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ /
modif request. Note that the TSC Set is not yet applied in this patch,
it will be applied in upcoming VAMOS patches.
The activ / modif request may pass -1 for tsc_set and/or tsc to indicate
no specific choice of TSC Set and TSC, resulting in the same behavior as
before this patch.
For example, lchan->activate.info.tsc* may be passed as -1. The exact
choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e.
one level up (the .info sub-struct is considered as immutable input
args). The lchan->activate.tsc* are the values actually encoded in RSL
messages. After the ACK, the lchan->activate.tsc* is stored in
lchan->tsc* to indicate the TSC actually in use. Same for modif.
Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the
TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3
value. This is a weird discrepancy, odd choice made by the spec authors.
For conformance with the spec wording, I decided to pass the TSC Set
number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire
format upon message encoding. So log messages and VTY output will
indicate the first TSC Set as "1", but the first TSC as "0", as defined
in 3GPP TS 45.002, even if that is somewhat weird.
Related: SYS#5315 OS#4940
Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
Expose the training sequence code used in the RSL Channel Description IE
as an input parameter.
So far the Channel Description IE is always composed with a training
sequence code from gsm_ts_tsc(). For RSL commands enabling VAMOS mode,
specific training sequence codes are required.
So far, all callers still use gsm_ts_tsc(), making this a patch without
any functional change. Upcoming patches will pass specific TSC as
configured for VAMOS instead, in specific places.
Related: SYS#5315 OS#4940
Change-Id: I49503a6f5d25bb3bc9a0505bd79ed1d5c4f50577
Move the conversion from chan_mode to lchan type out of the
lchan_select_by_chan_mode() function, so that the conversion can be used
by other code paths, coming up in VAMOS patches.
Related: SYS#5315 OS#4940
Change-Id: I296651ebadba81f8b3db0d9bb5b5377877a43677
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
So far we do all channel reassignments by Handover Command. Since
osmo-bsc now supports rassignment of ongoing voice calls, do intra-cell
congestion resolution by Assignment Command.
In effect, add support for expecting an Assignment Command in
handover_test, and expect assignments instead of handovers for
intra-cell congestion resolution test cases.
Related: SYS#5330 OS#3277
Change-Id: Id56a890106b93fcee67ac9401b890e7b63bba421
So far the assignment FSM always tried to satisfy the channel mode and
rate by either re-using the current lchan or finding a new, unused
lchan. For VAMOS however, we want to pick one specific lchan.
Add target_lchan to struct assignment_request and skip all mode matching
and lchan selection when a specific target_lchan is set.
Related: SYS#5315 OS#4940
Change-Id: I71e0d4ff4746706e0be5266e4574d70ca432e3d7
It is better design to take state change actions in the onenter
function, instead of triggering a state change and then calling
lchan_mode_modify() or lchan_activate(). The reason is that in
principle, any state change may cause error handling to abort and
deallocate FSMs.
This is also preparation for reassignment to a specific lchan in an
upcoming patch.
Related: SYS#5315 OS#4940 OS#3277
Change-Id: I9a2e7eefd4196b80671311e5dfd275893ec0e275
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
The previous patch reshuffled the code without having any functional
change. In this patch, a functional change follows:
It does not really make sense to decide on AMR mode filtering based on
whether an activation request came from the VTY:
a) BTS: There is no need to skip AMR mode filtering for the BTS config
at all. There is always a BTS.
b) MSC: Instead of testing for a VTY origin of the request, rather skip
the MSC AMR config filtering exactly when there is no conn associated
with the lchan.
Move the bts filtering directly into mr_config_filter().
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Split off two function from lchan_mr_config() which do not directly
manipulate struct gsm_lchan members. This allows subsequent patches to
re-use mr_config_filter() for Channel Mode Modify without depending on
lchan->activate.info; allows to filter AMR modes without modifying the
state of an already active lchan before sending a Channel Activation or
Channel Mode Modify; and allows to move mr_config_render_lv() to
gsm_04_08_rr.c so that the mr_ms_lv and mr_bts_lv no longer need to be
stored in struct gsm_lchan -- they essentially duplicate s15_s0.
Rationale:
This is a follow-up for the AMR configuration in the sense that previous
patch Ie0da36124d73efc28a8809b63d7c96e2167fc412 started for channel mode
and rate, and the s15_s0 bits:
The AMR mode filtering directly manipulates struct gsm_lchan members and
takes parameters from lchan->activate.info. This makes it hard to
separate lchan activation from the Channel Mode Modify procedure.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Iebac2dc26412d877e5364f90d6f2ed7a7952351e
The GSM48_CMODE_DATA_* rates are completely unused in OsmoBSC anyway,
but there is some code in abis_rsl.c checking its value, and if we were
to start using it that is the place where it should be.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0e065a5dca5f4a31d5d81e3528a539214a74170
The single place that calls this special case is now actually doing the
exact same thing as the general case, and this is merely code dup.
Related: SYS#5315 OS#4940
Change-Id: Ic62e8a48d3c88a1966086240a41732d169328491
I noticed during testing that an lchan used as TCH/F in fact still had
its channel mode set to Signalling -- because on Assignment, the Speech
mode used to be placed in the *previous* lchan and the new lchan was
never updated after the Activ ACK. This is unbearable confusion which I
complained about numerous times, so far mostly for cosmetic reasons. But
implementing re-assignment properly actually requires this to be cleaned
up.
Keep all volatile chan mode settings in lchan->activate.* or
lchan->modify.*, and only update lchan->* members when an ACK has been
received for those settings. So a failed request keeps a sane state.
Make sure that those settings are in fact updated in the proper lchan,
upon an ACK, so that subsequent re-assignment or mode-modify know the
accurate lchan state.
Related are upcoming patches that sort out the AMR multirate
configuration in a similar fashion, see
Iebac2dc26412d877e5364f90d6f2ed7a7952351e
Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Ie57f9d0e3912632903d9740291225bfd1634ed47.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
The amr_mode parameter may be passed as -1 and is directly used as an
array index in amr_modes[]. The AMR related switch case properly checks
against a -1 index, but the EFR does not -- and should not use s15_s0.
Change-Id: I9bae5b4fb8ab8c2002fe785e130dc9faeeda892c
So far, only the MSC asked for Assignment via Assignment Request, which
we answer with a BSSMAP Assignment Complete or Assignment Failure when
done.
When Assignment is triggered for any other reason (congestion
resolution, VAMOS, VTY), we will not send any such messages to the MSC.
Additional enum values will be added in subsequent commits:
Id56a890106b93fcee67ac9401b890e7b63bba421 ASSIGN_FOR_CONGESTION_RESOLUTION
If006f5caaf83b07675f57e5665cfa79328da55e6 ASSIGN_FOR_VTY
Related: SYS#5315 OS#4940
Change-Id: Ie0cddbdb00abcec78e153f4ae6d04ce75080a111
The Channel Mode Modify procedure is currently implemented for changing
a TCH lchan from signalling to voice mode. For that, however, it is
re-using (abusing) the channel activation structs and state transitions,
and thus always implies activating a voice stream when the mode
modification is done.
I will add a Channel Mode Modify to enable VAMOS mode soon, so I require
separate structs and state transitions which also work on an lchan that
already has a voice stream established: a struct lchan_modify_info and
LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state
ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED.
For the part where a Channel Mode Modify enables a voice stream after
switching from signalling to speech mode, still use the channel
activation code path, but only once the mode modification is done.
General improvements:
- To ask for a mode modification, emit an FSM event that ensures a mode
modify only happens when the lchan state allows it.
- The new lchan_modify_info struct reflects only those parts that have
an effect during a mode modification (before the lchan_activate_info
was fully populated, many values not having an effect).
- More accurate logging, indicating "Mode Modify" instead of "Channel
Activation"
A TTCN3 test for the Channel Mode Modify procedure is added in
Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both
before and after this patch is applied.
Related: SYS#4895
Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
In subsequent patches, I will add enum lchan_modify_for and enum
assignment_for, I prefer to have similar lchan_activate_for naming.
Change-Id: Ia4420fcd1234dbee92e768e5a32eab13fba29ea9
Soon, there will also be enums with ASSIGNMENT_FOR_* and MODIFY_FOR_*
naming. Add the ACTIVATE_ prefix to the existing enum to clarify.
Change-Id: I12190d4d154a1da6a9ebc9a755ccc2fe382ff188
So far we were comparing the requested MSC side RTP address+port with
the MGW side's address+port, which would practically always fail, and
hence we always issued redundant MDCX even if for unchanged MSC side.
Skip the MDCX if the MSC side remains unchanged.
Emit the success event immediately if the MDCX is skipped.
Depends: Ibb488925827d9dc0ccb1f8d6d84728745d086793 (osmo-mgw/libosmo-mgcp-client)
Change-Id: If994ecef9d4269a8120b0575de9b6d0c3be19146
Change lchan_set_last_error() to macro so that the error log reflects
where the error was encountered.
Change-Id: I571fdf2d418c52d120215cf19e57a3c96d67af07
Clarify that this is the lchan that is being assigned to the MS, in
contrast to the current lchan.
Change-Id: I0de017f7c43ec495c2cd0f05f313740f42ab0bb1
This variable is the lchan that the Assignment Command should be sent
to, i.e. the MS's current lchan. The "dest" could be interpreted as the
destination of the assignment, the lchan that the MS should move to.
Change-Id: If2c102a8f1d45f84b6a765555abf7cd7a4749b0f
In practice, '+ true' may result in '+ 1', but that is not type safe. We
rely on the number of items added by summing up booleans, rather make it
explicitly 1.
Change-Id: I17a82f4f208203b748ba2d6ace0ddc06f87c1cef
A recent commit removed the references to the per-TRX description, but
wrongly removed the per-BTS in this place too.
Fixes: defb5b1200
Change-Id: Iacaa2a25633a8706bfde9e0c196fee3e5bff1639
I noticed that lchan_release() is generally called in varying error
situations, so it makes sense to generally skip the release procedure
when the lchan is already in the UNUSED state.
Change-Id: I6e9faf682d1668388d5470419110408a098b9900
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
After I found that X12 was missing from the VTY config, make sure that
no timers have been forgotten in lcs_ta_req.c: change the default
timeout to -1. We will notice missing timers during testing.
Change-Id: I7c0b098622548bf0f0374c304522e6a9db0331e3
While adding timers for Channel Mode Modify, I notice that X12 is
used in lcs_ta_req.c, but missing in net_init.c. Add it so that it is
exposed on the VTY configuration.
Change-Id: I19540f64de4937b39963bb66bebb1b5d433c2be2
A crash was reported in bssmap_le_tx_reset() sending a RESET with
sccp_user == NULL. A previous patch fixes what I infer as the root
cause, but I thought let's also have this additional safeguard.
Related: OS#5134
Change-Id: I13834c4e576e8d33e67cb63e222b41255cd94875
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
So far the function uses insane byte array magic numbers to compose the
OML "RSL Connect" message. For VAMOS, I intend to modify that message.
To ensure sanity, first change the attr composition to msgb_put*().
Related: OS#4940
Change-Id: Iba005635cf86aee1fde77d58ef203e28eed92281
"""
The old BSS shall inform the new BSS of the MS's last used E-UTRAN PLMN
in the "Last used E-UTRAN PLMN ID" information element included in the
"Old BSS to New BSS information" Information Element if this information
is present.
"""
Depends: libosmocore.git Change-Id I6280ce1abc283f1491bc6f391b2dd952df33a16b
Related: SYS#5337
Change-Id: I6cf54f9a16d598f98dc56b25f0fef56225a25a28
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
For neighbors configured without explicit ARFCN+BSIC ('neighbor bts N',
'neighbor lac-ci N M', ...), actually use the local neighbor cell's
ARFCN.
So far the code looked correct on first sight, but passed an unused part
of the struct neighbor union, always resulting in ARFCN 0.
Related: SYS#5367
Change-Id: Ifb54d9a91e9bca032c721f12c873c6216733e7b1
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.
Related: SYS#5337
Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
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
It's already being called in inp_sig_cb(), once the A-bis/OML link
is established. There is no need to do this on the A-bis/RSL link
establishment again.
Change-Id: I435018f439181cdd046ca99fe7e01ac85e226cce
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
Check against NULL pointers to allow only resolving local or only remote
neighbors in resolve_neighbors(). (Though no caller exists currently
that would need this feature, it is trivial and more future-safe.)
Related: CID#220459 CID#220460
Change-Id: I8c2046335ec6f8a5d6b757446c98d8e630ee015f
The reported feature vector may contain new features the BSC is
not aware of. Report each of them individually as NOTICE.
It's normal when some BTS feature is considered as not supported
by the BSC, but a BTS reports that it is - do not log this.
Change-Id: I2f925bcdb010cb10d074bf7c82619e3ae1f8818b
Calling generate_cell_chan_list() on each Assignment Command is
quite expensive, because this function basically re-constructs
the Cell Allocation (using bitvec API) and the Frequency List
from scratch. This IE can be borrowed from pre-calculated
SI1 message, so let's do this.
Change-Id: I9c8c5ae9059ff096765412b3f3c7181a94163afc
Before, it is not clear whether the RTP is already done setting up or
the RTP is skipped entirely. This log message clarifies that.
Change-Id: I18ffcf93e82ee47413e4b2f741ffbfbb18322e1d
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
Increase the number of values saved in the FIFO from 16 to 60, so there
is more time to read them out.
Related: SYS#4877
Change-Id: Ic5fd7c0fa030004fd88fee74f0028fb93c9f2d10
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
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 function is not really handover specific, and will be used in other
places in subsequent patches.
Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
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
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
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 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
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
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
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
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
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 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
config_write_bts_gprs() currently writes the remote address of an
NSVC even if osmo_sockaddr_str_from_sockaddr() returns non-zero
code. Thus saving a configuration with only one configured NSVC
to a file would produce the following:
bts N
...
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23023
gprs nsvc 0 remote ip 127.0.0.1
gprs nsvc 0 remote udp port 23000
gprs nsvc 1 nsvci 0
gprs nsvc 1 local udp port 0
gprs nsvc 1 remote ip
and next time osmo-bsc would refuse to start due to:
Error occurred during reading the below line:
gprs nsvc 1 remote ip
The related condition consists of the following two parts:
- checking if osmo_sockaddr_str_from_sockaddr() != 0;
- checking if 'remote.af != AF_UNSPEC'.
The first one is wrong, because osmo_sockaddr_str_from_sockaddr(),
like many other functions, returns 0 on success. Let's fix this.
After the fix, the second part does not seem to make sense, because
remote.af would remain AF_UNSPEC (0) if the function call succeeds.
Printing the remote port alone does not make sense, let's avoid
printing it if the address cannot be parsed into a string.
Change-Id: I5d6cbde4f605c8184db4ade87de5644a849c05db
Fixes: I621360cab1e12c22248e33d62a9929995053ce04
For balancing load across congested cells and across congested TCH/*
kinds, instead of comparing the number of lchans above the configured
congestion threshold, compare the percent of lchans of overload.
In short, using a percentage prevents cells with less min-free-slots to
fill up 100% while neighbor cells still may have several free lchans
available.
An obvious example of why this is desirable is illustrated by
test_balance_congestion_by_percentage.ho_vty:
Cell A has min-free-slots 2, and has all slots occupied.
Cell B has min-free-slots 4, and has 2 slots remaining free.
If we count congested lchans as in current master: cell A has a
congestion count of 2: two more lchans in use than "allowed". If we move
one lchan over to cell B, it ends up with a congestion count of 3, which
is worse than 2. So when counting lchans, we decide that cell A should
remain full.
Instead, when comparing percentage of remaining lchans, we would see
that cell A is loaded 100% above congestion (2 of 2 remaining lchans in
use), but when moving one lchan to cell B, that would only be 75% loaded
above its treshold (3 of 4 remaining lchans in use). So a percentage
comparison would cause a handover to cell B.
Related: SYS#5259
Change-Id: I55234c6c99eb02ceee52be0d7388bea14304930f
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
When evenly distributing congestion across cells, count the number of
occupied lchans surpassing congestion, and not the overall number of
free lchans -- which disregards congestion thresholds.
Fix the bugs shown by
test_congestion_no_oscillation.ho_vty
test_balance_congestion_tchf_tchh.ho_vty
This implements a simple calculation for congestion load by counting
lchans in use above congestion. An improvement of this calculation
using percent follows in I55234c6c99eb02ceee52be0d7388bea14304930f.
Related: SYS#5259
Change-Id: Icb373dc6bfc9819446db5e96f71921781fe2026d
Store the number of free lchans and the min-free-slots settings in
ho_candidate, instead of figuring those out in various places, to make
it easier to read.
Prepare for upcoming patch which also requires these values to fix a
bug.
Change-Id: Ie6ca5af5e8d0ebb8deaaaa637e2728008ecba517
So far it is often confusing which cell a specific member refers to.
Clarify lchan, bts, ... to current.lchan, target.bts, ...
Also move the rxlev_{current,target} to {current,target}.rxlev.
Eliminate numerous local variables to make it easier to read which side
is being used (e.g. "c->target.bts" instead of just "bts").
No functional change.
Change-Id: I06898eb745a5be548df0b76fa760ce790cfab3ed
Fix flaws in picking a candidate for congestion resolution, shown in
recently added tests.
- For TCH/H->TCH/F upgrading, do not favor moving to a weaker neighbor
cell.
- When comparing dynamic timeslots on the same cell, favor a dynamic
timeslot that frees an entire dyn TS even though the target rxlev
differs.
Do not separate the passes for inter-cell and intra-cell candidates:
before, the inter-cell pass would already pick a candidate and start
handover, even though the subsequent intra-cell pass would have revealed
a better candidate. Join the intra-cell considerations into
pick_better_lchan_to_move().
The intra-cell pass was separate, because it would find the *weakest*
current rxlev, to give a TCH/H to TCH/F upgrade to the currently weakest
lchan.
Instead of the separate pass for weakest rxlev, in addition to the
target cell's rxlev, also consider the rxlev *change* in
pick_better_lchan_to_move(): For candidates that do not change the rxlev
(usually those that stay in the same cell) and that upgrade to TCH/F,
favor a candidate with weaker current rxlev.
Completely revisit the conditions in pick_better_lchan_to_move() to
yield the desired prioritization of candidate preferences.
In three handover tests, remove the "FAIL" comments and adjust to now
expect the actually desired behavior.
Related: SYS#5032
Change-Id: I2704899c85c35dfd4eba43468452483f40016ca2
Instead of passing the TCH/H -> TCH/F bias (AFS bias) in local
variables, rather store it in the ho_candidate struct next to the other
rxlev related values.
Add the AFS bias to the compared rxlev in pick_better_lchan_to_move().
Modify pick_better_lchan_to_move() to simpler semantics of returning
either a or b.
No functional change.
Change-Id: I73860abdf2a77270ca4851ad58c09767d1bb08f1
Store the rxlev of the current lchan and the target BTS in the
ho_candidate, to clarify the code.
No functional change, cosmetically prepare for
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: Ie6c165e17bb3c99eebc967a6bb02529db8bdfc98
In handover_decision_2.c, instead of repeating a similar loop four
times, put that loop in a function and parameterize it.
Prepare for a fix of two problems in handover decision 2, see
I2704899c85c35dfd4eba43468452483f40016ca2.
Change-Id: I7c32d08e490a88a7f044b0a71dc4b07d748dd572
Adding SMSCB messages to a BTS so far only worked if there were
existing messages with a lower scheduling period than the new message.
Before this patch, it fails for new messages if they are of equal or
lower scheduling period than the existing messages.
Change-Id: I69a05b22200b3a1ee406b0673553e135603d723b
None of those commands apply immediately, they only affect newly
established logical channels. The reason is that the related
IEs are only getting sent on channel activation / assignment.
Change-Id: I06c7851115fb31d1eb92c400d9724f4f051bd171
Related: SYS#5114
Both commands are basically doing the same thing, so we can merge
them into a single command by adding a parameter to the command
string. The VTY syntax remains the same:
do-something foo
do-something bar
becomes:
do-something (foo|bar)
This change reduces code duplication.
Change-Id: Ibe98718d8f4933926eed0e622109c9c82537f526
Related: SYS#5114
Presence of these lines in the config file does not necessarily mean
that the BTS will not perform measurement pre-processing. It actually
means that the BSC would not include the optional IEs related to the
measurement pre-processing, so the BTS may still apply its default
averaging algorythm with default parameters.
In order to avoid potential confusion, let's avoid printing them.
Change-Id: I585b5bf4fde93d66e47666e0fa9903f21a268b51
Related: SYS#4918
This fixes the following heap overflow in the SMSCB scheduler:
==109051==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d00003a9a0 at pc 0x55d77e4bedf1 bp 0x7fff8cdc4240 sp 0x7fff8cdc4238
READ of size 8 at 0x60d00003a9a0 thread T0
#0 0x55d77e4bedf0 in bts_smscb_sched_add_before /space/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/cbch_scheduler.c:64
Change-Id: If529aa905336a1b9e7a36e931c165df0ba9899ad
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
There is only one parameter in command:
repeat dl-facch (command|all)
so indeed argv[0] must be used instead of argv[1].
Change-Id: I01efff109a33791e13b0149fc47c792d3266da71
Related: SYS#5114
For several years now we are using line lengths longer than 80chars,
let's re-format this code more in-line with our new style.
Change-Id: I8143280358c0e23ca7e32b882e952eac991e105b
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
Before the recent changes, the MS Power Parameters IE would always
be included empty in RSL CHANnel ACTIVation messages iff the BTS
type is 'osmo-bts'. Then this behavior was changed, so the user
would need to enable dynamic power control explicitly.
This is a regression, let's revert it back to the old behaviour.
Change-Id: Idb453fc894584ccf4f5f8b45a24421db958e9478
Related: SYS#4918
According to 3GPP TS 45.008, section A.3.2.1:
c) Comparison of RXQUAL_XX with L_RXQUAL_XX_P (XX = DL or UL):
Increase XX_TXPWR if at least P3 averaged values out of N3
averaged values are greater (worse quality) than L_RXQUAL_XX_P.
d) Comparison of RXQUAL_XX with U_RXQUAL_XX_P (XX = DL or UL):
Decrease XX_TXPWR if at least P4 averaged values out of N4
averaged values are lower (better quality) than U_RXQUAL_XX_P.
Given that RxQual is a value in range 0 .. 7, where 0 is the best
and 7 is the worst: L_RXQUAL_XX_P must define the worst quality,
while U_RXQUAL_XX_P must define the best quality value.
Change-Id: I0f37b23ed360782f3c1f4275234c4e18a17aa89b
Related: SYS#4918
If the user doesn't specify any CON connection groups in the config
file, then the CON is not used. The current code runs into an error
condition, as abis_om2k_tx_con_conf_req() never sends the CON CONF REQ
if the groups list is empty, but we still wait in the FSM for the
arrival of a CFG REQ ACCEPT. The CON FSM eventually times out in T10
and we proceed with the IS, ignoring the error.
With this patch, we simply skip the entire CON MO in case there is no
related configuration.
Change-Id: Ia4d5bd96734686381f04aa3b380b17a161a31174
In I68ae0bc51a565f903b47cf72f3e3dd6f1a2d2651 we started to
initialize all (TS 12.21) NM MO state to LOCKED by default,
which means BTSs not using TS 12.21 are stumbling across
a general check in bts_isdn_sign_link() and will fail to
process and uplink RSL messages.
Change-Id: I4450cc47ede4005bf4bbd4af8d5a22c78377d4cd
Related: OSE4914
Thanks to this message, there is no need to include MS/BS Power
Control parameters in every RSL CHANnel ACTIvation message.
Instead, we send them only once, and then send empty IEs.
Change-Id: I46ae4e6003a1839ee57f8e941a54bf479f7e532d
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
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
There's no real need to retrieve the trx before passing it to the
function, we can do that in the function itself and hence also simplify
the function itself.
Related: OS#4870
Change-Id: I7181510c5021ff2712c09ebc6ec8b13fdd8e8dc2
The condition was set in st_op_disabled_notinstalled_on_enter():
"""
site_mgr->peer_has_no_avstate_offline = (bts->type == GSM_BTS_TYPE_NANOBTS);
"""
However, at startup of the FSM the oneneter func of the default initial
state is not called. In any case, if called it would be too early since
the type is not known yet (because its parsed later on at the VTY with
the "type" command, that's after the "bts X" node is called and the
bts_sm is allocated.
So we need to make sure to always enable it, also for nanobts.
Change-Id: Ic6049a44ae3fca1b8e968fe800c268f579e7cad4
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
MS Classmark 3 is optional, and thus can be NULL.
Change-Id: I4f1455a3db4972ea9843564b590e405c51083b47
Fixes: I39ae439d05562b35b2e47774dc92f8789fea1a57
Fixes: CID#215593 "Explicit null dereferenced"
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
When ICMI becomes zero for 'start-mode auto', the smod bits will remain
whatever start-mode was set in the previous osmo-bsc config. Instead, osmo-bsc
should clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
Change-Id: I1ec5bad0bce01cc425ee05ecf70c83ec662a226a
So far, the smod bits reflecting the start mode never made it to the
MultiRate Config IE: gsm48_mr_cfg_from_gsm0808_sc_cfg() always sets them
to zero, and the mode filtering fails to carry the BTS set bits.
Set smod bits according to BTS config after the filtering of available
modes.
Change-Id: I49691df01745a7c485bf165e897872c35fc4b147
Send the proper ICMI value, instead of always sending ICMI=1 regardless
of the AMR start-mode setting.
To avoid test fallout from the fix, we should first merge
osmo-ttcn3-hacks I4cff01c37d5c7e301e9a01f773b7e009a789519b
Change-Id: I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Iff920ff3dbeb48bd871b7578470f27fe9d0f9516
Fixes: OS#4865
The IPV6_NSVC feature is required to use IPv6 NSVC to connect
to the SGSN. The features in general should be dynamic discovered for
the BTS which support this.
Workaround for OS#4870
Related: SYS#4915, OS#4870
Change-Id: I711efca931012b8e66516f2721390e9dbdbb72a8
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (killall -SIGABRT
osmo-bsc), then the process would print the talloc report and continue
running, which is not desired.
Change-Id: I125288283af630efa20d64505e319636964a0982
Fixes: OS#4865
When a used timeslot gets moved to another timeslot for load balancing, prefer
moving a dynamic timeslot, as illustrated by handover_test.c test 30.
Rationale: freeing up a dynamic timeslot is better for PDCH availability, as
well as for flexibility in timeslots. Test 30 shows that when freeing a static
TCH/F even though a dynamic one with identical ratings is in use, later
handovers to a TCH/H may become impossible, because no more dynamic timeslots
are available to switch to TCH/H. A freed dynamic timeslot allows congestion
resolution to continue and reduce more TCH/F to TCH/H.
The scope of this preference is per-TRX, where the RXLEV ratings used for
picking a target lchan are the same by definition. In other words, this never
overrules picking another lchan that has better RXLEV.
Among lchans on dynamic timeslots that could be moved, this code favors moving
later lchans; mainly because it makes for a simpler condition in the code.
Change-Id: Ic221b8d2687cdec0bf94410c84a4da43853f0900
There are four places deciding which of 2 lchans to move, depending on average
db ratings. Upcoming patches will enrich that decision for better handling of
dynamic timeslots, so have one common function for these to avoid code dup.
Change-Id: I745dc95cf564dd330295cecb4d64dccebf55163f
The function bssmap_handle_cipher_mode() suggests to check if an lchan
is actually present when it gets called, but it only checks for conn.
This might lead to a segfault later in the execution path.
Change-Id: I3103ec89cd6dce1a11ea8e9f8187373e4114e852
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
Neels Hofmeyr
Oliver Smith
Vadim Yanitskiy
Pau Espin
Keith Whyte
Philipp Maier
Harald Welte