aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2020-07-26fix compilation with gcc-10Harald Welte2-6/+6
/usr/bin/ld: /home/laforge/projects/git/osmo-bts/tests/sysmobts/../../src/osmo-bts-sysmo/tch.c:584: undefined reference to `femtobts_tch_pl_names' /usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: multiple definition of `pdch_msu_size'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: first defined here /usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: multiple definition of `femtobts_l1prim_type'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: first defined here see also: https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000651.html Change-Id: I4a9896153876fcda496365776883827746205f00
2020-01-03rsl: ensure measurement reports are sentPhilipp Maier1-0/+2
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-11-30bts-trx: Drop low layer MS Power Control Loop algoPau Espin Pedrol2-7/+0
Let's drop it instead of having code duplication from common code in a lower layer, and maintain only the one in l1sap for all BTS models. As a result, osmo-bts-trx loses feature BTS_FEAT_MS_PWR_CTRL_DSP and will only be able to use "ms-power-control osmo" in VTY, which will be enabled by default (meaning: change of behavior, now MS Power Control is enabled by default in osmo-bts-trx and can only by disabled by BSC). Old bts-trx specific VTY command "(no) osmotrx ms-power-loop" is marked as deprecated but still working for more usual case (1 TRX configured) to avoid breaking backward compatibility. TA low level loop is still kept in loops.c and will be moved to l1sap at some point too. Related: OS#1851 Change-Id: I0d8b0c981d9ead91d93999df6e45fb06e426aeb9
2019-11-22pcuif_proto.h: extend RACH.ind with TRX and timeslot number fieldsVadim Yanitskiy2-2/+5
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-19osmo-bts-trx: general handling of NOPE / IDLE indicationsVadim Yanitskiy1-0/+2
Each logical channel can now optionally have an additional handler, that will be called when a NOPE / IDLE indication is received from the transceiver. The aim of that handler is to keep the logical channel state updated in case if one or more Uplink bursts are lost. Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637 Related: OS#3428
2019-11-14Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSPPau Espin Pedrol1-0/+1
It indicates whether BTS model supports managing an MS Power Control Loop over HW/DSP instead of using the software based osmocom algorithm present in osmo-bts. osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one since it acts on lower layers and interferes with osmocom algorithm since it controls the same end variable "lchan->ms_power_ctrl.current", this way we make sure both aren't enabled at the same time. Old behavior in kept: if common upper-layer algo is not enabled explicitly in VTY (ms-power-control osmo) and bts-trx specific lower layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no power control is done at all. Related: OS#1851 Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
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-11-14Move and rename gsm_lchan.ms_power fieldPau Espin Pedrol1-3/+3
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-14Change gsm_lchan field fixed to boolPau Espin Pedrol1-1/+1
Change-Id: I715ef151b67a21e325c574585a257e71b4b0ce2a
2019-11-14Change gsm_bts_trx field to bool and rename itPau Espin Pedrol2-2/+2
Thies field is used to store and retrieve whether MS power needs to be calculated and updated by osmo-bts software or autonomously by lower layers. Previous name was not clear and may have been understood as indicating whether MS Power Control loop is done or not in general, and the responsible for that is located under lchan's ms_power_ctrl.fixed. Related: OS#1851 Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
2019-10-17Fix common misspellings and typosMartin Hauke1-4/+4
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-10-16bts-trx: Time out if no clock ind recvd after RSP POWERONPau Espin Pedrol1-0/+6
Before this patch, if due to whatever reason the TRX started fine (RSP POWERON 0) and sockets were created but no CLOCK IND was ever received by the BTS, it wouldn't notice since the timerfd timeouts (bts_shutdown("no clock")) are only checked after the first CLOCK IND is sent by the TRX. As a result, the BTS would be kept on forever saying everything is fine but it would be sending no DL burst at all to the TRX (tested with a modfied osmo-trx dropping clock indication). With this patch, new APIs are added to indicate the scheduler_trx code the timeframes where clock ind are expected (between RSP POWERON 0 and RSP POWEROFF 0); if TRX sends clock indications out of that timeframe, BTs lower layers will drop them (controlled by "powered" bool). Hence, the scheduler_trx can now place a timeout (reusing same timerfd because its new use is exclusive in time with its other previous use) when it is told that CLOCK IND should start appearing, and if none arrives in considerable time, then the BTS can be shut down to notify the rest of the network. Related: OS#4215 Change-Id: Iba5dbe867aff10e70ec73dbf1f7aeeecb15c0a4d
2019-10-11log: set L1 SAPI log contextOliver Smith1-0/+31
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: also consider RSL_CHAN_OSMO_CBCH8 as CBCHVadim Yanitskiy1-1/+2
Currently we don't distinguish between CBCH on BCCH+SDCCH/4 and CBCH on SDCCH/8, but in libosmogsm we have two independent (non-standard) RSL channel number values for them. Maybe some day we will, so let's extend the definition of L1SAP_IS_CHAN_CBCH. Change-Id: I2f6d501a29edaf89dfb17d5d64f930cdb1943630
2019-10-09L1SAP: use RSL_CHAN_* definitions from libosmogsmVadim Yanitskiy1-10/+21
Change-Id: I2708b5d5bb6b92f90766ac752bafd28cff2549b0
2019-10-05bts-trx: Rework code handling poweron statePau Espin Pedrol1-0/+2
Use of variables in each code is confusing and mixing configuration with POWERON/POWEROFF state (which is at least per phy inst and not per TRX, since those commands are only expected on the 1st phy inst). * field "poweron" becomes "enabled", and is used as an indicator for actions to take during TRX provisioning (hether to power it on and configure it or to power it off). * poweron/poweroff state becomes "powered", and it is shared by all trx in same phy_link, and is updated only after confirmation by TRX. * poweron_set becomes poweronoff_set (because it's used by both POWERON and POWEROFF), and becomes shared by all trx in same phy_link, since those CMDs are usually sent by first phy instance of the link (the first trx). Related: OS#4215 Change-Id: Icd0b482f1454236432e1952220bbec9d178b8607
2019-10-05bts-trx: vty: Print phy link state in cmd 'show transceiver'Pau Espin Pedrol1-0/+2
Change-Id: I8e49f8edad9f9c68d110dbb7faeea5143aa91022
2019-10-05struct gsm_bts: Add model_priv pointer handing bts_model specific dataPau Espin Pedrol1-13/+1
Currently there's bts-virtual specific fields in gsm_bts which is not used by other models and are always allocated. An alternative would be having a union with different structs inside, one per model, but since we already have the bts_model abstraction, in this case it makes more sense to use that abstraction instead of filling code with preprocessor ifdefs to guard against non-defined types, etc. Existing model specific data is moved there. This new infra will be user further in forthcoming commits. Related: OS#4215 Change-Id: Ib17a752cdbaa7d5eb8c5dfa0b197f80a4f38b38e
2019-10-04scheduler: fix handling of PTCCH/U and PTCCH/D logical channelsVadim Yanitskiy1-1/+1
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-09-27bts.h: Remove non-existent function definitionsPau Espin Pedrol1-8/+0
Change-Id: I4d06e1cdea5970cbb493f29980b1c04e01c0e8a4
2019-09-10osmo-bts-trx: migrate to new generic ECU abstractionHarald Welte1-3/+3
libosmocodec has recently introduced a generic ECU abstraction layer which supports (pluggable) Error Concealment Units for not only the FR codec, but potentially any other codec, too. Change-Id: I001005aae6de76d4e045b8dc572239f057bb150d Depends: libosmocore I4d33c9c7c2d4c7462ff38a49c178b65accae1915
2019-09-06pcu_interface: Forward ETWS Primary Notification to PCUHarald Welte2-0/+10
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/+10
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-08-05Remove undefined param passed to {logging,osmo_stats}_vty_add_cmdsPau Espin Pedrol1-1/+1
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. API osmo_stats_vty_add_cmds never had a param list but has seem problem (no "void"), so some users decided to pass a parameter to it. Change-Id: Ia4d1a7914308d1481fe31fe0986265ead339e61e Related: OS#4138
2019-07-23bts-trx: Introduce VTY command osmotrx trxd-max-versionPau Espin Pedrol1-0/+1
This command allows setting a maximum TRXD format version to negotiate with TRX. osmo-bts-trx will hence end up using that version if supported by TRX, or a lower one otherwise (or fail if TRX doesn't support any of them). Since now the maximum version can be 0, avoid going through SETFORMAT negotiation in that case, since 0 is the default version. This way we keep backward compatibility with TRX implementations that exit upon receival of unknown commands (such as SC5 current one). The VTY command is located in the "phy" node instead of the "phy instance" node because instances of same phy are expected to use same host with same implementation, so TRXD version to use should be the same for both. Related: OS#4006 Change-Id: I5eb1fdc002f9d7f4acf475356d8fc998dc8f6326
2019-07-21Clarify and refactor link quality (C/I) handlingVadim Yanitskiy1-2/+2
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-07-16osmo-bts/scheduler: provide actual C/I values to OsmoPCUVadim Yanitskiy1-1/+3
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels), computed from the training sequence of each received burst, by comparing the "ideal" training sequence with the actual one. So far, there was no way to expose more measurements from OsmoTRX, excluding both RSSI and ToA. Since the new version of TRXD header, we can receive C/I indications and send the averaged (per 4 bursts) values to OsmoPCU (as a part of PCUIF_DATA.ind). Please note that we also need to attach C/I measurements to the following L1SAP primitives: - PRIM_PH_RACH.ind, - PRIM_PH_DATA.ind, - PRIM_TCH.ind, but this will be done in the follow up changes. Change-Id: Ia58043bd2381a4d34d604522e02899ae64ee0d26 Fixes: OS#1855
2019-07-16osmo-bts-trx/scheduler: pass trx_ul_burst_ind to lchan handlersVadim Yanitskiy1-19/+12
This change needs to be done in order avoid adding more and more arguments to the UL logical channel handlers (such as rx_rach_fn). Since we have different versions of the TRXD header, and may have other burst-based PHYs in the future, some fields of an Uplink burst indication have conditional presence. Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0 Related: OS#4006, OS#1855
2019-07-04osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 supportVadim Yanitskiy1-0/+14
The new version adds the following fields to the TRX2L1 message, keeping the L12TRX message unchanged: +------+-----+-----+-----+--------------------+ | RSSI | ToA | MTS | C/I | soft-bits (254..0) | +------+-----+-----+-----+--------------------+ - MTS (1 octet) - Modulation and Training Sequence info, and - C/I (2 octets) - Carrier-to-Interference ratio (big endian). == Coding of MTS: Modulation and Training Sequence info 3GPP TS 45.002 version 15.1.0 defines several modulation types, and a few sets of training sequences for each type. The most common are GMSK and 8-PSK (which is used in EDGE). +-----------------+---------------------------------------+ | 7 6 5 4 3 2 1 0 | bit numbers (value range) | +-----------------+---------------------------------------+ | . . . . . X X X | Training Sequence Code (0..7) | +-----------------+---------------------------------------+ | . X X X X . . . | Modulation, TS set number (see below) | +-----------------+---------------------------------------+ | X . . . . . . . | IDLE / nope frame indication (0 or 1) | +-----------------+---------------------------------------+ The bit number 7 (MSB) is set to high when either nothing has been detected, or during IDLE frames, so we can deliver noise levels, and avoid clock gaps on the L1 side. Other bits are ignored, and should be set to low (0) in this case. == Coding of modulation and TS set number GMSK has 4 sets of training sequences (see tables 5.2.3a-d), while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets. Access and Synchronization bursts also have several synch. sequences. +-----------------+---------------------------------------+ | 7 6 5 4 3 2 1 0 | bit numbers (value range) | +-----------------+---------------------------------------+ | . 0 0 X X . . . | GMSK, 4 TS sets (0..3) | +-----------------+---------------------------------------+ | . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) | +-----------------+---------------------------------------+ | . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) | +-----------------+---------------------------------------+ | . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) | +-----------------+---------------------------------------+ | . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) | +-----------------+---------------------------------------+ | . 1 1 1 X . . . | RESERVED (0) | +-----------------+---------------------------------------+ == C/I: Carrier-to-Interference ratio The C/I value is computed from the training sequence of each burst, where we can compare the "ideal" training sequence with the actual training sequence, and then express that difference in centiBels. == Limitations - The only supported modulation types are GMSK and 8-PSK. Messages with other modulation types will be rejected. - IDLE / NOPE indications are not (yet) handled. - The logical channel handlers do not (yet) handle optional fields, such as TSC and C/I. This will be implemented in the follow-up changes. Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd Related: OS#4006
2019-06-27osmo-bts-trx/trx_if.c: introduce TRXD header version handlingVadim Yanitskiy1-4/+16
It may be necessary to extend the message specific header with more information. Since this is not a TLV-based protocol, we need to include the header format version. +-----------------+---------------------------+ | 7 6 5 4 3 2 1 0 | bit numbers (value range) | +-----------------+---------------------------+ | X X X X . . . . | header version (0..15) | +-----------------+---------------------------+ | . . . . . X X X | TDMA TN (0..7) | +-----------------+---------------------------+ | . . . . X . . . | RESERVED (0) | +-----------------+---------------------------+ Instead of prepending an additional byte, it was decided to use 4 MSB bits of the first octet, which used to be zero-initialized due to the value range of TDMA TN (0..7). Therefore the current header format has implicit version 0. Otherwise Wireshark (or trx_sniff.py) would have to guess the header version, or alternatively follow the control channel looking for the version setting command. This change introduces a new structure 'trx_ul_burst_ind', which represents an Uplink burst and the corresponding meta info. The purpose of this structure is to avoid overloading the existing functions, such as trx_sched_ul_burst(), with more and more arguments every time we bump the version. On receipt of a TRXD message, trx_data_read_cb() now parses the header version, and calls the corresponding dissector functions, e.g. trx_data_handle_(hdr|burst)_v0(). Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c Related: OS#4006
2019-06-13gsm_data_shared.h: Remove unused loc_list from struct gsm_btsPau Espin Pedrol1-3/+0
Change-Id: I52880962dfb0399c613048aa7ddfd828d3c6c933
2019-06-13lapdm: Use new libosmocore API to ensure per-channel-type N200 valuesHarald Welte1-2/+0
By using new libosmocore LAPDm API we can specify the GSM channel type and hence enable the LAPDm code to use a per-channel-type specific N200 value. At the same time, this new API also allows us to specify T200 values when initializing the LAPDm channel, so we don't have to fiddle with low-level lapdm data structures in what used to be oml_set_lchan_t200(). Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48 Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c Closes: OS#4037
2019-06-13l1sap: Compute statistics on FN advance in PH-RTS.indHarald Welte2-0/+10
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-06-08common/scheduler.c: refactor description of TRXC_* lchansVadim Yanitskiy2-10/+15
Let's avoid fancy alignment in the description of logical channels for the benefits of having better readability, the ability to add more comments and fields without making it look ugly. Get rid of value-string array 'trx_chan_type_names', since each logical channel has its name defined in 'trx_chan_desc'. Get rid of field 'chan' of 'trx_lchan_desc' structure since it's not used anywhere, and not actually needed because the position of each lchan description is defined by its TRXC_* type. Replace both 'pdch' and 'auto_active' fields with more generic bitmask field called 'flags', and define the following flags: - TRX_CHAN_FLAG_AUTO_ACTIVE, - TRX_CHAN_FLAG_PDCH. Use RSL channel mode #defines from libosmogsm instead of having hard-coded numbers. This increases readability. As a bonus, let's add a human readable description to each lchan definition, so it can be printed in the VTY some day. Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315 Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843 I7ab4958801b3422973b67ff0452b90afa8a3f501
2019-06-04bts-trx: trx_if.c: Introduce logging macro LOGPPHIPau Espin Pedrol1-0/+2
This way we unify format. We take the chance to add related information to some log messages which were not printing that information (and was confusing when using more than one phy instance). Change-Id: I5b17a01638ade9a6c41da73e550d5947fa92f568
2019-06-01osmo-bts/scheduler.h: cosmetic: use bool for ho_rach_detectVadim Yanitskiy1-1/+1
Change-Id: Id357e4ed38cbdca2082322da12b93d556056e916
2019-05-28clear GPRS indicator in SI3 while PCU is disconnectedHarald Welte2-0/+6
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-25Add severity to OML FAILURE EVENT REPORTHarald Welte1-2/+2
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-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte3-0/+14
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: Keep SMSCB queue length counterHarald Welte1-0/+1
This avoids having to iterate the list to count the number of elements. Change-Id: I72c47affeb87c9b898bc2290dc7ed113945f1805
2019-05-21cbch: Support Extended CBCHHarald Welte2-8/+11
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: Implement support for DEFAULT messageHarald Welte1-0/+1
The BSC can not only send us each to-be-sent message separately, but it can also configure a DEFAULT message, which is then to be sent instead of the NULL message. Let's add support for this Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba Closes: OS#4013
2019-04-19common/oml.c: constify argument 'trx' of handle_attrs_trx()Vadim Yanitskiy1-1/+1
Change-Id: Id476d492b3c1d0c728fca9eb0fb2254512bdef72
2019-03-27Forward GPRS SUSPEND REQ from DCCH to PCU socketHarald Welte2-0/+10
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15, a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if it wants to suspend GPRS services. The BSS is now responsible to somehow forward this to the SGSN. As the Gs interface between BSC and SGSN is both optional and doesn't have any provision to forward this message, we have to send it over to the PCU so it can use regular BSSGP signaling to inform the SGSN of the SUSPEND REQUEST. This patch requires libosmocore Change-Id I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of struct gsm48_gprs_susp_req. Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f Closes: OS#2249
2019-03-27oml: use oml_tx_failure_event_rep() instead of signals to SS_FAILPhilipp Maier1-1/+0
At some locations in the code a signal to SS_FAIL is dispatched in order to trigger the sending of an OML failure event report in oml.c. This is a bit overcomplicated for the task. Lets use oml_tx_failure_event_rep() to send the failure event reports and lets remove the signal handler for SS_FAIL. Change-Id: Ie4fce1273a19cc14f37ff6fc7582b2945c7e7c47 Related: OS#3843
2019-03-27oml: use oml_tx_failure_event_rep() instead of oml_fail_rep()Philipp Maier1-2/+0
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-27vty: add function gsmnet_from_vty() to vty.hPhilipp Maier1-0/+2
The function gsmnet_from_vty() is used in oc2gbts_vty.c, but it is not declared in vty.h. Lets add the declaration to vty.h, so that gsmnet_from_vty() can be used properly by other modules. Change-Id: I8cf63c6fabdb1f2dc67ca8193704ce4d1d4882d9
2019-03-18Constify pcu_rx_*() parametersMax1-1/+1
Use const for data parameter where appropriate. Change-Id: Ia228c001ca07cfde61b540bec6257b62aec93517
2019-03-18Make gsm_pchan2chan_nr() staticMax1-2/+0
It's only used inside of gsm_data_shared.c so let's mark it as such. Change-Id: I83f1783efe9dc07c8bf9901ebc94774aef1cd472