aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-07-16osmo-bts-trx/scheduler: pass trx_ul_burst_ind to lchan handlersVadim Yanitskiy4-152/+191
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-16osmo-bts-trx/trx_if.c: encode actual TRXD header versionVadim Yanitskiy1-2/+17
Both TRX2L1 (Uplink) and L12TRX (Downlink) messages should use the same TRXD header format (and version) as was negotiated. Change-Id: Idbc598ef7c1871ee8da830f3fbe0a5cc386f873d Related: OS#4006
2019-07-16osmo-bts-trx/trx_if.c: add TRXD header version negotiationVadim Yanitskiy4-5/+91
This change introduces a new command for TRXD header format negotiation - SETFORMAT. If the transceiver does not support the format negotiation, it would reject this command with 'RSP ERR 1'. If the requested version is not supported by the transceiver, status code of the response message should indicate a preferred (basically, the latest) version. The format of SETFORMAT command is the following: L1 -> TRX: CMD SETFORMAT VER_REQ L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ where: - VER_REQ is the requested version (suggested by the L1), - VER_RSP is either the applied version if matches VER_REQ, or a preferred version if VER_REQ is not supported. If the transceiver indicates VER_RSP different than VER_REQ, OsmoBTS is supposed to reinitiate the version negotiation using the suggested VER_RSP. For example: L1 -> TRX: CMD SETFORMAT 2 L1 <- TRX: RSP SETFORMAT 1 2 L1 -> TRX: CMD SETFORMAT 1 L1 <- TRX: RSP SETFORMAT 1 1 If no suitable VER_RSP is found, or the VER_REQ is incorrect, the status code in the response would be -1. As soon as VER_RSP matches VER_REQ in the response, the process of negotiation is complete. Changing the header version is supposed to be done before POWERON. Change-Id: I8afe950bd1ec2afaf3347ff848ee46e69c4f5011 Related: OS#4006
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-07-10contrib/jenkins.sh: run "make maintainer-clean"Oliver Smith1-0/+2
Related: OS#3047 Change-Id: I9d9b2412f005e4bda0ed35ba715cfb4dca1b04c1
2019-07-04osmo-bts-trx/trx_if.c: properly describe TRXD messages in logsVadim Yanitskiy1-4/+45
Since we may have different versions of the TRXD header, some new fields of an Uplink burst indication have conditional presence. Therefore we need a smart function to print them conditionally. Change-Id: I68729dc98a1840d2aa9e091153d176a103d5a228 Related: OS#4006
2019-07-04osmo-bts-trx/trx_if.c: drop RSSI / ToA debugging codeVadim Yanitskiy1-13/+0
This kind of debugging can be done using trx_sniff.py tool from the TRX Toolkit [1]. Probably, this code was needed during the initial development and testing. [1] https://git.osmocom.org/osmocom-bb/tree/src/target/trx_toolkit Change-Id: I50e0e5feeba4c3028f55209dd8e41e09ed5f70b1
2019-07-04osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 supportVadim Yanitskiy2-1/+183
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 Yanitskiy3-57/+199
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-27osmo-bts-trx/trx_if.c: rename and clarify TRX_MAX_BURST_LENVadim Yanitskiy1-4/+5
This constant actually defines the maximum TRXD message length, which includes the header and burst bits, not just burst. Change-Id: I383125e1c4df039fc6b554833bc8736deacbe731
2019-06-27osmo-bts-trx/trx_if.c: use osmo_loadXXbe() for TDMA FN and ToA256Vadim Yanitskiy1-2/+2
Change-Id: Iec0d86f9be7243578ddc1ab322fc313cb5ac5d0b
2019-06-25bts: Bypass T200 DCCH values for CCCHPau Espin Pedrol1-8/+11
Otherwise t200_ms_dcch array values are left uninitialized with random values, and passed later on to lapdm_channel_init2(). lapdm_channel_init2() will anyways fail during initial check on get_n200_dcch() and return -EINVAL, so let's not print garbage or call a function which will anyways simply return an error. Catched due to some strange values seen in log (see D0 and D3): osmo-bts/src/common/bts.c:421 (bts=0,trx=0,ts=0,ss=4) Setting T200 D0=1028672, D3=2, S0=520, S3=520 (all in ms) Related: OS#4066 Change-Id: I3d7e1883811acf97aac97325739f2ff97fc2aa08
2019-06-21revert changes to T200Eric Wild1-7/+17
The timers are unfortunately completely broken, so let's go back to the long default timeout values from 1ff0a2addd04de5bfe1601e84b013c65e500faf0 See related issues OS#4066 and OS#4074 Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
2019-06-19manuals: Add script to regenerate counter/vty documentationDaniel Willmann2-0/+18
This will generate the VTY/counter documentation for osmo-bts-virtual so it will be missing documentation for device-specific commands/counters. Change-Id: Idebb099b69924d6212db119f7a2f2861d4150d7e Related: OS#1700
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 Welte3-59/+40
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-13Update T200 timer default valuesHarald Welte1-9/+9
The default values of 1s were *very* long, particularly for fast channels such as FACCH. Let's use much more aggressive values that are more in-line with various recommendations that cold be found online, such as https://pcstelconext.wordpress.com/2011/05/02/2g-timer-explanations/ https://www.erlang.com/forum/erlang/thread.htx?thread=2844 https://www.erlang.com/forum/erlang/thread.htx?thread=7180 https://de.slideshare.net/BisiAdebambo/138078380-gsmtimers-59637131 Change-Id: Ic1268ae2d769b12da6cdd4ac8375e4bc033a9e3e
2019-06-13[correctly] use the LAPDm T200 values received via OMLHarald Welte1-16/+13
As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances in the BTS are configured via OML from the BSC. While OsmoBSC is sending them and OsmoBTS is parsing them, OsmoBTS stopped to make use of them from commit 3ca59512d2f4eb1f87699e8fada67f33674918b4 (January 2016) onwards. The cause for this has been documented and discovered in May 2017 in https://osmocom.org/issues/2294 and it is quite obvious: LAPDm timers are supposed to start when a given frame is actually transmitted on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be used over a synchronous interface in some deeply embedded processor. With OsmoBTS however, we have an asynchronous L1/L2 interface between a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx) and we receive PH-RTS.ind quite some time ahead. So if we start T200 at that point, then it will start running way before it has been sent or before the MS has had a chance to receive the message. The "correct" way to handle this is to actually measure the difference between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind (downlink) or PH-TIME.ind, and then add that amount to the actual timeout value. This ensures that the timers will time-out the user-specified amount of time after the actual transmit. Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4 Closes: OS#2294 Closes: OS#3906
2019-06-13l1sap: Compute statistics on FN advance in PH-RTS.indHarald Welte5-0/+46
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 Yanitskiy3-108/+467
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-05Use #define RSL_CHAN_RACH for RSL Channel Number of RACHVadim Yanitskiy5-5/+5
Change-Id: I7f54fccdae6799e5f4d956a101e11c2d6f998546
2019-06-04bts-trx: trx_if.c: Introduce logging macro LOGPPHIPau Espin Pedrol3-44/+38
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-03common/bts.c: bts_supports_cm(): take care about GSM48_CMODE_SIGNVadim Yanitskiy1-0/+5
At the moment, bts_supports_cm() is only called on reception of RSL Channel MODE MODIFY from the BSC. The idea is to check whether the indicated RSL channel mode is supported by a BTS model. RSL Channel MODE MODIFY message may indicate a channel in signalling mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far. Let's assume that signalling is always supported, as there is no special BTS_FEAT_* definition to check that. This change should make BTS_Tests.TC_rsl_modify_encr pass. Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
2019-06-03trx: Update documentation for fn-advance and rts-advanceHarald Welte1-2/+45
Change-Id: I83eff296bfb7acff9d8560b5346bd9791fe6e7d9 Related: OS#4036
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-06-01osmo-bts/scheduler.h: cosmetic: use bool for ho_rach_detectVadim Yanitskiy1-1/+1
Change-Id: Id357e4ed38cbdca2082322da12b93d556056e916
2019-06-01osmo-bts-trx/l1_if.h: drop unused ho_rach_detect from trx_l1hVadim Yanitskiy1-1/+0
Change-Id: I90b6d7fb1bb7ba2f8b1f500043635b0ae5cb4495
2019-06-01osmo-bts-trx/trx_if.c: dropping Tx bursts is a noticeable eventVadim Yanitskiy1-2/+1
Change-Id: Ia954b797a9bb90660b6548ec0ffb218a1dcff37a
2019-05-31debian: create -doc subpackage with pdf manualsOliver Smith4-2/+18
I have verified, that the resulting debian packages build in my own OBS namespace (see the -doc packages): https://download.opensuse.org/repositories/home:/osmith42/Debian_9.0/all/ https://build.opensuse.org/project/show/home:osmith42 Depends: Ib7251cca9116151e473798879375cd5eb48ff3ad (osmo-ci) Related: OS#3899 Change-Id: I6d7a182d0a668693a5014aca0edc50ada9ac0d0f
2019-05-29osmo-bts-lc15: Change LED behaviour to be the same as oc2gDaniel Willmann2-14/+31
It looks like the status LED on the sysmobts2100 never worked correctly since lc15bts-mgr expects osmo-bts-lc15 to create and manage /var/run/osmo-bts/state, but there is nothing to do so in osmo-bts. This patch copies the functions from oc2g to manage the state file in lc15. Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed Related: SYS#4493
2019-05-29osmo-bts-oc2g: Fix status LED responsibilitiesDaniel Willmann2-14/+3
osmo-bts-oc2g no longer modifies the status LED and instead leaves that to the bts manager. The service file now also creates a directory in /var/run needed for osmo-bts to communicate with oc2gbts-mgr. This status file is used by oc2gbts-mgr to figure out when the bts is operational. Related: SYS#4493 Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
2019-05-28clear GPRS indicator in SI3 while PCU is disconnectedHarald Welte5-9/+63
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-28lc15,sysmo,oc2g: fix dsp-trace-flag commandNeels Hofmeyr3-3/+3
Remove the '~' from '|= flag', it is plain wrong. This affects the correct parsing of DSP trace flags from the config file only. The bug is not present in the interactive VTY command at runtime. Change-Id: I915971f49642967c969f5dd475e8faa960ef3960
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 Welte9-49/+50
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-24oml: Have one generic log message for all transmitted messagesHarald Welte1-6/+2
Rather than open-coding "Tx foobar..." in various functions (and forgetting it in half of them), let's add a generic message into oml_mo_send_msg(). Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
2019-05-24oml: Print more context from FOM Header or using MOHarald Welte1-28/+31
Some of our OML log lines were missing any context. Try making more sense by printing any context information about the given managed object, TRX, ... as we have it. Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
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-24load_indication: Fix missing re-set of RACH parametersHarald Welte1-0/+1
While we re-set the PCH load counters after every report, we never actually re-set the RACH load counters. This meant that the period/window for RACH load averaging would always grow, rather than being reset every load indication period. Related: OS#3750 Change-Id: Icd9150ba56d77d031c3cf496c5936c2de52b364c
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 Welte2-1/+45
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-24rsl.adoc: DELETE INDICATION is implemented since Feb '18Harald Welte1-1/+1
In the following commit, we introduced transmitting the RSL DELETE INDICATION on AGCH overflow: commit 19da7fdea8912831b19d9aeed51cd2226f342283 Author: Harald Welte <laforge@gnumonks.org> Date: Sat Feb 24 04:32:29 2018 +0100 So let's sync the manual with the code. Change-Id: I988778bdb83271355dc11b1a30a59e1a5dba5fb2 Related: OS#2990
2019-05-24Use LOGPLCHAN whenever possibleHarald Welte6-210/+150
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: Improve verbosity and extend logging; Always indicate BASIC/EXTD CBCHHarald Welte1-19/+35
Change-Id: I6c8f9fc6215b616371e46c1f4ca4e44b8c7ac096
2019-05-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte7-2/+137
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-22sysmo: Fix "nominal power" / BS power display in VTYHarald Welte1-1/+1
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm, "milli-dBm", while trx->nominal_power is only whole dBm. We were missing the required divider of 1000 ever since Change-Id Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017. The good news is that this really only affected the VTY output and not any actual operational aspect of the system. Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68 Closes: SYS#4570
2019-05-21README.md: Mention LimeSDR as SDR deviceHarald Welte1-1/+1
Change-Id: I0ab5b5721861d7e29c66e849d9e0f4eec2e047e6
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-20 18:47:49 +0000