aboutsummaryrefslogtreecommitdiffstats
path: root/src/common/l1sap.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-09l1sap: do not print redundant info in l1sap_chan_act()Vadim Yanitskiy1-2/+1
LOGPLCHAN() prepends the BTS/TRX/TS numbers itself. Change-Id: I8a1dd7da7098fe8c8a015459608d9134821fb322
2020-06-25Use libosmocore's TDMA frame number API (constatns & arithmetic)Vadim Yanitskiy1-2/+2
Depends: (libosmocore) Ic291fd3644f34964374227a191c7045d79d77e0d Change-Id: I61c97a62bd5dbbb4a984921ebdfc10ad6ed00f2a
2020-06-11Do not mix public and private BTS features, use libosmocore's APIVadim Yanitskiy1-4/+4
It was a very bad idea to mix "public" BTS features, that are reported to the BSC via OML, and those features, that are used locally (and exclusively) in osmo-bts. Why? At least because we already have the BTS feature manipulation API in libosmocore, that is used by osmo-bsc, but for some reason not by osmo-bts. New features added to libosmocore would clash with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP. So what this change does can be described as follows: - remove duplicate definition of the "public" features, - use libosmocore's API for the "public" features, - separate both "internal" and "public" features: - the "public" features continue to live in bitvec, - the "internal" features become flags, - s/BTS_FEAT/BTS_INTERNAL_FLAG/g. Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
2020-06-05gsm_data_shared: drop unused sacch_deact from struct gsm_lchanVadim Yanitskiy1-3/+0
Change-Id: I93c6bebbf715076c774248596089c77511733acc
2020-04-01l1sap: fix gsmtap_ph_rach(): properly pack 8-bit and 11-bit RAVadim Yanitskiy1-2/+12
According to 3GPP TS 44.004, section 7.4a, two alternative RACH block formats are specified: 8 bit (1 octet) and 11 bit. The bit order is little-endian (right to left). In L1SAP PH-RACH.ind structure (see ph_rach_ind_param) we use a field of type uint16_t to store RA values regardles of the block format. Thus when packing it to bytes, we cannot just cast uint16_t* to uint8_t*, we need to do some bit shifting. Change-Id: I0e91d825bb2e1897647dd5403c311d833a89ff2e
2020-03-08l1sap: Use msgb_pull_l2() and unify l1sap_tch_ind + l1sap_ph_data_indHarald Welte1-3/+2
In l1sap_ph_data_ind() we can use msgb_pull_l2() which is an exact implementation of the functionality there. In l1sap_tch_ind(), the existing code is actually wrong by making the assumption that the msgb contains exactly an entire osmo_phsap_prim. Better to also dynamically compute the number of bytes to ensure we only pull those ahead of the L2 header, no matter what their exact count. Change-Id: I13f7f8ba93795e40b1fb4a306fe765e059f642cf
2020-02-17osmo-bts-sysmo: merge measurement data and payloadPhilipp Maier1-1/+11
For osmo-bts-sysmo the MPH INFO MEAS IND indication is still sent separately. Lets merge the measurement information into the PH DATA Change-Id: Iffe7865727fbf9bca8eb32a96e8ea05cf718a948 Related: OS#2977
2020-02-12l1sap: Change loglevel of Rx TCH.ind INFO->DEBUGPau Espin Pedrol1-1/+1
This line appears tens of times per second when a call is ongoing, making it impossible to follow logs on INFO level. Change-Id: Iadb1baf55df2f6d96f85260f2e8d03627fef7e66
2020-01-20l1sap: merge MEAS IND into PRIM PH DATA / PRIM TCHPhilipp Maier1-20/+88
The MPH INFO MEAS IND indication, which contains the uplink measurement data is sent in parallel to the PH DATA and TCH indications as a separate indications. This makes the overall uplink measurement data processing unnecessarly complex. So lets put the data that is relevant for measurement into the PH DATA and TCH indications directly. This change only affects osmo-bts-trx at the moment. In order to keep the upper layers (l1sap.c) compatible we add an autodection to switch between separate measurement indications and included measurement data. Related: OS#2977 Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42 Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
2020-01-14L1SAP: use LOGL_DEBUG for logging from rach_pass_filter()Vadim Yanitskiy1-3/+3
Due to relatively small training sequence of Access Bursts, there can be frequent false-positives (basically noise). Fortunately, we can distinguish them from the real Access Bursts by checking the signal measurements attached to them (BER, ToA and C/I). Let's reduce verbosity of logging messages as they are mostly useful for debugging and may confuse the users / operators. Change-Id: I7ab6727ffff00140a7f9e762b299b711481393f1
2020-01-03l1sap.c: ensure ms power control loop is runningPhilipp Maier1-0/+2
When a bad SACCH frame is received the processing of the frame is ended early and lchan_ms_pwr_ctrl() is not called. This means that the power control loop does not get informed about a situation where the signal level is very weak and increasing the ms power would make sense. In order to ensure that the power control keeps working on lost SACCH frames, lets call lchan_ms_pwr_ctrl() with the current RSSI and the requested (BSC) power setting. Related: OS#4281 Change-Id: I4fb85754b1a69376b02da7f4b175c6e8ec9cc35c
2020-01-03rsl: ensure measurement reports are sentPhilipp Maier1-1/+10
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-23l1sap: is_fille_frame(): verify len of data comparedPau Espin Pedrol1-0/+3
Change-Id: Id3d1725ff36091ed5c57927caad09a8baea6f52e
2019-12-04rach_pass_filter(): Add information about channel typeHarald Welte1-10/+11
When logging about filtering access bursts, let's indicate if this is on a CCCH, PDCH or handover related. Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
2019-11-22pcuif_proto.h: extend RACH.ind with TRX and timeslot number fieldsVadim Yanitskiy1-2/+4
Since there can be multiple PDCH channels configured on different timeslots, different TRXes, and BTSes, the PTCCH/U handling code in OsmoPCU needs to know the exact origin of a given RACH.ind. Otherwise, it is not known which subscriber originated a given PTCCH/U indication, and hence it is impossible to send PTCCH/D Timing Advance notification properly. Fortunately, we can extend the RACH.ind message without even bumping the protocol version, because every single PDU has a fixed size defined by the largest message - INFO.ind. In case if the actual message payload is smaller, the rest is filled with a constant padding byte (0x00). Older versions of OsmoPCU will consider the new fields as padding, while the messages from older OsmoBTS versions will always have both fields set to 0x00. Since C0/TS0 cannot be configured to PDCH, this can be easily detected on the other end. Change-Id: Iff38934a108b6b1cd298669834263a7d5296c3f6 Related: OS#4102, OS#1545
2019-11-20power_control.c: Don't use announced MS Power level as input for loop ↵Pau Espin Pedrol1-1/+0
calculations Use instead the received MS Power currently in use by the MS matching the measured signal. This way there's no need to wait for the MS to reach the announced MS power level or add checks in case the MS doesn't support that specific power level. Furthermore, more fine grained announced power level value can be obtained faster due to more input iterations not being dropped while waiting. osmo-bts-trx specific algo was not following this approach and using announced MS power instead because it's wowrking at a lower level and henche was not using the transmitted MS Power level value by the MS as input for the calculation. The "if (diff < 2 && diff > -2))" condition is dropped since equal signal strength may still result in a different MS power level announced (the one currently used by the MS during tx of last SACCH block). Related: OS#1851 Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
2019-11-14power_control.c: Fix ms pwr ctrl skipped if MS doesn't support announced MS ↵Pau Espin Pedrol1-0/+1
Power Level Related: OS#1851 Change-Id: I1a9c00fe4eb3fa1eaa7997a9ec20716ddfe180a7
2019-10-28cosmetic: l1sap.c: Fix typoPau Espin Pedrol1-1/+1
Change-Id: I9fee7be915546cfd11810c74d511beb8ec10d044
2019-10-17Fix common misspellings and typosMartin Hauke1-5/+5
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-10-11log: set L1 SAPI log contextOliver Smith1-0/+82
Add a new common L1 SAPI enum, to unify all the BTS specific SAPIs. Translate to this enum, and set the context for uplink messages in each BTS specific implementation. Set the context for downlink messages in the common l1sap code, by converting the osmo_phsap_prim back to the SAPI value (mostly looking at chan_nr). The new functions for doing this conversion, get_common_sapi_by_trx_prim() and get_common_sapi_ph_data(), are based on the existing to_gsmtap() and gsmtap_ph_data() functions. Note that we can't set the uplink SAPI context in the common code, because then we can't set it as early as possible. In this patch, the SAPI context is set for the PHYs where the SAPI is readily available. With additional conversion from the RSL channel, the SAPI context could be set for osmo-bts-trx in a follow up patch. Related: OS#2356 Depends: (libosmocore) I814cb3328d99faca9220adb5a80ffb934f219d7d Change-Id: I6b7bb2e1d61502b61214f854a4ec5cbb7267545b
2019-10-09L1SAP: there can be no DATA.ind primitives on PTCCH/U, reject themVadim Yanitskiy1-16/+18
Change-Id: Ib846a9b8e619c7da56b5f0a54d16f629913af80d
2019-10-09L1SAP: use GSMTAP_CHANNEL_PDTCH for PDTCH blocks by defaultVadim Yanitskiy1-2/+4
We don't know whether a data block on PDCH belongs to PDTCH or PACCH without parsing it, because the latter one is being allocated on demand. Let's use GSMTAP_CHANNEL_PDTCH by default, rather than GSMTAP_CHANNEL_PACCH. Change-Id: I7639215ef936a8ac05ca417a91f4e12755f318d4
2019-10-09L1SAP: fix gsmtap_pdch(): there can be no DATA.ind on PTCCH/UVadim Yanitskiy1-7/+0
Change-Id: Id69010ffa8c697e8c01bbb21509253c330f95343
2019-10-09L1SAP: use the actual ARFCN for outgoing PCUIF messagesVadim Yanitskiy1-4/+4
Change-Id: I07b3aac97603d85fb6cf077d3a342b12b0643171
2019-10-09L1SAP: properly handle 11-bit encoded RACH.ind in gsmtap_ph_rach()Vadim Yanitskiy1-1/+1
Change-Id: Id263c2b716fd282d37d705a1c5f430ce7c0edaf0
2019-10-09L1SAP: refactor handling of Access Bursts on PDCHVadim Yanitskiy1-15/+43
First of all, we also need to apply the same filtering to Access Bursts on PDCH as for the normal ones on RACH, i.e. filter them by ToA (Timing of Arrival) and BER (Bit Error Rate). Secondly, we shall not interpret Access Bursts on PDTCH/U as handover related ones. Instead, let's print a warning and ignore them since they are not (yet) supported by OsmoBTS. Finally, in gsmtap_pdch() we need to set a proper channel type for Access Bursts received on PDCH (PDTCH/U or PTCCH/U). Change-Id: I461fde9f4543c45c42b591cd3fd0ff3d98673cec
2019-10-09L1SAP: do not pass unused parameter to l1sap_handover_rach()Vadim Yanitskiy1-3/+2
Change-Id: I7f2d909f1bde09cbec106240df290381b3418e46
2019-10-09L1SAP: clarify debug messages in rach_pass_filter()Vadim Yanitskiy1-3/+3
RACH stands for Random Access CHannel, while in rach_pass_filter() we're dealing with Access Bursts, that may be received on other logical channels too (e.g. PTCCH, PDTCH or any other). Change-Id: I1e5ca9930ab491a6916c972865154d54530cbf51
2019-10-04common/l1sap: increase ToA precision for packet Access BurstsVadim Yanitskiy1-1/+2
QTA is a Timing Advance value in units of 1/4 of a symbol. Let's use ToA256 (1/256 of a symbol) field of L1SAP RACH.ind as a base for QTA calculation in order to achieve better precision. Change-Id: I6e6fa7985c430a9bdbd12af2a8b2a5a66f11a41c
2019-10-04scheduler: fix handling of PTCCH/U and PTCCH/D logical channelsVadim Yanitskiy1-2/+16
According to 3GPP TS 45.010, section 5.6.2, for packet-switched channels the BTS shall monitor the delay of the Access Bursts sent by the MS on PTCCH and respond with timing advance values for all MS performing the procedure on that PDCH. According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing advance control channel) is a packet dedicated channel, that is used for continuous Timing Advance control (mentioned above). There are two sub-types of that logical channel: - PTCCH/U (Uplink): used to transmit random Access Bursts to allow estimation of the Timing Advance for one MS in packet transfer mode. - PTCCH/D (Downlink): used by the network to transmit Timing Advance updates for several MS. As per 3GPP TS 45.003, section 5.2, the coding scheme used for PTCCH/U is the same as for PRACH as specified in subclause 5.3, while the coding scheme used for PTCCH/D is the same as for CS-1 as specified in subclause 5.1.1. The way we used to handle both PTCCH/U and PTCCH/D is absolutely wrong - they have nothing to do with xCCH coding. Instead, we need to use tx_pdtch_fn() for Downlink and rx_rach_fn() for Uplink. In l1sap_ph_rach_ind() we need to check if an Access Burst was received on PTCCH/U and forward it to OsmoPCU with proper SAPI value (PCU_IF_SAPI_PTCCH). To be able to specify a SAPI, a new parameter is introduced to pcu_tx_rach_ind(). Change-Id: I232e5f514fbad2c51daaa59ff516004aba97c8a3 Related: OS#4102
2019-10-02l1sap: Log conn dropped due to radio link counter timeoutPau Espin Pedrol1-1/+5
Change-Id: I78c5ff00be8d2c870ed0277294a8e499ba8a8d95
2019-07-21Move Access Burst link quality handling to L1SAPVadim Yanitskiy1-0/+8
Change-Id: I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78 Depends: (libosmocore) Ie2a66ebd040b61d6daf49e04bf8a84d3d64764ee
2019-07-21Clarify and refactor link quality (C/I) handlingVadim Yanitskiy1-1/+1
The radio link quality is defined by C/I (Carrier-to-Interference ratio), which is computed from the training sequence of each received burst, by comparing the "ideal" training sequence with the actual (received) one. Link quality measurements are used by L1SAP to filter out "ghost" Access Bursts, and by the link quality adaptation algorithms. One can define minimum link quality values using the VTY interface. On the VTY interface we expect integer C/I values in centiBels (cB, 10e-2 B), while the internal structures are using float values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy, oc2g, and litecell15) expose C/I measurements in deciBels, while on the L1SAP interface we finally send then in centiBels. Let's avoid this confusion and stick to a single format, that will be used by the internal logic of OsmoBTS - integer values (int16_t) in centiBels. This will give us the range of: -32768 .. 32767 centiBels, or -3276.8 .. 3276.7 deciBels, which is certainly sufficient. Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
2019-06-13l1sap: Compute statistics on FN advance in PH-RTS.indHarald Welte1-0/+29
Let's keep some statistics about the min/max/average frame number advance that we're observing above L1SAP when comparing the time in the PH-RTS.ind and the frame number we observe in PH-DATA.ind of data that was received on the uplink. The statistics are currently only shown in the VTY, but this is a precursor to using them to correctly advance the LAPDm timers in a follow-up patch. Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2 Related: OS#2294 Related: OS#3906
2019-05-25Add severity to OML FAILURE EVENT REPORTHarald Welte1-1/+1
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-24l1sap: Fix calculation of expired RACH slots in case of missing frame numbersHarald Welte1-2/+5
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots depends on the frame number. So in case of lost/skipped frame numbers, we cannot simply compute the value for the current fn and then multiply it by the number of frame numbers expired. Rather, we have to 'replay' all missed frame numbers and individually determine how many RACH slots happened in that frame. Related: OS#3750 Change-Id: If4f8d2ea55fc722c64c330cde09e833b67ee98fe
2019-05-24l1sap: Correctly count RACH slots in calc_exprd_rach_frames()Harald Welte1-4/+1
We used a bogus multiplication factor of four when computing the number of expired RACH slots. While there are four RACH slots per block (i.e. 4 times more RACH received than normal MAC blocks), that multiplier doesn't apply here: We are calling this function per *frame* and not per *block*. So the maximum number of RACH slots per *frame* is (in most suual cases with a single CCCH) at maximum 1. Only some obscure configurations with multiple CCCHs in a single cell would render higher values. In any case, *blocks* never even enter this equation. This wrong multiplier resulted in rather weird RACH load reports to the BSC. Related: OS#3750 Change-Id: I6b14fd6e7819f9164fb4a09b432a9f419e3b6e5c
2019-05-24Use LOGPLCHAN whenever possibleHarald Welte1-31/+25
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-04-21common/l1sap.c: fix: add missing new line to a debug messageVadim Yanitskiy1-1/+1
Change-Id: I7c0dab255289a5847d1a0af009e8962e4410e5ca
2019-03-27oml: use oml_tx_failure_event_rep() instead of oml_fail_rep()Philipp Maier1-2/+4
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets use only oml_tx_failure_event_rep() and remove oml_fail_rep() Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6 Related: OS#3843
2019-03-18Constify pcu_rx_*() parametersMax1-1/+1
Use const for data parameter where appropriate. Change-Id: Ia228c001ca07cfde61b540bec6257b62aec93517
2018-11-22Fix type mismatchMax1-1/+1
llist_count() return unsigned value, let's use it for counter as well. Change-Id: I81097a64ef694bec046afcc23cf995dc539a706b
2018-10-10l1sap: Log name of chan_nr instead of hex valuePau Espin Pedrol1-25/+27
Change-Id: If98e130d17f1d153a13ba28f48a0a563731fde41
2018-09-30Fix computing CCCH block number from frame numberHarald Welte1-2/+37
The existing implementation used a simplistic macro, which was wrong in many ways: 1) it returned a negative value for "fn % 51 < 5" conditions without raising any error message or asserting 2) it returned a wrong block number for many different input frame numbers, as it didn't account properly for the FCCH/SCH gaps between the blocks Let's replace the simplistic macro with a proper lookup table based on TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH frame numbers. Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5 Closes: OS#3024
2018-09-17get_lchan_by_chan_nr(): Fix resolution of CBCHHarald Welte1-1/+12
The CBCH (as per GSM specs) always maps on sub-slot 2 of either the SDCCH/4 or SDCCH/8 that it replaces. However, the way how we express it as RSL-style channel number (0xC8) doesn't allow room for any sub-slots. The top 5 bits are used for expressing CBCH, while the bottom 3 bits are used for the timeslot number (TN). So when transforming from channel number to lchan, we must handle the CBCH case specially by using a hard-coded sub-slot number of 2. Change-Id: I44e2f763d5d25311167f435f2ca7e030b2a3f009 Related: OS#1617
2018-09-17l1sap/scheduler: Consistently print chan_nr as hex numberHarald Welte1-5/+5
It's very confusing if some log messages log chan_nr as decimal, while most log it as hexadecimal. Let's standardize on hex everywhere. Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
2018-09-09CBCH: Move processing via L1SAPHarald Welte1-0/+6
for some historical reason, CBCH handling was not using the normal L1SAP boundary. Let's change that and traverse L1SAP just like for e.g. BCCH which is quite similar to CBCH handling. This also has the added benefit of logging CBCH via GSMTAP. Change-Id: Ibdba4c5e808330f8406f441a97fe0e81170fce97 Closes: OS#3534
2018-08-31paging: add unit-test to check different bs_ag_blks_res settingsPhilipp Maier1-3/+12
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3 setting, defines how many of the CCCH blocks shall be used for AGCH. The remaining CCCH blocks will then be available as PCH for paging. Unfortunately there is no unit-test yet that verifies that all of the 8 different settings for bs_ag_blks_res. - Separate the the decision logic that checks if a given fn is part of an AGCH into a function to have it available in the unit-test. - Add a test that checks all possible bs_ag_blks_res settings. Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989 Related: OS#1575
2018-08-23Revert "send TCH/F fill frames in DTX mode (WIP)"Stefan Sperling1-64/+13
This reverts commit 9bffa87c1195d2977d49244fbc3e3c0c9b65c318. This commit was not intended to be merged yet. Change-Id: Ibd8c0899451ae3c17bc07d4e112e32b4897405c9
2018-08-22send TCH/F fill frames in DTX mode (WIP)Stefan Sperling1-13/+64
Send DTX TCH fill frames according to GSM 05.08, section 8.3. Change-Id: I7bff00b8cf41dc1b0e6e668173bebce23be0d253 Related: OS#1950
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 13:49:42 +0000