This configuration will be used as a fall-back when the MultiRate
configuration IE is not included in the CHAN ACT/MODIFY messages.
Change-Id: Ie96af636105ee1ffe2d9a0bd9eea375faebad149
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917, OS#4984
3GPP TS 48.058 defines the MultiRate configuration IE as optional,
and states that it's "included if the Channel Mode indicates that a
multi-rate codec is used". If I understand this correctly, it may
be omitted even if a multi-rate codec is requested. Otherwise it
would have been defined as a conditional IE.
For now let's print a warnig if this IE was expected, but missing.
We may need to apply some hard-coded defaults in this case.
If this IE is present, but the Channel Mode indicates a codec other
than AMR, let's send NACK with cause=RSL_ERR_OPT_IE_ERROR, assuming
that the CHAN ACT/MODIFY message is malformed.
Change-Id: I6ddc0b46a268ed56ac727cda57d0d68b2746fd59
Related: SYS#5917, OS#4984
According to 3GPP TS 48.058, section 4.1.4, BTS shall start transmission
on SACCH if both MS Power and *Timing Advance* IEs are present. There
can be no Access Delay IE in the RSL CHANnel ACTIVation message.
Change-Id: Icd8ccfd6e37ded8966125a473b5003845ba87fec
Fixes: I170b63c9856230d5f1a10654a9d950ada8e730d7
Related: SYS#5838
This avoid a NOTICE log line like the following when gsm_lchan_release()
is called.
"""
rsl.c:2484 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: cause = Normal event, unspecified
"""
Change-Id: I0ce78c52644983220f5810bc5c661b07afd9e543
It may happen after the A-bis connection recovery that the RF RESource
INDication message gets sent too early, while some timeslots are not
yet configured. This confuses the BSC and provokes error messages.
Change-Id: I00bc6fe67ea1bbedcd5d8640e73bd8b16b9e667f
Related: SYS#5313, SYS#4971
Currently an Uplink SACCH block is being passed to LAPDm first, and
then gets forwareded to the BSC in handle_ms_meas_report(), together
with the Uplink measurements collected so far.
This approach has a serious flaw: handle_ms_meas_report() won't be
called if an Uplink block contains SAPI=3 data (SMS) or was not
decoded at all (len=0) fow whatever reason. Therefore, no RSL
MEASurement RESult message will be sent to the BSC.
Rename handle_ms_meas_report() to lchan_meas_handle_sacch(), and call
it from l1sap_ph_data_ind(). This way perioduc RSL MEASurement RESult
messages will be sent regardless of what happens on Uplink SACCH.
Change-Id: Ifed91f87fd653debc87a09da3fd31ad64a13f330
Fixes: TC_meas_res_speech_{tchf,tchh}_sapi3
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
During the merge of [1] the patch hunk was applied at a slightly
wrong location, so the code path has become unreacheable.
Change-Id: I823c9101bcca72d5792e16379b02d3602ffc2726
Fixes: [1] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
For the sake of consistency, call repeated_dl_facch_active_decision()
from handle_ms_meas_report(), so we have all functions using the
measurement results for Downlink executed in a single place.
Change-Id: Ibd5377ce642e49161f320ac8c33e9f966b3ddfaf
Related: SYS#5114, SYS#5319
Fixes crash when TTCN3 BTS_Tests_LAPDm TC_rr_response_frame_loss
runs run after TC_t200_n200.
The BTS was shutdown after TC_t200_n200 failed (drop oml link), and
lchan was moved ACTIVE->NONE without lapdm_channel_exit() being called
on it. Hence, on next test (TC_rr_response_frame_loss), when
lchan_init_lapdm() was called again, some memory corruption was caused.
The lapdm_channel_exit can be dropped from gsm_lchan_release() and
rsl_tx_rf_rel_ack() since it's already called in the same path:
"""
rsl_rx_rf_chan_rel
gsm_lchan_release(lchan, LCHAN_REL_ACT_RSL);
l1sap_chan_rel(lchan->ts->trx, gsm_lchan2chan_nr(lchan));
l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE)
bts_model_l1sap_down
bts_model_lchan_deactivate_sacch(lchan);
-
lchan_deactivate(lchan);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_NONE); <---------
mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0);
l1sap_info_rel_cnf
rsl_tx_rf_rel_ack(lchan);
lapdm_channel_exit(&lchan->lapdm_ch);
lapdm_channel_exit(&lchan->lapdm_ch);
"""
Related: SYS#5262
Change-Id: If0ec5f0c7be4d15c8d684d33e15e24d68bd5192e
The OML NM Channel FSM state only apply to primary timeslots, hence we
need to make sure we pick the primary TS (the non-shadow one).
Due to this bug, all channels on shadow TS where NACKed because the
related state was never "Enabled Ok".
Fixes: c97a7f51e1
Related: OS#5249
Related: OS#5251
Change-Id: If47e4bdd45a05ed1b5709b6e3d541f2830723e37
This information may be useful for the BSC to determine whether
dynamic PDCH timeslots might be better used for new circuit
switched connections, or whether alternative PDCH slots should
be allocated for interference reasons.
Change-Id: I5b4d1da0920e788ac8063cc765fe5b0223c76758
Related: SYS#5313
It's cleaner from the architectural point of view to have the
interference measurements processed in a separate function.
Change-Id: I3981608e01a50585359cad673c38c8a305027d30
Related: SYS#5313
It may happen that the BSC requests logical channel activation on a
dynamic timeslot, which is in a process of switching from one pchan
type to another due to a preceding channel activation request.
In this case 'struct gsm_bts_trx_ts' already holds an msgb with the
preceding RSL CHANnel ACTIVation message, that is normally handled
once the PHY completes the process of timeslot re-configuration.
On receipt of subsequent RSL CHANnel ACTIVation messages, in function
dyn_ts_l1_reconnect() we overwrite the preceeding msgb (memleak), by
the most recent one. And once the timeslot re-configuration is done,
only the most recent CHANnel ACTIVation message gets ACKed.
In order to avoid this, let's move the msgb ownership to 'struct
gsm_lchan', so it cannot be overwritten by the CHANnel ACTIVation
message that is related to a different lchan on the same timeslot.
Change-Id: Ia625c2827fca883ea712076706d5ef21ed793ba6
Related: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Fixes: OS#5245
Have a more stable loop with less temporary oscillations at the expense
of increased reaction time.
4 SACCH blocks (P_CON_INTERVAL=2) is the minimum interval to get stable
measurements for the last requested MS Power level. With P_CON_INTERVAL=1,
are also made during a period with stable power being use to transmit,
but the MS Power level used (and announced in MR) is not the last one
requested by the BTS, but the one requested in the previous loop
iteration. This can make the MS and BTS bounce 2 values forth and back,
and create some temporary oscillation.
See osmo-bsc User manual section "Power Control" for more information.
Related: SYS#5371
Change-Id: I91c505447f68714239a4f033d4f06e91893df201
A broken BSC could send a Chan Activation on a TS which has not yet been
enabled (or even configured). This is the case with our TTCN3 tests,
where OML side is currently handled in parallel by an osmo-bsc while
TTCN3 takes care of the RSL side. This can actually be seen as a
malfunctioning BSC, but it was spotted that given this sequence of
events osmo-bts can crash (see ticket below).
Hence, let's NACK any attempt from a BSC to activate an lchan on a
disabled TS.
Related: OS#5249
Change-Id: I9c3b68487c12efc412a057728a561e061560c544
The first check in this function ensures that the state is NONE.
Therefore it does not make sense to print it below..
Change-Id: I62ea4117dd5e1eebb8774809134e5cb73774945c
The temporary overpower value that is to be used with FACCH and SACCH is
transferred using a proprietary RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP). The
parsed value is then stored in lchan->bs_acch_overpower_db so that it
can be used.
Change-Id: I426c2510865c4a986c68f2027cc676aaac0d8a4c
Related: SYS#5319
This is a preparation commit in order to move power loops up in the
stack in order to have DTXu information available, in order to decide
whether SUB or FULL ul measurements should be used in the MS Power
Control Loop.
Function rsl_tx_meas_res() is stripped from code changing state, and it
simply encodes content and transmits the message.
Change-Id: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
The ip.access style dynamic timeslots are a bit special in a way that
on the A-bis/RSL we always use the Channel Number value of TCH/F,
even in PDCH mode. This is why gsm_lchan2chan_nr() would always
return values corresponding to TCH/F for TCH/F_PDCH.
This behavior is only acceptable in the context of RSL messages, while
other parts of the code base may not work properly due to this trick.
A good example is the scheduler in osmo-bts-trx, where we have to
patch Channel Number value to make channel activation work.
DPCU INFO pcu_sock.c:853 Activate request received: TRX=0 TS=5
DL1C INFO l1sap.c:2043 (bts=0,trx=0,ts=5,ss=0) Activating channel TCH/F on TS5
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PDTCH
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PTCCH
In the code branch responsible for channel deactivation, we somehow
forgot to add the same workaround, so deactivation does not work:
DL1C INFO l1sap.c:2076 (bts=0,trx=0,ts=5,ss=0) Deactivating channel TCH/F on TS5
DTRX INFO trx_if.c:255 phy0.0: Enqueuing TRX control command 'CMD NOHANDOVER 5 0'
DRSL NOTICE rsl.c:1286 (bts=0,trx=0,ts=5,ss=0) (bts=0,trx=0,ts=5,ss=0) not sending REL ACK
Because of that, TCH/F_PDCH timeslots actually remain active after
deactivation, so the scheduler keeps producing L1SAP DATA.ind.
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583426/1194/00/29/14 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583430/1194/04/33/18 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
Instead of patching Channel Number in various places, let's rather
make the RSL specific behavior configurable by having two variants
of gsm_lchan2chan_nr().
Change-Id: I01680140c7201bf5284b278bceaea8ae01c122b2
Fixes: OS#5238
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
This commit extends existing MS Power Control Loop algorithm to take
into account computed C/I values on the UL, received from MS. The
related C/I parameters used by the algorithm are configured at and
provided by the BSC, which transmits them to the BTS similar to already
existing parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I5dfd8ff9ab6b499646498b507624758dcc160fb6
struct ipac_preproc_cfg seems to suggest that there may be up to 3 IEs
in some cases:
"struct ipac_preproc_ave_cfg ms_ave_cfg[3];"
Change-Id: I02633713eb557ee52e790a239f7b13b8c5b2b3bd
Fixes: 9238c3549d
Related: SYS#4918
When an Immediate Assignment comes in targeting an lchan that is not yet
active, then hold back the RR Immediate Assignment until the channel
becomes active.
This allows the BSC to send the Immediate Assignment before first
waiting for the Channel Activation ACK, saving one Abis roundtrip, and
helping avoid double allocation on high latency Abis links.
Related: SYS#5559
Related: I56c25cde152040fb66bdba44399bd37671ae3df2 (osmo-bsc)
Related: Ifb2c62431a91dafa6116b5d6b9410930f00a6e18 (osmo-ttcn3-hacks)
Change-Id: Ie52765b238b01f22fb327fe12327fbf10abcad4c
Instead of using tlvp_val16_unal() and then doing ntohs() here
and there, convert the remote port to the host byte order once.
Change-Id: Id883a976a03fd3022ed9d66f703b01244df2d9db
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
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.
Change-Id: I3299b6cdd230d3767321c3d6c64d468b7f5e1d02
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, in the recent 3GPP TS 45.008 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.
The power reduction operation can be controlled by the BSC by
sending BS POWER CONTROL on the A-bis/RSL with the Channel Number
IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the
transmission power on inactive timeslots of the BCCH carrier.
This is a non-standard, Osmocom specific extension, so indicate
support of this feature to the BSC in the feature vector. Also
add a VTY command to allow enabling/disabling the power reduction
locally. Add some signalling notes to the A-bis/RSL manual.
For more details, see 3GPP TS 45.008, section 7.1.
Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716
Related: SYS#4919
This change implements general interference averaging logic for
the higher layers. In l1sap_info_time_ind(), where we receive
TDMA time updates from BTS model, call rsl_tx_rf_res() for each
transceiver according to the interval defined by the Intave
parameter received from the BSC. In rsl_tx_rf_res() perform
the actual averaging for each inactive logical channel, and
then send everything to the BSC over the A-bis/RSL.
The BTS model specific code needs to report the measurements
for each logical channel every 104 TDMA frames (SACCH period)
by calling gsm_lchan_interf_meas_push().
Change-Id: Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
OsmoPCU will need this SI2 in order to gain knowledge of the BCCH
Frequency List being broadcasted, in order to build a per-MS specific
Neighbour List using NC_FREQUENCY_LIST bits in Packet Measurement Order.
Related: SYS#5303
Change-Id: If70c64f941f621a9a68aef2c846639b5c7f2f74b
This is an Osmocom specific RSL IE that, if present, takes
precedence over the values indicated via the A-bis/OML.
Change-Id: I717e5b2a6ca5b4faeaab9cae4bb971907945871b
Related: SYS#4895, OS#4941
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Neels Hofmeyr