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
Ensure that we check the PHY capabilities in both cases:
* RSL CHANnel ACTIVation, and
* RSL CHANnel MODE MODIFY,
by calling bts_supports_cm() from rsl_handle_chan_mod_ie().
Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode',
so we can handle VAMOS enabled channel modes and CSD later on.
Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91
Related: SYS#5315, OS#4940
For some reason, handling of the Channel Identification IE was done
in l1sap_chan_act(). This function is being called on reciept
of the CHANnel ACTIVation message, but not on MODE MODIFY.
Change-Id: I07f95e69e6230a1daca62cc0a7c64954f191fa8a
Related: SYS#5315, OS#4940
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
In change [1] I added the missing 'default' branch to the 'switch'
statement in lchan_tchmode_from_cmode(). This caused massive
regressions in ttcn3-bts-test, because osmo-bts started to NACK
some RSL CHANnel ACTIVation messages.
What caused a lot of regressions in ttcn3-bts-test is actually the
missing branch for RSL_CMOD_SPD_SIGN in the 'switch' statement.
It was not a problem before [1], because the 'default' branch was
not there. I was about to add the missing 'cause' when I realized
that this function needs to be reworked first...
First of all, lchan_tchmode_from_cmode() does a bit more than just
deriving RR (TS 44.018) channel mode from RSL (TS 48.058) channel
mode. It additionally stores the 'Speech or data indicator' to
the logical channel state, and also changes some global DTXd related
flags in 'struct gsm_bts'. Let's use a more precise name.
lchan_tchmode_from_cmode() -> rsl_handle_chan_mod_ie()
Together with renaming, it becomes logical to have the IE presence
check in rsl_handle_chan_mod_ie(), so that we can reduce code
duplication in the calling functions a bit.
Finally, the main problem is that coding and interpretation of the
6-th octet 'Speech coding algor./data rate + transp ind' depends on
the 4-th octet of the Channel Mode IE. We cannot handle all values
in one 'switch' statement without proper discrimination:
a) If octet 4 indicates Speech, then octet 6 shall be interpreted
as the GSM speech coding algorithm (FR, HR, AMR, etc.).
b) If octet 4 indicates Signalling, then octet 6 shall be set
to '00'O, because this is the only value defined in version
16.0.0 of 3GPP TS 48.058. All other values are reserved.
c) If octet 4 indicates Data, then octet 6 shall be interpreted
as CSD data rate further discriminated by service transparency.
Therefore, we need take both values into account. This can be
achieved by mixing them together using the bitwise operators,
just like we do in L1SAP code.
Change-Id: Iba967f5bd0cc8ad6cd3ccd40cca38b15ffe96b2c
Related: [1] I67a70132999be6580a29e6b814763309a6df4ae9
Related: SYS#4895, OS#4941
in struct gsm_lchan and also in other places l1_info is handled in its
binary form. Libosmocore now offers structs to handle l1 info, so lets
use those structs to get rid of all the manual decoding of l1_info.
Depends: libosmocore I23c1890b89d5a0574eb05dace9f64cc59d6f6df7
Change-Id: I5eb516d7849750f3dd174d48c9f07dabf2c80515
This patch PCUIF extends the SAPI 4 that is used
to transfer SI13 only, so that it can transfer SI1 and SI3 as well.
The system information SI1, SI3 and SI13 is needed by the NACC RIM
application which runs inside osmo-pcu.
Depends: osmo-pcu I5138ab183793e7eee4dc494318d984e9f1f56932
Change-Id: Ib7aeb41e634ad6fcab3766a4667b0267c749436a
Related: SYS#5103
A channel activation for handover to another cell does not know the
Timing Advance until the handover RACH is received. It does not make
much sense to enable downlink SACCH without an accurate TA.
If the BSC omits the Access Delay IE (a.k.a. the Timing Advance), do not
enable downlink SACCH. This is expected to happen only for inter-cell
handover. In all other situations, the TA should be known either from a
Channel Request RACH for Immediate Assignment, or from the previous
lchan on the same cell upon Assignment / intra-cell handover.
Related: OS#4008 OS#4009 SYS#5192
Change-Id: I170b63c9856230d5f1a10654a9d950ada8e730d7
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
This is a follow-up fix for I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
get_si4_ro_offset() itself already checks if it's less than GSM_MACBLOCK_LEN,
so we must check if it's not negative.
Change-Id: Iba99e5de625af6bed6720a38fec26c2acc6251c0
In Change-Id I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa we introduced
patching of SI4 to indicate GPRS presence in terms of PCU connection
status. Unfortauntely this didn't account for optional IEs being
present in SI4, and hence overwrote any CBCH related information
elements, if present.
This in turn meant that since the above-mentioned commit, you could
have either a GPRS-capable, network, or a Cell Broadcast capable one.
Change-Id: I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
Related: OS#3075
Checking if a given RSL IE is present is a straightforward task,
so there is no need for a special boolean flag.
Change-Id: I6a12930314c79b9c3efabfa575b17f78105fea4c
struct lchan_power_ctrl_state actually contains more fields,
which also must be initialized on CHANnel ACTIVation.
Change-Id: Id9719088fc6e9479c13e9b327a3466d9e2810a3a
Related: SYS#4918
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
3GPP TS 44.006, section 11 describes a method how the downlink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I00806f936b15fbaf6a4e7bbd61f3bec262cdbb28
Related: OS#4794, SYS#5114
3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114
This part adds the common lchan flags to indicate whether DL SACCH
should be activated.
Note that currently, osmo-bsc *always* sends the MS Power IE as well as
the TA IE, also for inter-cell HO, so in the osmoverse, nothing will
change until we also adjust osmo-bsc. See OS#4858.
Change-Id: Ibea973ccadf5d424213f141f97a61395856b76de
If for whatever reason a TS stops being announced as available to the
PCU (for instance because the TRX became administratively locked), the
PCU will send a Release for that channel, but in that case we don't want
to send an RSL RF Channel Release ACK because it was not initiated by
related command from BSC.
In the case of a simple PDCH timeslot (no dynamic), the behavior is
already there but we don't print an error log since it's expected.
In the case of a dyn osmo TS, we only need to respond to RF Channel
Release when PDCH is deactivated here, but in other cases we don't need
to submit anything to BSC.
Change-Id: I8ae9ee450763a0e14edf950e38b64a32df14f44f
According to 3GPP TS 08.58, section 9.3.4, BS Power IE indicates
the transmission power attenuation on a particular channel:
+--------------+---------+-----------------+
| Reserved (3) | FPC (1) | Power level (4) |
+--------------+---------+-----------------+
so let's change handling of this IE as follows:
- s/bs_power/bs_power_red/g, so it reflects 'reduction';
- store power attenuation value in dB, not in 2 db steps;
- get rid of ms_power_ctrl.bts_tx_pwr, it's always 0 anyway;
- fix rsl_tx_meas_res(): use lchan->bs_power_red;
- always check if FPC (Fast Power Control) flag is set;
- we don't support it, so reject messages containing it;
- fix rsl_rx_chan_activ(): properly apply the bitmask.
Change-Id: I16cc50dfca102030380a06e16c234d5f6698f38f
- get rid of gsm_lchan::mr_bts_lv, it's never used anyway,
- check IE length in amr_parse_mr_conf() before parsing,
- check return code of amr_parse_mr_conf().
Change-Id: Ibfd5845ea429945b352dd14421e86562998d65ca
rsl.c: In function ‘rsl_rx_ipac_XXcx’:
rsl.c:2147:39: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 28 [-Werror=format-truncation=]
2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr);
| ^~
rsl.c:2147:3: note: ‘snprintf’ output between 5 and 260 bytes into a destination of size 32
2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Id982a814f401e304327d25c77666f039bc156c1f
osmo-bts currently does not generate a measurement report in case the
SACCH of the related traffic channel is lost. This is a problem because
the moment when reception gets bad measurmenet reporting is crucial to
carry out handover decisions effectively.
The presence of a SACCH block controls the conclusion of the measurement
interval and the sending of the RSL measurement report. The latter one
not only requires a measurmenet indication, it also requires a fully
intact SACCH block.
Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to
ensure a SACCH block is always reported up to l1sap.c. In cases where
the SACCH is bad, trigger the sending of the RSL measurement report
manually without attaching the measurmenet data from the MS (which we do
not have in this case)
Related: OS#2975
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
Simplify when the fixed field is set in rsl_rx_chan_activ.
Comment talks about enabling autonoumous control loop, but it is
actually describing it when disabling it, which is confusing.
Change-Id: Id6b444a33ab062f6dab11a0ce62d8aecaea87591
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
Otherwise older ms_power value will be kept and used as a maximum.
From TS 08.58 sec 4.8 "MS power control":
"""
If power control is supported by BTS and it is to be used,
this is indicated by optional parameters in the MS POWER CONTROL
message (or the CHANNEL ACTIVATION message). Based on the
measurements performed on the uplink, TRX then attempts to keep
the power control parameters within the limits set by the
MS POWER CONTROL message (or by the CHANNEL ACTIVATION message).
"""
Change-Id: I0583eef477c33279ee5bfcda80141f365413a276
All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This enables the last of the three methods by passing any
ETWS Primary Notifications received over RSL via the PCU socket into
the PCU.
Change-Id: Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
Related: OS#4047, OS#4048
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Neels Hofmeyr
Oliver Smith
Martin Hauke