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
Hi all.
I'm working on probation on mobile operator as a student.
Currently, I'm trying to create site for testing, using Huawei BTS 3900B
and OpenBSC software.
But I can't set up it.
I have a several questions:
1) Huawei BTS uses Abis over IP, how can I connect this BTS to OpenBSC.
2) Are there any examples of configuration in this case?
Thanks.
Dear Experts,
Hello, I am running a gsm system with followings:
OpenBSC version: 0.13.0.319-30e0e
LCR version 1.14
astersik version 1.8.10.1
The system is sited is a busy area. The system works fine for few days but
hangs once the hlr.sqlite3 file size reaches near 12 MB and that causes the
osmo-nitb to take 99% of the cpu usage. I used "./osmo-nitb -m -P -C" to
run the system. The hlr.sqlite3 file increases @2MB/Day. The 'Subscriber'
table of the hlr.sqlite3 file adds a large number of IMSI with
authorized=0. Tables like Counters, Eqipment and EquipmentWatch are filling
up with lots of data. Now the only solution to this problem is to manually
delete the data from the tables.
May I get some light to solve the issue form the experts like you all?
With regards.
[ Content from the openbsc.cfg file is as following:
!
! OpenBSC configuration saved from vty
! !
password foo
!
line vty
no login
!
e1_input
e1_line 0 driver ipa
network
network country code XXX
mobile network code XX
short name Test
long name Test
auth policy closed
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 0
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 4
timer t3111 1
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3141 0
bts 0
type sysmobts
band GSMXXX
cell_identity X
location_area_code X
training_sequence_code 7
base_station_id_code 63
ms max power 30
cell reselection hysteresis 4
rxlev access min 0
periodic location update 100
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id XXXX 0
oml ip.access stream_id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn XXX
nominal power 23
max_power_red XX
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
Hi
On 05.06.2015 15:15, ☎ wrote:
> Could you perhaps summarize what's happening around tests/gb/gprs_bssgp_test.c:229?
The line before the failing test is
rc = bssgp_tx_fc_bvc(&bctx, tag, bmax, rate, bmax_ms, rate_ms,
NULL, NULL);
The bssgp_tx_fc_bvc function will in general call gprs_ns_sendmsg ->
gprs_ns_tx -> nsip_sendmsg -> sendto. The sendto function had been
"replaced" by redefining it locally which worked at least with the
default ld up to ubuntu 14.04. (see Holger's replies).
The system's sendto will fail in the test, since the UDP socket has not
been configured. The local replacement (see gprs_bbsgp_test.c:37) will call
fprintf(stderr, "MESSAGE to 0x%08x, msg length %d\n%s\n",
dest_host, len, osmo_hexdump(buf, len));
so you just need to look into the stderr output to see, whether this is
a linker issue.
If yes, the issue will appear in more test programs, since that pattern
has been used many times.
If there is no way to trick the linker to use the "old" behaviour, those
test programs will have to be changed to use another mocking mechanism,
e.g. by using the --wrap feature (if it is supported by the linker), see
openbsc:openbsc/tests/sgsn/sgsn_test.c.
HTH
Jacob
>
> The test fails for me (and another person with ubuntu 15.04 x86_64) on OSMO_ASSERT(rc
>> = 0);
>
> This is 100% reproducible but I don't know much about Gb part so I'm not sure how to
> track this down properly. Any ideas/advices?
>
--
- Jacob Erlbeck <jerlbeck(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Pardon for multiple copies, but this is really curious: gbprocy test also fails for
me during OpenBSC build at gbproxy_test.c:1922 which also contains following
misterious comment:
/* TODO: The following breaks with the current libosmocore, enable it
* again (and remove the plain expect_msg), when the msgb_bssgph patch
* is integrated */
What is the status of this "msgb_bssgph patch" patch? Is there patchwork link available?
I suspect it's still unmerged because swapping the lines as instructed in comment
still results in crash with the latest libosmocore from git.
Commenting out both lines produce sane-looking output but the test expectedly fails
due to mismatch with expected output.
I wonder if should comment out the 2nd line until the libosmocore patch is merged or
perhaps consider merging the necessary patch?
22.05.2015 15:38, ☎ пишет:
> Hi.
>
> Anyone else experienced this with latest libosmocore from git?
>
> ./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test
> stderr:
> MESSAGE to 0x7f0000ff, msg length 12
> 02 00 81 01 01 82 0b 56 04 82 0b 55
> All NS-VCs for NSEI 2901 are either dead or blocked!
> All NS-VCs for NSEI 2901 are either dead or blocked!
> BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
> BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
> NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
> Unable to resolve NSEI 4660 to NS-VC!
> Assert failed rc >= 0 gb/gprs_bssgp_test.c:229
> /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25:
> 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_
> bssgp_test
>
--
best regards,
Max, http://fairwaves.co
Hello,
I've been experiencing this bug ever since I started experimenting with
OpenBSC.
At first I thought it as a problem with unstable connection, but it
continued to happen even after I connected to the nanoBTS directly
through a switch.
I used Wireshark to track down the cause and discovered that OpenBSC was
responding too late to PING message from the nanoBTS. I am attaching the
pcap file of the moment.
This happens as soon as 1 hour from the first connection, sometimes it
runs okay for 18 hours but I've never seen my nanoBTS running straight
for more than 24hrs
Please take a look into the log. Any help will be greatly appreciated.
Tell me in case if you need more information
Regards,
Pierre
Following is the log from openbsc console.
Sat Jun 27 03:24:43 2015 <0004> bsc_init.c:286 bootstrapping RSL for
BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7
Sat Jun 27 08:17:39 2015 <001a> ipa.c:246 Cannot send PING message.
Reason: Broken pipe
Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:110 Unexpected return
from ipa_ccm_rcvmsg_base (ret=-32)
Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:236 Sign link vanished,
dead socket
Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:69 Forcing socket
shutdown with no signal link set
Sat Jun 27 08:20:51 2015 <001a> input/ipa.c:265 accept()ed new link from
192.168.28.31 to port 3002
Sat Jun 27 08:21:08 2015 <001a> input/ipa.c:265 accept()ed new link from
192.168.28.31 to port 3003
Sat Jun 27 08:21:11 2015 <0004> bsc_init.c:286 bootstrapping RSL for
BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7
and sometimes without the error from ipa_ccm_rcvmsg_base
Sun Jun 28 09:17:40 2015 <001a> input/ipaccess.c:236 Sign link vanished,
dead socket
Sun Jun 28 09:17:40 2015 <001a> input/ipaccess.c:69 Forcing socket
shutdown with no signal link set
Sun Jun 28 09:20:39 2015 <001a> input/ipa.c:265 accept()ed new link from
192.168.28.31 to port 3002
Sun Jun 28 09:20:56 2015 <001a> input/ipa.c:265 accept()ed new link from
192.168.28.31 to port 3003
Sun Jun 28 09:20:59 2015 <0004> bsc_init.c:286 bootstrapping RSL for
BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7
I would like to know if anyone has a Nanobts for sale hopefully under
500$. I'm looking for the 900MHz or 1800MHz ones, preferably the ones
with SMA antenna connectors (the white square ones) without internal
antennas. Doesn't matter if they are used/old/new, just something
that works without issues :)
Otherwise you have to restart BTS or at least break the RSL connection
to apply the change.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Currently the size of the IMSI pointer is used instead of the size of
the talloc'ed buffer.
This commit changes the call to gsm48_mi_to_string to use the same
value that has been used with talloc_zero_size(). The length is
changed to 17 since that value is used for GSM_IMSI_LENGTH in
openbsc.
Fixes: Coverity CID 1040663
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp_bss.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gb/gprs_bssgp_bss.c b/src/gb/gprs_bssgp_bss.c
index 962bf2e..3a9012e 100644
--- a/src/gb/gprs_bssgp_bss.c
+++ b/src/gb/gprs_bssgp_bss.c
@@ -34,6 +34,8 @@
#include "common_vty.h"
+#define GSM_IMSI_LENGTH 17
+
uint8_t *bssgp_msgb_tlli_put(struct msgb *msg, uint32_t tlli)
{
uint32_t _tlli = htonl(tlli);
@@ -498,8 +500,8 @@ int bssgp_rx_paging(struct bssgp_paging_info *pinfo,
if (!TLVP_PRESENT(&tp, BSSGP_IE_IMSI))
goto err_mand_ie;
if (!pinfo->imsi)
- pinfo->imsi = talloc_zero_size(pinfo, 16);
- gsm48_mi_to_string(pinfo->imsi, sizeof(pinfo->imsi),
+ pinfo->imsi = talloc_zero_size(pinfo, GSM_IMSI_LENGTH);
+ gsm48_mi_to_string(pinfo->imsi, GSM_IMSI_LENGTH,
TLVP_VAL(&tp, BSSGP_IE_IMSI),
TLVP_LEN(&tp, BSSGP_IE_IMSI));
--
1.9.1