Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
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,
I suggest to change a stock Redmine theme to something more beautiful,
for example gitmike: https://github.com/makotokw/redmine-theme-gitmike
which used by srlabs.de and looks like pretty. Furthermore, the Osmocom
logo will look better on light background.
Opinions?
С наилучшими пожеланиями,
Яницкий Вадим.
Hi,
Is it possible to have the virtual BTS start a location update at a specific time. In other words, can I add a command that asks all phones to request a location update at any desired time ?
Best regards,
Robert,
Hi list,
I've just seen my first Location Update Accept from our UMTS UE+femtoCell
using osmo-cscn as IuCS network core :D
The Identity Request (IMSI) that the UE used to not answer is now being
answered, and I am getting a successful Location Update Accept from
osmo-cscn after that.
The reason why it didn't work last time isn't entirely clear. All I
changed since is the *test* program that simulates the UE+hNodeB, and I
merely verified that osmo-cscn works (as far as LU is concerned).
A hint is, Daniel told me that the IuPS setup had one day stopped to reply
with a message that used to work before, and has since again started
working. So it might've been a timing issue in the reply towards UE.
Next steps:
Next I will briefly try to run Daniel's 3G SGSN together with CSCN to see
whether the premature Iu Release (?) he sees still happens when CS is
connected successfully.
There is also still a segfault in osmo-hnbgw, triggered by reconnecting a
second time with our hnb-test that simulates an hNodeB. That's next on the
hacking todo list.
According to the specs, proper Authentication is mandatory for UMTS, which
osmo-cscn should initiate. That's not happening yet. It seems our testing
UE is fine with that, so I'll see when I'll get to that.
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi list,
I just thought I had fixed gsm_7bit_decode_n(), since its API doc says
* \param length The length of the input sequence (in octets).
int gsm_7bit_decode_n([...], uint8_t length);
but the implementation is
int gsm_7bit_decode_n([...], uint8_t septet_l)
and indeed the length parameter is handled as septet length. So, logically, I
came up with this patch:
diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c
index e8e452f..a9afc1a 100644
--- a/src/gsm/gsm_utils.c
+++ b/src/gsm/gsm_utils.c
@@ -184,8 +184,9 @@
return text - text_buf_begin;
}
-int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t septet_l)
+int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t octet_l)
{
+ uint8_t septet_l = ((uint16_t)octet_l * 8) / 7;
return gsm_7bit_decode_n_hdr(text, n, user_data, septet_l, 0);
}
(the cast to uint16_t makes 100% sure the calculation isn't truncated to
uint8_t after the *8 multiplication -- I picked this up while hacking on 8bit
microcontrollers. That truncation doesn't really happen on our 32bit/64bit
machines, but if it did, the length would effectively be limited to 255/8 == 31
characters.)
Then I noticed that callers actually do *8/7 before calling the function:
parse_process_uss_req():
num_chars = (uss_req_data[6] * 8) / 7;
/* Prevent a mobile-originated buffer-overrun! */
if (num_chars > MAX_LEN_USSD_STRING)
num_chars = MAX_LEN_USSD_STRING;
gsm_7bit_decode_n_ussd((char *)req->ussd_text,
sizeof(req->ussd_text),
&(uss_req_data[7]), num_chars);
(This is gsm_7bit_decode_n_ussd(), its API doc says "see gsm_7bit_decode_n()")
So we have the API talking about length "in octets" while the implementation
clearly employs septet length.
Fixing the implementation to match the API doc would break binary
compatibility. I should probably fix the API doc to match that weird
implementation, but it nags and hurts a little.
Any opinions?
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I am looking into building a very simple MNCC to SIP bridge to be used with the NITB (and later the CSCN). This will be based on what was learned from adding the RTP bridge which means the audio will not flow through the bridge (eventually later there will be a UDP proxy for NAT traversal)
The primary design points are:
* Being able to select TCH/F or TCH/H
* Decide on the codec very late
* Support for AMR parameters through MNCC
I just look at MO and MT Call establishment from a high-level point of view:
MO-Call:
* NITB will send the SETUP indication
* MNCC GW will do screening and decide if to proceed
* MNCC GW will make TCH/F or TCH/H decision and ask for a source IP, source port
* Based on bearer caps (to be handled by MNCC GW?) and TCH/F, TCH/H MNCC GW can offer a SDP file with multiple codecs to the PBX.
...
* PBX will decide on a codec (ringing or 200 connect)
* MNCC GW will ask NITB to reconfigure and audio will flow
* (TODO: check ringtone, check default, check codec change)
MT-Call:
* MNCC GW will be presented with a list of codecs already
* Depending on that TCH/F or TCH/H can/must be chosen (e.g. for AMR even the codec rate can be in the SDP file that decides which TCH/F or TCH/H to use)
* Can decide bearer caps once paging has succeeded and call is progressing
* Sets audio codec and waits for call to connect
Handover support:
* IP/port (and then SSRC and timestamp in RTP) will change
* MNCC GW could try SIP re-invite with changed parameters
* MMCC GW could hope PBX implements RTP annex and re-learns the connection
Do you have comments or remarks? The above will lead to a version update, probably a dedicated assignment command in MNCC, and separating socket creation and codec change. Anyone wants to have a go at that?
have a nice weekend
holger