Hello,
I want to use the local sims having different MNC/MCC for implementing GPRS
using osmocoms with OpenBTS same as I have used them for GSM calls and sms
using only openBTS. But your site
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently
not possible". As it is long when posted on this site so I want to ask is
it possible *now* to use the local sims? Hope you have understood my
question. Waiting for your reply. Thanks.
Regards,
Saba Arshad
Hello All,
We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )
A sample bitmap taken from a real mobile log is used for the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9
Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2
Target execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353
Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8
Regards
Prasad
Hello Max,
> What about MCS UL? Do you have some statistics which one has been used
The uplink tests have been completed for all EGPRS coding scheme (MCS1 - 9) using the ping or TCP download.
We have not conducted specific test for throughput estimation in uplink direction till now.
Regards
Saurabh
Hello,
We have completed first phase of performance test on EGPRS using iperf tool for short duration runs (1 to 3 hours).
Steady throughput of 215 to 223 kbps in Downlink has been achieved under lab conditions over the air test using one Huawei E398 dongle as UE.
PCU was configured for 4 PDTCH allocation.
Osmo-pcu is based on master branch plus Radisys code changes which are currently under Gerrit review.
The execution of test was done on NuRAN 1.0 hardware.
Below is a summary of test results
Test type MCS DL Duration Throughput(kbps)
Achieved Theoretical
TCP MCS9 1hour 217 236.8
UDP MCS9 3hour 223 236.8
Regards
Saurabh
Hi all.
I've noticed in osmo-bts logs several messages from L1:
238:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL)
243:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL)
246:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL)
251:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL)
254:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL)
260:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH TxDL)
263:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL)
274:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PDTCH RxUL)
Similarly, there are messages related to PTCCH:
257:<0006> oml.c:689 (bts=0,trx=0,ts=2,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL)
266:<0006> oml.c:689 (bts=0,trx=0,ts=3,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL)
277:<0006> oml.c:689 (bts=0,trx=0,ts=4,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL)
288:<0006> oml.c:689 (bts=0,trx=0,ts=7,ss=0) MPH-ACTIVATE.conf (PTCCH TxDL)
Notice that while PDTCH is activated for both UL and DL, the PTCCH is
only activated for DL.
As far as I've understood continuous TA procedure I've got to have PTCCH
activated in both directions. The problem is that I have troubles
locating the code which triggers the activation above.
There is l1if_connect_pdch() in osmo-pcu src/sysmo_l1_if.c but it uses
GsmL1_PrimId_MphConnectReq while if I understood correctly
GsmL1_PrimId_MphActivateReq is necessary for channel activation. There
is mph_send_activate_req() in osmo-bts oml.c which uses it. It's called
from lchan_act_compl_cb() via sapi_queue_send() which is also in
mph_send_activate_req() - I have hard time understanding how this works
at all. Do we have this documented somewhere?
--
Max Suraev <msuraev(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 Director: Harald Welte
Hi.
While looking at http://projects.osmocom.org/issues/1616 I've noticed
that there seems to be no particular function which get signal quality
info from dsp. At least looking at code around ENABLE_DIRECT_PHY have
not enlightened me so far.
The question is - how exactly signal quality is obtained from dsp (on hw
with direct dsp access) to osmo-pcu. There is clear difference between
l1if_pdch_req() and pcu_tx_data_req() on TX path but what's the
equivalent for RX?
--
Max Suraev <msuraev(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 Director: Harald Welte
Hi.
While working on https://osmocom.org/issues/1531 I've found that I have
to update BTS's configuration (see src/bts.cpp) from osmo-pcu L1 code
(see src/osmo-bts-sysmo/sysmo_l1_hw.c). The problem is that the only
thing I got in L1 is struct femtol1_hdl which have trx_no but that's
about it.
Is there a way to get pointer to BTS so I can call bts->set_ta() using
trx_no? Or I shall somehow change interface for l1if_fd_cb() - that's
where my function with new data is called from?
--
Max Suraev <msuraev(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 Director: Harald Welte
Good Morning all,
my real life distraction is mostly gone and I can be more active in developing and reviewing again. From my point of view Sysmocom and me have responded to all Gerrit reviews and we are waiting for the next iteration of the patchset. Before giving a high-level point of view of orders and dependencies I would like to say some words about testing.
(Automatic Unit-)testing is crucial. Sometimes it is the easiest way to test a behavior, it allows to hit/test error paths but are hit less frequently. Combined with regular execution of the tests and forbidding to merge code that breaks tests, features that worked once and have a good test will continue to work. It is the key for being able to move forward quickly.
For many patches I reviewed test + feature or test + bugfix were in separate commits and then the order is problematic. From my point of view there are only a few "right" combinations. Let me try to explain:
Assume some code is doing "if (res) " instead of "if (!res)" and after long debugging we have found that single line (and our code is full of printf now) and it is a path that has not been systematically tested yet. To move forward and create a patchset we should:
* Add a test case that triggers the broken behavior. With a xUnit framework we would add an expected failure, with our approach we either capture the broken output, comment the OSMO_ASSERT or revert the OSMO_ASSERT condition.
(See libosmocore
* Let's say that if is already in code like:
if (a)
if (b)
if (c)
if (d)
and we would like to re-factor it to be more readable. Then please do the refactoring _before_ applying the bugfix. The test output/result should not change as it is a refactoring.
* Finally apply the fix. For bugfixes try to make them as small and clear as possible. Let's say even if you don't like the algorithm used, fix it. As part of the fix the test assertions can be enabled and the output change. The smaller the fix, the better. See libosmocore 6ac70a41ee4cc9f3f286fb6b8f397215590fc2ac for such an example.
* If the algorithm is indeed bad now is the time to change it. It should just change the (refactored) method, test output and result should be stable and maybe add more tests as the new code is easier to test.
In general my preferred way:
New feature => one commit to add feature + test
Bugfix => First test, then bugfix+test output/result update
thank you
holger
Hi guys,
maybe a short summary helps to see where we are and where we need to go. Let me start with myself.
Besides reviewing code I have two GPRS related topics I want to look at. The first one is the missing state transition for single phase access to avoid having to revert, the second one is to use perf to look at the performance difference of the two compressed bitmap routines.
The bigger picture is that we have some features that work in parallel and the right order might be important to unlock them. My review/merging priority right now is:
* 11bit RACH decoding:
** Get the libosmocore change in. As 0x0 is used as a value it needs to be inside the enum
** PCU protocol change to transport this access burst type and update to uint16_t
** OpenBSC change to allow 11bit burst access
** PCU change
* T4 compression/decompression:
I am not sold on the look-up tree yet but I understand that for good compression the API in libosmocore needs to change.
a.) We remove T4 support from libosmocore as it is not used outside of the PCU and this gives us a way to mature the API without having to synchronize two projects
b.) We know which out variables we need to add and can define the API
The implementation (unrolled loop vs. tree) can be decided at a later point as we can hide it from the interface.
* Changing coding schemes on re-transmission/etc. These are features and fixes that only relate to the PCU. I can merge whatever patchset is ready first.
kind regards and looking forward to rebased patchsets
holger
Hi,
Currently i am working in LTE and would like to test SGW and PDN-GW along
with GTP protocol for my research aspect. I have already worked and used
OpenairInterface EPC. But, i wanted to explore other kernel or user-space
options of GTP.
Please let me know the procedure to access the code of ,
(i) Latest mainline linux kernel version with your GTP code and user space
GTP module.
(ii) Also, could you please kindly provide me access to the SGW/GGSN and
PGW codes.
Please kindly provide me access to the latest code, such that i could test
it and will even post the test results to the community.
Thanks & Regards
Vasu.
