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
