Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
Good afternoon!
In libbsc/bsc_init.c we have the following case:
case GSM_BAND_900:
if (bts->c0->arfcn < 1 ||
(bts->c0->arfcn > 124 && bts->c0->arfcn < 955) ||
bts->c0->arfcn > 1023) {
LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n");
return -EINVAL;
}
break;
3GPP 45.005, table 2-2 gives valid channel numbers as:
P-GSM900 -> 1-124,
E-GSM900 -> 0-124 and 975-1023
R-GSM900 -> 0-124 and 955-1023
ER-GSM900 -> 0-124 and 940-1023
The code looks to bounds check ARFCN closest to R-GSM900, but omits ARFCN 0.
Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history?
Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)?
The other band checks look correct.
Kind Regards,
Mike
PS: osmo-arfcn is okay with ARFCN 0:
$ ./osmo-arfcn -a 0
ARFCN 0: Uplink 890.0 MHz / Downlink 935.0 MHz
Currently the DL sometimes hangs and sometimes a lot of messages
(still not able to send PDU) are logged. This is caused by an invalid
timer delay computation, setting msecs either to 0 or to some big value.
This is due to an '&' operator at the wrong place, accessing some
parts in fc instead of the first element of the list.
This commit fixes that issue.
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c
index 4c93b69..fe4fcca 100644
--- a/src/gb/gprs_bssgp.c
+++ b/src/gb/gprs_bssgp.c
@@ -628,7 +628,7 @@ static int fc_queue_timer_cfg(struct bssgp_flow_control *fc)
if (llist_empty(&fc->queue))
return 0;
- fcqe = llist_entry(&fc->queue.next, struct bssgp_fc_queue_element,
+ fcqe = llist_entry(fc->queue.next, struct bssgp_fc_queue_element,
list);
if (fc->bucket_leak_rate != 0) {
--
1.9.1
In test_rtp_seq_state an assignment is accidently done within an
assertion.
This commit changes that into a comparison as it was intended.
Fixes: Coverity CID 1295457, 1295458
Sponsored-by: On-Waves ehf
---
openbsc/tests/mgcp/mgcp_transcoding_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/tests/mgcp/mgcp_transcoding_test.c b/openbsc/tests/mgcp/mgcp_transcoding_test.c
index 1b8001e..c5c0a0b 100644
--- a/openbsc/tests/mgcp/mgcp_transcoding_test.c
+++ b/openbsc/tests/mgcp/mgcp_transcoding_test.c
@@ -295,7 +295,7 @@ static void test_rtp_seq_state(void)
OSMO_ASSERT(cont >= 0);
OSMO_ASSERT(state->is_running);
OSMO_ASSERT(state->next_seq == 2);
- OSMO_ASSERT(state->next_time = 240);
+ OSMO_ASSERT(state->next_time == 240);
/* verify that the right timestamp was written */
OSMO_ASSERT(len == audio_packets_pcma[0].len);
--
1.9.1
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
---
openbsc/doc/sgsn-remote-protocol.txt | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/openbsc/doc/sgsn-remote-protocol.txt b/openbsc/doc/sgsn-remote-protocol.txt
index 3369d19..88a384e 100644
--- a/openbsc/doc/sgsn-remote-protocol.txt
+++ b/openbsc/doc/sgsn-remote-protocol.txt
@@ -121,6 +121,7 @@ Network peer -> SGSN
01 IMSI 4.2.9 M TLV 2-10
04 PDP info complete 4.2.8 O TLV 2
05 PDP info 4.2.3 1-10 TLV
+ 13 MSISDN 4.2.10 O TLV 0-9
If the PDP info complete IE is present, the old PDP info list shall be cleared.
@@ -357,6 +358,7 @@ IEI that shall be used for the encoding.
| 0x10 PDP context id big endian int |
| 0x11 PDP type 4.2.4 |
| 0x12 APN 04.08, 10.5.6.1 |
+ | 0x13 MSISDN ISDN-AddressString/octet |
| 0x20 RAND octet string |
| 0x21 SRES octet string |
| 0x22 Kc octet string |
@@ -397,3 +399,24 @@ The IMSI is encoded like in octet 4-N of the Called Party BCD Number defined in
Note 1) Either '1 1 1 1 | Number digit N' (N odd) or
'Number digit N | Number digit N-1' (N even),
where N is the number of digits.
+
+4.2.10. ISDN-AddressString / MSISDN /Called Party BCD Number
+
+
+MSISDN. ISDN-AddressString in GSM 09.02 and Called Party
+BCD Number in GSM 04.08.
+
+ 8 7 6 5 4 3 2 1
+ +-----------------------------------------------------+
+ | | IEI | octet 1
+ +-----------------------------------------------------+
+ | Length of IE contents | octet 2
+ +-----------------------------------------------------+
+ | ext | Type of num | Numbering plan | octet 2
+ +-----------------------------------------------------+
+ | Number digit 2 | Number digit 1 | octet 3
+ +-----------------------------------------------------+
+ | Number digit 4 | Number digit 3 | octet 4
+ +-----------------------------------------------------+
+ : : :
+ +-----------------------------------------------------+
--
2.3.5
Dear Osmcom,
I am working on a project, where I am connecting OsmoBTS with OsmocomBB
without hardware.
I am trying to remove l1 on both sides and connect OsmoBTS with BB
application via simple unix sockets. Based on the further recommendations,
I am using osmobts-trx branch. Currently I am able to handle messages
between BTS and TRX driver on clock and control ports, and on BB side I am
in state that phone wants to connect into a cell (so its waiting for BCCH)
. I am now trying to find a possible way how to handle messages on data
port , between BTS – TRX ( TRX is removed, there is my application
instead), and forward these messages to my customized BB l1 interface . The
thing is that I need to send to BB phone (layer23) messages in structures
from gsm_04_08.h (i.e. gsm48_system_information_type_3). I am not sure if I
will be able to get needed from the messages coming on the data port 5702.
I found, that PCU creates unix socket on “/tmp/pcu_bts” , but only in case
sysmoBTS is in use (please correct me if I am wrong), so this will be not
possible due compilation errors without HW. Here I found the
gsm48_system_information_type_3 messages.
So basically I need somehow to get this message structures on my custom l1
BB interface. Do you have any idea how to do this ?
Any advice will be highly appreciated.
Many thanks you for your attention :)
Best regards,
Dominik Tamaskovic.
Dear Pablo, Ciaby,
from what I see we have the following OpenBSC/OS integration.
* OpenBSC wants to send some RSL data and calls abis_rsl_sendmsg
** abis_rsl_sendmsg entails the msgb into a queue and informs
the lower layer driver (ipa in our case)
** ipa sets the when to ~= BSC_FD_WRITE
* code returns
* OpenBSC runs select for all fds/timers..
* libosmocore dispatches fd's
** libosmo-abis/ipaccess.c will try to write a single message
** libosmo-abis/ipaccess.c will set the BSC_FD_WRITE again if
the queue is not empty
* Linux/TCP will run nagle to combine these messages
* OpenBSC runs select for all fds/timers...
....
The integration does work but appears to be a bit painful for
busy and high latency links. E.g. OpenBSC starts timers when
abis_rsl_sendmsg is invoked which might just be a little bit
later.
I wonder if there is a better way? For reading we could read
until -EWOULDBLOCK but then this might not be too fair for
the other parts of the software. For writing we might end up
in the situation where a write only partially succeeds and we
need to remember how much of the msgb to write next... So we
would need to do ioctl's to check how much space is left in
the send buffer
Do you have ideas? comments? is it a non issue? is it something
we can do better? Is there a TCP mode where a "write" either
fully succeeds or fails with -ENOSPC or such?
holger
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
In case the default TCH/F codec is "EFR" and we do an early
assignment from SDCCH to a TCH we would assign the TCH/H
codec. This is because the lchan_type will be neither a
TCH/H nor a TCH/F.
At the same time the _gsm48_lchan_modify code to check for
half vs. full-rate is the other way around. Align both.
It is full-rate if it is not a TCH_H. This will have some
other complications down the way (early assignment on
cells with only TCH/H). So the mode should not depend on
the _current_ channel but the kind of channel we want.
---
openbsc/src/libmsc/mncc_builtin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/libmsc/mncc_builtin.c b/openbsc/src/libmsc/mncc_builtin.c
index a5a463b..5c3461b 100644
--- a/openbsc/src/libmsc/mncc_builtin.c
+++ b/openbsc/src/libmsc/mncc_builtin.c
@@ -69,7 +69,7 @@ static uint8_t determine_lchan_mode(struct gsm_mncc *setup)
{
/* FIXME: check codec capabilities of the phone */
- if (setup->lchan_type == GSM_LCHAN_TCH_F)
+ if (setup->lchan_type != GSM_LCHAN_TCH_H)
return mncc_int.def_codec[0];
else
return mncc_int.def_codec[1];
--
2.1.4
Currently the inner loop in show_bsc_mgcp iterates of the timeslot
interval [0, 31]. Timeslot 0 is not valid, which causes
mgcp_timeslot_to_endpoint to generate a corresponding warning and to
return an invalid endp value. That value causes an out-of-bound
read access, possibly hitting unallocated memory.
This patch fixes the loop range by starting with timeslot 1.
Note that this does not prevent mgcp_timeslot_to_endpoint from
returning an invalid endpoint index when called with arguments not
within its domain.
Addresses:
<000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0
[...]
vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256
max = 1
con = 0xb4a004f0
i = 0
j = 0
[...]
==15700== ERROR: AddressSanitizer: heap-use-after-free on address
0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c
Sponsored-by: On-Waves ehf
---
openbsc/src/osmo-bsc_nat/bsc_nat_vty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c
index 5f4ad28..2b7db2e 100644
--- a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c
+++ b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c
@@ -250,7 +250,7 @@ DEFUN(show_bsc_mgcp, show_bsc_mgcp_cmd, "show bsc mgcp NR",
vty_out(vty, "MGCP Status for %d%s", con->cfg->nr, VTY_NEWLINE);
max = bsc_mgcp_nr_multiplexes(con->max_endpoints);
for (i = 0; i < max; ++i) {
- for (j = 0; j < 32; ++j) {
+ for (j = 1; j < 32; ++j) {
endp = mgcp_timeslot_to_endpoint(i, j);
vty_out(vty, " Endpoint 0x%x %s%s", endp,
con->_endpoint_status[endp] == 0
--
1.9.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi! First a small update:
we finally decided to _not_ use token mode, as it confuses a lot of
phones, after receiving the token message the SIM goes into an error
state and the only way to recover is to reboot the phone. Now we just
read the IMSI straight from the SIM (using the card python library,
just like osmo-sim-auth does) and register them.
Now, the issue we see is that 1-2 users every day reach a point where
they can make phone calls and send messages, but they can't receive
neither of them. Sometimes the problem can be fixed by running:
> subscriber extension <EXT> clear-requests
but this only work when there are pending requests. In other cases,
the phone has to be rebooted. Did anyone encounter the same issue?
Cheers
Ciaby
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJUef1WAAoJEPU83OtbD4fQ69kQAI7peg30lHwbDPMXnTX80gUu
0dGsiK2iB5oWZ6Ohbs3W+/+xVoMseuG1di6Rk0XT9buN2IOR5fMfAs3INQ2EuAlV
qz1RRn5Ux8uV0RJWyAJoSt7eFh3gbnDgsJ+x8SXEHQRw4rYHG2P+HXyEtncW6A6y
L8/oPeIxH/LlP/55MP3KUY5BnQmN658LnJU9AFSwPkpjn2f/dj4o6mUdWo8haTTQ
UWPWEdhQoeXPBqHsn2cKamT13SmiepMYAGuDEJci9LCS+J8vd70ukAP/oa1L6u1w
+3+RbcNvC9fwAKDLU01b/cu630v6/mhk0lxWNlIz/kNL1aHPZe8QhP5sM4SuLtzj
UaeHLxp4u2Pb7N31b3qtRA4jgl+5YFla5376F3d00jPSfZpmFggFgdRB2qWhF1m8
WucfzLc41dV1AVTdL90ISSRt1LZ/fLHBea8kgUxK+KrhBO7U7AV3PXk9of4EAf7y
VKMX3KZWwtEKhpi0v3PihgW8bS/RaG3zEmsr30QXzXVaZknCfjGi8OOOB0JaHY48
o3g40YpzeyEq1gOyKKfBmtf1qk4GgLyPKfMUoTvXE2oNHmrg3ZlJldABKNzR9qz3
5hsHJ6/QGsBST1E3dphI0Zb6ubLnFwqBl02GyeJELLbtPCLPQMDicx03cqT4BjO3
vzDcPdIWg1sfSomYKMK9
=Zw4T
-----END PGP SIGNATURE-----