Hi,
I have pushed series of patches related to ARQ-2 support for EGPRS DL Retransmission. This patches have been reviewed earlier and
comments have been Addressed. These patches are tested and validated with NuRAN 1.0 hardware.
Below are the links to Gerrit review of each patches along with patch description.
1) https://gerrit.osmocom.org/#/c/332/ ==>Add data structure for ARQ-II in EGPRS DL.
2) https://gerrit.osmocom.org/#/c/333/ ==>Add Accessor functions for ARQ-II in EGPRS DL.
3) https://gerrit.osmocom.org/#/c/334/ ==>Modify DL tbf flow for ARQ-II in EGPRS DL Retx.
4) https://gerrit.osmocom.org/#/c/335/ ==>Add test cases to support ARQ-II for EGPRS DL Retx.
Above patches must be merged to master in the same order as mentioned above.
Thanks,
Aravind Sirsikar
Hi Holger,
> Holger Freyther: Looks good to me, approved
In http://git.osmocom.org/osmo-pcu, one of the 5 patches submitted for Gerrit review(MCS5-MCS9 support in EGPRS UL)has been
merged to master. As this patch is part of series of 5 patches it should be merged in below order.
1) Remove GMSK only check in EGPRS UL(Change-Id:I567acc012d8ad49681715f0104ba7e91625e1e7a)
2) Add Header Type2 support in EGPRS UL(Change-Id:Iac2422c8acbdcefe20aafbba6a4eb87c9893e3ba)
3) Add header type 1 support for EGPRS uplink(Change-Id:I13c250e2e07377982ac3f29745f3cffd4088552a)
4) Add test cases for Header Type 2 in EGPRS UL(Change-Id:I1dd46010065a6d6da21e8e45af71e6d5f649b0b0)
5) Add test cases for Header type1 in EGPRS UL(Change-Id:I21811bb126dbe151b0708a964d3143bc2fd52389)
Currently osmo-pcu build is failing since only patch 4 of the list above has been merged. Can you please let me know how to proceed over this?
Going forward it will be helpful for us if you can suggest how to number the patches of a series in Gerrit review.
Thanks,
Aravind Sirsikar
Hi,
Can you guide us to address issues we are currently facing about Gerrit process as listed below
1) Jenkins Build reports failure. Can you suggest the reason for this.
Because in our local branch the Unit test and build is successful.
2) Is there any specific process to resubmit patch after addressing the
review comments.
Thanks,
Aravind Sirsikar
Hello All,
We at Radisys have started working on EGPRS performance analysis and stability testing on NuRAN LiteCell 1.0. Below are the High level Items we have planned.
1) EGPRS Performance benchmarking analysis and optimization
2) CPU and Memory benchmarking and analysis
3) EGPRS multi user tests, Stability, Stress and Soak testing
We will keep sharing the relevant patches as well as bench marking report to the mailing list for seeking inputs and suggestion.
Thanks,
Aravind Sirsikar
Dear all,
Deater has been investigating which issues currently prevent us from
using GEA in OsmoSGSN. His mail has been sitting in my inbox too long,
and hence I'm forwarding his results here to the mailing list for
further discussion / follow-up.
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)
Hi.
Imagine following configuration:
- GSM network advertises GPRS capabilities in System Information messages
- It's not actually available (SGSN crashed, all the timeslots are
occupied by TCH etc)
What would be expected behavior for MS in this scenario?
Shall it switch to alternative network in hope of getting promised GPRS?
Shall it hang on the currently camped network providing voice/sms only?
Which spec(s) cover that? What could be decision factors for the MS? SIM
entries, some data in SI, some timeout somewhere, smth else?
--
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 Directors: Holger Freyther, Harald Welte
Hi All,
We are trying to cross compile and test latest osmo-pcu, osmo-bts, openbsc, osmo-sgsn , and ggsn. One issue we see with latest sysmobts-mgr
(Commit ed494443cc1e9732b43ef99cccf187d17ac931ef) on Nuran 1.0 is as below.
- PA is off
- Signal is very low
- No signal on slave.
With sysmobts-mgr preloaded(older commit version) on board, the setup works fine.
Please help us in resolving this issue seen in master branch of osmo-bts latest commit.
Regards
Prasad
Hi,
as discussed at OsmoDevCon and the mails from last week. The following list of projects have moved to use gerrit for codereview:
* libosmocore.git
* libosmo-abis.git
* libosmo-netif.git
* libosmo-sccp.git
* libsmpp34.git
* openbsc.git
* osmo-bts.git
* osmo-iuh.git
* osmo-pcu.git
* cellmgr-ng.git
* osmo-sip-connector.git
I have created this[1] page with the minimum to set-up gerrit as git-remote, register, configure the account and then hopefully the most frequently used comments.
kind regards
holger
[1] http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit
Hi All,
We have noticed that the PCU sends invalid block number to L1 in DSP leading to unexpected message warning in DSP "GsmL1_PhDataReq(1) : Unexpected burst (Invalid blockNumber) [2!=1, SAPI 21-21]]".
After an investigation, we observe that the 'pcu_rx_rts_req' function in pcu_l1_if.cpp receives invalid block number from BTS.
Looking at the BTS side, the calculation of L1SAP_FN2PTCCHBLOCK defined as '#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7)' does not seem to be valid for expected PTCCH block numbers B0, B1,B2,B3 defined in Table 6 in TS 05.02 version 8.11.0.
What do you think about re-define the calculation of the L1SAP_FN2PTCCHBLOCK?
Regards,
Minh-Quang Nguyen
Concepteur logiciel | Software designer GSM/Network
T. 418 914-7484 x2296 | 1 855 914-7484 | F. 418 914-9477
2150, Cyrille-Duquet, Québec (Québec) G1N 2G3 CANADA
minh-quang.nguyen(a)nutaq.com <mailto:minh-quang.nguyen@nutaq.com>
www.nutaq.com <http://www.nutaq.com/>
QUEBEC MONTREAL NEW YORK <http://www.nutaq.com/signature/nutaq_q_m_ny.jpg>
Facebook <http://www.facebook.com/pages/Nutaq-Innovation/351864938229900> Twitter <https://twitter.com/NutaqInnovation> LinkedIn <http://www.linkedin.com/company/Nutaq> YouTube <http://www.youtube.com/NutaqInnovation>
This series of patches supports Incremental redundency for EGPRS DL case.
These patches have been integration tested on Nuran 1.0 for EGPRS MCS 9 support
in DL. And in UL only MCS4 has been tested. The EGPRS testing has been done with
Browsing and Ping in DL with larger packet sizes(1500).
Aravind Sirsikar (4):
Add data structure for MCS change in Retx
Add Accessor functions for MCS change in Retx
Modify DL tbf flow for MCS change in Retx
Add test cases to support MCS change during Retx
src/gprs_coding_scheme.cpp | 36 ++++
src/gprs_coding_scheme.h | 27 ++-
src/gprs_ms.cpp | 5 +
src/gprs_ms.h | 1 +
src/rlc.h | 10 ++
src/tbf_dl.cpp | 41 +++--
tests/tbf/TbfTest.cpp | 224 +++++++++++++++++++++++++
tests/tbf/TbfTest.err | 397 ++++++++++++++++++++++++++++++++++++++++++++
tests/tbf/TbfTest.ok | 9 +
9 files changed, 737 insertions(+), 13 deletions(-)
--
1.7.9.5
Hi Harald,
Can you please let us know the commit version for osmo-pcu which has been verified for EGPRS functionality on Nuran 1.0 hardware.
We have been trying the latest commit 1aa75273025b033d17c1068369a7ba145d5c9f06 which does not work( no uplink data received yet).
Can you provide details of the hardware in which EGPRS functionality has been successfully verified.
Thanks,
Aravind Sirsikar
From: Max <msuraev(a)sysmocom.de>
Define automake variable for configure flags to be used while running
'make distcheck'. This should prevent additional vty tests from running
in readonly distcheck environment. Note: user can still break the build
by overriding this with DISTCHECK_CONFIGURE_FLAGS variable.
---
src/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/Makefile.am b/src/Makefile.am
index 6428bef..487ef1d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -19,6 +19,7 @@
#
AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGB_CFLAGS) $(LIBOSMOGSM_CFLAGS)
+AM_DISTCHECK_CONFIGURE_FLAGS="--enable-sysmocom-dsp=no"
if ENABLE_SYSMODSP
AM_CPPFLAGS += -DENABLE_SYSMODSP
--
2.8.1
Hello,
Thanks for your inputs. We are starting integration of NURAN 1.0 for CS , SMS and GPRS/ EGPRS. We would like to know the steps to bring up the board with all software elements .
We understand that osmo-bts/osmo-pcu and osmo-bsc will be cross compiled. As a first step we would like to know the details of cross compilation and tool chain to be used for osmo-bts / osmo-pcu and osmo-bsc .
Also in the test setup described at http://openbsc.osmocom.org/trac , we see that there are third party components like MSC , SGSN and GGSN mentioned. Let us know what components are used for sample integration test setup.
Regards
Prasad
-----Original Message-----
From: osmocom-net-gprs [mailto:osmocom-net-gprs-bounces@lists.osmocom.org] On Behalf Of Neels Hofmeyr
Sent: Monday, March 14, 2016 5:43 AM
To: Prasad Kaup <Prasad.Kaup(a)radisys.com>
Cc: osmocom-net-gprs(a)lists.osmocom.org; Yves Godin <Yves.Godin(a)nutaq.com>
Subject: Re: Regarding integration of NURAN L1 1.0
Hi Prasad,
AFAIK you need the header files with matching version number to your sysmoBTS's firmware version from http://git.sysmocom.de/sysmo-bts/layer1-api/
I'm a bit new on building osmo-bts myself, so I can't yet say precisely which ./configure options you need to pass; but do take a look at
./configure --help
Hope this helps...
~Neels
Hi again.
I'm still having problem really getting the sgsnemu and ggsn to talk to
each other. When I use 127.0.0.1 and 127.0.0.2 as the listen and remote for
the sgsnemu and 127.0.0.2 as listen and 127.0.0.0/24 as network in the ggsn
conf, the sgsnemu says "Received echo response Received create PDP context
response. IP address: 127.0.0.2" and then nothing happens. When using two
computers, one running ggsn and one sgsnemu with the ip-addresses as
192.168.1.14 and 192.168.1.11 respectively, the sgsnemu doesn't seem to get
connented. It prints out "idletime.tv_sec 3, idleTime.tv_usec 0" over and
over, and "Echo Request timed out". The picture attached is from wireshark
on the ggsn computer.
I lookt at the pcap you send and it looks like what I would like for my
setup.
You talk mentioned using symoBTS how much does it cost? And how long is a
delivery for it?
Regards
Terje Skow
2016-03-01 12:56 GMT+01:00 Terje Kristoffer Skow <terjeks(a)stud.ntnu.no>:
> Thank you very much!!
>
> I will have some work getting through this, but I recon I'll have some
> more questions later.
>
> Again thank you
>
> 2016-03-01 12:39 GMT+01:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>:
>
>> On Tue, Mar 01, 2016 at 11:12:01AM +0100, Terje Kristoffer Hybbestad Skow
>> wrote:
>> > The "logfile /tmp/foo" did gave an error message saying "unrecognized
>> > option".
>>
>> It seems the logfile option was added on 2014-03-23 with commit
>> 9c0ff4fafe4276396125a52c89d36967566fe08c. It may make sense if you build
>> your osmocom stack from the git sources to benefit from the latest fixes.
>>
>> See http://git.osmocom.org, specifically you'd probably want to clone
>> and build
>>
>> git://git.osmocom.org/libosmocore
>> git://git.osmocom.org/openggsn
>>
>> The build steps being for example
>>
>> autoreconf -fi
>> ./configure
>> make
>> sudo make install
>>
>>
>> > I'm going to look at DNS packets going through a GGSN to try and find
>> ways
>> > to detect DNS tunnels, do you have any recommendations how to do this?
>> > I do not have the time or resources to use real UE's so I hope to
>> simulate
>> > it on a computer using VMs or something like that.
>>
>> > I have looked at this:
>> http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS as
>>
>> The BTS is for communicating with a phone over the air interface. Abis and
>> osmo-nitb are used for voice calls only. The SGSN is needed for real
>> networks,
>> you should be fine with the sgsnemu. So all you need is sgsnemu and
>> openggsn.
>>
>> You want to figure out how to use the sgsnemu, starting with a route into
>> the
>> tunnel device that sgsnemu opens up. So you need to look at the 'ip route'
>> commands (if you're on linux). I guess you won't need VMs; granted, it
>> might
>> make it easier to avoid circular routes (to IP addresses that should only
>> be
>> seen on the GGSN side), but certainly not a necessary prerequisite.
>>
>> I tried to ping through the sgsnemu tunnel once but saw, as I mentioned,
>> that
>> the GGSN thwarts GTP messages without a proper context being created
>> first. It
>> shouldn't be too hard, but I haven't investigated further. So you'd want
>> to
>> understand the GTP Ctrl & User messages to setup a PGP context (TEIs and
>> stuff), and figure out how sgsnemu might make your life easier in that
>> regard.
>> You probably want to read ETSI 29.060 to figure out GTP:
>>
>> http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/03.19.00_60/ts_129…
>> You may find attached pcap file interesting (open in wireshark and note
>> that
>> the DNS queries are transmitted over GTP between SGSN and GGSN even though
>> wireshark tends to show only the DNS and src/dest enclosed in the GTP).
>> And again, you may look at
>> http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c
>> about simplistic code examples of composing a PGP context conversation.
>>
>> If you'd like any more answers to questions you didn't ask ;)
>> just give us a shout...
>>
>> ~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
>>
>
>
Parameters are added to the structure ph_rach_ind_param to
differentiate the type of RACH received from Layer 1. This is to
further support the 11 bit RACH.
---
include/osmocom/gsm/l1sap.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h
index 1af8ba8..d7bd172 100644
--- a/include/osmocom/gsm/l1sap.h
+++ b/include/osmocom/gsm/l1sap.h
@@ -44,12 +44,21 @@ struct ph_rach_req_param {
uint16_t offset; /*!< \brief Timing Offset */
};
+/*! \brief for PH_RA_IND burstType inforamtion */
+enum ph_burst_type {
+ GSM_L1_BURST_TYPE_ACCESS_0 = 4,
+ GSM_L1_BURST_TYPE_ACCESS_1,
+ GSM_L1_BURST_TYPE_ACCESS_2
+};
+
/*! \brief for PH-RANDOM_ACCESS.ind */
struct ph_rach_ind_param {
uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */
- uint8_t ra; /*!< \brief Random Access */
+ uint16_t ra; /*!< \brief Random Access */
uint8_t acc_delay; /*!< \brief Delay in bit periods */
uint32_t fn; /*!< \brief GSM Frame Number at time of RA */
+ uint8_t is_11bit; /*!< \brief no.of bits in RACH*/
+ enum ph_burst_type burst; /*!< \brief type of burst*/
};
/*! \brief for PH-[UNIT]DATA.{req,ind} | PH-RTS.ind */
--
2.5.0
Hi,
we are now running our own copy of patchwork at https://patchwork.osmocom.org. In addition to single patches this version can track series and has a REST API and git-pw client support. The system is currently subscribed to the GPRS, OpenBSC and OsmocomBB mailinglist.
The installation is running offlineimap every couple of minutes to fetch new mail, this means it can take some minutes for your comment or patch to be visible.
kind regards
holger
Hi guys,
Please, let me introduce myself.
My name is Manuel Munoz, Computer Scientist, looking for a topic for my
project/undergrad thesis at Universidad de Leon, Spain.
I am evaluating these days the possibility to do something interesting
which could be used as my project and also to put my bit for the OpenGGSN
project.
Some more about me.
I am 36, have been working for +10 years in IT (sysadmin, php developer,
plsql developer, datacenters...).
I can speak English and Spanish and hold a 3 years bachelor degree.
Not long ago I worked for two years for providers of 2G/3G network
monitoring systems, so I have some knowledge about those topics.
Also quite fluent in C, wireshark, unix scripting...
This weekend I have been doing a quick research and refreshing my mind
about both security and mobile networks, and also took a look to OpenGGSN
code.
Long story short, what about me implementing IPSec for GTP-C in OpenGGSN?
Do you think it could be useful? Feasible?
3GPP Protect GTP signalling messages by IPSec (
http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_14_Oslo/Docs/PDF/S3-00042…
)
3GPP Use IPSec to secure GTP messages (
http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_13_yokohama/docs/PDF/S3-0…
)
Maybe some other security-oriented feature you want to be implemented?
I would love to hear your thoughts!
Thanks for your time,
Manuel
> On 27 Mar 2016, at 16:30, Sylvain Munaut <246tnt(a)gmail.com> wrote:
>
>> this is now in place and the old domains are now using X509 certs of letsencrypt.
>
> Do you know if redmine supports going to HTTPS only (i.e. redir http
> to https). I changed the "protocol" to HTTPS in the admin panel but
> that had no effect afaict.
I don't know.
> I would prefer to be HTTPS only and also have the session cookie have
> the "Secure" flag (so they're never sent over plain HTTP)
I added:
proxy_set_header X-Forwarded-Ssl on;
to the nginx config in the hope that redmine makes use of that instead of the X-Forwarded-Proto. If it matters to you deeply we can make a general http -> https redirect.
holger
Hello,
We have planned to support 11 bit RACH in osmo-pcu and osmo-bts. In this regard, we have a query related to layer 1 to osmo-bts interface, as described below.
1. For 11 bit RACH, in PH-RA-IND sent from layer 1.
* Whether 'u8Size' will be 2 in case of 11 bit RACH ?
* What is the alignment of 11 bits inside 'u8Buffer ?
2. How osmo-bts can distinguish between types of 11 bit RACH based on received layer 1 message ? (spec 44.060 section 11.2.5a)
* is burst type GsmL1_BurstType_Access_0 equivalent to GPRS_8_BIT_RACH/ GPRS_11_BIT_RACH
* is burst type GsmL1_BurstType_Access_1 equivalent to EGPRS_8_PSK_11_BIT_RACH
* is burst type GsmL1_BurstType_Access_2 equivalent to EGPRS_NO_8_PSK_11_BIT_RACH
Regards
Bhargava Abhyankar
Hello,
In current master code base 5 different arrays are used for compression as described below,
* Two dimensional array is used to store terminating code words for 1's length code and 0's length code.
* Two dimensional array is used to keep size of each codeword
* Two dimensional array is used to store make up code words
* Two dimensional array is used to keep size of each codeword of makeup code words
* one array for each code word to return corresponding value for makeup code words
We are proposing following modification for above,
* Array of strings shall be used for 1's run length code word
* Array of strings shall be used for 0's run length code word
These two arrays will have code words of both terminating codes and make up codes together.
In this approach two trees (i.e ones list and zero list) shall be introduced and entire code word traversing shall be done in respective tree in single traversal.
With this approach we can avoid multiple array usage.
The above changes will be sent in my next patch
Regards,
Sangamesh
Dear Saurabh,
it would be nice if you could address the review comment of Harald for the padding patch and send it again. In terms of the commit message it would be interesting to know how you found it, if something broke because of it (e.g. if a specific Handset+Chipset+Firmware release broke). Such information is nicely captured in a commit message and might help future developers to prevent doing a revert or similar.
In terms of the EDGE support it is custom in Free Software projects to build on top of what is already present. I don't have a specific approach and there are multiple options but from what I see the situation is:
* You seem to have added additional encoding regression tests. It would be nice to move them to the master version and see if the result is similar/correct as well.
* Jacob has not implemented compressed bitmaps in the DL TBF handling. The reason is because we want to avoid bufferbloat our windows don't really get that big and it seems we didn't need it yet. Now that you have built a tree based encoder, it might make sense to include the encoder, add tests for the encoding, reason/explain the performance and then hook the encoding in the DL ACK handling.
* Any other corrections/fixes you have.
* Identify other areas where your support is behaving better than the code in master or features missing and implemented in your branch.
Do you already have an idea yourself how you intend to move forward and get your improvements included in the main repository?
kind regards
holger