During specific release scenarios, it became clear that an lchan still
pointed at a conn even after it had been deallocated. That was due to
setting conn->lchan = NULL but not lchan->conn = NULL. Fix that.
Do lchan_forget_conn() first, because during gscon_forget_lchan() we may
enter the gscon clearing dance, which in case of no SCCP conn being
present will soon / should immediately deallocate the conn.
Related: OS#5337
Related: I8c8537acf6b47b121903197608636c43ae601a57 (osmo-bsc)
Change-Id: Idbfe4672233ba8105eff5ba77ee07fd871358255
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy
to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values.
Handover code is one such instance that forgets to set -1.
Change the semantics of tsc_set and tsc so that this kind of error can
not happen again as easily: use a separate bool to flag whether to use
the default config or explicit values.
Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as
well as abis_rsl_chan_rqd_queue_poll().
Related: OS#5244 SYS#4895
Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks)
Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
So far we were inherting the bs_power in used when activating an lchan
for an MS for which we already had previous lchan. For instance, when an
MS is first assigned an SDCCH, and later on, it is assigned a TCH to
place a voice call.
Doing so is, however, not correct because current and old lchans may be
placed on different TS or even on different TRX, which means they will
have different BS Power restrictions. In the scenario described above,
for instance, an SDCCH could have been assigned on C0 and hence have
a bs_power of 0, and later on, whenever the TCH lchan as created, it
would have inherited the C0 bs_power despite it may have been possible
to use a different (lower) max bs power.
Furthermore, the lchan->bs_power_db basically stores the *maximum* bs
power reduction. Hence it makes not sense at all to copy over the value,
since it is anyway not updated from MS measurement reports so far
anyway.
Fixes: 997a257f8d
Related: SYS#4919
Change-Id: I4a7736aa9a1395e0cc118b98b69896bd0f1e94e6
A previous commit (Feb 05 2021) moved copy of TA value to some other
place to fix some related issues, but forgot to update the comment.
Fixes: b03e73f27b
Change-Id: Ia10038919b6650dff45b7233f58fea94e9808712
Testing has shown that the Training Sequence Code in pre-chan-ack mode
is inaccurate (only worked with a BSIC that incidentally yielded the
same TSC value as the wrong TSC value sent in the IMM ASS msg).
Move the code setting the correct TSC and TSC-Set to the first stage of
channel activation (lchan_fsm_wait_ts_ready_onenter()) so that it is
available for both pre-chan-ack and pre-ts-ack Early-IA modes.
Have a separate function for setting the preliminary values requested in
Channel Activation (lchan->activate.*) into the accepted operative
places (lchan->*). Call this early for early-IA modes.
Hence the TSC and TSC-Set used in the early IMM ASS message is now the
correct one, and the same as sent during Channel Activation.
There shouldn't be any, but if there are other values besides TSC
suffering from the same problem, they are now also set to the right
values before sending IMM ASS early.
Related: SYS#5559
Related: I4479244b0c53648e62e84e1ebf986f51d659484f (osmo-ttcn3-hacks)
Change-Id: I9f26074154600d854a0b3baee2f38a6666f4cb56
bs_power_db, as its name suggests (also check vty code and
rsl_tx_chan_activ()) contains value in dB, not in 2dB steps.
Change-Id: I76bd6bb1b307ab75ba1292865747419228e0687a
Add experimental 'pre-ts-ack' to the 'immediate-assignment' options:
send the IMM ASS even before a dynamic timeslot is switched. This
possibly saves an Abis roundtrip, but may be racy.
When pre-ts-ack is chosen, already do the IMM ASS before the dyn TS
pchan switch is ACKed.
In Immediate Assignment, in case the dyn TS is not ready yet, get the
pchan kind from lchan->type, which already reflects the target type, and
not from ts->pchan_is, which still reflects the previous pchan type.
Related test is in I2ae28cd92910d4bc341a88571599347a64a18fe5
Related: SYS#5559
Change-Id: I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
When 'immediate-assignment pre-chan-ack' is set, send the Immediate
Assignment directly after the Channel Activation, not waiting for the
Activation ACK, to save an Abis roundtrip.
Related test is in If71f4562d532b6c5faf55f5fd073449a8a137ebf
Related: SYS#5559
Change-Id: I56c25cde152040fb66bdba44399bd37671ae3df2
The bottom of the function changes the lchan state. If a failure branch
is reached, that should no longer happen. Change 'break' to 'return' in
four places to not mix up the channel release.
Related: SYS#5559
Change-Id: I4674752ab4f1c8e8147ef3366f90e9ea2abd5aec
As seen in osmo-bsc log:
DCHAN ERROR abis_rsl.c:2287 lchan(12-0-2-TCH_H-1){BORKEN}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Idc7796d41f3483c89559746d9a00fdf32bf67c57
call lchan_reset() after allocation, to make sure that lchan->* fields
that have a nonzero default value get initialized properly.
In particular, a future patch adds interference measurements, and an
lchan that never received any Resource Indication info should always
indicate that there are no measurements (a nonzero constant).
Related: SYS#5313
Change-Id: I700a969f5b11c21dacda9a7cad00c943dce554b3
This allows quickly finding out whether the timeout is happening due to
RLL not established or whether RTP is not ready. In essence, it
indicates whether issue may be coming from MGW or from MS/BTS side.
If coming from MGW, the timer T3101 is in general not a problem and the
issue should be related to some misbehaving.
If coming from MS/BTS, T3101 may require tunning (it could be a
misbehaving of the MS/BTS too, or simply bad signal).
Related: SYS#5526
Change-Id: Ib655f71aec584962c70d84a4405d996505dff53c
As seen in osmo-bsc log during heavy load scenario:
<000f> abis_rsl.c:2171 lchan(12-2-6-TCH_H-0)[0x559b880d1f40]{WAIT_RF_RELEASE_ACK}: Event LCHAN_EV_RLL_REL_IND not permitted
Related: SYS#5523
Change-Id: Ie307872851490ae4d60c8117a5f4e2d8c2a414d6
BS Power Control is not allowed on the BCCH/CCCH carrier, unless
the BTS is operating in the BCCH carrier power reduction mode.
Allow constrained BS power reduction (up to 6 dB) on active logical
channels iff BCCH carrier power reduction mode is enabled.
Take into account that the maximum power difference between a timeslot
used for BCCH/CCCH and the timeslot preceding it shall not exceed 3 dB.
Change-Id: I2cc6a86731984f586ef35b43a8d3de631f7d8a2f
Related: SYS#4919, SYS#4918
Change gsm_lchan_name_compute() to a function that in-place updates the
lchan->name. That allows calling it numerous times with the talloc
handled internally. Rename it to lchan_update_name().
Add 'shadow' to lchan_update_name() and lchan_fsm_update_id() for VAMOS
shadow lchans, and also print the lchan index that it is a shadow for,
instead of the index in the lchan array.
When set_pchan_is() updates the VAMOSness of the lchans, call
lchan_fsm_update_id(). From lchan_fsm_update_id() also call
lchan_update_name().
This is a bit convoluted for legacy reasons. There are utility programs
and C tests using bts_trx.c but not lchan_fsm.c. lchan_update_name()
lives in gsm_data.c for that reason. This patch calls
lchan_update_name() from lchan_fsm_update_id() and not vice versa to
avoid having to add stubbed lchan_fsm_update_id() functions to all
utility programs and C tests.
We can't easily unify the lchan->name and lchan->fi->id without lots of
refactoring rippling through all those little utility programs and C
tests.
Change-Id: I7c2bae3b895a91f1b99b4147ecc0e3009cb7439a
Add function lchan_activate_set_ch_mode_rate_and_mr_config() and call it
for both plain channel activation and after a mode modify that needs RTP
activation. The AMR config was missing after Mode Modify.
Related: SYS#5315 OS#4940
Change-Id: I842fe7a14a91d1ec123cb4a3f52afe34456c03e3
lchan->activate.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->activate.ch_mode_rate, i.e. not in .activate.info, but in
.activate. Use that everywhere.
This is mostly a non-functional change, preparing for a subsequent patch
that adds handling of VAMOS shadow lchans.
As side effect of adding lchan_activate_set_ch_mode_rate_and_mr_config()
after MODE_MODIF_ACK (enabling the voice stream after a channel mode
modify), fix AMR config: the call to lchan_mr_config() was missing.
Change-Id: Icc9cc7481b3984fdca34eef49ea91ad3388c06fe
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
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
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
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
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
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
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 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
Change lchan_set_last_error() to macro so that the error log reflects
where the error was encountered.
Change-Id: I571fdf2d418c52d120215cf19e57a3c96d67af07
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
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""
Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""
Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.
This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.
Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
sysmoBTS is a BTS model sold by Sysmocom, which runs osmo-bts.
The later may also work with some other back-ends, including
the genaral purpose SDR hardware. Therefore, it's more
logical to call it 'osmo-bts'.
Change-Id: I93ab4dbf483e0786c35685b75ee4ea83bd591f7b
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr