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,
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,
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
This patch is the test suite modification for the fix encoding of
padding bits. New test vectors have been added both in downlink
and uplink.
---
tests/rlcmac/RLCMACTest.cpp | 7 +++++--
tests/rlcmac/RLCMACTest.ok | 32 ++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 2 deletions(-)
This patch is for fixing encoding of padding bits according to the
3gpp spec 44.060 section 11, wherein it shall always start with 0
bit followed with spare padding bits.
During introduction of basic EGPRS feature new hex dump messages
from a different working network log were used in Unit test. These
exposed the issue of incorrect handling of padding bits encoding
in osmo-pcu.
Corrections in the existing test vector of rlcmac is also updated.
In testsuite tbf appropriate corrections for the Tbftest.err is
also done.
---
src/csn1.cpp | 7 ++++++-
tests/rlcmac/RLCMACTest.cpp | 6 +++---
tests/rlcmac/RLCMACTest.ok | 18 +++++++++---------
tests/tbf/TbfTest.err | 18 +++++++++---------
4 files changed, 27 insertions(+), 22 deletions(-)
This patch is the test suite modification for the fix encoding of
padding bits. New test vectors have been added both in downlink
and uplink.
---
tests/rlcmac/RLCMACTest.cpp | 7 +++++--
tests/rlcmac/RLCMACTest.ok | 32 ++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 2 deletions(-)
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
---
TODO | 2 ++
1 file changed, 2 insertions(+)
diff --git a/TODO b/TODO
index a449398..97500c8 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,6 @@
* Make the TBF ul/dl list per BTS
+
+
* Make the SBA per BTS
* Make the tbf point to the BTS so we can kill plenty of parameters
* Group more into in classes.. remove bts pointers.
--
2.6.3
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
---
TODO | 1 +
1 file changed, 1 insertion(+)
diff --git a/TODO b/TODO
index a449398..b154940 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,4 @@
+
* Make the TBF ul/dl list per BTS
* Make the SBA per BTS
* Make the tbf point to the BTS so we can kill plenty of parameters
--
2.6.3
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
---
TODO | 1 +
1 file changed, 1 insertion(+)
diff --git a/TODO b/TODO
index a449398..b154940 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,4 @@
+
* Make the TBF ul/dl list per BTS
* Make the SBA per BTS
* Make the tbf point to the BTS so we can kill plenty of parameters
--
2.6.3
Hello,
We are starting to integrate and test NURAN L1 1.0 with osmo-bts / osmo-pcu at Radisys.
We downloaded latest osmo-bts master branch. When we checked the code, we see that NURAN specific code is present in osmo-bts/src/osmo-bts-litecell15. When we tried to compile osmo-bts/src/osmo-bts-litecell15 , we see the following error
nrw/litecell15/litecell15.h: No such file or directory
Let us know if these files are missing or we are missing some steps.
Thanks and regards
Prasad
This patch is for fixing encoding of padding bits according to the
3gpp spec 44.060 section 11, wherein it shall always start with 0
bit followed with spare padding bits.
During introduction of basic EGPRS feature new hex dump messages
from a different working network log were used in Unit test. These
exposed the issue of incorrect handling of padding bits encoding
in osmo-pcu.
Corrections in the existing test vector and new hex dump vectors
shall be submitted in a separate patch. If only this patch is
applied rlcmac testsuite will fail for few vectors.
---
src/csn1.cpp | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/csn1.cpp b/src/csn1.cpp
index 54cc411..82bf17f 100644
--- a/src/csn1.cpp
+++ b/src/csn1.cpp
@@ -2400,7 +2400,12 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector
guint8 bits_to_handle = remaining_bits_len%8;
if (bits_to_handle > 0)
{
- guint8 fl = filler&(0xff>>(8-bits_to_handle));
+ /* section 11 of 44.060
+ * The padding bits may be the 'null' string. Otherwise, the
+ * padding bits starts with bit '0', followed by 'spare padding'
+ * < padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ;
+ */
+ guint8 fl = filler&(0xff>>(8-bits_to_handle + 1));
bitvec_write_field(vector, writeIndex, fl, bits_to_handle);
LOGPC(DCSN1, LOGL_NOTICE, "%u|", fl);
remaining_bits_len -= bits_to_handle;
--
1.7.9.5
Hello All,
This mail is to highlight the necessity of the "[PATCH] Fix encoding of padding bits to start with 0 bit"
In the latest master osmo-pcu 0.2.752-173e, the identified bug in encoding of padding bits is generating incorrect Control message.
Example of an incorrect Packet Downlink Assignment message from the current TbfTest.err log is @ line number 3433
Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 0b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Incorrect encoding has resulted in the analyzer interpreting PFI present with value 21.
Whereas with the fix for encoding padding bits result is
Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 03 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
Output of the message analyzer(http://www.3gpp-message-analyser.com/) is attached in the mail.
Please review the patch and let us know procedure for a merge to master.
Regards
Saurabh
This patch is the test suite modification for the fix encoding of
padding bits. New test vectors have been added both in downlink
and uplink.
Correction in existing test vector is also done.
---
tests/rlcmac/RLCMACTest.cpp | 13 ++++++-----
tests/rlcmac/RLCMACTest.ok | 50 +++++++++++++++++++++++++++++++++++--------
2 files changed, 49 insertions(+), 14 deletions(-)
Dear all,
some of you may have already seen it on the RSS feed, on Twitter or on
planet.osmocom.org[1]: sysmocom has decided that we will re-release our
existing formerly sysmocom-internal User Manuals and VTY reference
manuals under GNU GFDL.
The hope is that with better documentation we can enable more people to
use Osmocom software more easily, leading to more adoption.
While those manuals are far from being complete or perfect, I had spent
a lot of time in February on further polishing them for the upcoming
public release. I do believe they provide a better stasting point than
what all of what we had in the wiki (whether old trac or new redmine).
The manuals are written in asciidoc[2], with the occasional use of
mscgen[3] and graphviz[4], which I believe together are a pretty good
set of tools to very efficiently and productively work on documentation,
whilst focussing on actual content and not on formatting/syntax like
when using docbook-xml or LaTeX.
The osmo-gsm-manuals.git repository is pulled by our jenkins
installation, which then builds the PDF manuals and pushes them to
http://ftp.osmocom.org/docs/latest/
I seriously do hope that we will receive improvements and extensions for
the manuals. As the asciidoc source is in yet another git repo, sending
patches is as easy as it gets. Holger always states nobody ever
contributes to manuals, and I would love to prove him wrong ;)
In terms of overlapping information in the wiki and in the manuals: I'm
in favor (and in the process) of removing outdated old wiki command line
reference and VTY reference sections, and simply referring to the
manuals instead.
Please do read through the manuals and do send patches, whether it's a
spelling fix, improved wording, adding missing information or fixing
actual technical mistakes.
In tems of further dccumentation improvements, Holger has volunteered to
ensure that the Doxygen API of libosmocore is also automatically
generated+pushed in a similar fashion to make it publicly web-visible.
I'd also encurage everyone to contribute patches to covert those parts
of libosmocore.git that don't hve doxygen annotation yet.
Thanks in advance!
Regards,
Harald
[1] http://projects.osmocom.org/news/47
[2] http://asciidoc.org/
[3] http://www.mcternan.me.uk/mscgen/
[4] http://www.graphviz.org/
--
- 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)
Hello All,
In the latest master, Unit test for TBF is failing. Please find the attached tests/testsuite.log with this mail.
I was working on resubmission of padding encoding patch wherein this failure was noticed.
Regards
Saurabh
Hello All,
We are currently working on providing the support of Fast Ack/Nack Reporting(FANR) feature in OsmoPCU.
We have Identified and listed major changes in OsmoPCU as below.
1) Introduction of new header types in UL/DL
a. Mainly due to presence of CES/P and PANI fields
2) Following Control Messages changes
a. Packet Downlink Assignment
b. Packet Uplink Assignment
c. EGPRS Packet Channel Request
3) MS Radio Capability
a. Extraction of Reduced Latency Capability
4) VTY interface changes to enable/disable the feature
5) Downlink PAN Handling
6) Uplink PAN Handling
7) RLC window modification
a. Introduction of state variable to manage REPORTED and UNREPORTED states in UL direction
b. Introduction of new state TENTATIVE_ACK in DL direction
8) TBF flow changes
9) Handling of Tentative Ack blocks during retransmission
Note: There may be impacts on osmo-bts. But the impacts has not been considered yet.
We plan to have a separate branch from master for this development.
Please let us know your valuable feedback.
Thanks,
Aravind Sirsikar
Hello All,
We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues
We have identified impacts to be in osmo-pcu, osmo-bts and osmocore
Main changes identified are
osmo-pcu:
* In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind
* Corresponding function prototypes due to change in data type
* 11 bit RACH handling in bts.cpp
* Changes in encoding.cpp to support immediate assignment with EGPRS allocation
osmocore:
* In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param"
* Function prototype changes
osmobts:
* Function prototype changes due to change in data type
Please let us know your valuable feedback.
We plan to have a separate branch from master for this development. Please let us know the procedure to do this.
Regards
Prasad
Hello,
Clarification required on Downlink window state GPRS_RLC_DL_BSN_RESEND in OSMO-PCU
Could you please let us know the significance of the state GPRS_RLC_DL_BSN_RESEND while handling downlink window.
Our understanding is that state GPRS_RLC_DL_BSN_RESEND is used in case of retransmission of UNACKED blocks, which can be done without having GPRS_RLC_DL_BSN_RESEND state.
Kindly let us know if we are missing something in our understanding. This will help us in enhancing the state variable handling in FANR (FAST ACK NACK REPORTING) feature.
We are planning to introduce new state (i.e GPRS_RLC_DL_BSN_TENTATIVE_ACK ) as part of FANR feature implementation.
Thanks & Regards,
Sangamesh
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
>
Thank you Neels!
The "logfile /tmp/foo" did gave an error message saying "unrecognized
option".
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
an idea of how to set up the testbed, but I do not know which of the nodes
I really need. Do you have any idea?
Regards
Terje Kristoffer Skow
2016-02-29 18:50 GMT+01:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>:
> Hey Terje,
>
> On Mon, Feb 29, 2016 at 12:46:30PM +0100, Terje Kristoffer Hybbestad Skow
> wrote:
> > Does this mailinglist also regard openGGSN?
>
> Yes, the Osmocom community has adopted maintenance of OpenGGSN, even
> though it
> wasn't written "here".
>
> > If so do I have some questions. I have problem setting it up correctly.
>
> To test the basic openggsn I used to do something like this:
>
>
> sudo -s
>
> LD_LIBRARY_PATH=/usr/local/lib ./git/openggsn/ggsn/ggsn -f -c
> ./localggsn.conf &
>
> ./git/openggsn/sgsnemu/sgsnemu --createif -l 127.0.0.1 -r 127.0.0.2
>
>
> With localggsn.conf as
>
> listen 127.0.0.2
> net 127.0.0.0/24
> pcodns1 8.8.8.8
> logfile /tmp/foo
>
>
> The above works on linux because it allows implicitly creating the
> 127.*.*.*
> interfaces. On other OSes, you'd have to create those first on one of your
> network interfaces.
>
> See http://git.osmocom.org/openggsn/tree/examples/ggsn.conf for more
> config
> options.
>
> I'd recommend to use wireshark to see what packets are transmitted back and
> forth, if you're not already doing that.
>
> I've "recently" implemented GTPhub, which relays GTP, e.g. through a NAT.
> If
> that's of interest too, call again, and I can give you an example config
> for
> testing sgsnemu -> gtphub -> openggsn, too.
>
> To actually relay data through the tunnel interface that is created, AFAIK
> you
> first need to send a Create PDP Context message to the GGSN. Maybe read
> http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c
> For testing real data, I used an actual sysmoBTS with a "special" SIM card
> instead of sgsnemu, because here in the lab that was easier... :P
>
> Hope to have helped :)
>
> ~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
>
Hello Max,
Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below
1. There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972
c. From above example difference in time is 48milliseconds or approx.. 10FN duration
2. For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
b. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6
Please let me know if these are known behavior in your integration environment ?
These time variations may have an impact on the poll response behavior from MS as well.
Regards
Saurabh
-----Original Message-----
From: Max [mailto:msuraev@sysmocom.de]
Sent: Thursday, February 25, 2016 3:58 PM
To: osmocom-net-gprs(a)lists.osmocom.org; Saurabh Sharan <Saurabh.Sharan(a)radisys.com>
Subject: PCU scheduling and PACCH timeout question
Hello.
I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests.
The debug output from RLCMAC layer and corresponding .pcap files are attached.
The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866
After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do.
There are several other occurrences like that in both log and pcap.
Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine?
--
Max Suraev <msuraev(a)sysmocom.de<mailto:msuraev@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