Deprecate
gsm0808_sc_cfg_from_gsm48_mr_cfg() and
gsm48_mr_cfg_from_gsm0808_sc_cfg(),
and add new functions
gsm0808_sc_cfg_from_amr_modes() and
gsm0808_sc_cfg_get_best_amr_modes()
to fix the behavior as follows:
When the mr_cfg enables a specific rate, do not include all AMR
configurations that feature this rate. Instead, enable only those
configurations that are a subset of the mr_cfg.
For example, in the old functions, setting only m4_75 = 1 would result
in enabling all of S0, S8, S9, S10, S12, S14. S14 would allow all of
4.75k, 5.9k, 7.95k, 12.2k, instead of limiting to 4.75k only.
In the new functions, do not modify the .version and .icmi members, act
only on the AMR rates.
Changes from old behavior to new behavior is clearly shown in
tests/gsm0808/gsm0808_test.ok.
Keep the deprecated functions unchanged, yielding incorrect behavior,
and let the API users decide when and how to upgrade to the more sane
behavior.
For example, changing the behavior of existing functions in-place would
have repercussions on osmo-bsc installations, where now only those AMR
modes listed in the config would be used -- we are becoming stricter.
Possibly this would deteriorate or break sites alone from upgrading
libosmocore -- i.e. those sites that fail to list an essential AMR rate
for matching with peers, but where that essential AMR rate was
erratically allowed by the old behavior.
The old behavior, by example of osmo-bsc:
- Picking rates in osmo-bsc.cfg has non-obvious effects, often
including rates that are configured as 'forbidden'.
- If any of 4.75, 5.90, 7.40, 12.2 is enabled in osmo-bsc.cfg, the
configuration S1 ends up enabled in s15_s0
(gsm0808_sc_cfg_from_gsm48_mr_cfg()).
- In gsm48_mr_cfg_from_gsm0808_sc_cfg() used during channel activation,
if S1 is present, the four rates from S1 are returned.
- In summary, in the vast majority of cases, the S1 set will be used --
even if only one of its AMR rates is originally present in mr_cfg.
- Configurations above S7 are ignored.
The new behavior, assuming osmo-bsc moved to the more sane
implementation introduced in this patch:
- Only one of the rate combinations defined by S0..S15 is going to be
used.
This is mainly because AMR rate selections are sent to the MSC and
back from the MSC in the somewhat limited S0..S15 bit form.
Enabling one or more of these combinations of rates in osmo-bsc.cfg
makes sense:
- 4.75, 5.90, 7.40, 12.2 (S1)
- 4.75, 5.90 (S8)
- 4.75, 5.90, 6.70 (S9)
- 4.75, 5.90, 6.70, 7.40 (S10)
- 4.75, 5.90, 6.70, 10.2 (S12)
- 4.75, 5.90, 7.95, 12.2 (S14)
- e.g. if only 4.75 is enabled, only 4.75 is used (S0).
- e.g. in case of 6.70=allowed + 7.75=allowed + 10.2=allowed,
we have to choose between "only 6.70", "only 7.75", "only 10.2".
On FR we'd pick S6 = "only 10.2", because it is the highest rate.
So osmo-bsc.cfg should rather choose rates exactly matching a specific
Sn bit, e.g. all rates of S12, to obtain a flexible variety of AMR
rates.
3GPP TS 48.008 3.2.2.103 'Speech Codec List' says to this:
NOTE: One of these Codec Configurations, "Config-NB-Code 1" = S1, is
recommended for TrFO [Transcoder Free Operation].
S14 also seems a good choice, it is like S1 but with 7k95 instead of
7k40; 7k95 is the highest possible AMR-HR rate. It is not clear at this
point why S1 seems to be preferred over S14.
Ironically, the old behavior would usually end up selecting exactly S1
in almost every case, which is what 3GPP TS 48.008 3.2.2.103 recommends.
This is, however, not obvious to the caller / the site admin.
Related: SYS#5066
Change-Id: I900fda192742fa8f6dd54e9131ef1704b14cc41a
3GPP TS 44.021 specifies the format for modified V.110 frames as used
on the GSM air (radio) interface. Implement encoders and decoders for
this modified V.110 format.
Related: OS#1572
Change-Id: I60a2f2690459359437df20cf4da9043fa7c3ad11
V.110 defines a B-channel protocol for transmission of synchronous and
asynchronous serial data of V-series interfaces via terminal adapters
over ISDN.
Let's add (unoptimized but easy to debug) functions for encoding and
decoding of V.110 frames for various bit-rates.
Related: OS#1572
Change-Id: I1b5fd3847d3bfb0a0f763e0574893962ec699680
As per gnu extension doc ->
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Thread-Local.html :
".. When used with extern or static, __thread must appear immediately
after the other storage class specifier."
Change-Id: Ied1d3cf3ad2ff424bd0a2682aff29a8939b419b8
Those functions were introduced in I51b3604ba79e42c474aa17007e7e308a12afcea8
but the recent introduction of libosmocore.map didn't list them
Change-Id: I4ac14aae13ff60c110444da989761cd1e86f8925
Fixes: I13169c00a59fb59513dfc598de5a71d094492422
Use the same 32k0, 29k0, 14k4, … notation for GSM0808_DATA_RATE, as
it is already used in RSL_CMOD_CSD. As GSM0808_DATA_RATE enumes were
just added to libosmocore and aren't used yet, don't add backwards
compatible defines.
Related: OS#4393
Change-Id: Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
Use the 32k0, 29k0, 14k4, … notation instead of 32000, 29000, 14400 etc
to make transparent data enums with non-transparent data enums where
this notation is already used.
Related: OS#4393
Change-Id: I7b7c8f175f349811b17a3db68a57577bd3f1d2df
Improve the test output to make it easier to confirm that the fix in an
upcoming patch (I900fda192742fa8f6dd54e9131ef1704b14cc41a) is indeed
correct.
Spell out each S0-S15 mode along with the bitmask.
Rejigger the format of printing the mr_cfg flags, so that the AMR modes
line up vertically with the S0-S15 modes.
This clearly shows that the mr_cfg <-> s15_s0 conversion is wrong.
For example, in this test only 4k75 is enabled, yet we allow configs
featuring 6 other rates:
Input:
cfg.smod=0 spare=0 icmi=0 nscb=0 ver=0
m4_75=1 ------- ------- ------- ------- ------- ------- -------
Result (fr):
S15-S0 = 0x5701 = 0b0101011100000001
S0 4.75
S8 4.75 5.90
S9 4.75 5.90 6.70
S10 4.75 5.90 6.70 7.40
S12 4.75 5.90 6.70 10.2
S14 4.75 5.90 7.95 12.2
Result (hr):
S15-S0 = 0x0701 = 0b0000011100000001
S0 4.75
S8 4.75 5.90
S9 4.75 5.90 6.70
S10 4.75 5.90 6.70 7.40
In this test, an s15_s0 featuring a configuration with 6k70 allowed does
not result in m6_70 == 1:
Input:
S15-S0 = 0x0c12 = 0b0000110000010010
S1 4.75 5.90 7.40 12.2
S4 7.40
S10 4.75 5.90 6.70 7.40
S11 4.75 5.90 6.70 7.40
Output:
cfg.smod=0 spare=0 icmi=1 nscb=0 ver=1
m4_75=1 ------- m5_90=1 ------- m7_40=1 ------- ------- m12_2=1
Almost every conversion contains errors like this.
Related: I900fda192742fa8f6dd54e9131ef1704b14cc41a
Change-Id: Iec7c491d9fadd37d9e43fbaac8e709c2029f8a8e
Provide the definitions from 3GPP TS 28.062, Table 7.11.3.1.3-2 as
generally usable API.
Likely users:
- upcoming patch to improve conversion between S0-S15 and MultiRate
config, I900fda192742fa8f6dd54e9131ef1704b14cc41a
- osmo-msc to figure out conversion between SDP AMR mode-set and 3GPP TS
48.008 Permitted Speech S0-S15.
- osmo-bsc to choose AMR modes for channel activation from cfg /
permitted speech from MSC.
Related: SYS#5066
Change-Id: Icef7dd626d3d4641c66b8dd87e2047fc0ab547d1
These should not be used, but add them for backwards compatibility with
building older versions of osmo-bsc, osmo-iuh, osmo-pcap against current
libosmocore.
Fixes: 213fc420 ("Add libosmocore.map")
Change-Id: I4cfccf3622844d0923818bb8d8ce206f70e44a0d
According to 3GPP TS 48.008 3.2.2.11, it is inverted.
0: Transparent service
1: Non-transparent service
Change-Id: I2e5786ad053ee871079b4a8d95caccd6b03b59b6
This patch adds the [de]interleaving for CSD (circuit switched data),
nominally for TCH/F 9.6, but the same is also used for TCH/F 4.8,
TCH/H 4.8, TCH/F 2.4 and TCH/F 14.4.
Related: OS#4396, OS#1572
Change-Id: I6b16c2d0d7febf3883da662b2c7fec543335de12
This patch is a preparation for the upcoming change making use of
the built-in static_assert(), which is available since C11.
When using built-in static_assert(), gcc v12.2.1 fails:
iuup.c: In function 'osmo_iuup_msgb_alloc_c':
iuup.c:194:33: error: expression in static assertion is not constant
194 | osmo_static_assert(size > IUUP_MSGB_HEADROOM_MIN_REQUIRED, iuup_msgb_alloc_headroom_bigger);
../../include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
This one is not really a *static* assert(), because it operates on the
user supplied argument 'size', which is not guaranteed to be an integer
literal. Neither it triggers a compilation failure as expected, nor
does it abort at run-time. It simply does nothing.
Change-Id: I53db679728250e0c60ed277efb18142073ffe9c4
This patch is a preparation for the upcoming change making use of
the built-in static_assert(), which is available since C11.
When using built-in static_assert(), gcc v12.2.1 fails:
include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom_c':
include/osmocom/core/msgb.h:532:33: error: expression in static assertion is not constant
532 | osmo_static_assert(size >= headroom, headroom_bigger);
include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom':
include/osmocom/core/msgb.h:554:33: error: expression in static assertion is not constant
554 | osmo_static_assert(size >= headroom, headroom_bigger);
include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
These are not really *static* assert()s, because they operate on the
user supplied arguments 'size' and 'headroom', which are not guaranteed
to be integer literals. Neither they trigger compilation failures
as expected, nor do they abort at run-time. They simply do nothing.
Change-Id: I17ef4f3283ce20a5b452b7874c826acfb02a0123
This patch adds the convolutional code definitions for CSD (circuit
switched data) on TCH/F channels with user bit rates of 2400, 4800, 9600
and 14400 bps.
Related: OS#4396, OS#1572
Change-Id: I412131d7ee2e676402bf8d88394af17c4447b664
In the unit tests we're using memcmp() to compare decoding results
against the expected results. This is a reasonable approach, but
there is a pitfall: not only the struct fields are compared, but
also the padding bytes preceding/following them.
When using gcc's extension zero-initializer {} or even the standard
approved { 0 } zero-initializer, padding bytes are not guaranteed
to be zeroed. Even worse, according to [1], the init behavior is
inconsistent between gcc and clang and optimization levels.
All decoding functions in {bsslap,bssmap_le}.c currently use gcc's
extension zero-initializer {}. This is not a problem when building
with CC=gcc, but with CC=clang the bssmap_le_test fails due to
mismatch of padding bytes in struct lcs_cause_ie:
[4] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[5] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[6] PERFORM LOCATION ABORT: ERROR: decoded PDU != encoded PDU
Out of the known struct initialization methods, only the memset()
has consistent behavior and sets all bytes to zero, including the
padding ones. Using it fixes the bssmap_le_test for CC=clang.
[1] https://interrupt.memfault.com/blog/c-struct-padding-initialization
Change-Id: Ib16964b16eb04315efc416164ed46c15b5dc7254
Fixes: OS#5923
Lets get rid of the magic number in struct osmo_i460_timeslot and
replace it with a define constant.
Change-Id: Id3a3782927c7dcbc873223d56129f291c04fee26
Related: OS#5198
It already happened several times [1][2] that new features were added
to enum osmo_bts_features, but the osmo_bts_features_{descs,names}[]
were left unchanged. Let's add static_assert()s to prevent this.
Change-Id: I8e3b7d3996e9f3e16c6d4e0d1d406fa538d5e9be
Related: [1] f4f5d54ea2
Related: [2] 18c6a8183f
Let's disambiguate. Our existing OSMO_AUTH_ALG_XOR was always only
the XOR-3G algorithm. Now that we recently introduced XOR-2G,
let's rename (with backwards compatibility #define).
Change-Id: I446e54d0ddf4a18c46ee022b1249af73552e3ce1
We've so far only been supporting XOR-3G algorithm as specified
in TS 34.108 (in both 3G and 2G-derivation mode).
However, XOR-3G used for 2G auth is different from the XOR-2G algorithm
as defined in Annex A of TS 51.010-1. Let's add support for that one,
too.
Change-Id: I0ee0565382c1e4515d44ff9b1752685c0a66ae39
According to 3GPP TS 48.008 V16.0.0 § 3.2.2.11, the "Channel and rate
type" fills the whole octet 4, so don't cut it off.
This fixes decoding of e.g. GSM0808_SIGN_FULL_PREF_NO_CHANGE, which I
noticed while writing a test.
Related: OS#5911
Change-Id: Ib5fba18eb82736c4f52f315ae1197159b7090e69
Currently there's a big mess where include dir osmocom/gprs/ is used by
both libosmogsm and libosmogb.
Most of the header files under osmocom/gprs/ are actually all the
headers of libosmogb (there's no osmocom/gb/ dir). But a couple files
are actually RLC/MAC (TS 44.060) related are are also stored in there.
Those files have no relation/use in Gb, and are actually interused with
GSM (eg System Information 13 Rest Octets).
Hence, it makes sense to have the RLC/MAC related parts inside
osmocom/gsm/ as they should be in libosmogsm (and they actually are,
see gprs_rlc.h function implemented in src/gsm/gsm48_rest_octets.c).
The fact that some libosmogsm headers were placed in osmocom/gprs
instead of osmocom/gsm already created some issues, like
libosmocore.spec.in putting "%_includedir/%name/osmocom/gprs/" under
libosmogb, which is wrong.
As a first step to fix the mess, we move the 2 RLC/MAC headers currently
under osmocom/gprs/{gprs_rlc,protocol/gsm_04_60}.h under a single header
gsm/protocol/gsm_44_060.h
The two old headers are left existing for backward compatibility and now
simply include the new libosmogsm header, plus a warning asking users to
switch to the new header so we can eventually get rid of them.
This means libosmogb depends on libosmogsm, which is fine and was
already the case beforehand (libosmogb using functions like
gsm48_encode_ra() and linking against it in src/gb/Makefile.am).
Change-Id: I70cc21bf25a7081070738abacb409ed19094c3b2
Those allow selecting source host:port for UDP socket sending GSMTAP data.
It's handy when you have several GSMTAP sources operating simultaneously.
Change-Id: I51b3604ba79e42c474aa17007e7e308a12afcea8
There may be situations where we must check if there are still I.460
subchannels active, so lets make the function osmo_i460_subchan_count
public
Change-Id: I0454ffe5809f21504c1e263a781c06596d452d4b
Related: OS#5198
Neels Hofmeyr
Harald Welte
Eric Wild
Vadim Yanitskiy
Pau Espin
Oliver Smith
Daniel Willmann
Max
Philipp Maier