AgeCommit message (Collapse)AuthorFilesLines
2019-08-27pcu_sock: fix endian-swapped CellIDosmith/pcu-testsOliver Smith1-1/+1
Restore the correct endianness of the cell identity stored in the system information type 3 struct, just like we do it with the location area code. Related: OS#3854 Change-Id: I68faf4558f0686fb2a3db24077dceaae05bf0262
2019-08-23virtual: set link quality for GSMTAP_CHANNEL_RACHOliver Smith1-0/+1
Don't ignore all incoming RACH requests anymore: 000881/00/23/14/09 Ignoring RACH request: link quality (0) below the minimum (50) Related: OS#3925 Fixes: b777c0f3ecb8b770f032db449e947f0f9731de11 ("Move Access Burst link quality handling to L1SAP") Change-Id: Ifcd576fed84346688e711a26a05c6d350588e83d
2019-08-23Cosmetic: virtual: l1sap.c: fix typosOliver Smith1-1/+1
Change-Id: Id24e75812bda17e99f17a37b367462533a5607f9
2019-08-07Bump version: 1.0.1 → Espin Pedrol1-0/+187
Change-Id: I708f6a63b51459d77368c48e115f64aaa6646bfd
2019-08-07configure.ac: Require libosmocore 1.2.0Pau Espin Pedrol1-6/+6
Some commits started using libosmocore APIs osmo_gsm48_rest_octets_si3_encode() and lapdm_channel_init2(), which are only available in latest libosmocore release 1.2.0. Let's update configure.ac accordingly. Fixes: 1e96e31c106aed9192ed9ea78ff1a711464390d7 Fixes: 46d62b984a10b3966d8a0d0a435d4efab0e9c500 Change-Id: If84c53d8192e8db98eb9439b898d83e94c5e5476
2019-08-05Remove undefined param passed to {logging,osmo_stats}_vty_add_cmdsPau Espin Pedrol6-7/+7
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-08-02scheduler_trx: Handle negative return of gsm0503_tch_hr_decode()Harald Welte1-1/+1
If gsm0503_tch_hr_decode() returns a negative error, we shouldn't set the marker bit or pass the negative value as length value into osmo_hr_check_sid(). Change-Id: If49ca6926c576a2b17507b6a95b6f3ca17877d66 Closes: CID#187645
2019-07-31osmo-bts-trx: Don't attemtp to adjust MS power if fixedHarald Welte1-0/+3
If the BSC has instructed the BTS via RSL to not autonomously perform MS power control, we are storing this in lchan->ms_power_ctrl.fixed. However, osmo-bts-trx would simply ignore that flag in loops.c and continue to compute new MS power values based on measurement results. Change-Id: I628d1f4f1094c22248d372c11c2ecc504135b757
2019-07-31osmo-bts-trx: Don't increment rssi_valid_count twiceHarald Welte1-1/+0
In the ms_power_val() function, don't increment the number of valid RSSI values counter twice. Change-Id: I19d9d933a69f7ad6252cbe51751d5db41790c698
2019-07-24trx: Use LOGPPHI instead of LOGP in some more messagesPau Espin Pedrol1-10/+10
This allows to clearly identify the phy instance owning those messages. Change-Id: I90990e4dbcbb2fb4a3fcb24658bdf53e57030bcf
2019-07-24manuals: Update vty documentationDaniel Willmann1-1633/+1742
This documentation only includes commands for osmo-bts-virtual Change-Id: Icc0c96d173f31f2eb5fcb6385525a17f94ead852 Related: OS#1700
2019-07-23bts-trx: Introduce VTY command osmotrx trxd-max-versionPau Espin Pedrol4-4/+36
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-21osmo-bts-trx/scheduler: rx_data_fn(): provide actual C/I ratio to L1SAPVadim Yanitskiy1-2/+14
Change-Id: Iea0dad65e9bc511f99375fd3ee2eb44e47a6168f
2019-07-21osmo-bts-trx/scheduler: rx_rach_fn(): provide actual C/I ratio to L1SAPVadim Yanitskiy1-2/+4
Change-Id: I8d86dec7ebc039cbfd038c4342ff328b11281865
2019-07-21Move Access Burst link quality handling to L1SAPVadim Yanitskiy6-21/+19
Change-Id: I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78 Depends: (libosmocore) Ie2a66ebd040b61d6daf49e04bf8a84d3d64764ee
2019-07-21Clarify and refactor link quality (C/I) handlingVadim Yanitskiy9-22/+22
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-21sysmo/l1_if.c: Annotate fall-through in switch statementHarald Welte1-0/+1
Change-Id: I72937e087288fe7681fafe4099e49849657924bd Closes: CID#162019
2019-07-18manuals: Add counter documentationDaniel Willmann3-0/+72
Change-Id: I994ad6aae7f409e0f15ff1d388127e16243b378a Related: OS#1700
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 Alteholz4-4/+4
Change-Id: I3d6cb6fc1b182d8520ba60e431ab9b74e71d5e3c
2019-07-16osmo-bts-trx/scheduler: rx_rach_fn(): enrich debug messageVadim Yanitskiy1-3/+9
Change-Id: I1cb28a9d6c98993705b73937409276994f375dc0
2019-07-16osmo-bts-trx/scheduler: rx_rach_fn(): clarify handover RACH handlingVadim Yanitskiy1-1/+2
Change-Id: I3da39d48052af1759297f4ad75c220b3046c0691
2019-07-16osmo-bts-trx/scheduler: rx_rach_fn(): use optional TSC info from TRXVadim Yanitskiy1-9/+12
TSC (Training Sequence Code) is an optional parameter of the UL burst indication. We need this information in order to decide whether an Access Burst is 11-bit encoded or not (see OS#1854). If this information is absent, we try to correlate the received synch. sequence with the known ones (3GPP TS 05.02, section 5.2.7), and fall-back to the default TS0 if it fails. Since the new TRXD header version, the training sequence code is indicated by the transceiver. Let's use it! Change-Id: I1e654a2e49cb83c5f1e6249c0de688f99bc466b0 Related: OS#1854, OS#4006
2019-07-16osmo-bts/scheduler: provide actual C/I values to OsmoPCUVadim Yanitskiy2-3/+18
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 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