aboutsummaryrefslogtreecommitdiffstats
path: root/src/common/rsl.c
AgeCommit message (Collapse)AuthorFilesLines
2021-01-08power_control: migrate MS/BS control loops to the new paramsVadim Yanitskiy1-8/+1
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
2021-01-07power_control: handle MS/BS Power control params on A-bis/RSLVadim Yanitskiy1-14/+229
Change-Id: I5a901eca5a78a0335a6954064e602e65cda85390 Depends: I2f4ed56837dd479dbbd10c0a7df0ed7565d3946a Related: SYS#4918
2021-01-03fix-up missed review comment in CBCH SI4 patching fixHarald Welte1-1/+1
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
2021-01-03sysinfo.c: Fix SI4 GPRS patching which overwrote CBCH IEHarald Welte1-7/+10
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
2020-12-30rsl: remove redundant boolean flag in rsl_rx_chan_activ()Vadim Yanitskiy1-3/+1
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
2020-12-10log: rsl_rx_chan_activ: show chan type as human readable stringNeels Hofmeyr1-2/+4
Change-Id: I3acf6c18309d3b4093dbc295be622363cb6dbcdc
2020-12-08rsl: properly initialize MS/BS Power Control stateVadim Yanitskiy1-6/+10
struct lchan_power_ctrl_state actually contains more fields, which also must be initialized on CHANnel ACTIVation. Change-Id: Id9719088fc6e9479c13e9b327a3466d9e2810a3a Related: SYS#4918
2020-12-06power_control: implement BS (Downlink) Power ControlVadim Yanitskiy1-16/+36
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
2020-11-27l1sap: add repeated downlink SACCHPhilipp Maier1-2/+4
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
2020-11-27l1sap: add repeated downlink FACCHPhilipp Maier1-0/+32
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
2020-11-26part 1 of: fix SAPIs for handover to match 48.058 4.1.{3,4}Neels Hofmeyr1-0/+14
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
2020-10-15sysinfo: Don't broadcast SI4 GPRS INDICATOR if PCU is disconnectedHarald Welte1-0/+9
Depends: libosmocore.git I9d6ed06731ae15fdcef1a1f397d6ac2b7b1ca980 Change-Id: I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa Related: OS#3075
2020-09-16Avoid sending RSL RF REL ACK if PDCH chan is disabled by administrative lockPau Espin Pedrol1-5/+19
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
2020-08-07rsl: constify the 'lchan' argument of rsl_tx_conn_fail()Vadim Yanitskiy1-1/+1
Change-Id: Icec43d7c1f3b99292fa87462ad65b2c19fdd3b5f
2020-07-23rsl: Fix wrong param passed to gsm_pchan_name() in log linePau Espin Pedrol1-1/+1
Change-Id: I42b7a79b85e8750a12166dbfc66ad06f7cb713a6
2020-06-15A-bis/RSL: refactor handling of BS Power IE (power reduction)Vadim Yanitskiy1-17/+26
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
2020-06-05rsl: refactor handling of RSL_IE_MR_CONFIGVadim Yanitskiy1-14/+13
- 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
2020-03-08rsl: make IP DSCP configurablelaforge/virt-voiceOliver Smith1-2/+9
Related: OS#4438 Depends: libosmo-abis I41603db8c1286660ad57ac1c78a8fb393a2b080b Change-Id: Icdef5d40243fefdeae23f3bcf9c6702e8487928a
2020-01-12rsl.c: Fix compiler error on gcc-9.2.1Harald Welte1-1/+1
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
2020-01-03rsl: ensure measurement reports are sentPhilipp Maier1-4/+7
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
2019-12-05rsl: Clarify when autnonoums MS Power Ctrl Loop is usedPau Espin Pedrol1-9/+6
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
2019-12-03rsl_rx_chan_act: Apply bitmask when parsing IE MS_POWERPau Espin Pedrol1-1/+1
Change-Id: I99c6a4d353f405582d5e4f9d12c01c25c7bb4dff
2019-11-14Move and rename gsm_lchan.ms_power fieldPau Espin Pedrol1-12/+11
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
2019-11-14rsl: Remove unneeded duplicate reset on some lchan fieldsPau Espin Pedrol1-3/+0
Both ms_power and ms_power_ctrl are reset to 0 again further below. Change-Id: Ia2a5da068d440232361d57bd5ac33eddebf05ebe
2019-11-14Change gsm_lchan field fixed to boolPau Espin Pedrol1-8/+8
Change-Id: I715ef151b67a21e325c574585a257e71b4b0ce2a
2019-11-12rsl: Fix logged value in rx MS Power ControlPau Espin Pedrol1-1/+1
The interesting value in this case is the incoming new ms max power. Change-Id: Ib6fcb21b1b4bdbc8b749a1b8543d97331699ef3b
2019-11-12rsl: Assign recv pwr to lchan's max ms powerPau Espin Pedrol1-2/+22
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
2019-10-17Fix common misspellings and typosMartin Hauke1-4/+4
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-09-07common/rsl.c: fix possible NULL-pointer dereferenceVadim Yanitskiy1-1/+5
Change-Id: I11a35a8f500fafa7b3c93d2f2244cc4d42f09f1b Fixes: CID#203810
2019-09-06pcu_interface: Forward ETWS Primary Notification to PCUHarald Welte1-0/+5
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
2019-09-05ETWS Primary Notification via P1 Rest OctetsHarald Welte1-0/+43
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. Closes: OS#4047 Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680 Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
2019-07-18common/rsl.c: fix: properly handle SI3 Rest OctetsVadim Yanitskiy1-1/+3
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 ;) Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
2019-07-17fix spelling stuff mentioned by lintianThorsten Alteholz1-1/+1
Change-Id: I3d6cb6fc1b182d8520ba60e431ab9b74e71d5e3c
2019-07-16RSL: Fix fixed MS power control in RSL CHAN ACTIVEric Wild1-0/+8
Dynamic MS power control should only be active if a power parameters IE was supplied. Change-Id: I0bbe171a287b10d71fc853cd721f66e4c84db8c5
2019-06-05Use #define RSL_CHAN_RACH for RSL Channel Number of RACHVadim Yanitskiy1-1/+1
Change-Id: I7f54fccdae6799e5f4d956a101e11c2d6f998546
2019-06-01common/rsl.c: RSL_IE_HANDO_REF is mandatory for handover CHAN ACTVadim Yanitskiy1-3/+7
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. Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
2019-05-28clear GPRS indicator in SI3 while PCU is disconnectedHarald Welte1-7/+15
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. Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git) Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git) Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git) Related: OS#3075
2019-05-27Fix passing of RR SUSPEND REQ from DCCH to PCU socketHarald Welte1-9/+33
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. Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6 Related: OS#2249 Related: OS#4023
2019-05-26common/rsl.c: fix NULL-pointer dereference in rsl_rx_rll()Vadim Yanitskiy1-2/+2
Change-Id: I07e39e69a42dd09841f5d03608ec0d0b2345139a Fixes: CID#198663 Null pointer dereferences
2019-05-25Add severity to OML FAILURE EVENT REPORTHarald Welte1-4/+4
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. Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
2019-05-24rsl: MS POWER COCNTROL isn't (only) about "forcing" power levelsHarald Welte1-1/+1
...so let's have a more neutral error message Change-Id: I1ffa336b18347c2fcedfeb398b255dc517245d7a
2019-05-24rsl: Implement parsing of BS Power Control messageHarald Welte1-0/+44
Change-Id: Id144a7e468f730e3cdaefa4cf2ad51c6106310a2
2019-05-24RSL: Fix logic about fixed/dynamic MS power control in MS POWER COMMANDHarald Welte1-6/+21
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. Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5 Related: OS#1622
2019-05-24Use LOGPLCHAN whenever possibleHarald Welte1-143/+101
There's no point in open-coding what LOGPLCHAN was created to do: Log some event while stating the name of the logical channel. Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
2019-05-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte1-0/+26
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 Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
2019-05-21cbch: Support Extended CBCHHarald Welte1-2/+8
The logic for Extended CBCH are the same as for the Basic CBCH, we just need to * duplicate our related state * parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE * start to send data on the Extended CBCH (TB=4..7) Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429 Closes: OS#3535
2019-05-21cbch: Fix memory leak and send error message on invalid SMSCB commandHarald Welte1-3/+7
Change-Id: I411d1fb3693a2f7cf7bba3d38b1aaf276a4137ba Related: OS#4011
2019-05-21RSL: Fix off-by-one error when parsing SACCH INFO IE in RSL CHAN ACTHarald Welte1-1/+1
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 rejected. Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e Related: OS#3750
2019-05-21RSL: Reject RLL messages for lchans that are not active yetHarald Welte1-0/+8
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." Related: OS#3750 Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
2019-05-20rsl: Include Channel Nr and Link ID in Error reports whenever possibleHarald Welte1-13/+27
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we still should include it whenever possible to help error analysis. Related: OS#3750 Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58