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
Dear all,
the valuable L1SAP abstraction has been sitting out of master for too
long time. It is a pity that this has taken so long. I've finally been
able to put some time into osmo-bts again and reviewed the following
patch series. It consists of mostly Andreas' work, interspersed with
smaller patches/fixups that I introduced after the respective original
patch from Andreas.
I have started a sysmobts between all of the major steps in this patch
series and did a short manual tests involving registration (LU) of two
MS, mobile-to-mobile call and vty-to-mobile SMS. So far I couldn't see
any problems. What has not been tested yet is the PCU interface as well
as encryption support. I plan to do this later this week.
I intend to merge the code after this current review cycle. Please take
your time to have a look and provide feedback (if any), so we can get
this over and work on new features again, rather than infrastrutural
changes.
I didn't yet rebase the osmo-bts-trx interface on top of the L1SAP, as I
don't have a hardware setup for it, and I will leave it to the owners of
such hardware to publish/push the respective code after L1SAP is merged.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Currently the BVCI is not set in all invocations to bssgp_tx_status()
when the cause is UNKNOWN_BVCI.
This patch adds the argument where it is missing.
It also adds a check for compliance (GSM 08.18, 10.4.14.1) to
bssgp_tx_status() to emit errors when the following requirement is
not fulfilled: The BVCI must be included if (and only if) the cause
is either "BVCI blocked" or "BVCI unknown".
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp.c | 2 +-
src/gb/gprs_bssgp_util.c | 14 ++++++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c
index 5ef1887..b8c6c74 100644
--- a/src/gb/gprs_bssgp.c
+++ b/src/gb/gprs_bssgp.c
@@ -998,7 +998,7 @@ int bssgp_rcvmsg(struct msgb *msg)
LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU "
"type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci,
pdu_type);
- return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, NULL, msg);
+ return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg);
}
if (bctx) {
diff --git a/src/gb/gprs_bssgp_util.c b/src/gb/gprs_bssgp_util.c
index ae4647e..261e0b0 100644
--- a/src/gb/gprs_bssgp_util.c
+++ b/src/gb/gprs_bssgp_util.c
@@ -99,6 +99,20 @@ int bssgp_tx_status(uint8_t cause, uint16_t *bvci, struct msgb *orig_msg)
struct bssgp_normal_hdr *bgph =
(struct bssgp_normal_hdr *) msgb_put(msg, sizeof(*bgph));
+ /* GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the
+ cause is either "BVCI blocked" or "BVCI unknown" */
+ if (cause == BSSGP_CAUSE_UNKNOWN_BVCI || cause == BSSGP_CAUSE_BVCI_BLOCKED) {
+ if (bvci == NULL)
+ LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: "
+ "missing conditional BVCI\n",
+ bssgp_cause_str(cause));
+ } else {
+ if (bvci != NULL)
+ LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: "
+ "unexpected conditional BVCI\n",
+ bssgp_cause_str(cause));
+ }
+
LOGP(DBSSGP, LOGL_NOTICE, "BSSGP BVCI=%u Tx STATUS, cause=%s\n",
bvci ? *bvci : 0, bssgp_cause_str(cause));
msgb_nsei(msg) = msgb_nsei(orig_msg);
--
1.9.1
Hello everyone
I am new to openbsc, and trying to implement my own mobile network for my
masters project. Till now everything has gone well and my network is
working gud. But the issue is when I am trying to implement rrlp with
openbsc. I have set the rrlp mode to ms-based, but there is no response
from the phone on sending the request. I have checked that the request is
going to the phone with the help of wireshark. So please anyone help me
with this, that should i use E-OTD or ms-assisted method for getting the
response from the phone.
Thanking you in anticipation
Kunal
Hi,
I have an Odroid-XU I have setup with Debian Wheezy and a USRP B200.
After building the UHD drivers from source, I followed the "network from
scratch" page. I also configured and built osmo-trx with the
--with-neon-vfpv4 option. Things are running OK, a whole lot better than
my attempt with OpenBTS actually. I"m able to connect to the network
with my Samsung S4 phone, but after an hour or so of the BTS running, I
get a UHD recieved time out error (see below). I wonder what could be
causing this? I have the B200 plugged into the USB 3.0 port, along with
external power.
Thanks in advance for any help.
root@odroid-wheezy:~# osmo-trx
linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.007.002-94-ge56809a0
Config Settings
Log Level............... NOTICE
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Samples-per-Symbol...... 1
External Reference...... Disabled
C0 Filler Table......... Disabled
Diversity............... Disabled
Tuning offset........... 0
-- Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex... done
-- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200_fpga.bin...
done
-- Operating over USB 3.
-- Detecting internal GPSDO.... No GPSDO found
-- not found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz
-- Actually got clock rate 32.000000 MHz
-- Performing timer loopback test... pass
-- Asking for clock rate 26.000000 MHz
-- Actually got clock rate 26.000000 MHz
-- Performing timer loopback test... pass
-- Setting B200 1 SPS
-- Transceiver active with 1 channel(s)
ALERT 3030074464 23:06:10.4 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:10.5 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:10.6 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:10.7 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:10.8 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:10.9 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.0 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.1 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.2 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.3 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.4 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.5 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.6 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.7 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:11.9 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.0 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.1 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.2 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.3 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.4 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.5 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.6 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.7 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.8 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:12.9 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.0 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.1 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.2 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.3 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.4 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.5 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.6 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.7 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.8 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:13.9 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:14.0 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:14.1 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
ALERT 3030074464 23:06:14.2 UHDDevice.cpp:832:check_rx_md_err: UHD:
Receive timed out
terminate called after throwing an instance of 'uhd::assertion_error'
what(): AssertionError: accum_timeout < _timeout
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /root/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:232
I wrote a short post about using nanoBTS behind NAT and getting proper connection.
http://manatails.net/blog/2014/09/setting-arbitary-destination-ip-for-rtp-p…
As OpenBSC does not natively support NAT like Asterisk does, One needs to use a simple hack to manually tell the BSC about the connection information.
Regards,
Pierre
Hello, I've been working with my nanoBTS units again. But I've noticed some crashes while using GPRS data.
I am currently using the newest git repo for everything. And a nanoBTS 1900 and an iPhone.
Attached is the log of the crash. Please let me know if you need more information.
Regards,
Pierre
Dear Sir
I am trying to use the RRLP protocol implemented in openbsc, till now i am
able to send the rrlp request and activate the phone gps(ms-based mode) but
i am not getting any reply from the phone's side neither any location error
or any location. So please suggest me what to do in this case.
Thanks & Regards
Snehasish
Dear list,
It seems that after the last 2-3 weeks massive committing storm, I
lost the ability to compile an interworking version of
OpenBSC/Osmo-BTS/Osmo-PCU because the Osmo-PCU and the Osmo-BTS cannot
connect anymore.
According to the wiki, I need to use "jolly/multi-trx" for Osmo-Abis
and "jolly/trx" for Osmo-BTS, and "jolly/testing" with OpenBSC.
Previously this setup was working, but now Osmo-BTS tells the PCU
socket is not connected, while the PCU is running with the correct
config on the same PC.
I also wanted to try "201409-trx" branch (moved back to master with
osmo-abis and openbsc for this one, otherwise I got errors during the
configuration phase), but I got compilation errors with Osmo-BTS at
RSL.c
If someone can point me in the right direction which branches should I
use to get an interworking copy with a B200, that would be awesome. I
am also happy to try the new branch "201409-trx" if someone can tell
me which branches to use for that too.
Thanks!
Csaba