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
This is the last out-of-tree patch that we're still using to package
OpenBSC in Rhizomatica. Adding SMPP support in the Debian packages
shouldn't be an issue, right?
Cheers
Ciaby
Hi all,
Attached is a patch for the openbsc which extends meas_feed with
channel information - type and id (bts/trx/ts/ss). This is used by the
web incarnation of meas_vis utility we wrote [1]. Originally it was a
pure copy of the original meas_vis, but when we deployed it at
Rhizomatica, they suggested it would be more useful if the channel
information is displayed.
It would be great to see this patch merged to master.
When/if this is merged, I'll submit a patch with meas_json utility
which listens on the meas_feed socket and converts it to JSON format
digestible by web tools. This JSON is what meas_web uses as a data
feed.
[1] https://github.com/fairwaves/meas_web
PS Apologies for attaching the patch instead of inlining it. GMail
would ruin it.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Hi Folks,
At present endpoint IDs are assumed to end with @mgw when trying to find/match non-e1 endpoint ids. Unless the MGCP peer supports compatible configuration, DNS or a hosts file may need to be setup to meet the hardwired host name requirement in the openBsc MGCP, and then we can still only run one BSC.
The attached patch makes a simple change to use either the configured local_ip or source_addr, matching logic used in SDP responses. It also improves the error message when an endpoint can't be found.
Please consider for inclusion to mainline.
Kind Regards,
Mike
Hello.
I have a problem with my sysmoBTS. When I start the bts I receive a BOOTME
message. So after identify in the SysmoBTS Manual the problem like broken
UBL, I tried to follow the manual using the dvnixload utility. I installed
the binutils-multiarch package and others neccesary for the execution of
the divnixload, but during the proccess I get an error:
root@ubun-osmo:/home/osmo-user/Documentos# ./dvnixload -p /dev/ttyUSB0
ubl-sysmobts-v2.elf u-boot-sysmobts-v2.elf
dvnixload info: Using cross compiler ""
dvnixload info: Expecting messages: [BOOTME] [BOOTPSP] [I_ME]
dvnixload info: [BOOTME] received
dvnixload error: Entry point not found
dvnixload error: Entry point not found
Do someone know why I get an "Entry point not found" message and how I can
fix it?
Thank you so much!!
Hi all,
I'm developing gr-gsm - the ancestor of Airprobe's gsm-receiver. I want
to add support for 8-PSK reception. I'm going to implement a demodulator
(preferably doing also channel equalization) and also modulator
(currently mostly to generate test data).
I don't want to duplicate work that was already done so I want to ask if
you are aware of any publicly available 8-PSK implementations (or
partial implementations) aimed at supporting EDGE reception? Also I will
greatly appreciate pointing to any documents containing good information
on this topic.
--
Best Regards,
Piotr Krysik
Hi Holger,
I added libosmocore commit 7c942ba1475a366cc7c8a129fbdd335166ce21c6
during the camp as at the simtrace/osmocombb/openbsc workshop, several
participants could not build the respective software packages.
This behavior was observed by Kevin and me, and adding subdir-objects
resolved the problem. Due to the hectic nature of a workshop where
everyone is waiting for the build to succeed on the system of all
participants we did not have time to record the specific distribution
versions at that time.
On Debian unstable with autoconf 2.50 / automake 1.15, the build
generates the following warnings:
===============
src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c' is in a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
===============
The project still builds afterwards on this Debian system, so indeed it
is just a warning. However, the warning quite clearly indicates that
the use of subdir-objects is not optional in the future!
So I'm not sure your revert of the assciated commit is the right way to
proceed.
The point seems to be that 'make distclean' wants to remove the
generated objects for the tests, but the latter only are compiled when
'make check' is used, but not in the default build.
Any ideas?
--
- 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)
From: Pablo Neira Ayuso <pablo(a)netfilter.org>
The following patchset, although it looks a bit large, it is composed of many
small incremental changes to improve the existing osmux infrastructure and to
add dummy padding support.
The dummy padding consists of a osmux header and payload that looks like this:
OSMUX seq=000 ccid=002 ft=2 ctr=3 amr_f=0 amr_q=0 amr_ft=03 amr_cmr=00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ]
The frame type is OSMUX_FT_DUMMY (=2) in the batch that whose payload is
padded with 0xff. Note that the message above is padding the circuit ID 2.
This is used for early bandwidth preallocation in links that involve relatively
slow dynamic bandwidth allocation such as Iridium/OpenPort.
The osmux test infrastructure has been improved (to resolve some memleaks) and
enhanced to cover this new dummy support.
The OpenBSC changeset is composed of one very small patch that will come after
this batch.
If no major concerns, I'll push this initial batch soon into the repository.
Thanks.
Pablo Neira Ayuso (18):
osmux: discard non voice osmux message
osmux: add osmux_input_state structure
osmux: add circuit helper functions
osmux: rename struct batch_list_node to osmux_circuit
osmux: rename circuit->list to circuit->rtp_list
osmux: pass up struct osmux_batch
osmux: count pending messages to be transformed in the batch
osmux: introduce osmux_xfrm_input_close_circuit()
osmux: introduce osmux_xfrm_input_open_circuit()
tests: osmux: adapt it to use the new circuit API
tests: osmux: factor out main test loop
tests: osmux: test online deactivation of dummy padding
tests: osmux: validate dummy padding with no voice data interaction
tests: osmux: test circuit reopening after closure
osmux: kill osmux_get_hdr()
tests: osmux: fix msgb leaks
tests: compile tests with debugging symbols, ie. -g
tests: osmux: iterate 64 times in osmo_test_loop()
include/osmocom/netif/osmux.h | 8 +-
src/osmux.c | 374 ++++++++++++++++++++++++++---------------
tests/Makefile.am | 2 +-
tests/osmux/osmux_test.c | 80 ++++++---
4 files changed, 304 insertions(+), 160 deletions(-)
--
1.7.10.4
Dear Sir
As we know that mnc 01 and 1 are different for GSM.
In config file even on providing MCC 001 and mnc 01 its flashes mcc as 1
and mnc as 1.
How to get over from this issue and get the network as 001-01 instead of
1-1.
Regards.
Ravi
Hi list,
I've installed omsocom for the first time on a USRP B200 and I'm interested
in trying out the GPRS stack. I've followed a few pages on the wiki, namely
http://openbsc.osmocom.org/trac/wiki/network_from_scratch and
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS to get set up and I am
not sure how up to date these tutorials are. I have calls working via the
LCR, but I cannot get GPRS functioning. I see no activity on the BSC log
when attempting GPRS attach using APN openbsc. I also see no traffic
between the SGSN and the BSC (listening with tshark on 127.0.0.1:23000).
Any help is appreciated.
I am currently using osmo-trx/master, osmo-bsc/jolly/testing,
libosmo-abis/jolly/multi-trx, omso-bts/jolly/trx, openggsn/master, and
osmo-pcu/master.
Best,
Omar