|Age||Commit message (Collapse)||Author||Files||Lines|
In change  the new power control structures and default params
were introduced. In change , 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 , 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.
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.
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.
Checking if a given RSL IE is present is a straightforward task,
so there is no need for a special boolean flag.
struct lchan_power_ctrl_state actually contains more fields,
which also must be initialized on CHANnel ACTIVation.
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.
3GPP TS 44.006, section 11 describes a method how the downlink
SACCH transmission can be repeated to increase transmission
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
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.
Depends: libosmocore.git I9d6ed06731ae15fdcef1a1f397d6ac2b7b1ca980
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.
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.
- 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().
Depends: libosmo-abis I41603db8c1286660ad57ac1c78a8fb393a2b080b
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);
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)
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
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.
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
Both ms_power and ms_power_ctrl are reset to 0 again further below.
The interesting value in this case is the incoming new ms max power.
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).
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
Related: OS#4047, OS#4048
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
It was noticed with old Sony Ericsson phones (like W595 and K510i)
that the service provided by Osmocom network becomes unreliable
from time to time. The RSSI indicator on those phones shows that
the signal is lost, so neither CS nor PS services are working.
As it then turned out, System Information 3 broadcasted on the
Um interface is different than the one received from the BSC.
In particular, the content of SI3 Rest Octets IE is different.
Among with the 'GPRS Indicator', which is actually expected to
indicate whether the PCU is connected or not, SI3 Rest Octets
on the Um interface contain both 'Optional Power Offset' and
'Scheduling if and where' IEs, which are not present in the
original messages from the BSC.
Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE
contains different 'GPRS RA Colour' value, and informs the MS
that System Information 13 is sent on extended BCCH, which
is not even supported by OsmoBTS!
The culprit is in rsl_rx_bcch_info(), where we pass a pointer
to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a
pointer to the beginning of SI3 buffer, we actually need to
shift it to the beginning of the SI3 Rest Octets IE.
This change makes my Sony Ericsson phones happy ;)
Dynamic MS power control should only be active if a power parameters IE
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference
element must be included if channel activation type is 'handover'.
Let's properly reject CHANnel ACTivation messages with missing
RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted
as regular (non-handover) channel requests.
Found using TC_ho_rach() TTCN-3 test case.
osmo-bts cannot provide GPRS service while osmo-pcu is not connected.
The BSC has no knowledge of the PCU connection state. Prevent MSs
from trying to register for GPRS while the PCU is disconnected by
erasing the GPRS Indicator in SI3.
Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git)
Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git)
Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git)
The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.
As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.
Fixes: CID#198663 Null pointer dereferences
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
...so let's have a more neutral error message
The spec is quite clear: If the MS Power Parameters IE is present, then
the BTS shall perform autonomous MS power control. If it's absent,
then the MS power shall be fied. Let's adjust our code accordingly.
There's no point in open-coding what LOGPLCHAN was created to do:
Log some event while stating the name of the logical channel.
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
The logic for Extended CBCH are the same as for the Basic CBCH, we just
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
This off-by-one error in length verification caused all SACCH INFO IE
to be deemed invalid and hence any RSL CHAN ACT with that IE to be
The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.