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
Shows a bug / missing feature, to be fixed in
Ifcf59964b5e2d550d79e4ba14d90962808f79dae
Related: SYS#5339
Change-Id: I1cc9bc39e8695faa983819b909e0ec76f0dbc296
Subsequent patch will add a test that uses this to show a handover
oscillation problem in the presence of nonzero BS Power.
Related: SYS#5339
Change-Id: I158d4b27370ab19318f83018803853f423c89b79
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
In osmo-bsc, gsm48_multirate_config() is used in a way where the struct
amr_mode *modes always points at the full set of configured modes, and
only the AMR bits m4_75 thru m12_2 are unset to filter the used modes.
In the current test, the bits are unset to filter, but also the struct
amr_mode *modes is reduced accordingly. Instead, keep the modes fully
populated and unset only bits, like osmo-bsc does in practice.
The test results should not (and do not) differ.
Change-Id: I545de6fb66a4b74a3f08899795b4b4d9c4538f58
It's acceptable to verify an outcome by printing to an expected output.
It's unacceptable to commit those expected outputs without first
verifying that they are in fact correct!
In this case, the output has obviously not been even read, since the
length byte clearly indicates that one byte is missing from each buffer
dump.
I have now verified by hand against 3GPP TS 44.018 that each one of the
generated octets are indeed correct.
Change-Id: I92fcc7afe018a4a8dc91f0f2167e3a7835f623c9
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
Neels Hofmeyr
Pau Espin
Philipp Maier
Harald Welte