The VTY handover_vtc.c offers a large number of handover specific
settings. Those settings are (with one exception) auto generated using
macros. Lets add an equivalent for the control interface that uses the
same auto generation mechanisms.
Change-Id: I12f143906818fd6b16e8783157cbb1eb51e49ffc
Depends: libosmocore I53fc207677f52b1dc748b01d58424839cdba807c
Related: SYS#5369
The VTY defun already indicates BSC_VTY_ATTR_RESTART_ABIS_OML_LINK
correctly, but so far we would immediately start using the new values
internally, and wrongly interpret interference levels. Fix that.
Have bts->interf_meas_params twice: interf_meas_params_cfg for the VTY
configured values, and interf_meas_params_used for the values that the
BTS actually knows about, after they were sent via OML.
In a running BSC, when changing the interference level boundaries on the
telnet VTY, the BTS is not immediately told about the change. That would
require a BTS restart. Hence store the cfg values separately in
interf_meas_params_cfg. For comparing/printing interference levels in a
running BTS, only employ the values that were actually sent via OML and
placed in interf_meas_params_used.
Related: SYS#5313
Change-Id: Iad8cf4151ff7f86dc0549158ed5d91d788d40b1f
Hold off re-assignment after an intra-cell re-assignment due to low
rxqual.
Adjust test_amr_tch_h_to_f_rxqual.ho_vty to show the changed behaviour.
Related: SYS#5198
Change-Id: Id00a07313fe04eec509b336c0637b59c707760e0
In an upcoming patch, handover_decision_2.c will use this indicator to
decide whether to start a penalty timer:
"hodec2: add low-rxqual-assignment penalty timer (2/2)"
Id00a07313fe04eec509b336c0637b59c707760e0
Related: SYS#5198
Change-Id: I5de385e0666f716184a62e6e70d656545ac5d2ee
Store the config option whether the channel allocator should try to
avoid lchans with higher interference levels reported in RES IND.
The actual implementation of avoiding interference follows in
I844494092193811dfd9fa4d52983cbaed0fc9248
Related: SYS#5313
Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
Add TDMA_MEAS_SET_AUTO to indicate automatic choice between FULL and
SUBSET measurements depending on DTX. So far use only in hodec2.
TDMA_MEAS_SET_AUTO looks at each individual measurement report's DTX
flag and for each report chooses FULL if DTX is not used, or SUB if DTX
is used.
The default setting for 'handover2 tdma-measurement' is still 'subset'.
To use the automatic choice, users need configure
handover2 tdma-measurement auto
Change-Id: I67dce55ccf892c8679272ee5dfedc25620f0f725
Cosmetic preparation for enabling automatic choice between FULL and
SUBSET measurements depending on DTX in handover decision 2.
Change the internal API to pass separate enums for the choices {RXLEV,
RXQUAL}, {UL, DL} and {FULL, SUB}.
Change-Id: I283e03126a6bc1f5f1b35f9801e841053edd2947
They will gain support to be activated as SDCCH/8 soon too.
Related: OS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
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
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
inter-BSC into this BSC: from BSSMAP Handover Request, parse and store
Kc128. All else is already implemented: depending on the chosen
encryption algorithm, Kc128 will end up in the Channel Activation.
inter-BSC out of this BSC: nothing is needed to support A5/4, the BSSMAP
Handover Required message does not contain any encryption related
information. The MSC already knows the chosen algorithm.
Related: SYS#5324
Change-Id: I7e9590e8c96aa50086148863ad9a2741b978e614
Receive and store the Kc128 key from MSC, and use as key sent to BTS if
A5/4 is the chosen encryption algorithm.
(A5/4 in handover will follow in a separate patch)
Related: SYS#5324
Change-Id: I7c458c8a7350f34ff79531b3c891e1b367614469
Add VTY command to trigger an intra-cell re-assignment, also allowing to
re-assign to a secondary VAMOS lchan.
Related: SYS#5315 OS#4940
Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
Add the Osmocom-specific extension to indicate VAMOS shadow lchans in
RSL, in lchan lookup and RSL message transmission.
Note that RR messages containing cbits (Assignment Command, Handover
Command, ...) must *not* send Osmocom specific cbits to the MS. Only the
RSL messages directed to the BTS send Osmocom specific bits.
Related: SYS#5315 OS#4940
Depends: If33c1695922d110c0d2c60d5c0136caf2587194e (libosmocore)
Change-Id: I957eff0d2c33ec795eda75a4bff21965b0179f73
It's bad to abort the program for an incompatible chan_nr. Instead of
OSMO_ASSERT(), make sure that error handling happens all they way to the
original callers of gsm_lchan2chan_nr etc.
This is also preparation to add further error causes: Osmocom specific
cbits needed for a non-Osmo BTS.
Related: SYS#5315 OS#4940
Change-Id: I71ed6437c403a3f9336e17a94b4948fca295d853
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
So far there is a bunch of code setting a primary lchan in VAMOS mode.
This patch now adds the actual secondary "shadow" lchans that may be
combined with a primary lchan in VAMOS mode to form a multiplex.
VAMOS lchans are put in the same ts->lchan[] array that keeps the
primary lchans. They are at most two additional usable lchans (for a
TCH/H shadow) added to either TCH/F or TCH/H.
Keeping these in the same array allows looping over all lchans easily.
The ts->max_primary_lchans indicates the index of the first VAMOS shadow
lchan.
Related: SYS#5315 OS#4940
Change-Id: I928af99498bba488d317693f3144d4fccbbe9af3
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
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
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 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
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
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
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 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
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
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
Change lchan_set_last_error() to macro so that the error log reflects
where the error was encountered.
Change-Id: I571fdf2d418c52d120215cf19e57a3c96d67af07
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
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
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
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
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
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
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
The function is not really handover specific, and will be used in other
places in subsequent patches.
Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
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 required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Other BTS are not enabled by default since NACC support is not known to
work nor tested there.
Depends: libosmocore.git Change-Id I61991266b95d0c13d51b47906cc07846e9cf1390
Related: SYS#4909
Change-Id: If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28
Add 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
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
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
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
This change introduces two optional function pointers:
- power_ctrl_enc_rsl_params() - this function will be called by the
A-bis/RSL code in order to encode MS/BS Power control parameters
for CHANnel ACTIVation and MS/BS POWER CONTROL messages.
- power_ctrl_send_def_params() - this function will be called for
each transceiver on A-bis/RSL link establishment in order to
send default MS/BS Power control parameters.
Change-Id: Iba3ad5d8d549a6676050272f85b21c9b4c219d21
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
Steve Langasek <steve.langasek@ubuntu.com> submitted some patches
against downstream osmo-bsc 1.3.0 because some possible null derefences
were detected by the compiler on Ubuntu s390x. Code has eveolved since
then and patch doesn't apply directly anymore, since related code
changed (we now use osmo_count in bsc_subscr_get).
The compiled allegedly claimed some null dereference in gsm_lchan_name.
In general code using that function seems to be doing checks for
existing lchan before calling it, or assuming the lchan pointer is not
null, so I couldn't find any major issue.
However, let's add a OSMO_ASSERT to make sure we can easily identify the
issue if an issue ever happens there, since the gsm_lchan_name should
clearly only be called on non null pointers.
Change-Id: If4d12cb1d95ee2a89244bb8f27df839871667387
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
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
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
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
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
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
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
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
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
Move conn allocation to bsc_compl_l3(), from gsm0408_rcvmsg().
Drop dispatch of GSCON_EV_A_DISC_IND, because a) we did not receive such
DISC.IND, and b) the lchan release will discard the conn in the regular
fashion.
In upcoming LCS patch, bsc_compl_l3() will decide whether to allocate a new
conn or whether a conn from a Perform Location Request already exists for the
subscriber.
In this patch, it becomes clear that the conn->bsub is always NULL in
bsc_compl_l3(), and that the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);'
never has the intended effect. An upcoming patch will change that.
Change-Id: I92af0f0d54c4282d782f2b29d524a64006c3b674
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973
Related: SYS#4915
Change-Id: I740be0a401612bb5ed4e8ccd7f4be8176b936449
The protocol 9 was extended (compatible) with
* app info request
* suspend request (ETWS)
* rach indition (add fields ts / trx)
Only copy the relevant parts but no implementation.
Related: OS#4766, OS#4767, OS#4768
Change-Id: Ia81310326b093a8e473b6c69045304667b3b60f1
During the A-bis/OML bootstrapping, osmo-bsc sends Opstart to the
Radio Carrier MO twice. The first Opstart is triggered by the
State Changed Event Report, originated by the Radio Carrier itself.
The second is triggered by Software Activated Report.
According to 3GPP TS 12.21, figure 2, we shall send it only once,
after the "Attribute setting" step. Therefore, the first Opstart
is premature, and we shall not send it.
Related: SYS#5063, OS#4755
Change-Id: If69393551117266ecb726d8961153560b2b3cc59
Backwards compatibly, introduce timer groups in OsmoBSC, and move some
non-specified T timers to new X timers:
T993111 -> X3111
T993210 -> X3210
T999 -> X4
Why X4? because there already is an X3 used elsewhere in Osmocom, and I find
it less confusing if X-numbers don't repeat across programs. See
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc.
This makes the MGCP timeout configurable for the first time.
Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T
timers to X timers on-the-fly. All previous VTY commands still work, and new
'timer [(net|mgw)] ...' commands are added. timer.vty shows this.
Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so
that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands.
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
It does not make sense to set the bsc_subscr's LAC from a Paging Request,
especially since the paging code has loops that possibly kick off several
pagings.
At this point, there remains no code setting bsub->lac anywhere. We could set
it during rx of Complete Layer 3, but since there is no use for it besides a
vty dump, let's just drop the bsub->lac completely, and the vty dump of it.
Change-Id: Id017bd494d329b6fc254d7135b4074ac2b224d66
RF-locking: simply ask bsc_grace_allow_new_connection() at the start of
page_subscriber(). Before this patch, we would log an INFO of "Paging request
failed" when RF-locked, for each BTS. Instead log "RF-locked". (An upcoming
patch will introduce a LOG_PAGING() macro that will trivially add more log
context there, so not bothering now.)
Drop LAC condition: since Stefan introduced page_subscriber() starting 2018
Ic3c62ff0fccea586794ea4b3c275a0685cc9326e, matching a requested LAC to a
specific BTS is done *before* calling page_subscriber().
BTW: the msc->core_lac (config 'core-location-area-code') has not had an effect
on Paging maybe ever. I opened OS#4751.
Change-Id: Ic8696414a1db8f4b1be502d6434599f684746ed6
when an emergency call arrives while all TCH are busy, the BSC should
pick an arbitrary (preferably the longest lasting) call / lchan and
release it in favor of the incoming emergancy call.
The release of the existing call is a process that can not be done
synchronously while the ChanRQD is handled sonce multiple messages are
exchanged between BTS and MSC and multiple FSMs need to do their work.
To be able to release one lchan while handling a ChanRQD a queue is
implemented in which the incomming channel requests are collected. If
an emergency call is established while all channels are busy, an
arbitrary lchan is picked and freed. When freeing the lchan is done,
the queue is checked again and the emergency call is put on the free
lchan (TCH/H or TCH/F).
Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36
Related: OS#4549
osmo-nitb supports the modification of an lchan if the lchan is
compatible but in the wrong mode. This feature was dropped in the
transition to AoIP/bsc-split. However, osmo-bsc still has code to
generate and parse the messeages, but the FSMs do not support a mode
modify yetm
Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in
order to support mode modify again
Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb
Related: OS#4549
During handover cleanup due to a Clear Command from the MSC, do not send
another Clear Request to the MSC. Only send that when no Clear Command was
received yet.
Add a flag rx_clear_command per gscon instance, indicating whether a Clear
Command was received, and exit early in gscon_bssmap_clear() when true.
This is part of patches fixing the rate counters around handover, which uncover
some bugs:
- Another patch enables proper handover result handling when receiving a Clear
Command.
- After that, the handover_end() handling would always cause sending a Clear
Request, even if a Clear Command was already received.
- This patch removes the extraneous Clear Request, for this scenario and for
all other corner cases that might still exist.
Related: OS#4736
Change-Id: Iab82cac0a7ffa7d36338c8ff7c0618a813025f13
So far, during inter-BSC outgoing handover, when receiving an RR Handover
Failure from the MS, it would be counted as 'error'. Instead, add the 'failed'
counter like for all other HO types.
It may make sense to omit the 'failed' counter for inter-BSC *incoming*
handover, because then we won't receive an RR Handover Failure message. I
probably got those two mixed up during initial development.
Related: OS#4736
Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc
to be configured as CBC client *and* CBC server at the same time.
cbsp_link.c expects at most one CBSP link to be established, and, upon sending
CBSP messages, probes whether to send the message to a CBSP server or client
link. When both listen-port and remote-ip are configured (regardless of an
actual CBSP connection), osmo-bsc gets confused about where to send CBSP
messages.
One solution would be more accurate probing for an actual established TCP
connection. But the simpler and less confusing solution is to force the user to
configure only server or only client mode, never both.
Introduce 'cbc' / 'mode (server|client|disabled)'.
Secondly, clarify the 'cbc' config structure into distinct 'server' and
'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP
addresses for server and client mode can remain configured when the CBSP link
is switched between server/client/disabled modes.
To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str
for address configuration.
Related: OS#4702
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
As 3GPP TS 48.058 clearly states, an RLL RELease INDication is only
sent if the datalink is released by the MS. Thre's no cause value
giving further diagnostics, but if the MS releases the link, it is
clearly not the BSS's fault, and hence "BSS not equipped" is wrong.
Change-Id: I38222e60071841abcd06046a472ddb35907164a4
Related: OS#4728
Philipp Maier
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Keith Whyte
Harald Welte