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.
Related: OS#4138
Change-Id: Ic1ac815eafab49577ff883a5d700ecca5936d216
Ubsan complains about shifts into the sign bit due to automatic int
promotion, so cast explicitly.
Change-Id: I6387c7313832f6c7c920e1016b74562b66d6b68e
Related: OS#4029
The recent versions of OsmoBTS do provide the following measurements:
- RSSI (Received Signal Strength Indication),
- ToA (Timing of Arrival),
- BER (Bit Error Rate),
as well as C/I (Carrier-to-Interference ratio) since [1] (OS#4006).
[1] https://gerrit.osmocom.org/r/Ia58043bd2381a4d34d604522e02899ae64ee0d26
Change-Id: I0fd6c35e8cf0b1314f4e3c336b233b5f7e42dfc6
Related: OS#1855
In most cases the length field was present and this field takes 7
bits of the maximum available 110 rest bits.
The length field was only removed when encoding huge bitmaps usually
only happen on lossy connections with packet lost.
However the cases without length field were encoded incorrect,
because all remaining bits must be used by the uncompressed bitmaps,
but the PCU violates this by encoding always the "release 5" bit.
Rather than fixing the encoding without length field, simply remove it
and always encode with length field. This also reduces the code
complexity.
Change-Id: I7bc2e18d647b72b8f17ba7a5c9c5e421d88275fb
The ESN, SSN and uncompress bitmap len are uint16_t. The Window is using uint16_t in
function arguments and return values. Don't do so many integer conversions.
Change-Id: If62fa09d7bfa8e91ce707824f7019edb1b83da9e
search_runlen() must know the exact size in bits when parsing
the bits otherwise it read over the buffer.
Fixes testcase #7 which was wrongly decoded.
Change-Id: Ie34a0651e7e7efea4e9ecff1e3a467588113cf47
The i value will only count forward and is limited to 11 bit. The integer is also
converted when returning to uint16_t
Change-Id: Ib8a9081bbcb8b4344498254c58941002d17f9381
The last bits of the CRBB (compressed receive block bitmap) was incorrect
encoded when the CRBB is not byte aligned.
Related: OS#3728
Change-Id: I7261aa71b37d7ead52992f8db462f72a3804988e
The instance bssgp_nsi is a global instance to be used by all
NS related functions. Previous the PCU allocated and initialized
the bssgp_nsi instance when (re-)connecting and freeing on disconnect.
The problem of the implicit initialisation is gprs_ns_vty_init(bssgp_nsi).
All vty init functions must be called before the configuration is read,
otherwise a previous vty written configuration is invalid.
Furthermore the vty modifications to the `ns` object were lost when the PCU has to
reconnect to the SGSN.
Fixes: OS#4024
Change-Id: I2aa53ea54e9352577f6280ad7b9d1d9da9f57eaf
rename the function sgsn_ns_cb -> gprs_bssgp_ns_cb.
To allow writing and reading the same configuration, the pcu needs to register
all vty commands before reading the configuration. This callback
is required to register NS based vty commands
Related: OS#4024
Change-Id: I440c0df2e32fe22bf43288c00bb4aa3a0c6a3a51
In 3GPP TS 44.060 the selection of MCS for retransmissions is defined as
separate tables (8.1.1.1 and 8.1.1.2) depending on the value of
resegmentation bit (which is opposite to the way EGPRS_ARQ are defined
in the source code). Let's follow the same idea and explicitly check for
resegmentation bit value and use separate tables. This also makes it
easier to add proper support for special cases (MCS-6-9 and MCS-5-7) and
padding in future independently for different ARQ types. The code is
also moved to c to avoid unnecessary conversions to and from cpp class.
Change-Id: Ia73baeefee7a58834f0fc50e3b8bf8d5e3eb7815
Problem:
TA provided from L1 PH-DATA-IND is a relative amount of TA adjustment to actual TA
being used for given TBF. The current TA update algorithm in PCU simply applies the relative
amount of TA to given TBF but does not take into account of current TA.
As a result, the PCU will request wrong TA jump for given TBF if the MS is moving away from
BTS more than 2 km.
Related issue: http://osmocom.org/issues/2611
Fixes:
- The PCU needs increase or decrease current TA of given TBF on receiving of relative
amount of TA adjustment provided by PH-DATA-IND from L1.
- The PCU needs to set absolute TA of given TBF on receiving absolute TA provided by
PH-RA-IND from L1.
From-Commit: 139ad3f42193
From-Remote: https://gitlab.com/nrw_noa/osmo-pcu
Change-Id: I7665586dd5722bbe04632ee5673d3033bc082324
Write initial bits of 3GPP TS 44.018 §10.5.2.16 IA Rest Octets the same
way as write_ia_rest_*() routines do.
This should also fix the issue addressed in
I75dd5bebc74eea85edf9582607c774d0bba0d2a6 initially by properly encoding
L/H bits.
Change-Id: I7ed5270bf95c3f6e9e026ff447eef8539f6f0314
* use enum CodingScheme directly instead of converting it to class and
back
* drop useless mode check
* log errorneous update attempt
Change-Id: I763136c2f356d63aa3d28d09c57fd5faf5336258
Write TAI (if available) when generating Rest Octets for UL
Assignment. This should not affect actual PCU behavior because TAI is
not yet supported by upper layers but we have to adjust corresponding
tests anyway.
That's updated version of reverted commit.
Change-Id: I69407793bdb863be5fc42adadf75842d22f27335
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
The difference in the expected test output is due to proper handling of
TAI which should not be transmitted for SBA according to the Note in
Table 10.5.2.16.1 in 3GPP TS 44.018.
The change was manually tested against real mobile phone using options
'gprs mode gprs' in osmo-bsc.cfg and 'two-phase-access' in osmo-pcu.cfg
to make sure appropriate code path is actually triggered.
That's partially based on reverted commit 93d947f5e8.
Change-Id: I97d53c27c1ca9e032d431b3aa7f915027d63ddc0
Related: OS#3014
Use bitvec_set_*() directly without external write pointer tracking to
simplify the code. This is part of IA Rest Octets (3GPP TS 44.018
§10.5.2.16) which is the last part of the message so it should not
interfere with the rest of encoding functions.
That's partially based on reverted commit 93d947f5e8.
Change-Id: Ibe294b26ac374b9264a734db9663cacc105a4474
Related: OS#3014
Previously result of ".to_num() - 1" was used without any checks which
means that in case of to_num() returning zero we would effectively try
to encode (uint8_t)(-1).
Let's fix this by using proper mcs_chan_code() function which returns
Channel Coding Command for MCS without the need to further correct it
and adjust expected tests output accordingly.
Change-Id: I868062a81fffe6714a811c032215f25a79259905
Add function to encode MCS value as proper EDGE or GPRS Channel Coding
value according to 3GPP TS 44.060 and corresponding helpers.
Use it for everything except IA Rest Octet encoding which is done in a
follow-up patches to make sure that we distinguish between
encoding-related changes to test output and unrelated changes.
Change-Id: I127fb29f5aaf77a7f6c4c565dfeb3b711af9845d
This is a much safe way, it allows for modifications of the debug
subsystem enum member values without breakage. Also, the syntax
introduced here is what we do in all other Osmocom CNI projects.
Change-Id: I2be88586ca44b0b8361f96cf3c034c8459244c2c
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. As of
Change-Id I3c1af662c8f0d3d22da200638480f6ef05c3ed1f, OsmoBTS forwards
this via the PCU socket, so we need to pick it up and send it via BSSGP
to the SGSN.
Change-Id: I7b4beb413a6f974373a404b5a11c44d86ba695d3
Closes: OS#2249
In Change-Id I787fed84a7b613158a5618dd5cffafe4e4927234 in February 2018
we accidentially introduced a change that would erroneously swap
the endianness of the CellID on the way between PCUIF socket and
BSGSP. This meant that all OsmoPCU based BTSs would report the
wrong CellId to the SGSN.
Closes: OS#3854
Change-Id: I2f6cc930c5dbf8dac386b24b0756df2efe8199e4
In preparation for Channel Coding Command encoder in follow-up patches
let's add necessary helpers. Those are similar to previously used
helpers from GprsCodingScheme class but without CamelCase and with less
typo chances between Gprs and Egprs cases.
Change-Id: I6699cbc8d7ae766fa4d2b3d37e5f9ff1cf158b7e
bts.h needs pdch.h whether we're compiling C or C++ code so move it out
of the #ifdef.
make[1]: Entering directory '/home/daniel/scm/osmo/oc2g/osmo-pcu-oc2g/src'
CC osmo-bts-oc2g/oc2g_l1_if.o
In file included from osmo-bts-oc2g/oc2g_l1_if.c:39:
./bts.h:74:26: error: array type has incomplete element type ‘struct gprs_rlcmac_pdch’
struct gprs_rlcmac_pdch pdch[8];
^~~~
Change-Id: Ib39e4424f73c677b34f921917440f211e400e14f
Move Mode (EDGE/GPRS) definition and related functions outside of
GprsCodingScheme class. This allows us to use standard libosmocore
value_string functions.
Change-Id: I3baaac7f1ca3f5b88917a23c1679d63847455f47
The TAI is described as { 0 | 1 < TIMING_ADVANCE_INDEX : bit (4) > } in
3GPP TS 44.018 §10.5.2.16.1 so it should be encoded with if-else.
Change-Id: I54482790e1cf3cb13a635a99a481250576deabaf
Move functions which compute number of blocks or bits depending on
header type and corresponding enum outside of GprsCodingScheme
class. This will allows us to use standard libosmocore value_sting
functions in upcoming patches for IA Rest Octet encoding/decoding.
Change-Id: Id0873f85e1f16a72e17e7fbc4ad76b194917067f
Pau Espin
Vadim Yanitskiy
Eric Wild
Harald Welte
Daniel Willmann