From Saurabh.Sharan at radisys.com  Tue Mar  1 07:05:13 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Tue, 1 Mar 2016 07:05:13 +0000
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <040E1C04-E6BE-4917-B541-55F011401029@freyther.de>
References: <56CED717.9060409@sysmocom.de>
 <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
 <56D0863B.1000401@sysmocom.de>
 <BY1PR08MB1308A7DA171754683E5937F285A70@BY1PR08MB1308.namprd08.prod.outlook.com>
 <040E1C04-E6BE-4917-B541-55F011401029@freyther.de>
Message-ID: <BY1PR08MB13085C95A35C1A521ECC1F6985BB0@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello Holger,

The extraction was done manually from wireshark capture file. I have not created any script for this.

Steps were

*         Set time display format in wireshark capture for microseconds and from beginning of capture

*         Filter the log for TS 4 (control TS was chosen) and direction downlink ((gsmtap.uplink == 0) && (gsmtap.ts == 4))

*         Keep column display for GSM Frame Number in the wireshark capture

*         After this Print "output to file" utility in wireshark for "as displayed" converts the displayed capture into text

*         Copy entire text and delimit with whitespace in an excel sheet

*         Add formula for time difference and frame number difference between previous to next row (for time difference multiply by 1000 to get milliseconds)

*         These new rows will serve as further elements for plot and analysis



Regards

Saurabh



-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de]
Sent: Monday, February 29, 2016 11:22 PM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: Max <msuraev at sysmocom.de>; osmocom-net-gprs at lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question





> On 26 Feb 2016, at 21:23, Saurabh Sharan <Saurabh.Sharan at radisys.com<mailto:Saurabh.Sharan at radisys.com>> wrote:

>

> Hello Max,



Dear Saurabh,





> Please find below chart that indicate time skew is happening in the setup.

> I have also attached the excel sheet used for this analysis here for reference.

> TS4 in downlink is considered for drawing the plot. Please note that block duration value of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of 4,4,5,4,4,5,..and so on.

> 4FN duration is 18.4ms and 5 FN is 23 ms approx.

> But the spikes in the system as high as 26.8ms may result in incorrect air interface behavior from L1.



how did you extract the values? Did you create a lua script for wireshark/tshark? It would be interesting to automate this.



kind regards

                holger


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160301/53ba89a2/attachment.htm>

From terjeks at stud.ntnu.no  Tue Mar  1 10:12:01 2016
From: terjeks at stud.ntnu.no (Terje Kristoffer Hybbestad Skow)
Date: Tue, 1 Mar 2016 11:12:01 +0100
Subject: OpenGGSN
In-Reply-To: <27920679945c4c37bad3e563b12d0b06@AM2PR05MB0675.eurprd05.prod.outlook.com>
References: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>
 <27920679945c4c37bad3e563b12d0b06@AM2PR05MB0675.eurprd05.prod.outlook.com>
Message-ID: <CAK6q=udLSVw3Bzk-SaRRaMv2hF_zZWTdgqC5wtaXVAuM0Kj02Q@mail.gmail.com>

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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160301/5821e0c5/attachment.htm>

From nhofmeyr at sysmocom.de  Tue Mar  1 11:39:25 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 1 Mar 2016 12:39:25 +0100
Subject: OpenGGSN
In-Reply-To: <CAK6q=udLSVw3Bzk-SaRRaMv2hF_zZWTdgqC5wtaXVAuM0Kj02Q@mail.gmail.com>
References: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>
 <27920679945c4c37bad3e563b12d0b06@AM2PR05MB0675.eurprd05.prod.outlook.com>
 <CAK6q=udLSVw3Bzk-SaRRaMv2hF_zZWTdgqC5wtaXVAuM0Kj02Q@mail.gmail.com>
Message-ID: <20160301113925.GA1178@dub6>

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_129060v031900p.pdf
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace3.pcapng
Type: application/octet-stream
Size: 6048 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160301/f9257d8f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160301/f9257d8f/attachment.bin>

From terjeks at stud.ntnu.no  Tue Mar  1 11:56:00 2016
From: terjeks at stud.ntnu.no (Terje Kristoffer Hybbestad Skow)
Date: Tue, 1 Mar 2016 12:56:00 +0100
Subject: OpenGGSN
In-Reply-To: <5395e2e5606d4550a1133320e9112771@AM2PR05MB0675.eurprd05.prod.outlook.com>
References: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>
 <27920679945c4c37bad3e563b12d0b06@AM2PR05MB0675.eurprd05.prod.outlook.com>
 <CAK6q=udLSVw3Bzk-SaRRaMv2hF_zZWTdgqC5wtaXVAuM0Kj02Q@mail.gmail.com>
 <5395e2e5606d4550a1133320e9112771@AM2PR05MB0675.eurprd05.prod.outlook.com>
Message-ID: <CAK6q=ufyYr_nvDP=SNqpNWbBAgi6Y++b8jYknHLOAVRN0XApBg@mail.gmail.com>

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 at 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_129060v031900p.pdf
> 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160301/007077bf/attachment.htm>

From holger at freyther.de  Wed Mar  2 19:14:05 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 2 Mar 2016 20:14:05 +0100
Subject: Padding patch and moving forward with EGPRS support/merge
Message-ID: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>

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



From Sangamesh.Sajjan at radisys.com  Thu Mar  3 07:42:13 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Thu, 3 Mar 2016 07:42:13 +0000
Subject: Clarification on downlink window state variable
Message-ID: <BLUPR08MB7113314B1EB0EB2EF08994788BD0@BLUPR08MB711.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160303/6870c3ea/attachment.htm>

From Saurabh.Sharan at radisys.com  Thu Mar  3 12:31:48 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Thu, 3 Mar 2016 12:31:48 +0000
Subject: [osmo-pcu 0.2.749-22d7] testsuite: 3 failed
Message-ID: <BY1PR08MB1308CDFF663A64856D216FDF85BD0@BY1PR08MB1308.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160303/6795d4a3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testsuite.log
Type: application/octet-stream
Size: 59053 bytes
Desc: testsuite.log
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160303/6795d4a3/attachment.obj>

From holger at freyther.de  Thu Mar  3 13:04:43 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 3 Mar 2016 14:04:43 +0100
Subject: [osmo-pcu 0.2.749-22d7] testsuite: 3 failed
In-Reply-To: <BY1PR08MB1308CDFF663A64856D216FDF85BD0@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <BY1PR08MB1308CDFF663A64856D216FDF85BD0@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <4E000755-19EC-4284-B7C9-8413E4CA27D1@freyther.de>


> On 03 Mar 2016, at 13:31, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello All,

Hi!


> 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.

yes, I had hoped for Max to notice and fix it. The Coverity tool has noticed a copy-and-paste error and I assume he needs to update the expected test result. I will have a look at it tonight.

holger

From jacob01 at gmx.net  Thu Mar  3 13:40:20 2016
From: jacob01 at gmx.net (Jacob Erlbeck)
Date: Thu, 3 Mar 2016 14:40:20 +0100
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
Message-ID: <56D83EC4.9010802@gmx.net>

Hi,

On 02.03.2016 20:14, Holger Freyther wrote:
> * Jacob has not implemented compressed bitmaps in the DL TBF handling.

More precisely, compressed bitmaps (decoding) are supported for DL TBFs
only, since it is required to decode them DL Ack/Nack if the window size
is increased which makes sense with multiple PDCH.

> 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.

The reason for not implementing them for UL TBF ACK yet was the fact
that we only support single slot only in that direction and that the
imposed restriction won't probably hurt in most cases. We can still send
URBB even if the window size were larger than 96, so there are only some
cases with long runs of NACKs and very few ACKs which might suffer from
a slightly increased latency.

> 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.

-> UL TBF ACK handling

Jacob



From Prasad.Kaup at radisys.com  Thu Mar  3 14:53:05 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Thu, 3 Mar 2016 14:53:05 +0000
Subject: Support of 11 bit RACH support in osmoPCU
In-Reply-To: <56D06FE7.6010209@gmx.net>
References: <BN3PR08MB12376E3DB78EBF28B50F23C2E6A70@BN3PR08MB1237.namprd08.prod.outlook.com>
 <56D06FE7.6010209@gmx.net>
Message-ID: <BN3PR08MB1237764D4CF3A690427955ECE6BD0@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello  Jacob,
	I am thinking that for EGPRS,  osmo-bts must be able to distinguish by TSC or by any other means (by L1 message?)  and inform osmo-pcu in a modified  gsm_pcu_if_rach_ind to indicate that it is for EGPRS. Please   let me know your comments.

Regards
Prasad

-----Original Message-----
From: Jacob Erlbeck [mailto:jacob01 at gmx.net] 
Sent: Friday, February 26, 2016 9:02 PM
To: Prasad Kaup <Prasad.Kaup at radisys.com>; osmocom-net-gprs at lists.osmocom.org
Subject: Re: Support of 11 bit RACH support in osmoPCU

Hello Prasad

On 26.02.2016 13:46, Prasad Kaup wrote:

> 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/

Are you also planning to add the TSC being used which would be needed for EGPRS as well?

Regards

Jacob


From Arvind.Sirsikar at radisys.com  Thu Mar  3 15:09:49 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Thu, 3 Mar 2016 15:09:49 +0000
Subject: Support of Fast Ack/Nack reporting in osmoPCU
Message-ID: <BN3PR08MB1173D80B697D018443FBDEFBF0BD0@BN3PR08MB1173.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160303/f0c87dfa/attachment.htm>

From msuraev at sysmocom.de  Thu Mar  3 17:17:53 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 3 Mar 2016 18:17:53 +0100
Subject: [osmo-pcu 0.2.749-22d7] testsuite: 3 failed
In-Reply-To: <4E000755-19EC-4284-B7C9-8413E4CA27D1@freyther.de>
References: <BY1PR08MB1308CDFF663A64856D216FDF85BD0@BY1PR08MB1308.namprd08.prod.outlook.com>
 <4E000755-19EC-4284-B7C9-8413E4CA27D1@freyther.de>
Message-ID: <56D871C1.1050104@sysmocom.de>

Yes, the test failure is due to additional logging introduced in
22d7e75e1f160e5337140d9f3dcb2679b621b646.
I was planning to fix it alongside with additional feedback I've got for
this commit but it got postponed due to other tasks.

On 03/03/2016 02:04 PM, Holger Freyther wrote:
>> On 03 Mar 2016, at 13:31, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
>>
>> Hello All,
> Hi!
>
>
>> 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.
> yes, I had hoped for Max to notice and fix it. The Coverity tool has noticed a copy-and-paste error and I assume he needs to update the expected test result. I will have a look at it tonight.
>
> holger

-- 
Max Suraev <msuraev at 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 



From msuraev at sysmocom.de  Thu Mar  3 17:36:31 2016
From: msuraev at sysmocom.de (msuraev at sysmocom.de)
Date: Thu,  3 Mar 2016 18:36:31 +0100
Subject: [PATCH] Add constructors to gprs_rlc_v_b and gprs_rlc_v_n
Message-ID: <1457026591-11687-1-git-send-email-msuraev@sysmocom.de>

From: Max <msuraev at sysmocom.de>

Fixes: Coverity: CID 1351738, 1351737
---
 src/rlc.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/rlc.h b/src/rlc.h
index 54f28df..93f0399 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -143,8 +143,7 @@ struct gprs_rlc_v_b {
 	void mark_invalid(int bsn);
 
 	void reset();
-
-
+	gprs_rlc_v_b();
 private:
 	bool is_state(int bsn, const gprs_rlc_dl_bsn_state state) const;
 	void mark(int bsn, const gprs_rlc_dl_bsn_state state);
@@ -216,6 +215,7 @@ struct gprs_rlc_v_n {
 	bool is_received(int bsn) const;
 
 	gprs_rlc_ul_bsn_state state(int bsn) const;
+	gprs_rlc_v_n();
 private:
 	bool is_state(int bsn, const gprs_rlc_ul_bsn_state state) const;
 	void mark(int bsn, const gprs_rlc_ul_bsn_state state);
@@ -490,6 +490,16 @@ inline const int16_t gprs_rlc_dl_window::distance() const
 	return (m_v_s - m_v_a) & mod_sns();
 }
 
+inline gprs_rlc_v_b::gprs_rlc_v_b()
+{
+	reset();
+}
+
+inline gprs_rlc_v_n::gprs_rlc_v_n()
+{
+	reset();
+}
+
 inline gprs_rlc_ul_window::gprs_rlc_ul_window()
 	: m_v_r(0)
 	, m_v_q(0)
-- 
2.7.2



From holger at freyther.de  Fri Mar  4 17:04:31 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 4 Mar 2016 18:04:31 +0100
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <56D83EC4.9010802@gmx.net>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net>
Message-ID: <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>


> On 03 Mar 2016, at 14:40, Jacob Erlbeck <jacob01 at gmx.net> wrote:
> 
> Hi,
> 
> On 02.03.2016 20:14, Holger Freyther wrote:
>> * Jacob has not implemented compressed bitmaps in the DL TBF handling.
> 
> More precisely, compressed bitmaps (decoding) are supported for DL TBFs
> only, since it is required to decode them DL Ack/Nack if the window size
> is increased which makes sense with multiple PDCH.
> 
>> 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.
> 
> The reason for not implementing them for UL TBF ACK yet was the fact
> that we only support single slot only in that direction and that the
> imposed restriction won't probably hurt in most cases. We can still send
> URBB even if the window size were larger than 96, so there are only some
> cases with long runs of NACKs and very few ACKs which might suffer from
> a slightly increased latency.
> 
>> 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.
> 
> -> UL TBF ACK handling

thanks for the correction.




From laforge at gnumonks.org  Mon Mar  7 17:48:10 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 8 Mar 2016 00:48:10 +0700
Subject: Public Osmocom User Manuals
Message-ID: <20160307174810.GQ5976@nataraja>

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Mon Mar  7 19:17:46 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 7 Mar 2016 20:17:46 +0100
Subject: Public Osmocom User Manuals
In-Reply-To: <20160307174810.GQ5976@nataraja>
References: <20160307174810.GQ5976@nataraja>
Message-ID: <093B635E-E9F9-4607-B032-0F4E692F8F24@freyther.de>


> On 07 Mar 2016, at 18:48, Harald Welte <laforge at gnumonks.org> wrote:
> 

> 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.

http://ftp.osmocom.org/api/latest/libosmocore/

http://ftp.osmocom.org/api/latest/libosmocore/codec/html/index.html
http://ftp.osmocom.org/api/latest/libosmocore/core/html/index.html
http://ftp.osmocom.org/api/latest/libosmocore/gsm/html/index.html
http://ftp.osmocom.org/api/latest/libosmocore/vty/html/index.html

If I would use this to find out about the API I would miss an overview page that lists all the libraries and links to them. I think we need some tweaks to the doxygen configuration to link it together? Anyone has experience with that? Like the manuals these documents are updated by jenkins after every change to libosmocore. If there are other projects that would like to update documentation I am happy to add it too.

kind regards
	holger

From Prasad.Kaup at radisys.com  Tue Mar  8 06:21:31 2016
From: Prasad.Kaup at radisys.com (Prasad.Kaup at radisys.com)
Date: Tue, 8 Mar 2016 11:51:31 +0530
Subject: [PATCH] Introduction of new Header Types for FANR
Message-ID: <1457418091-3148-1-git-send-email-Prasad.Kaup@radisys.com>

From: Aravind Sirsikar <Arvind.Sirsikar at radisys.com>

Defines new Header Type structures for FANR

Signed-off-by: Prasad Kaup <Prasad.Kaup at radisys.com>
---
 src/rlc.h | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 106 insertions(+), 3 deletions(-)

diff --git a/src/rlc.h b/src/rlc.h
index f7c5457..81332ce 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -363,9 +363,55 @@ struct gprs_rlc_dl_header_egprs_1 {
        uint8_t  bsn1_b;
 	uint8_t bsn1_c:1,
 		bsn2_a:7;
-
  	uint8_t	bsn2_b:3,
-		cps:5;	
+		cps:5;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.3.1.2 */
+struct gprs_rlc_dl_header_egprs_fanr_type1 {
+	uint8_t usf:3,
+		ces_p:3,
+		pani:1,
+		tfi_a:1;
+	uint8_t tfi_b:4,
+		pr:2,
+		bsn1_a:2;
+	uint8_t bsn1_b;
+	uint8_t bsn1_c:1,
+		bsn2_a:7;
+	uint8_t	bsn2_b:3,
+		cps:5;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.3.2.2 */
+struct gprs_rlc_dl_header_egprs_fanr_type2 {
+	uint8_t usf:3,
+		ces_p:3,
+		pani:1,
+		tfi_a:1;
+	uint8_t tfi_b:4,
+		pr:2,
+		bsn_a:2;
+       uint8_t  bsn_b;
+	uint8_t bsn_c:1,
+		cps:3,
+		dummy:4;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.3.3.2  */
+struct gprs_rlc_dl_header_egprs_fanr_type3 {
+	uint8_t usf:3,
+		ces_p:2,
+		pani:2,
+		tfi_a:1;
+	uint8_t tfi_b:4,
+		pr:2,
+		bsn_a:2;
+        uint8_t bsn_b;
+	uint8_t bsn_c:1,
+		cps:4,
+		spb:2,
+		dummy:1;
 } __attribute__ ((packed));
 
 struct rlc_li_field {
@@ -413,7 +459,7 @@ struct gprs_rlc_ul_header_egprs_2 {
 		dummy:3;
 } __attribute__ ((packed));
 
-
+/* TS 44.060 10.3a.4.1.1 */
 struct gprs_rlc_ul_header_egprs_1 {
 	uint8_t r:1,
 		si:1,
@@ -431,6 +477,63 @@ struct gprs_rlc_ul_header_egprs_1 {
 	uint8_t spare2:6,
 		dummy:2;
 } __attribute__ ((packed));
+
+/* TS 44.060 10.3a.4.1.2 */
+struct gprs_rlc_ul_header_egprs_fanr_type1 {
+	uint8_t r:1,
+		si:1,
+		cv:4,
+		tfi_a:2;
+	uint8_t tfi_b:3,
+		bsn1_a:5;
+	uint8_t bsn1_b:6,
+		bsn2_a:2;
+	uint8_t bsn2_b;
+	uint8_t cps:5,
+		rsb:1,
+		pi:1,
+		pani:1;
+	uint8_t spare2:6,
+		dummy:2;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.4.2.2 */
+struct gprs_rlc_ul_header_egprs_fanr_type2 {
+	uint8_t r:1,
+		si:1,
+		cv:4,
+		tfi_a:2;
+	uint8_t tfi_b:3,
+		bsn1_a:5;
+	uint8_t bsn1_b:6,
+		cps_a:2;
+	uint8_t cps_b:1,
+		rsb:1,
+		pi:1,
+		pani:1,
+		spare:4;
+	uint8_t spare1:5,
+		dummy:3;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.4.3.2 */
+struct gprs_rlc_ul_header_egprs_fanr_type3 {
+	uint8_t r:1,
+		si:1,
+		cv:4,
+		tfi_a:2;
+	uint8_t tfi_b:3,
+		bsn1_a:5;
+	uint8_t bsn1_b:6,
+		cps_a:2;
+	uint8_t cps_b:2,
+		spb:2,
+		rsb:1,
+		pi:1,
+		pani:1,
+		dummy:1;
+} __attribute__ ((packed));
+
 }
 
 inline bool gprs_rlc_v_b::is_state(int bsn, const gprs_rlc_dl_bsn_state type) const
-- 
2.1.4



From saurabh.sharan at radisys.com  Tue Mar  8 07:56:49 2016
From: saurabh.sharan at radisys.com (Saurabh Sharan)
Date: Tue, 8 Mar 2016 13:26:49 +0530
Subject: [PATCH] Fix encoding of padding bits to start with 0 bit
Message-ID: <1457423809-13646-1-git-send-email-saurabh.sharan@radisys.com>

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



From saurabh.sharan at radisys.com  Tue Mar  8 12:54:02 2016
From: saurabh.sharan at radisys.com (Saurabh Sharan)
Date: Tue, 8 Mar 2016 18:24:02 +0530
Subject: [PATCH] Add test vectors for EGPRS messages
Message-ID: <1457441642-760-1-git-send-email-saurabh.sharan@radisys.com>


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(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-test-vectors-for-EGPRS-messages.patch
Type: text/x-patch
Size: 5535 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160308/894210b7/attachment.bin>

From Bhargava.Abhyankar at radisys.com  Tue Mar  8 13:15:58 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Tue, 8 Mar 2016 18:45:58 +0530
Subject: [PATCH] Support of 11 bit RACH
Message-ID: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>

This patch is first of series of patches to support 11 bit RACH.
This includes interface structure changes between osmo-pcu and
osmo-bts to support 11 bit RACH.Processing of 11 bit RACH for
GPRS is added in bts.cpp.
Unit test for the same shall be sent as separate patch.
EGPRS PACKET CHANNEL REQUEST is not part of this patch.Note also
that this feature requires changes in osmo-bts and versioning needs
to be addressed further.
---
 src/bts.cpp       | 36 +++++++++++++++++++++++++++---------
 src/bts.h         |  9 ++++++++-
 src/pcu_l1_if.cpp |  2 +-
 src/pcuif_proto.h |  3 ++-
 4 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..a999c48 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -459,7 +459,7 @@ int BTS::rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn)
 	return 0;
 }
 
-int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
+int BTS::rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta, uint8_t rach_type)
 {
 	struct gprs_rlcmac_ul_tbf *tbf = NULL;
 	uint8_t trx_no, ts_no = 0;
@@ -475,14 +475,32 @@ int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
 
 	LOGP(DRLCMAC, LOGL_DEBUG, "MS requests UL TBF on RACH, so we provide "
 		"one:\n");
-	if ((ra & 0xf8) == 0x70) {
-		LOGP(DRLCMAC, LOGL_DEBUG, "MS requests single block "
-			"allocation\n");
-		sb = 1;
-	} else if (m_bts.force_two_phase) {
-		LOGP(DRLCMAC, LOGL_DEBUG, "MS requests single phase access, "
-			"but we force two phase access\n");
-		sb = 1;
+
+	if (rach_type == GPRS_8_BIT_RACH ) {
+		if ((ra & 0xf8) == 0x70) {
+			LOGP(DRLCMAC, LOGL_DEBUG, "MS requests single block "
+					"allocation\n");
+			sb = 1;
+		} else if (m_bts.force_two_phase) {
+			LOGP(DRLCMAC, LOGL_DEBUG, "MS requests single phase access, "
+					"but we force two phase access\n");
+			sb = 1;
+		}
+
+	} else if(rach_type == GPRS_11_BIT_RACH ) {
+		if((ra & RACH_CAUSE_SINGLE_BLOCK) == 0x0600) {
+                         LOGP(DRLCMAC, LOGL_DEBUG, "11 bit RACH received.MS requests single block "
+                                        "allocation\n");
+                        sb = 1;
+
+                } else if (m_bts.force_two_phase) {
+                        LOGP(DRLCMAC, LOGL_DEBUG, "11 bit RACHreceived.MS requests single phase access, "
+                                        "but we force two phase access\n");
+                        sb = 1;
+                }
+	} else if (rach_type == EGPRS_11_BIT_RACH) {
+		/*TODO*/
+
 	}
 	if (qta < 0)
 		qta = 0;
diff --git a/src/bts.h b/src/bts.h
index c975304..870e6f3 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -41,6 +41,7 @@ extern "C" {
 
 #define LLC_CODEL_DISABLE 0
 #define LLC_CODEL_USE_DEFAULT (-1)
+#define RACH_CAUSE_SINGLE_BLOCK ((~((~0) << 6)) << 5) /* Establish cause */
 
 struct BTS;
 struct GprsMs;
@@ -251,6 +252,12 @@ public:
 		TIMER_T3190_MSEC = 5000,
 	};
 
+        enum {
+		GPRS_8_BIT_RACH = 0,
+		GPRS_11_BIT_RACH = 1,
+		EGPRS_11_BIT_RACH = 2,
+	};
+
 	BTS();
 	~BTS();
 
@@ -275,7 +282,7 @@ public:
 	int tfi_find_free(enum gprs_rlcmac_tbf_direction dir, uint8_t *_trx, int8_t use_trx);
 
 	int rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn);
-	int rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta);
+	int rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta, uint8_t rach_type = 0);
 
 	void trigger_dl_ass(gprs_rlcmac_dl_tbf *tbf, gprs_rlcmac_tbf *old_tbf);
 	void snd_dl_ass(gprs_rlcmac_tbf *tbf, uint8_t poll, const char *imsi);
diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp
index 19dda5c..d937d20 100644
--- a/src/pcu_l1_if.cpp
+++ b/src/pcu_l1_if.cpp
@@ -313,7 +313,7 @@ static int pcu_rx_rach_ind(struct gsm_pcu_if_rach_ind *rach_ind)
 	case PCU_IF_SAPI_RACH:
 		rc = BTS::main_bts()->rcv_rach(
 			rach_ind->ra, rach_ind->fn,
-			rach_ind->qta);
+			rach_ind->qta,rach_ind->rach_type);
 		break;
 	default:
 		LOGP(DL1IF, LOGL_ERROR, "Received PCU rach request with "
diff --git a/src/pcuif_proto.h b/src/pcuif_proto.h
index 9d740ac..0844183 100644
--- a/src/pcuif_proto.h
+++ b/src/pcuif_proto.h
@@ -64,10 +64,11 @@ struct gsm_pcu_if_rts_req {
 
 struct gsm_pcu_if_rach_ind {
 	uint8_t		sapi;
-	uint8_t		ra;
+	uint16_t	ra;
 	int16_t		qta;
 	uint32_t	fn;
 	uint16_t	arfcn;
+	uint8_t		rach_type;
 } __attribute__ ((packed));
 
 struct gsm_pcu_if_info_trx {
-- 
2.5.0




From Saurabh.Sharan at radisys.com  Tue Mar  8 14:21:55 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Tue, 8 Mar 2016 14:21:55 +0000
Subject: Incorrect Packet Downlink Assignment message in TbfTest.err 
Message-ID: <BY1PR08MB1308BC1D57442DAFEB3BB60985B20@BY1PR08MB1308.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160308/d605e423/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmolog.txt
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160308/d605e423/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: paddingFixlog.txt
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160308/d605e423/attachment-0001.txt>

From holger at freyther.de  Tue Mar  8 17:42:29 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 8 Mar 2016 18:42:29 +0100
Subject: [PATCH] Support of 11 bit RACH
In-Reply-To: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>


> On 08 Mar 2016, at 14:15, Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com> wrote:


Dear Bhargava,


> 
> This patch is first of series of patches to support 11 bit RACH.
> This includes interface structure changes between osmo-pcu and
> osmo-bts to support 11 bit RACH.Processing of 11 bit RACH for
> GPRS is added in bts.cpp.
> Unit test for the same shall be sent as separate patch.
> EGPRS PACKET CHANNEL REQUEST is not part of this patch.Note also
> that this feature requires changes in osmo-bts and versioning needs
> to be addressed further.


could you start by sending a patch for both osmo-bts and osmo-pcu to modify the pcuif_proto.h with the new protocol and the version number increase and osmo-bts to set it as GPRS_8_BIT_RACH (to match current behavior if that makes sense)?



> ---
> src/bts.cpp       | 36 +++++++++++++++++++++++++++---------
> src/bts.h         |  9 ++++++++-
> src/pcu_l1_if.cpp |  2 +-
> src/pcuif_proto.h |  3 ++-
> 4 files changed, 38 insertions(+), 12 deletions(-)
> 
> diff --git a/src/bts.cpp b/src/bts.cpp
> index 715fb51..a999c48 100644
> --- a/src/bts.cpp
> +++ b/src/bts.cpp
> @@ -459,7 +459,7 @@ int BTS::rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn)
> 	return 0;
> }
> 
> -int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
> +int BTS::rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta, uint8_t rach_type)
> {
> 

> +	} else if(rach_type == GPRS_11_BIT_RACH ) {
> +		if((ra & RACH_CAUSE_SINGLE_BLOCK) == 0x0600) {

please have a look at the Linux Kernel CodingStyle guidelines about necessary spaces between the if keyword and the opening parenthesis.

In terms of style, could you move the code that select the 'sb' into a separate (static inline) helper function. Not that we do it right now but in general this allows us to unit test such things more easily.




> +	} else if (rach_type == EGPRS_11_BIT_RACH) {
> +		/*TODO*/
> +


Do you think a log message is necessary here? Also in terms of TODO, maybe describe what someone in the future should put there?


kind regards
	holger

From holger at freyther.de  Tue Mar  8 17:54:33 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 8 Mar 2016 18:54:33 +0100
Subject: [PATCH] Fix encoding of padding bits to start with 0 bit
In-Reply-To: <1457423809-13646-1-git-send-email-saurabh.sharan@radisys.com>
References: <1457423809-13646-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <8337EEC2-2471-42CC-B808-36237326F7F9@freyther.de>


> On 08 Mar 2016, at 08:56, Saurabh Sharan <saurabh.sharan at radisys.com> wrote:


Dear Saurabh,


> 
> 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.

thanks a lot. The commit message is a lot better. In general we would like to be able to use "git bisect" for this to work every single commit needs to work/compile. This means that your padding patch should include the updates for the RLCMacTest (but not the new vectors) and the update for the test expectations of the tbf test. The second patch for RLCMacTest should then carry the new test vectors.

Could you please send updated patches?

thanks a lot
	holger



From arvind.sirsikar at radisys.com  Wed Mar  9 12:37:14 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 9 Mar 2016 18:07:14 +0530
Subject: [PATCH] VTY changes for FANR feature
Message-ID: <1457527034-12235-1-git-send-email-arvind.sirsikar@radisys.com>

Enables user to Enable/Disable FANR feature from VTY interface

This is second patch among series of patches for FANR feature
---
 src/bts.h        |    1 +
 src/pcu_main.cpp |    4 ++++
 src/pcu_vty.c    |   35 +++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+)

diff --git a/src/bts.h b/src/bts.h
index ccb8025..7e3ea80 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -192,6 +192,7 @@ struct gprs_rlcmac_bts {
 	uint8_t force_two_phase;
 	uint8_t alpha, gamma;
 	uint8_t egprs_enabled;
+	uint8_t fanr_enabled;
         uint8_t initial_mcs_dl;
         uint8_t initial_mcs_ul;
         uint8_t max_mcs_dl;
diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index 9f38742..32d234d 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -183,6 +183,10 @@ int main(int argc, char *argv[])
         bts->initial_mcs_ul = 1;
 	bts->max_mcs_ul = 9;
 	bts->max_mcs_dl = 9;
+
+	bts->egprs_enabled = true;
+	bts->fanr_enabled = false;
+
 	/* CS-1 to CS-4 */
 	bts->cs_lqual_ranges[0].low = -256;
 	bts->cs_lqual_ranges[0].high = 6;
diff --git a/src/pcu_vty.c b/src/pcu_vty.c
index edc777d..90c828b 100644
--- a/src/pcu_vty.c
+++ b/src/pcu_vty.c
@@ -59,6 +59,11 @@ static int config_write_pcu(struct vty *vty)
 	else
 		vty_out(vty, " no egprs%s", VTY_NEWLINE);
 
+	if (bts->fanr_enabled)
+		vty_out(vty, " egprs fanr %s", VTY_NEWLINE);
+	else
+		vty_out(vty, " no egprs fanr%s", VTY_NEWLINE);
+
 	vty_out(vty, " flow-control-interval %d%s", bts->fc_interval,
 		VTY_NEWLINE);
 	if (bts->fc_bvc_bucket_size)
@@ -201,6 +206,34 @@ DEFUN(cfg_pcu_no_egprs,
 	return CMD_SUCCESS;
 }
 
+#define EGPRS_FANR_STR "EGPRS FANR configuration\n"
+
+DEFUN(cfg_pcu_egprs_fanr,
+      cfg_pcu_egprs_fanr_cmd,
+      "egprs_fanr",
+      EGPRS_FANR_STR)
+{
+	struct gprs_rlcmac_bts *bts = bts_main_data();
+
+	bts->fanr_enabled = 1;
+	vty_out(vty, "%%EGPRS FANR is enabled %s", VTY_NEWLINE);
+
+	return CMD_SUCCESS;
+}
+
+DEFUN(cfg_pcu_no_egprs_fanr,
+      cfg_pcu_no_egprs_fanr_cmd,
+      "no egprs fanr",
+      NO_STR EGPRS_FANR_STR)
+{
+	struct gprs_rlcmac_bts *bts = bts_main_data();
+
+	bts->fanr_enabled = 0;
+	vty_out(vty, "%%EGPRS FANR is disabled %s", VTY_NEWLINE);
+
+	return CMD_SUCCESS;
+}
+
 DEFUN(cfg_pcu_fc_interval,
       cfg_pcu_fc_interval_cmd,
       "flow-control-interval <1-10>",
@@ -929,6 +962,8 @@ int pcu_vty_init(const struct log_info *cat)
 	vty_install_default(PCU_NODE);
 	install_element(PCU_NODE, &cfg_pcu_egprs_cmd);
 	install_element(PCU_NODE, &cfg_pcu_no_egprs_cmd);
+	install_element(PCU_NODE, &cfg_pcu_egprs_fanr_cmd);
+	install_element(PCU_NODE, &cfg_pcu_no_egprs_fanr_cmd);
 	install_element(PCU_NODE, &cfg_pcu_no_two_phase_cmd);
 	install_element(PCU_NODE, &cfg_pcu_cs_cmd);
 	install_element(PCU_NODE, &cfg_pcu_no_cs_cmd);
-- 
1.7.9.5




From sangamesh.sajjan at radisys.com  Wed Mar  9 14:33:07 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Wed, 9 Mar 2016 20:03:07 +0530
Subject: [PATCH] Uplink PAN header changes for FANR feature
Message-ID: <1457533987-3524-1-git-send-email-sangamesh.sajjan@radisys.com>

Added structure definition for handling uplink PAN and added new
RLC state for Tentative Ack
---
 src/bts.h |    1 +
 src/rlc.h |   36 +++++++++++++++++++++++++++++++++++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/src/bts.h b/src/bts.h
index ccb8025..756cddf 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -48,6 +48,7 @@ struct GprsMs;
 #define  BITS_TO_BYTES(X)      (X ? (X/8):0)+1
 #define  MOD8(X)             (((X)+8)&0x07)
 #define  MOD64(X)            ((X + 64) & 0x3F)
+#define  MOD2048(X)            ((X + 2048) & 0x7FF)
 extern const uint8_t* one_run_len_code_list[MAX_CDWDTBL_LEN];
 extern const uint8_t* zero_run_len_code_list[MAX_CDWDTBL_LEN];
 
diff --git a/src/rlc.h b/src/rlc.h
index f7c5457..d29527d 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -52,6 +52,7 @@ enum gprs_rlc_dl_bsn_state {
 	GPRS_RLC_DL_BSN_ACKED,
 	GPRS_RLC_DL_BSN_UNACKED,
 	GPRS_RLC_DL_BSN_RESEND,
+	GPRS_RLC_DL_BSN_TENTATIVE_ACK,
 	GPRS_RLC_DL_BSN_MAX,
 };
 
@@ -85,6 +86,15 @@ struct gprs_rlc_ul_data_block_info {
 	unsigned int spb;
 };
 
+struct egprs_ssn_based_pan_info {
+	unsigned int bow;
+	unsigned int short_ssn_a;
+	unsigned int short_ssn_rb;
+	unsigned int rb_a;
+	unsigned int rb_b;
+	unsigned int tfi;
+};
+
 struct gprs_rlc_ul_header_generic{
 	GprsCodingScheme cs;
 	unsigned int r;
@@ -97,6 +107,7 @@ struct gprs_rlc_ul_header_generic{
 	unsigned int num_data_blocks;
         unsigned int data_offs_bytes[2];
 	struct gprs_rlc_ul_data_block_info block_info[2];
+	struct egprs_ssn_based_pan_info pan_info;
 };
 struct gprs_rlc_data {
 	uint8_t *prepare(size_t block_data_length);
@@ -161,7 +172,8 @@ struct gprs_rlc_v_b {
 	bool is_resend(int bsn) const;
 	bool is_invalid(int bsn) const;
 	gprs_rlc_dl_bsn_state get_state(int bsn) const;
-
+	bool is_tentative_acked(int bsn) const;
+	void mark_tentative_acked(int bsn);
 	/* Mark a RLC frame for something */
 	void mark_unacked(int bsn);
 	void mark_nacked(int bsn);
@@ -431,6 +443,18 @@ struct gprs_rlc_ul_header_egprs_1 {
 	uint8_t spare2:6,
 		dummy:2;
 } __attribute__ ((packed));
+
+/* TS 44.060 10.3a.5.1 */
+struct egprs_ssn_based_pan_header {
+        uint8_t bow:1,
+                short_ssn_a:7;
+        uint8_t short_ssn_rb:4,
+                rb_a:4;
+        uint8_t rb_b:4,
+                tfi_a:4;
+        uint8_t tfi_b:1;
+} __attribute__ ((packed));
+
 }
 
 inline bool gprs_rlc_v_b::is_state(int bsn, const gprs_rlc_dl_bsn_state type) const
@@ -468,6 +492,16 @@ inline bool gprs_rlc_v_b::is_invalid(int bsn) const
 	return is_state(bsn, GPRS_RLC_DL_BSN_INVALID);
 }
 
+inline bool gprs_rlc_v_b::is_tentative_acked(int bsn) const
+{
+	return is_state(bsn, GPRS_RLC_DL_BSN_TENTATIVE_ACK);
+}
+
+inline void gprs_rlc_v_b::mark_tentative_acked(int bsn)
+{
+	return mark(bsn, GPRS_RLC_DL_BSN_TENTATIVE_ACK);
+}
+
 inline gprs_rlc_dl_bsn_state gprs_rlc_v_b::get_state(int bsn) const
 {
 	return m_v_b[bsn & mod_sns_half()];
-- 
1.7.9.5




From arvind.sirsikar at radisys.com  Thu Mar 10 04:57:11 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Thu, 10 Mar 2016 10:27:11 +0530
Subject: [PATCH] Structure modifications for FANR feature
Message-ID: <1457585831-25853-1-git-send-email-arvind.sirsikar@radisys.com>

Adds new variable m_fanr_enabled in the gprs_rlcmac_tbf structure
Adds new variable m_is_fanr_capable in  GprsMs class
Adds new variable pan_allowed in mcs_info structure variable

This is the fourth patch among series of patches for FANR feature
---
 src/gprs_coding_scheme.cpp |   60 ++++++++++++++++++++++++++------------------
 src/gprs_ms.cpp            |    1 +
 src/gprs_ms.h              |   17 +++++++++++++
 src/tbf.cpp                |    3 ++-
 src/tbf.h                  |   14 +++++++++++
 5 files changed, 69 insertions(+), 26 deletions(-)

diff --git a/src/gprs_coding_scheme.cpp b/src/gprs_coding_scheme.cpp
index 232cee3..53ce868 100644
--- a/src/gprs_coding_scheme.cpp
+++ b/src/gprs_coding_scheme.cpp
@@ -30,23 +30,24 @@ static struct {
 	unsigned int num_blocks;
 	const char *name;
 	GprsCodingScheme::HeaderType data_hdr;
+	bool pan_allowed;
 } mcs_info[GprsCodingScheme::NUM_SCHEMES] = {
-	{{0, 0},    {0, 0},    0, 0, "UNKNOWN", GprsCodingScheme::HEADER_INVALID},
-	{{23, 0},   {23, 0},  20, 1, "CS-1", GprsCodingScheme::HEADER_GPRS_DATA},
-	{{33, 7},   {33, 7},  30, 1, "CS-2", GprsCodingScheme::HEADER_GPRS_DATA},
-	{{39, 3},   {39, 3},  36, 1, "CS-3", GprsCodingScheme::HEADER_GPRS_DATA},
-	{{53, 7},   {53, 7},  50, 1, "CS-4", GprsCodingScheme::HEADER_GPRS_DATA},
-
-	{{26, 1},   {26, 1},  22, 1, "MCS-1", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3},
-	{{32, 1},   {32, 1},  28, 1, "MCS-2", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3},
-	{{41, 1},   {41, 1},  37, 1, "MCS-3", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3},
-	{{48, 1},   {48, 1},  44, 1, "MCS-4", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3},
-
-	{{60, 7},   {59, 6},  56, 1, "MCS-5", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2},
-	{{78, 7},   {77, 6},  74, 1, "MCS-6", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2},
-	{{118, 2},  {117, 4}, 56, 2, "MCS-7", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1},
-	{{142, 2},  {141, 4}, 68, 2, "MCS-8", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1},
-	{{154, 2},  {153, 4}, 74, 2, "MCS-9", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1},
+	{{0, 0},    {0, 0},    0, 0, "UNKNOWN", GprsCodingScheme::HEADER_INVALID,false},
+	{{23, 0},   {23, 0},  20, 1, "CS-1", GprsCodingScheme::HEADER_GPRS_DATA, false},
+	{{33, 7},   {33, 7},  30, 1, "CS-2", GprsCodingScheme::HEADER_GPRS_DATA, false},
+	{{39, 3},   {39, 3},  36, 1, "CS-3", GprsCodingScheme::HEADER_GPRS_DATA, false},
+	{{53, 7},   {53, 7},  50, 1, "CS-4", GprsCodingScheme::HEADER_GPRS_DATA, false},
+
+	{{26, 1},   {26, 1},  22, 1, "MCS-1", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true},
+	{{32, 1},   {32, 1},  28, 1, "MCS-2", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true},
+	{{41, 1},   {41, 1},  37, 1, "MCS-3", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true},
+	{{48, 1},   {48, 1},  44, 1, "MCS-4", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, false},
+
+	{{60, 7},   {59, 6},  56, 1, "MCS-5", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2, true},
+	{{78, 7},   {77, 6},  74, 1, "MCS-6", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2, true},
+	{{118, 2},  {117, 4}, 56, 2, "MCS-7", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, true},
+	{{142, 2},  {141, 4}, 68, 2, "MCS-8", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, true},
+	{{154, 2},  {153, 4}, 74, 2, "MCS-9", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, false},
 };
 
 /* CPS table for Header Type 3 */
@@ -132,20 +133,29 @@ uint8_t GprsCodingScheme::get_cps(uint8_t ps, bool is_padding)
 
 GprsCodingScheme GprsCodingScheme::getBySizeUL(unsigned size)
 {
+	/* The size 31, 37, 46, 66, 84, 124, 148 corresponds to PAN field
+	* inclusion in egprs UL frame. i.e 4 bytes extra. */
 	switch (size) {
 		case 23: return GprsCodingScheme(CS1);
-		case 27: return GprsCodingScheme(MCS1);
-		case 33: return GprsCodingScheme(MCS2);
+		case 27: return GprsCodingScheme(MCS1, EGPRS);
+		case 31: return GprsCodingScheme(MCS1,EGPRS);
+		case 33:return GprsCodingScheme(MCS2);
+		case 37: return GprsCodingScheme(MCS2,EGPRS);
 		case 34: return GprsCodingScheme(CS2);
 		case 40: return GprsCodingScheme(CS3);
-		case 42: return GprsCodingScheme(MCS3);
-		case 49: return GprsCodingScheme(MCS4);
+		case 42: return GprsCodingScheme(MCS3,EGPRS);
+		case 46: return GprsCodingScheme(MCS3,EGPRS);
+		case 49: return GprsCodingScheme(MCS4,EGPRS);
 		case 54: return GprsCodingScheme(CS4);
-		case 62: return GprsCodingScheme(MCS5);
-		case 80: return GprsCodingScheme(MCS6);
-		case 120: return GprsCodingScheme(MCS7);
-		case 144: return GprsCodingScheme(MCS8);
-		case 156: return GprsCodingScheme(MCS9);
+		case 62: return GprsCodingScheme(MCS5,EGPRS);
+		case 66: return GprsCodingScheme(MCS5,EGPRS);
+		case 80: return GprsCodingScheme(MCS6, EGPRS);
+		case 84: return GprsCodingScheme(MCS6,EGPRS);
+		case 120: return GprsCodingScheme(MCS7, EGPRS);
+		case 124: return GprsCodingScheme(MCS7,EGPRS);
+		case 144: return GprsCodingScheme(MCS8, EGPRS);
+		case 148: return GprsCodingScheme(MCS8,EGPRS);
+		case 156: return GprsCodingScheme(MCS9, EGPRS);
 	}
 
 	return GprsCodingScheme(UNKNOWN);
diff --git a/src/gprs_ms.cpp b/src/gprs_ms.cpp
index cd4582f..67c3e95 100644
--- a/src/gprs_ms.cpp
+++ b/src/gprs_ms.cpp
@@ -137,6 +137,7 @@ GprsMs::GprsMs(BTS *bts, uint32_t tlli) :
 		gprs_codel_set_interval(m_codel_state, codel_interval);
 	}
 	m_last_cs_not_low = now_msec();
+	m_is_fanr_capable = false;
 }
 
 GprsMs::~GprsMs()
diff --git a/src/gprs_ms.h b/src/gprs_ms.h
index 3c91e3c..3cd94bd 100644
--- a/src/gprs_ms.h
+++ b/src/gprs_ms.h
@@ -130,6 +130,8 @@ public:
 	/* internal use */
 	static void timeout(void *priv_);
 
+	bool is_fanr_capable() const;
+	void set_fanr_capable(bool);
 protected:
 	void update_status();
 	GprsMs *ref();
@@ -161,6 +163,11 @@ private:
 	gprs_llc_queue m_llc_queue;
 
 	bool m_is_idle;
+	/* member to validate fanr support. will be set after
+	 * after decoding RA capability of the MS
+	*/
+	bool m_is_fanr_capable;
+
 	int m_ref;
 	LListHead<GprsMs> m_list;
 	struct osmo_timer_list m_timer;
@@ -182,6 +189,16 @@ inline bool GprsMs::is_idle() const
 	return !m_ul_tbf && !m_dl_tbf && !m_ref && llist_empty(&m_old_tbfs);
 }
 
+inline bool GprsMs::is_fanr_capable() const
+{
+	return this->m_is_fanr_capable;
+}
+
+inline void GprsMs::set_fanr_capable(bool is_fanr_capable)
+{
+	this->m_is_fanr_capable = is_fanr_capable;
+}
+
 inline bool GprsMs::need_dl_tbf() const
 {
 	if (dl_tbf() != NULL && dl_tbf()->state_is_not(GPRS_RLCMAC_WAIT_RELEASE))
diff --git a/src/tbf.cpp b/src/tbf.cpp
index aedb9ae..93dd8c2 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -87,7 +87,8 @@ gprs_rlcmac_tbf::gprs_rlcmac_tbf(BTS *bts_, gprs_rlcmac_tbf_direction dir) :
 	m_ta(0),
 	m_ms_class(0),
 	m_ms_list(this),
-        m_egprs_enabled(false)
+	m_egprs_enabled(false),
+	m_fanr_enabled(false)
 {
 	/* The classes of these members do not have proper constructors yet.
 	 * Just set them to 0 like talloc_zero did */
diff --git a/src/tbf.h b/src/tbf.h
index 1f5d928..6e482c7 100644
--- a/src/tbf.h
+++ b/src/tbf.h
@@ -177,6 +177,9 @@ struct gprs_rlcmac_tbf {
         void enable_egprs();
         void disable_egprs();
 
+	bool is_fanr_enabled() const;
+	void enable_fanr();
+
 	/* attempt to make things a bit more fair */
 	void rotate_in_list();
 
@@ -261,6 +264,7 @@ protected:
 private:
 	LListHead<gprs_rlcmac_tbf> m_ms_list;
         bool m_egprs_enabled;
+	bool m_fanr_enabled;
 	mutable char m_name_buf[60];
 };
 
@@ -343,6 +347,16 @@ inline void gprs_rlcmac_tbf::disable_egprs()
         m_egprs_enabled = false;
 }
 
+inline bool gprs_rlcmac_tbf::is_fanr_enabled() const
+{
+	return m_fanr_enabled;
+}
+
+inline void gprs_rlcmac_tbf::enable_fanr()
+{
+	m_fanr_enabled = true;
+}
+
 struct gprs_rlcmac_dl_tbf : public gprs_rlcmac_tbf {
 	gprs_rlcmac_dl_tbf(BTS *bts);
 
-- 
1.7.9.5




From arvind.sirsikar at radisys.com  Thu Mar 10 05:45:14 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Thu, 10 Mar 2016 11:15:14 +0530
Subject: [PATCH] FANR UL and DL flow changes and UT fixes
Message-ID: <1457588714-14527-1-git-send-email-arvind.sirsikar@radisys.com>

FANR enabled TBF allocation for both UL and DL based
on ms capability

This is 5th patch among series of patches for FANR feature

The TbfTest.err and EdgeTest.err updation is not part of this patch
The Ms capability decoding is not part of this patch
---
 src/bts.cpp               |  132 +++++++++-----
 src/bts.h                 |    2 +-
 src/decoding.cpp          |  441 +++++++++++++++++++++++++++++++--------------
 src/decoding.h            |   24 +++
 src/gprs_bssgp_pcu.cpp    |   12 +-
 src/tbf.cpp               |   24 ++-
 src/tbf.h                 |   12 +-
 src/tbf_dl.cpp            |   10 +-
 src/tbf_ul.cpp            |    2 +-
 tests/alloc/AllocTest.cpp |   28 +--
 tests/edge/EdgeTest.cpp   |  235 ++++++++++++++++++++++--
 tests/tbf/TbfTest.cpp     |   16 +-
 12 files changed, 707 insertions(+), 231 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index ddce6dc..7897d25 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -552,7 +552,7 @@ int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
 		// Create new TBF
 		#warning "Copy and pate with other routines.."
 		/* set class to 0, since we don't know the multislot class yet */
-		tbf = tbf_alloc_ul_tbf(&m_bts, NULL, -1, 0, 0, 1);
+		tbf = tbf_alloc_ul_tbf(&m_bts, NULL, -1, 0, 0, 1, false);
 		if (!tbf) {
 			LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n");
 			/* FIXME: send reject */
@@ -641,7 +641,7 @@ void BTS::snd_dl_ass(gprs_rlcmac_tbf *tbf, uint8_t poll, const char *imsi)
 }
 
 
-GprsMs *BTS::ms_alloc(uint8_t ms_class, uint8_t egprs_ms_class)
+GprsMs *BTS::ms_alloc(uint8_t ms_class, uint8_t egprs_ms_class, bool is_fanr_capable)
 {
 	GprsMs *ms;
 	ms = ms_store().create_ms();
@@ -649,6 +649,7 @@ GprsMs *BTS::ms_alloc(uint8_t ms_class, uint8_t egprs_ms_class)
 	ms->set_timeout(m_bts.ms_idle_sec);
 	ms->set_ms_class(ms_class);
 	ms->set_egprs_ms_class(egprs_ms_class);
+	ms->set_fanr_capable(is_fanr_capable);
 
 	return ms;
 }
@@ -1037,7 +1038,7 @@ void gprs_rlcmac_pdch::rcv_control_egprs_dl_ack_nack(EGPRS_PD_AckNack_t *ack_nac
 		/* This call will register the new TBF with the MS on success */
 		tbf_alloc_ul(bts_data(), tbf->trx->trx_no,
 			tbf->ms_class(), tbf->ms()->egprs_ms_class(),
-			tbf->tlli(), tbf->ta(), tbf->ms());
+			tbf->tlli(), tbf->ta(), tbf->ms(), tbf->ms()->is_fanr_capable());
 
 		/* schedule uplink assignment */
 		tbf->ul_ass_state = GPRS_RLCMAC_UL_ASS_SEND_ASS;
@@ -1097,7 +1098,7 @@ void gprs_rlcmac_pdch::rcv_control_dl_ack_nack(Packet_Downlink_Ack_Nack_t *ack_n
 		/* This call will register the new TBF with the MS on success */
 		tbf_alloc_ul(bts_data(), tbf->trx->trx_no,
 			tbf->ms_class(), tbf->ms()->egprs_ms_class(),
-			tbf->tlli(), tbf->ta(), tbf->ms());
+			tbf->tlli(), tbf->ta(), tbf->ms(), tbf->ms()->is_fanr_capable());
 
 		/* schedule uplink assignment */
 		tbf->ul_ass_state = GPRS_RLCMAC_UL_ASS_SEND_ASS;
@@ -1119,6 +1120,7 @@ void gprs_rlcmac_pdch::rcv_resource_request(Packet_Resource_Request_t *request,
 		uint32_t tlli = request->ID.u.TLLI;
 		uint8_t ms_class = 0;
 		uint8_t egprs_ms_class = 0;
+		bool    is_egprs_ms_fanr_capable = 0;
 		uint8_t ta = 0;
 		struct pcu_l1_meas meas;
 
@@ -1174,6 +1176,10 @@ void gprs_rlcmac_pdch::rcv_resource_request(Packet_Resource_Request_t *request,
 			egprs_ms_class =
 				Decoding::get_egprs_ms_class_by_capability(
 					&request->MS_Radio_Access_capability);
+
+			is_egprs_ms_fanr_capable =
+				Decoding::is_ms_fanr_capable(
+					&request->MS_Radio_Access_capability);
 		}
 		if (!ms_class)
 			LOGP(DRLCMAC, LOGL_NOTICE, "MS does not give us a class.\n");
@@ -1182,7 +1188,7 @@ void gprs_rlcmac_pdch::rcv_resource_request(Packet_Resource_Request_t *request,
 				"MS supports EGPRS multislot class %d.\n",
 				egprs_ms_class);
 		ul_tbf = tbf_alloc_ul(bts_data(), trx_no(), ms_class,
-			egprs_ms_class, tlli, ta, ms);
+			egprs_ms_class, tlli, ta, ms, is_egprs_ms_fanr_capable);
 		if (!ul_tbf)
 			return;
 
@@ -1193,8 +1199,10 @@ void gprs_rlcmac_pdch::rcv_resource_request(Packet_Resource_Request_t *request,
 		ul_tbf->ul_ass_state = GPRS_RLCMAC_UL_ASS_SEND_ASS;
 
 		/* get capabilities */
-		if (ul_tbf->ms())
+		if (ul_tbf->ms()) {
 			ul_tbf->ms()->set_egprs_ms_class(egprs_ms_class);
+			ul_tbf->ms()->set_fanr_capable(is_egprs_ms_fanr_capable);
+		}
 
 		/* get measurements */
 		if (ul_tbf->ms()) {
@@ -1326,48 +1334,84 @@ int gprs_rlcmac_pdch::rcv_data_data_block(uint8_t *data, uint32_t fn,
 {
         int rc;
         struct gprs_rlc_ul_header_generic rlc_dec;
-        struct gprs_rlcmac_ul_tbf *tbf;
-        unsigned len = cs.maxBytesUL();
+        struct gprs_rlcmac_ul_tbf *tbf = NULL;
+
+	/* These are always data blocks, since EGPRS still uses CS-1 for
+	* control blocks (see 44.060, section 10.3, 1st par.)
+	*/
+	if (cs.isEgprs()) {
+		if (!bts()->bts_data()->egprs_enabled) {
+			LOGP(DRLCMACUL, LOGL_ERROR,
+			"Got %s RLC block but EGPRS is not enabled\n",
+			cs.name());
+			return -EINVAL;
+		}
 
-        /* These are always data blocks, since EGPRS still uses CS-1 for
-         * control blocks (see 44.060, section 10.3, 1st par.)
-         */
-        if (cs.isEgprs()) {
-                if (!bts()->bts_data()->egprs_enabled) {
-                        LOGP(DRLCMACUL, LOGL_ERROR,
-                                "Got %s RLC block but EGPRS is not enabled\n",
-                                cs.name());
-                        return -EINVAL;
-                }
+		uint8_t tfi = ((data[1] & 0x7) << 2)  | ((data[0] & 0xc0) >> 6);
 
-        }
+	        /* find TBF inst from given TFI */
+		tbf = ul_tbf_by_tfi(tfi);
+		if (!tbf) {
+			LOGP(DRLCMACUL, LOGL_NOTICE, "UL DATA unknown TFI=%d\n",
+				tfi);
+			return 0;
+		}
 
-        LOGP(DRLCMACUL, LOGL_DEBUG, "  UL data: %s\n", osmo_hexdump(data, len));
+		rc = Decoding::rlc_parse_ul_data_header_egprs(&rlc_dec, data, cs, tbf);
+		if (rc == -ENOTSUP ) {
+			LOGP(DRLCMACUL, LOGL_ERROR,
+				"Got %s RLC block but header parsing has failed\n",
+			cs.name());
+			bts()->decode_error();
+			return rc;
+		}
 
-        rc = Decoding::rlc_parse_ul_data_header(&rlc_dec, data, cs);
-        if (rc == -ENOTSUP ) {
-                LOGP(DRLCMACUL, LOGL_ERROR,
-                        "Got %s RLC block but header parsing has failed\n",
-                        cs.name());
-                bts()->decode_error();
-                return rc;
-        }
+		if (1 == rlc_dec.pani) {
+			if (false == tbf->is_fanr_enabled())
+				LOGP(DRLCMACUL, LOGL_ERROR, "Received PAN field "
+						"but FANR is not activated for TBF\n");
+		}
 
-        LOGP(DRLCMACUL, LOGL_INFO,
-                "Got %s RLC block: "
-                "R=%d, SI=%d, TFI=%d, CPS=%d, RSB=%d\n",
-                cs.name(),
-                rlc_dec.r, rlc_dec.si, rlc_dec.tfi, rlc_dec.cps, rlc_dec.rsb
-                );
-        /* find TBF inst from given TFI */
-        tbf = ul_tbf_by_tfi(rlc_dec.tfi);
-        if (!tbf) {
-                LOGP(DRLCMACUL, LOGL_NOTICE, "UL DATA unknown TFI=%d\n",
-                        rlc_dec.tfi);
-                return 0;
-        }
+		struct gprs_rlcmac_bts* bts_info =  bts_data();
+		if (false == bts_info->fanr_enabled) {
+			if (1 == rlc_dec.pani)
+				LOGP(DRLCMACUL, LOGL_ERROR, "PANI shall not be true since bts"
+						" not configured for fanr\n");
+		}
+		LOGP(DRLCMACUL, LOGL_INFO,
+				"Got %s RLC block: "
+				"R=%d, SI=%d, TFI=%d, CPS=%d, RSB=%d\n",
+				cs.name(),
+				rlc_dec.r, rlc_dec.si, rlc_dec.tfi, rlc_dec.cps, rlc_dec.rsb
+		);
+
+		if (tbf->is_fanr_enabled())
+			LOGP(DRLCMACUL, LOGL_INFO,"Pani value=%d \n",rlc_dec.pani);
+	}else{
+		rc = Decoding::rlc_parse_ul_data_header(&rlc_dec, data, cs);
+		if (rc == -ENOTSUP ) {
+			LOGP(DRLCMACUL, LOGL_ERROR,
+				"Got %s RLC block but header parsing has failed\n",
+				cs.name());
+			bts()->decode_error();
+			return rc;
+		}
+		/* find TBF inst from given TFI */
+		tbf = ul_tbf_by_tfi(rlc_dec.tfi);
+		if (!tbf) {
+			LOGP(DRLCMACUL, LOGL_NOTICE, "UL DATA unknown TFI=%d\n",
+					rlc_dec.tfi);
+			return 0;
+		}
+		LOGP(DRLCMACUL, LOGL_INFO,
+			"Got %s RLC block: "
+			"R=%d, SI=%d, TFI=%d, CPS=%d, RSB=%d\n",
+			cs.name(),
+			rlc_dec.r, rlc_dec.si, rlc_dec.tfi, rlc_dec.cps, rlc_dec.rsb
+		);
+	}
 
-        return tbf->rcv_data_block_acknowledged(&rlc_dec, data, len, meas);
+	return tbf->rcv_data_block_acknowledged(&rlc_dec, data, meas);
 }
 
 /* received RLC/MAC block from L1 */
@@ -1383,8 +1427,10 @@ int gprs_rlcmac_pdch::rcv_block(uint8_t *data, uint8_t len, uint32_t fn,
         }
                 
         LOGP(DRLCMACUL, LOGL_DEBUG, "Got RLC block, coding scheme: %s, "
-                "length: %d (%d))\n", cs.name(), len, cs.maxBytesUL());
+                "length: %d \n", cs.name(), len);
                         
+        LOGP(DRLCMACUL, LOGL_DEBUG, "UL data: %s\n", osmo_hexdump(data, len));
+
         if (cs.isGprs())
                 return rcv_block_gprs(data, fn, meas, cs);
                 
diff --git a/src/bts.h b/src/bts.h
index 7e3ea80..33a5f7c 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -303,7 +303,7 @@ public:
 	GprsMsStorage &ms_store();
 	GprsMs *ms_by_tlli(uint32_t tlli, uint32_t old_tlli = 0);
 	GprsMs *ms_by_imsi(const char *imsi);
-	GprsMs *ms_alloc(uint8_t ms_class, uint8_t egprs_ms_class = 0);
+	GprsMs *ms_alloc(uint8_t ms_class, uint8_t egprs_ms_class = 0, bool is_fanr_capable = false);
 
 	/*
 	 * Statistics
diff --git a/src/decoding.cpp b/src/decoding.cpp
index 2a57bed..649f68d 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -20,7 +20,7 @@
 #include <decoding.h>
 #include <rlc.h>
 #include <gprs_debug.h>
-
+#include "bts.h"
 #include <arpa/inet.h>
 
 #include <errno.h>
@@ -347,6 +347,12 @@ uint8_t Decoding::get_egprs_ms_class_by_capability(MS_Radio_Access_capability_t
 	return 0;
 }
 
+bool Decoding::is_ms_fanr_capable(MS_Radio_Access_capability_t *cap)
+{
+	/*TODO*/
+	return false;
+}
+
 void Decoding::extract_egprs_urbb(uint16_t urbb_length, const uint8_t *urbb, char *show_rbb)
 {
         for (int i = 0; i < urbb_length; i++) {
@@ -376,18 +382,311 @@ void Decoding::extract_rbb(const uint8_t *rbb, char *show_rbb)
 	show_rbb[64] = '\0';
 }
 
-int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
-	const uint8_t *data, GprsCodingScheme cs)
+int Decoding::decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
 {
-	const struct rlc_ul_header *gprs;
 	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+
+	const struct gprs_rlc_ul_header_egprs_fanr_type1 *egprs1;
+	egprs1 = static_cast<struct gprs_rlc_ul_header_egprs_fanr_type1*>
+		((void *)data);
+	rlc->r      = egprs1->r;
+	rlc->si     = egprs1->si;
+	rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
+	rlc->cps    = egprs1->cps;
+	rlc->rsb    = egprs1->rsb;
+	rlc->cv     = egprs1->cv;
+	rlc->pani     = egprs1->pani;
+
+	rlc->num_data_blocks = 2;
+	rlc->block_info[0].cv  = egprs1->cv;
+	rlc->block_info[0].pi  = egprs1->pi;
+	rlc->block_info[0].bsn =
+		(egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
+
+	rlc->block_info[0].spb = 0;
+
+	rlc->block_info[1].cv  = egprs1->cv;
+	rlc->block_info[1].pi  = egprs1->pi;
+
+	rlc->block_info[1].bsn = rlc->block_info[0].bsn + ((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
+	rlc->block_info[1].bsn = (rlc->block_info[1].bsn + 2048) % 2047;
+
+	rlc->block_info[0].e   = (data[6] & 0x01);
+	rlc->block_info[0].ti  = (data[6] &  0x02) >> 1;
+	rlc->block_info[1].e   = (data[6 + data_len + 1] & 0x01);
+	rlc->block_info[1].ti  = (data[6 + data_len + 1] &  0x02) >> 1;
+	rlc->block_info[1].spb = 0;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->block_info[1].data_len = data_len;
+	rlc->data_offs_bytes[0] = 7;
+	rlc->data_offs_bytes[1] = 7 + data_len + 1;
+	return 0;
+}
+
+int Decoding::decode_ul_data_type1(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
+{
+	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+
+	const struct gprs_rlc_ul_header_egprs_1 *egprs1;
+	egprs1 = static_cast<struct gprs_rlc_ul_header_egprs_1 *>
+		((void *)data);
+	rlc->r      = egprs1->r;
+	rlc->si     = egprs1->si;
+	rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
+	rlc->cps    = egprs1->cps;
+	rlc->rsb    = egprs1->rsb;
+	rlc->cv     = egprs1->cv;
+	rlc->pani     = 0;
+
+	rlc->num_data_blocks = 2;
+	rlc->block_info[0].cv  = egprs1->cv;
+	rlc->block_info[0].pi  = egprs1->pi;
+	rlc->block_info[0].bsn =
+		(egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
+	/* data base initialisation not from received block */
+	rlc->block_info[0].spb = 0;
+
+	rlc->block_info[1].cv  = egprs1->cv;
+	rlc->block_info[1].pi  = egprs1->pi;
+
+	rlc->block_info[1].bsn = rlc->block_info[0].bsn + ((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
+	rlc->block_info[1].bsn = (rlc->block_info[1].bsn + 2048) % 2047;
+
+	rlc->block_info[0].e   = (data[6] & 0x01);
+	rlc->block_info[0].ti  = (data[6] &  0x02) >> 1;
+	rlc->block_info[1].e   = (data[6 + data_len + 1] & 0x01);
+	rlc->block_info[1].ti  = (data[6 + data_len + 1] &  0x02) >> 1;
+	rlc->block_info[1].spb = 0;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->block_info[1].data_len = data_len;
+	rlc->data_offs_bytes[0] = 7;
+	rlc->data_offs_bytes[1] = 7 + data_len + 1;
+	return 0;
+}
+
+int Decoding::decode_ul_data_fanr_type2(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
+{
+	uint8_t   pad_bytes = 6;
+	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+	const struct gprs_rlc_ul_header_egprs_fanr_type2 *egprs2;
+	egprs2 = static_cast<struct gprs_rlc_ul_header_egprs_fanr_type2*>
+		((void *)data);
+	rlc->r      = egprs2->r;
+	rlc->si     = egprs2->si;
+	rlc->tfi    = (egprs2->tfi_a << 0)  | (egprs2->tfi_b << 2);
+	rlc->cps    = (egprs2->cps_a << 0)  | (egprs2->cps_b << 2);
+	rlc->rsb    = egprs2->rsb;
+	rlc->cv     = egprs2->cv;
+	rlc->pani     = egprs2->pani;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs2->cv;
+	rlc->block_info[0].pi  = egprs2->pi;
+	rlc->block_info[0].bsn =
+		(egprs2->bsn1_a << 0) | (egprs2->bsn1_b << 5);
+
+	/* data base initialisation not from received block */
+	rlc->block_info[0].spb = 0;
+
+	rlc->block_info[0].e   = (data[5] & 0x01);
+	rlc->block_info[0].ti  = (data[5] &  0x02) >> 1;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->data_offs_bytes[0] = 6;
+
+	if(*cs == GprsCodingScheme::MCS6){
+		if(rlc->cps == 2 || rlc->cps == 3 ){
+			rlc->block_info[0].data_len -= pad_bytes;
+			rlc->data_offs_bytes[0] += pad_bytes;
+			rlc->block_info[0].e   = (data[5 + pad_bytes] & 0x01);
+			rlc->block_info[0].ti  = (data[5 + pad_bytes] &  0x02) >> 1;
+		}
+	}
+	return 0;
+}
+
+int Decoding::decode_ul_data_type2(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
+{
+	uint8_t   pad_bytes = 6;
+	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+
+	const struct gprs_rlc_ul_header_egprs_2 *egprs2;
+	egprs2 = static_cast<struct gprs_rlc_ul_header_egprs_2 *>
+		((void *)data);
+	rlc->r      = egprs2->r;
+	rlc->si     = egprs2->si;
+	rlc->tfi    = (egprs2->tfi_a << 0)  | (egprs2->tfi_b << 2);
+	rlc->cps    = (egprs2->cps_a << 0)  | (egprs2->cps_b << 2);
+	rlc->rsb    = egprs2->rsb;
+	rlc->cv     = egprs2->cv;
+	rlc->pani     = 0;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs2->cv;
+	rlc->block_info[0].pi  = egprs2->pi;
+	rlc->block_info[0].bsn =
+		(egprs2->bsn1_a << 0) | (egprs2->bsn1_b << 5);
+
+	/* data base initialisation not from received block */
+	rlc->block_info[0].spb = 0;
+
+	rlc->block_info[0].e   = (data[5] & 0x01);
+	rlc->block_info[0].ti  = (data[5] &  0x02) >> 1;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->data_offs_bytes[0] = 6;
+
+	if(*cs == GprsCodingScheme::MCS6){
+		if(rlc->cps == 2 || rlc->cps == 3 ){
+			rlc->block_info[0].data_len -= pad_bytes;
+			rlc->data_offs_bytes[0] += pad_bytes;
+			rlc->block_info[0].e   = (data[5 + pad_bytes] & 0x01);
+			rlc->block_info[0].ti  = (data[5 + pad_bytes] &  0x02) >> 1;
+		}
+	}
+	return 0;
+}
+
+int Decoding::decode_ul_data_fanr_type3(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
+{
+	uint8_t   pad_bytes = 6;
+	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+
+	const struct gprs_rlc_ul_header_egprs_fanr_type3 *egprs3;
+	egprs3 = static_cast<struct gprs_rlc_ul_header_egprs_fanr_type3*>
+		((void *)data);
+	rlc->r      = egprs3->r;
+	rlc->si     = egprs3->si;
+	rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
+	rlc->cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
+	rlc->rsb    = egprs3->rsb;
+	rlc->cv     = egprs3->cv;
+	rlc->pani     = egprs3->pani;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs3->cv;
+	rlc->block_info[0].pi  = egprs3->pi;
+	rlc->block_info[0].spb = egprs3->spb;
+	rlc->block_info[0].bsn =
+		(egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
+
+	rlc->block_info[0].e   = (data[4] & 0x01);
+	rlc->block_info[0].ti  = (data[4] &  0x02) >> 1;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->data_offs_bytes[0] = 5;
+
+	if(rlc->block_info[0].spb == 2){
+		if(*cs == GprsCodingScheme::MCS3){
+			if(rlc->cps == 6 || rlc->cps == 7 || rlc->cps == 8){
+				rlc->block_info[0].data_len -= pad_bytes;
+				rlc->data_offs_bytes[0] += pad_bytes;
+				rlc->block_info[0].e   = (data[4 + pad_bytes] & 0x01);
+				rlc->block_info[0].ti  = (data[4 + pad_bytes] &  0x02) >> 1;
+			}
+		}
+	}
+	return 0;
+}
+
+int Decoding::decode_ul_data_type3(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme* cs)
+{
 	uint8_t   pad_bytes = 6;
+	unsigned int data_len = 0;
+	data_len = cs->maxDataBlockBytes();
+
+	const struct gprs_rlc_ul_header_egprs_3 *egprs3;
+	egprs3 = static_cast<struct gprs_rlc_ul_header_egprs_3 *>
+		((void *)data);
+	rlc->r      = egprs3->r;
+	rlc->si     = egprs3->si;
+	rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
+	rlc->cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
+	rlc->rsb    = egprs3->rsb;
+	rlc->cv     = egprs3->cv;
+	rlc->pani     = 0;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs3->cv;
+	rlc->block_info[0].pi  = egprs3->pi;
+	rlc->block_info[0].spb = egprs3->spb;
+	rlc->block_info[0].bsn =
+		(egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
+
+	rlc->block_info[0].e   = (data[4] & 0x01);
+	rlc->block_info[0].ti  = (data[4] &  0x02) >> 1;
+
+	rlc->block_info[0].data_len = data_len;
+	rlc->data_offs_bytes[0] = 5;
+
+	if(rlc->block_info[0].spb == 2){
+		if(*cs == GprsCodingScheme::MCS3){
+			if(rlc->cps == 6 || rlc->cps == 7 || rlc->cps == 8){
+				rlc->block_info[0].data_len -= pad_bytes;
+				rlc->data_offs_bytes[0] += pad_bytes;
+				rlc->block_info[0].e   = (data[4 + pad_bytes] & 0x01);
+				rlc->block_info[0].ti  = (data[4 + pad_bytes] &  0x02) >> 1;
+			}
+		}
+	}
+	return 0;
+}
+
+int Decoding::rlc_parse_ul_data_header_egprs(struct gprs_rlc_ul_header_generic *rlc,
+	const uint8_t *data, GprsCodingScheme cs, struct gprs_rlcmac_ul_tbf *tbf)
+{
 	rlc->cs = cs;
+	if (tbf->is_fanr_enabled()) {
+		if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3 == cs.headerTypeData()) {
+			decode_ul_data_fanr_type3(rlc,data,&cs);
+		}else if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2 == cs.headerTypeData()) {
+			decode_ul_data_fanr_type2(rlc,data,&cs);
+		}else if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 == cs.headerTypeData()) {
+			decode_ul_data_fanr_type1(rlc,data,&cs);
+		}else{
+			LOGP(DRLCMACUL, LOGL_ERROR, "Not a Valid TYPE (%d) for fanr Egprs Type\n",
+					cs.headerTypeData());
+			return -ENOTSUP;
+		}
+	}else{
+		if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3 == cs.headerTypeData()) {
+			decode_ul_data_type3(rlc,data,&cs);
+		}else if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2 == cs.headerTypeData()) {
+			decode_ul_data_type2(rlc,data,&cs);
+		}else if (GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 == cs.headerTypeData()) {
+			decode_ul_data_type1(rlc,data,&cs);
+		}else {
+			LOGP(DRLCMACUL, LOGL_ERROR, "Not a Valid TYPE (%d) for Normal Egprs Type\n",
+					cs.headerTypeData());
+			return -ENOTSUP;
+		}
+	}
+	return 0;
+}
 
+
+int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
+	const uint8_t *data, GprsCodingScheme cs)
+{
+	const struct rlc_ul_header *gprs;
+	rlc->cs = cs;
+	unsigned int data_len = 0;
 	data_len = cs.maxDataBlockBytes();
 
-	switch(cs.headerTypeData()) {
-	case GprsCodingScheme::HEADER_GPRS_DATA:
+	if(GprsCodingScheme::HEADER_GPRS_DATA == cs.headerTypeData()){
 		gprs = static_cast<struct rlc_ul_header *>
 			((void *)data);
 		rlc->r      = gprs->r;
@@ -395,7 +694,7 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
 		rlc->tfi    = gprs->tfi;
 		rlc->cps    = 0;
 		rlc->rsb    = 0;
-		rlc->pani= 0;
+		rlc->pani   = 0;
 
 		rlc->num_data_blocks = 1;
 		rlc->block_info[0].cv  = gprs->cv;
@@ -404,133 +703,13 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
 		rlc->block_info[0].e   = gprs->e;
 		rlc->block_info[0].ti  = gprs->ti;
 		rlc->block_info[0].spb = 0;
-                rlc->data_offs_bytes[0] = 3;
+		rlc->data_offs_bytes[0] = 3;
 
 		rlc->block_info[0].data_len = data_len;
-
-		break;
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3:
-		const struct gprs_rlc_ul_header_egprs_3 *egprs3;
-		egprs3 = static_cast<struct gprs_rlc_ul_header_egprs_3 *>
-                        ((void *)data);
-                rlc->r      = egprs3->r;
-                rlc->si     = egprs3->si;
-                rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
-                rlc->cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
-                rlc->rsb    = egprs3->rsb;
-                rlc->cv     = egprs3->cv;
-                /* pani 0 for fanr inactive */
-		rlc->pani     = 0;
-
-                rlc->num_data_blocks = 1;
-                rlc->block_info[0].cv  = egprs3->cv;
-                rlc->block_info[0].pi  = egprs3->pi;
-                rlc->block_info[0].spb = egprs3->spb;
-                rlc->block_info[0].bsn =
-                        (egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
-
-                rlc->block_info[0].e   = (data[4] & 0x01);
-                rlc->block_info[0].ti  = (data[4] &  0x02) >> 1;
-
-                rlc->block_info[0].data_len = data_len;
-                rlc->data_offs_bytes[0] = 5;
-
-		if(rlc->block_info[0].spb == 2){
-			if(cs == GprsCodingScheme::MCS3){ 
-				if(rlc->cps == 6 || rlc->cps == 7 || rlc->cps == 8){
-        	        		rlc->block_info[0].data_len -= pad_bytes;
-               				rlc->data_offs_bytes[0] += pad_bytes;
-                			rlc->block_info[0].e   = (data[4 + pad_bytes] & 0x01);
-			                rlc->block_info[0].ti  = (data[4 + pad_bytes] &  0x02) >> 1;
-				}
-			}
-		}
-		break;
-
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2:
-		const struct gprs_rlc_ul_header_egprs_2 *egprs2;
-		egprs2 = static_cast<struct gprs_rlc_ul_header_egprs_2 *>
-                        ((void *)data);
-                rlc->r      = egprs2->r;
-                rlc->si     = egprs2->si;
-                rlc->tfi    = (egprs2->tfi_a << 0)  | (egprs2->tfi_b << 2);
-                rlc->cps    = (egprs2->cps_a << 0)  | (egprs2->cps_b << 2);
-                rlc->rsb    = egprs2->rsb;
-                rlc->cv     = egprs2->cv;
-                /* pani 0 for fanr inactive */
-		rlc->pani     = 0;
-
-                rlc->num_data_blocks = 1;
-                rlc->block_info[0].cv  = egprs2->cv;
-                rlc->block_info[0].pi  = egprs2->pi;
-                rlc->block_info[0].bsn =
-                        (egprs2->bsn1_a << 0) | (egprs2->bsn1_b << 5);
-
-		/* data base initialisation not from received block */
-		rlc->block_info[0].spb = 0;
-
-                rlc->block_info[0].e   = (data[5] & 0x01);
-                rlc->block_info[0].ti  = (data[5] &  0x02) >> 1;
-
-                rlc->block_info[0].data_len = data_len;
-                rlc->data_offs_bytes[0] = 6;
-
-		if(cs == GprsCodingScheme::MCS6){ 
-			if(rlc->cps == 2 || rlc->cps == 3 ){
-        	        	rlc->block_info[0].data_len -= pad_bytes;
-               			rlc->data_offs_bytes[0] += pad_bytes;
-                		rlc->block_info[0].e   = (data[5 + pad_bytes] & 0x01);
-			        rlc->block_info[0].ti  = (data[5 + pad_bytes] &  0x02) >> 1;
-			}
-		}
-		break;
-
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1:
-		const struct gprs_rlc_ul_header_egprs_1 *egprs1;
-		egprs1 = static_cast<struct gprs_rlc_ul_header_egprs_1 *>
-                        ((void *)data);
-                rlc->r      = egprs1->r;
-                rlc->si     = egprs1->si;
-                rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
-                rlc->cps    = egprs1->cps;
-                rlc->rsb    = egprs1->rsb;
-                rlc->cv     = egprs1->cv;
-                /* pani 0 for fanr inactive */
-		rlc->pani     = 0;
-
-                rlc->num_data_blocks = 2;
-                rlc->block_info[0].cv  = egprs1->cv;
-                rlc->block_info[0].pi  = egprs1->pi;
-                rlc->block_info[0].bsn =
-                        (egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
-		/* data base initialisation not from received block */
-		rlc->block_info[0].spb = 0;
-
-		rlc->block_info[1].cv  = egprs1->cv;
-                rlc->block_info[1].pi  = egprs1->pi;
-		
-                rlc->block_info[1].bsn = rlc->block_info[0].bsn + ((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
-                rlc->block_info[1].bsn = (rlc->block_info[1].bsn + 2048) % 2047;
-
-                rlc->block_info[0].e   = (data[6] & 0x01);
-                rlc->block_info[0].ti  = (data[6] &  0x02) >> 1;
-                rlc->block_info[1].e   = (data[6 + data_len + 1] & 0x01);
-                rlc->block_info[1].ti  = (data[6 + data_len + 1] &  0x02) >> 1;
-		rlc->block_info[1].spb = 0;
-
-                rlc->block_info[0].data_len = data_len;
-                rlc->block_info[1].data_len = data_len;
-                rlc->data_offs_bytes[0] = 7;
-                rlc->data_offs_bytes[1] = 7 + data_len + 1;
-
-		break;
-	default:
-		LOGP(DRLCMACDL, LOGL_ERROR,
-			"Decoding of uplink %s data blocks not yet supported.\n",
-			cs.name());
+	}else{
+		LOGP(DRLCMACUL, LOGL_ERROR, "Not a Valid TYPE (%d)\n",cs.headerTypeData());
 		return -ENOTSUP;
-	};
-
+	}
 	return 0;
 }
 
diff --git a/src/decoding.h b/src/decoding.h
index ba0257f..25a9cf9 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -21,6 +21,7 @@
 
 #include <gsm_rlcmac.h>
 #include "gprs_coding_scheme.h"
+#include "tbf.h"
 #include "rlc.h"
 #include <stdint.h>
 
@@ -43,9 +44,32 @@ public:
 	static void extract_rbb(const uint8_t *rbb, char *extracted_rbb);
 	static void extract_egprs_urbb(uint16_t urbb_length, const uint8_t *urbb, char *show_rbb);
 	static uint8_t get_egprs_ms_class_by_capability(MS_Radio_Access_capability_t *cap);
+	static bool is_ms_fanr_capable(MS_Radio_Access_capability_t *cap);
 
 	static int rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
+
+	static int rlc_parse_ul_data_header_egprs(struct gprs_rlc_ul_header_generic *rlc,
+		const uint8_t *data, GprsCodingScheme cs, struct gprs_rlcmac_ul_tbf *tbf);
+
+	static int decode_ul_data_type3(struct gprs_rlc_ul_header_generic *rlc,
+			const uint8_t *data, GprsCodingScheme* cs);
+
+	static int decode_ul_data_fanr_type3(struct gprs_rlc_ul_header_generic *rlc,
+				const uint8_t *data, GprsCodingScheme* cs);
+
+	static int decode_ul_data_type2(struct gprs_rlc_ul_header_generic *rlc,
+				const uint8_t *data, GprsCodingScheme* cs);
+
+	static int decode_ul_data_fanr_type2(struct gprs_rlc_ul_header_generic *rlc,
+				const uint8_t *data, GprsCodingScheme* cs);
+
+	static int decode_ul_data_type1(struct gprs_rlc_ul_header_generic *rlc,
+				const uint8_t *data, GprsCodingScheme* cs);
+
+	static int decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
+				const uint8_t *data, GprsCodingScheme* cs);
+
 	static unsigned int rlc_copy_to_aligned_buffer(
 		const struct gprs_rlc_ul_header_generic *rlc,
 		unsigned int data_block_idx,
diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp
index 22ab8a8..cf6f41f 100644
--- a/src/gprs_bssgp_pcu.cpp
+++ b/src/gprs_bssgp_pcu.cpp
@@ -154,6 +154,13 @@ static int parse_egprs_ra_cap_ms_class(struct tlv_parsed *tp)
         bitvec_free(block);
         return egprs_ms_class;
 }
+
+static bool parse_egprs_ra_cap_ms_fanr_capable(struct tlv_parsed *tp)
+{
+	/*TODO*/
+        return false;
+}
+
 static int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp)
 {
 	struct bssgp_ud_hdr *budh;
@@ -192,6 +199,9 @@ static int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp)
 	/* parse egprs  ms radio access capability */
 	uint8_t egprs_ms_class = parse_egprs_ra_cap_ms_class(tp);
 
+	/* parse egprs  ms radio access capability to get fanr capability */
+	bool    is_fanr_capable = parse_egprs_ra_cap_ms_fanr_capable(tp);
+
 	/* get lifetime */
 	uint16_t delay_csec = 0xffff;
 	if (TLVP_PRESENT(tp, BSSGP_IE_PDU_LIFETIME))
@@ -221,7 +231,7 @@ static int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp)
 
 	LOGP(DBSSGP, LOGL_INFO, "LLC [SGSN -> PCU] = TLLI: 0x%08x IMSI: %s len: %d\n", tlli, imsi, len);
 	return gprs_rlcmac_dl_tbf::handle(the_pcu.bts, tlli, tlli_old, imsi,
-			ms_class, egprs_ms_class, delay_csec, data, len);
+			ms_class, egprs_ms_class, delay_csec, data, len, is_fanr_capable);
 }
 
 int gprs_bssgp_pcu_rx_paging_ps(struct msgb *msg, struct tlv_parsed *tp)
diff --git a/src/tbf.cpp b/src/tbf.cpp
index 93dd8c2..05f5c82 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -285,14 +285,14 @@ void gprs_rlcmac_tbf::update_ms(uint32_t tlli, enum gprs_rlcmac_tbf_direction di
 
 gprs_rlcmac_ul_tbf *tbf_alloc_ul(struct gprs_rlcmac_bts *bts,
 	int8_t use_trx, uint8_t ms_class, uint8_t egprs_ms_class,
-	uint32_t tlli, uint8_t ta, GprsMs *ms)
+	uint32_t tlli, uint8_t ta, GprsMs *ms, bool is_ms_fanr_capable)
 {
 	struct gprs_rlcmac_ul_tbf *tbf;
 
 #warning "Copy and paste with tbf_new_dl_assignment"
 	/* create new TBF, use same TRX as DL TBF */
 	/* use multislot class of downlink TBF */
-	tbf = tbf_alloc_ul_tbf(bts, ms, use_trx, ms_class, egprs_ms_class, 0);
+	tbf = tbf_alloc_ul_tbf(bts, ms, use_trx, ms_class, egprs_ms_class, 0, is_ms_fanr_capable);
 	if (!tbf) {
 		LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n");
 		/* FIXME: send reject */
@@ -611,7 +611,8 @@ static int ul_tbf_dtor(struct gprs_rlcmac_ul_tbf *tbf)
 
 struct gprs_rlcmac_ul_tbf *tbf_alloc_ul_tbf(struct gprs_rlcmac_bts *bts,
 	GprsMs *ms, int8_t use_trx,
-	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot)
+	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot,
+	bool is_ms_fanr_capable)
 {
 	struct gprs_rlcmac_ul_tbf *tbf;
 	int rc;
@@ -629,7 +630,7 @@ struct gprs_rlcmac_ul_tbf *tbf_alloc_ul_tbf(struct gprs_rlcmac_bts *bts,
 	new (tbf) gprs_rlcmac_ul_tbf(bts->bts);
 
 	if (!ms)
-		ms = bts->bts->ms_alloc(ms_class, egprs_ms_class);
+		ms = bts->bts->ms_alloc(ms_class, egprs_ms_class, is_ms_fanr_capable);
 
 	if (egprs_ms_class > 0 && bts->egprs_enabled) {
 		/* TODO: only for 8PSK, otherwise the GPRS MS class has to be used */
@@ -637,6 +638,9 @@ struct gprs_rlcmac_ul_tbf *tbf_alloc_ul_tbf(struct gprs_rlcmac_bts *bts,
 		tbf->m_window.set_sns(RLC_EGPRS_SNS);
 		tbf->m_window.set_ws(RLC_EGPRS_MIN_WS);
 	}
+	if((true == is_ms_fanr_capable) && bts->egprs_enabled ){
+		tbf->enable_fanr();
+	}
 
 	rc = setup_tbf(tbf, ms, use_trx, ms_class, egprs_ms_class, single_slot);
 	/* if no resource */
@@ -679,7 +683,7 @@ static int dl_tbf_dtor(struct gprs_rlcmac_dl_tbf *tbf)
 
 struct gprs_rlcmac_dl_tbf *tbf_alloc_dl_tbf(struct gprs_rlcmac_bts *bts,
         GprsMs *ms, int8_t use_trx,
-        uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot)
+        uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot, bool is_fanr_capable)
 {
 	struct gprs_rlcmac_dl_tbf *tbf;
 	int rc = -1;
@@ -703,11 +707,15 @@ struct gprs_rlcmac_dl_tbf *tbf_alloc_dl_tbf(struct gprs_rlcmac_bts *bts,
                 tbf->m_window.set_ws(RLC_EGPRS_MIN_WS);
         }
 
+	if((true == is_fanr_capable) && (bts->fanr_enabled)){
+		tbf->enable_fanr();
+	}
+
 	if (!ms)
         {
-                ms = bts->bts->ms_alloc(ms_class, egprs_ms_class);
+                ms = bts->bts->ms_alloc(ms_class, egprs_ms_class, is_fanr_capable);
         }
-		rc = setup_tbf(tbf, ms, use_trx, ms_class, egprs_ms_class, single_slot);
+	rc = setup_tbf(tbf, ms, use_trx, ms_class, egprs_ms_class, single_slot);
 	/* if no resource */
 	if (rc < 0) {
 		talloc_free(tbf);
@@ -1038,7 +1046,7 @@ int gprs_rlcmac_tbf::establish_dl_tbf_on_pacch()
 	bts->tbf_reused();
 	new_tbf = tbf_alloc_dl_tbf(bts->bts_data(), ms(),
 		this->trx->trx_no, ms_class(),
-		ms() ?  ms()->egprs_ms_class() : 0, 0);
+		ms() ?  ms()->egprs_ms_class() : 0, 0, 0);
 	if (!new_tbf) {
 		LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n");
 		return -1;
diff --git a/src/tbf.h b/src/tbf.h
index 6e482c7..a6878d7 100644
--- a/src/tbf.h
+++ b/src/tbf.h
@@ -271,14 +271,16 @@ private:
 
 struct gprs_rlcmac_ul_tbf *tbf_alloc_ul(struct gprs_rlcmac_bts *bts,
 	int8_t use_trx, uint8_t ms_class, uint8_t egprs_ms_class,
-	uint32_t tlli, uint8_t ta, GprsMs *ms);
+	uint32_t tlli, uint8_t ta, GprsMs *ms, bool is_ms_fanr_capable);
 
 struct gprs_rlcmac_ul_tbf *tbf_alloc_ul_tbf(struct gprs_rlcmac_bts *bts,
 	GprsMs *ms, int8_t use_trx,
-	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot);
+	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot,
+	bool is_ms_fanr_capable);
+
 struct gprs_rlcmac_dl_tbf *tbf_alloc_dl_tbf(struct gprs_rlcmac_bts *bts,
 	GprsMs *ms, int8_t use_trx,
-	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot);
+	uint8_t ms_class, uint8_t egprs_ms_class, uint8_t single_slot, bool is_fanr_capable);
 
 void tbf_free(struct gprs_rlcmac_tbf *tbf);
 
@@ -365,7 +367,7 @@ struct gprs_rlcmac_dl_tbf : public gprs_rlcmac_tbf {
                 const uint32_t tlli, const uint32_t tlli_old, const char *imsi,
                 const uint8_t ms_class, const uint8_t egprs_ms_class,
                 const uint16_t delay_csec,
-                const uint8_t *data, const uint16_t len);
+                const uint8_t *data, const uint16_t len, bool is_fanr_capable);
 	int append_data(const uint8_t ms_class,
 			const uint16_t pdu_delay_csec,
 			const uint8_t *data, const uint16_t len);
@@ -479,7 +481,7 @@ struct gprs_rlcmac_ul_tbf : public gprs_rlcmac_tbf {
 	/* blocks were acked */
 	int rcv_data_block_acknowledged(
 		const struct gprs_rlc_ul_header_generic *rlc,
-		uint8_t *data, uint8_t len, struct pcu_l1_meas *meas);
+		uint8_t *data,struct pcu_l1_meas *meas);
 	/* In case of re segmentation process the spb values and decides
 		 weather original block is rebuilt 
 	*/
diff --git a/src/tbf_dl.cpp b/src/tbf_dl.cpp
index a2f6324..a909d9d 100644
--- a/src/tbf_dl.cpp
+++ b/src/tbf_dl.cpp
@@ -137,7 +137,8 @@ static int tbf_new_dl_assignment(struct gprs_rlcmac_bts *bts,
                                 const uint32_t tlli, const uint32_t tlli_old,
                                 const uint8_t ms_class,
                                 const uint8_t egprs_ms_class,
-                                struct gprs_rlcmac_dl_tbf **tbf)
+                                struct gprs_rlcmac_dl_tbf **tbf,
+				bool   is_fanr_capable)
 {
 	uint8_t ss;
 	int8_t use_trx;
@@ -171,7 +172,7 @@ static int tbf_new_dl_assignment(struct gprs_rlcmac_bts *bts,
 #warning "Copy and paste with alloc_ul_tbf"
 	/* set number of downlink slots according to multislot class */
 
-        dl_tbf = tbf_alloc_dl_tbf(bts, ms, use_trx, ms_class, egprs_ms_class, ss);
+        dl_tbf = tbf_alloc_dl_tbf(bts, ms, use_trx, ms_class, egprs_ms_class, ss, is_fanr_capable);
 
 	if (!dl_tbf) {
 		LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n");
@@ -200,7 +201,8 @@ static int tbf_new_dl_assignment(struct gprs_rlcmac_bts *bts,
 int gprs_rlcmac_dl_tbf::handle(struct gprs_rlcmac_bts *bts,
 		const uint32_t tlli, const uint32_t tlli_old, const char *imsi,
 		const uint8_t ms_class, const uint8_t egprs_ms_class,
-		const uint16_t delay_csec, const uint8_t *data, const uint16_t len)
+		const uint16_t delay_csec, const uint8_t *data, const uint16_t len,
+		bool is_fanr_capable)
 {
 	struct gprs_rlcmac_dl_tbf *dl_tbf = NULL;
 	int rc;
@@ -246,7 +248,7 @@ int gprs_rlcmac_dl_tbf::handle(struct gprs_rlcmac_bts *bts,
 
 	if (!dl_tbf) {
                 rc = tbf_new_dl_assignment(bts, imsi, tlli, tlli_old,
-                        ms_class, egprs_ms_class, &dl_tbf);
+                        ms_class, egprs_ms_class, &dl_tbf, is_fanr_capable);
 		if (rc < 0)
 			return rc;
 	}
diff --git a/src/tbf_ul.cpp b/src/tbf_ul.cpp
index 9de1b6b..e89ac14 100644
--- a/src/tbf_ul.cpp
+++ b/src/tbf_ul.cpp
@@ -209,7 +209,7 @@ egprs_rlc_ul_reseg_bsn_state gprs_rlcmac_ul_tbf::assemble_rlc_block_frm_segmente
 
 int gprs_rlcmac_ul_tbf::rcv_data_block_acknowledged(
 	const struct gprs_rlc_ul_header_generic *rlc,
-	uint8_t *data, uint8_t len, struct pcu_l1_meas *meas)
+	uint8_t *data, struct pcu_l1_meas *meas)
 {
 	int8_t rssi = meas->have_rssi ? meas->rssi : 0;
 
diff --git a/tests/alloc/AllocTest.cpp b/tests/alloc/AllocTest.cpp
index d338b78..e7b1e45 100644
--- a/tests/alloc/AllocTest.cpp
+++ b/tests/alloc/AllocTest.cpp
@@ -43,10 +43,10 @@ static gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_bts *bts,
 {
 	if (dir == GPRS_RLCMAC_UL_TBF)
 		return tbf_alloc_ul_tbf(bts, ms, use_trx,
-			ms_class, egprs_ms_class, single_slot);
+			ms_class, egprs_ms_class, single_slot, false);
 	else
 		return tbf_alloc_dl_tbf(bts, ms, use_trx,
-			ms_class, egprs_ms_class, single_slot);
+			ms_class, egprs_ms_class, single_slot, false);
 }
 
 static void check_tfi_usage(BTS *the_bts)
@@ -202,7 +202,7 @@ static void test_alloc_b(int ms_class)
 		trx->pdch[6].enable();
 		trx->pdch[7].enable();
 
-		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, -1, ms_class, 0, 1);
+		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, -1, ms_class, 0, 1, false);
 		OSMO_ASSERT(ul_tbf);
 		OSMO_ASSERT(ul_tbf->ms());
 		OSMO_ASSERT(ul_tbf->ms()->current_trx());
@@ -210,7 +210,7 @@ static void test_alloc_b(int ms_class)
 		dump_assignment(ul_tbf, "UL");
 
 		/* assume final ack has not been sent */
-		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0);
+		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0, false);
 		OSMO_ASSERT(dl_tbf);
 		dump_assignment(dl_tbf, "DL");
 
@@ -244,7 +244,7 @@ static void test_alloc_b(int ms_class)
 		trx->pdch[6].enable();
 		trx->pdch[7].enable();
 
-		dl_tbf = tbf_alloc_dl_tbf(bts, NULL, -1, ms_class, 0, 1);
+		dl_tbf = tbf_alloc_dl_tbf(bts, NULL, -1, ms_class, 0, 1, false);
 		dl_tbf->update_ms(0x23, GPRS_RLCMAC_DL_TBF);
 		OSMO_ASSERT(dl_tbf);
 		OSMO_ASSERT(dl_tbf->ms());
@@ -252,7 +252,7 @@ static void test_alloc_b(int ms_class)
 		trx_no = dl_tbf->ms()->current_trx()->trx_no;
 		dump_assignment(dl_tbf, "DL");
 
-		ul_tbf = tbf_alloc_ul_tbf(bts, dl_tbf->ms(), trx_no, ms_class, 0, 0);
+		ul_tbf = tbf_alloc_ul_tbf(bts, dl_tbf->ms(), trx_no, ms_class, 0, 0, false);
 		ul_tbf->update_ms(0x23, GPRS_RLCMAC_UL_TBF);
 		ul_tbf->m_contention_resolution_done = 1;
 		OSMO_ASSERT(ul_tbf);
@@ -294,7 +294,7 @@ static void test_alloc_b(int ms_class)
 
 		tfi = the_bts.tfi_find_free(GPRS_RLCMAC_UL_TBF, &trx_no, -1);
 		OSMO_ASSERT(tfi >= 0);
-		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, .1, ms_class, 0, 0);
+		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, .1, ms_class, 0, 0, false);
 		OSMO_ASSERT(ul_tbf);
 		OSMO_ASSERT(ul_tbf->ms());
 		OSMO_ASSERT(ul_tbf->ms()->current_trx());
@@ -302,7 +302,7 @@ static void test_alloc_b(int ms_class)
 		dump_assignment(ul_tbf, "UL");
 
 		/* assume final ack has not been sent */
-		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0);
+		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0, false);
 		OSMO_ASSERT(dl_tbf);
 		dump_assignment(dl_tbf, "DL");
 
@@ -357,14 +357,14 @@ static void test_alloc_b(bool ts0, bool ts1, bool ts2, bool ts3, bool ts4, bool
 		ENABLE_PDCH(6, ts6, trx);
 		ENABLE_PDCH(7, ts7, trx);
 
-		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, -1, ms_class, 0, 1);
+		ul_tbf = tbf_alloc_ul_tbf(bts, NULL, -1, ms_class, 0, 1, false);
 		OSMO_ASSERT(ul_tbf->ms());
 		OSMO_ASSERT(ul_tbf->ms()->current_trx());
 		trx_no = ul_tbf->ms()->current_trx()->trx_no;
 		OSMO_ASSERT(ul_tbf);
 
 		/* assume final ack has not been sent */
-		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0);
+		dl_tbf = tbf_alloc_dl_tbf(bts, ul_tbf->ms(), trx_no, ms_class, 0, 0, false);
 		OSMO_ASSERT(dl_tbf);
 
 		/* verify that both are on the same ts */
@@ -401,14 +401,14 @@ static void test_alloc_b(bool ts0, bool ts1, bool ts2, bool ts3, bool ts4, bool
 		ENABLE_PDCH(6, ts6, trx);
 		ENABLE_PDCH(7, ts7, trx);
 
-		dl_tbf = tbf_alloc_dl_tbf(bts, NULL, -1, ms_class, 0, 1);
+		dl_tbf = tbf_alloc_dl_tbf(bts, NULL, -1, ms_class, 0, 1, false);
 		OSMO_ASSERT(dl_tbf);
 		OSMO_ASSERT(dl_tbf->ms());
 		OSMO_ASSERT(dl_tbf->ms()->current_trx());
 		trx_no = dl_tbf->ms()->current_trx()->trx_no;
 		dl_tbf->update_ms(0x23, GPRS_RLCMAC_DL_TBF);
 
-		ul_tbf = tbf_alloc_ul_tbf(bts, dl_tbf->ms(), trx_no, ms_class, 0, 0);
+		ul_tbf = tbf_alloc_ul_tbf(bts, dl_tbf->ms(), trx_no, ms_class, 0, 0, false);
 		OSMO_ASSERT(ul_tbf);
 		ul_tbf->update_ms(0x23, GPRS_RLCMAC_UL_TBF);
 		ul_tbf->m_contention_resolution_done = 1;
@@ -497,7 +497,7 @@ static GprsMs *alloc_tbfs(BTS *the_bts, GprsMs *ms, unsigned ms_class,
 	case TEST_MODE_UL_AND_DL:
 		if (ms && ms->ul_tbf())
 			tbf_free(ms->ul_tbf());
-		tbf = tbf_alloc_ul_tbf(bts, ms, trx_no, ms_class, 0, 0);
+		tbf = tbf_alloc_ul_tbf(bts, ms, trx_no, ms_class, 0, 0, false);
 		if (tbf == NULL)
 			return NULL;
 		break;
@@ -506,7 +506,7 @@ static GprsMs *alloc_tbfs(BTS *the_bts, GprsMs *ms, unsigned ms_class,
 	case TEST_MODE_DL_AND_UL:
 		if (ms && ms->dl_tbf())
 			tbf_free(ms->dl_tbf());
-		tbf = tbf_alloc_dl_tbf(bts, ms, trx_no, ms_class, 0, 0);
+		tbf = tbf_alloc_dl_tbf(bts, ms, trx_no, ms_class, 0, 0, false);
 		if (tbf == NULL)
 			return NULL;
 	}
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index 2abcd8f..7177832 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -251,12 +251,12 @@ static void test_rlc_decoder()
 	 */
 	gprs_rlcmac_tbf *dl_tbf = tbf_alloc_dl_tbf(the_bts.bts_data(),
 						NULL,
-						0, 0, 4, 0);
+						0, 0, 4, 0, false);
 	OSMO_ASSERT(dl_tbf != NULL);
 
 	gprs_rlcmac_tbf *ul_tbf = tbf_alloc_ul_tbf(the_bts.bts_data(),
 						dl_tbf->ms(),
-						0, 0, 4, 0);
+						0, 0, 4, 0, false);
 	/*
 	bts.cpp:1156 Got RLC block, coding scheme: CS-4, length : 54 (53))
 bts.cpp:1200   UL data: 3c 02 02 33 0a ed 5d fe d8 00 8f 18 33 2c 16 45 03 c0 68 75 00 00 16 45 00 03 c5 62 29 40 00 45 06 4e b6 c0 a8 00 02 c0 a8 00 01 86 74 1f 91 17 ac 35 ee 33 5e 
@@ -1055,7 +1055,7 @@ void send_dl_data(BTS *the_bts, uint32_t tlli, const char *imsi,
 	ms = the_bts->ms_store().get_ms(tlli, 0, imsi);
 
 	gprs_rlcmac_dl_tbf::handle(the_bts->bts_data(), tlli, 0, imsi, 0, 0,
-		1000, data, data_size);
+		1000, data, data_size, false);
 
 	ms = the_bts->ms_by_imsi(imsi);
 	OSMO_ASSERT(ms != NULL);
@@ -1079,7 +1079,7 @@ static gprs_rlcmac_dl_tbf *create_dl_tbf(BTS *the_bts, uint8_t ms_class,
 
 	tfi = the_bts->tfi_find_free(GPRS_RLCMAC_DL_TBF, &trx_no, -1);
 	OSMO_ASSERT(tfi >= 0);
-	dl_tbf = tbf_alloc_dl_tbf(bts, NULL, trx_no, ms_class, ms_class, 1);
+	dl_tbf = tbf_alloc_dl_tbf(bts, NULL, trx_no, ms_class, ms_class, 1, false);
 	check_tbf(dl_tbf);
 
 	/* "Establish" the DL TBF */
@@ -1093,7 +1093,7 @@ static gprs_rlcmac_dl_tbf *create_dl_tbf(BTS *the_bts, uint8_t ms_class,
 	return dl_tbf;
 }
 
-static void setup_bts(BTS *the_bts, uint8_t ts_no, uint8_t cs = 1)
+static void setup_bts(BTS *the_bts, uint8_t ts_no, uint8_t cs = 1, bool fanr_enable = false)
 {
 	gprs_rlcmac_bts *bts;
 	gprs_rlcmac_trx *trx;
@@ -1103,6 +1103,7 @@ static void setup_bts(BTS *the_bts, uint8_t ts_no, uint8_t cs = 1)
 	bts->alloc_algorithm = alloc_algorithm_a;
 	bts->initial_cs_dl = cs;
 	bts->initial_cs_ul = cs;
+	bts->fanr_enabled = fanr_enable;
 	trx = &bts->trx[0];
 
 	trx->pdch[ts_no].enable();
@@ -1260,11 +1261,11 @@ static gprs_rlcmac_ul_tbf *establish_ul_tbf_two_phase(BTS *the_bts,
 	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
 		MS_RA_capability_value[0].u.Content.Multislot_capability.
 		GPRS_multislot_class = ms_class;
-	
+
 	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
 		MS_RA_capability_value[0].u.Content.Multislot_capability.
 		Exist_EGPRS_multislot_class = 1;
-	
+
 	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
 		MS_RA_capability_value[0].u.Content.Multislot_capability.
 		EGPRS_multislot_class = ms_class;
@@ -1285,22 +1286,228 @@ static gprs_rlcmac_ul_tbf *establish_ul_tbf_two_phase(BTS *the_bts,
 
 	check_tbf(ul_tbf);
 
-	uint8_t data_msg[27] = {0};
+	uint8_t data_msg[200] = {0};
 	/* send fake data */
-	data_msg[0] = 0x00 | 0xf << 2; 
+	data_msg[0] = 0x00 | 0xf << 2;
 	data_msg[1] = uint8_t(0 | (tfi << 1));
 	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
 	data_msg[3] =uint8_t(0); /* BSN:7, E:1 */
 	data_msg[4] = uint8_t(1); /* E: 1 */
 
 	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
-	pdch->rcv_block(&data_msg[0], sizeof(data_msg), *fn, &meas);
-	
+	pdch->rcv_block(&data_msg[0], 27, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	ul_tbf->enable_fanr();
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 31, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(0 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 31, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 37, *fn, &meas);
+
 	ms = the_bts->ms_by_tlli(tlli);
 	OSMO_ASSERT(ms != NULL);
 	OSMO_ASSERT(ms->ta() == qta/4);
 	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(0 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 37, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 46, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(0 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
 
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 46, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 3); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 66, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(0 << 3); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 66, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 3); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 84, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(0 << 3); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 84, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[4] =uint8_t(1 << 7); /* BSN:7, E:1 */
+	data_msg[5] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0],124, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[4] =uint8_t(0 << 7); /* BSN:7, E:1 */
+	data_msg[5] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0],124, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[4] =uint8_t(1 << 7); /* BSN:7, E:1 */
+	data_msg[5] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0],148, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[4] =uint8_t(0 << 7); /* BSN:7, E:1 */
+	data_msg[5] = uint8_t(1); /* E: 1 */
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0],148, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
 	return ul_tbf;
 }
 
@@ -1449,7 +1656,7 @@ void test_tbf_two_phase()
 
 	printf("=== start %s ===\n", __func__);
 
-	setup_bts(&the_bts, ts_no, 9);
+	setup_bts(&the_bts, ts_no, 9, true);
 
 	ul_tbf = establish_ul_tbf_two_phase(&the_bts, ts_no, tlli, &fn, qta, ms_class);
 
@@ -2507,14 +2714,12 @@ void test_spb_handling()
         uint32_t tlli = 0xf1223344;
         const char *imsi = "0011223344";
         uint8_t ms_class = 1;
-        gprs_rlcmac_ul_tbf *ul_tbf;
-        GprsMs *ms;
 
         printf("=== start %s ===\n", __func__);
 
         setup_bts(&the_bts, ts_no, 7);
 
-        ul_tbf = spb_handler(&the_bts, ts_no, tlli, &fn, qta, ms_class);
+        spb_handler(&the_bts, ts_no, tlli, &fn, qta, ms_class);
 
 }
 
diff --git a/tests/tbf/TbfTest.cpp b/tests/tbf/TbfTest.cpp
index 8bf735a..26e09e6 100644
--- a/tests/tbf/TbfTest.cpp
+++ b/tests/tbf/TbfTest.cpp
@@ -90,14 +90,14 @@ static void test_tbf_tlli_update()
 	 */
 	gprs_rlcmac_tbf *dl_tbf = tbf_alloc_dl_tbf(the_bts.bts_data(),
 						NULL,
-						0, 0, 0, 0);
+						0, 0, 0, 0, false);
 	OSMO_ASSERT(dl_tbf != NULL);
 	dl_tbf->update_ms(0x2342, GPRS_RLCMAC_DL_TBF);
 	dl_tbf->set_ta(4);
 
 	gprs_rlcmac_tbf *ul_tbf = tbf_alloc_ul_tbf(the_bts.bts_data(),
 						dl_tbf->ms(),
-						0, 0, 0, 0);
+						0, 0, 0, 0, false);
 	OSMO_ASSERT(ul_tbf != NULL);
 	ul_tbf->update_ms(0x2342, GPRS_RLCMAC_UL_TBF);
 
@@ -175,7 +175,7 @@ static gprs_rlcmac_dl_tbf *create_dl_tbf(BTS *the_bts, uint8_t ms_class,
 
 	tfi = the_bts->tfi_find_free(GPRS_RLCMAC_DL_TBF, &trx_no, -1);
 	OSMO_ASSERT(tfi >= 0);
-	dl_tbf = tbf_alloc_dl_tbf(bts, NULL, trx_no, ms_class, 0, 1);
+	dl_tbf = tbf_alloc_dl_tbf(bts, NULL, trx_no, ms_class, 0, 1, false);
 	check_tbf(dl_tbf);
 
 	/* "Establish" the DL TBF */
@@ -452,7 +452,7 @@ static void test_tbf_exhaustion()
 		snprintf(imsi, sizeof(imsi), "001001%09d", i);
 
 		rc = gprs_rlcmac_dl_tbf::handle(bts, tlli, 0, imsi, ms_class, 0,
-			delay_csec, buf, sizeof(buf));
+			delay_csec, buf, sizeof(buf), false);
 
 		if (rc < 0)
 			break;
@@ -490,7 +490,7 @@ static void test_tbf_dl_llc_loss()
 	/* Handle LLC frame 1 */
 	memset(buf, 1, sizeof(buf));
 	rc = gprs_rlcmac_dl_tbf::handle(bts, tlli, 0, imsi, ms_class, 0,
-		delay_csec, buf, sizeof(buf));
+		delay_csec, buf, sizeof(buf), false);
 	OSMO_ASSERT(rc >= 0);
 
 	ms = the_bts.ms_store().get_ms(0, 0, imsi);
@@ -500,7 +500,7 @@ static void test_tbf_dl_llc_loss()
 	/* Handle LLC frame 2 */
 	memset(buf, 2, sizeof(buf));
 	rc = gprs_rlcmac_dl_tbf::handle(bts, tlli, 0, imsi, ms_class, 0,
-		delay_csec, buf, sizeof(buf));
+		delay_csec, buf, sizeof(buf), false);
 	OSMO_ASSERT(rc >= 0);
 
 	/* TBF establishment fails (timeout) */
@@ -509,7 +509,7 @@ static void test_tbf_dl_llc_loss()
 	/* Handle LLC frame 3 */
 	memset(buf, 3, sizeof(buf));
 	rc = gprs_rlcmac_dl_tbf::handle(bts, tlli, 0, imsi, ms_class, 0,
-		delay_csec, buf, sizeof(buf));
+		delay_csec, buf, sizeof(buf), false);
 	OSMO_ASSERT(rc >= 0);
 
 	OSMO_ASSERT(ms->dl_tbf() != NULL);
@@ -695,7 +695,7 @@ static void send_dl_data(BTS *the_bts, uint32_t tlli, const char *imsi,
 	ms = the_bts->ms_store().get_ms(tlli, 0, imsi);
 
 	gprs_rlcmac_dl_tbf::handle(the_bts->bts_data(), tlli, 0, imsi, 0, 0,
-		1000, data, data_size);
+		1000, data, data_size, false);
 
 	ms = the_bts->ms_by_imsi(imsi);
 	OSMO_ASSERT(ms != NULL);
-- 
1.7.9.5




From saurabh.sharan at radisys.com  Thu Mar 10 08:45:29 2016
From: saurabh.sharan at radisys.com (Saurabh Sharan)
Date: Thu, 10 Mar 2016 14:15:29 +0530
Subject: [PATCH] Fix encoding of padding bits to start with 0 bit
Message-ID: <1457599529-19440-1-git-send-email-saurabh.sharan@radisys.com>


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(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-encoding-of-padding-bits-to-start-with-0-bit.patch
Type: text/x-patch
Size: 12278 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160310/8065e441/attachment.bin>

From arvind.sirsikar at radisys.com  Thu Mar 10 08:52:24 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Thu, 10 Mar 2016 14:22:24 +0530
Subject: [PATCH] UT Expected error files TbfTest.err, EdgeTest.err for FANR
Message-ID: <1457599944-24309-1-git-send-email-arvind.sirsikar@radisys.com>


Modifies TbfTest.err, EdgeTest.err for FANR feature
---
 tests/edge/EdgeTest.err |  601 +++++++++++++++++++++++++++++------------------
 tests/tbf/TbfTest.err   |   90 ++++---
 2 files changed, 430 insertions(+), 261 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-UT-Expected-error-files-TbfTest.err-EdgeTest.err-for.patch
Type: text/x-patch
Size: 133107 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160310/885f6cf0/attachment.bin>

From msuraev at sysmocom.de  Thu Mar 10 09:52:19 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 10 Mar 2016 10:52:19 +0100
Subject: [PATCH] Fix encoding of padding bits to start with 0 bit
In-Reply-To: <1457599529-19440-1-git-send-email-saurabh.sharan@radisys.com>
References: <1457599529-19440-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <56E143D3.9030509@sysmocom.de>

Thank you for patch.
Out  of curiosity, have you tried to look in wireshark at gsmtap traces
before/after patch?
I wonder if it interprets things properly - do we need to patch it as well?

On 03/10/2016 09:45 AM, Saurabh Sharan wrote:
> 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(-)
>

-- 
Max Suraev <msuraev at 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 



From saurabh.sharan at radisys.com  Thu Mar 10 11:54:49 2016
From: saurabh.sharan at radisys.com (Saurabh Sharan)
Date: Thu, 10 Mar 2016 17:24:49 +0530
Subject: [PATCH] Add test vectors for EGPRS messages
Message-ID: <1457610889-24464-1-git-send-email-saurabh.sharan@radisys.com>


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(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-test-vectors-for-EGPRS-messages.patch
Type: text/x-patch
Size: 3429 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160310/0644674c/attachment.bin>

From sangamesh.sajjan at radisys.com  Thu Mar 10 14:20:40 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Thu, 10 Mar 2016 19:50:40 +0530
Subject: [PATCH] Uplink PAN handling for FANR feature
Message-ID: <1457619640-32314-1-git-send-email-sangamesh.sajjan@radisys.com>

Changes includes uplink PAN handling for Downlink tbf and
bitmap handling to update Tentative ack or nacked
---
 src/decoding.cpp        |   40 +++++++++++++++++++++
 src/tbf.cpp             |    2 ++
 src/tbf.h               |    1 +
 src/tbf_ul.cpp          |   92 +++++++++++++++++++++++++++++++++++++++++++++--
 tests/edge/EdgeTest.cpp |   68 +++++++++++++++++++++++++++++++++++
 5 files changed, 201 insertions(+), 2 deletions(-)

diff --git a/src/decoding.cpp b/src/decoding.cpp
index 649f68d..d3d0d89 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -423,6 +423,19 @@ int Decoding::decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
 	rlc->block_info[1].data_len = data_len;
 	rlc->data_offs_bytes[0] = 7;
 	rlc->data_offs_bytes[1] = 7 + data_len + 1;
+	if ( rlc->pani == 1) {
+		const struct egprs_ssn_based_pan_header *egprs1_fanr;
+		egprs1_fanr = static_cast<struct egprs_ssn_based_pan_header*>
+			((void *)&data[rlc->block_info[1].data_len + rlc->data_offs_bytes[1]]);
+		rlc->pan_info.bow = egprs1_fanr->bow;
+
+		rlc->pan_info.short_ssn_a = egprs1_fanr->short_ssn_a;
+		rlc->pan_info.short_ssn_rb = egprs1_fanr->short_ssn_rb;
+
+		rlc->pan_info.rb_a = egprs1_fanr->rb_a;
+		rlc->pan_info.rb_b = egprs1_fanr->rb_b;
+		rlc->pan_info.tfi = (egprs1_fanr->tfi_a << 0) | (egprs1_fanr->tfi_b << 4);
+	}
 	return 0;
 }
 
@@ -502,6 +515,19 @@ int Decoding::decode_ul_data_fanr_type2(struct gprs_rlc_ul_header_generic *rlc,
 	rlc->block_info[0].data_len = data_len;
 	rlc->data_offs_bytes[0] = 6;
 
+	if ( rlc->pani == 1) {
+		const struct egprs_ssn_based_pan_header *egprs2_fanr;
+		egprs2_fanr = static_cast<struct egprs_ssn_based_pan_header*>
+			((void *)&data[rlc->block_info[0].data_len + rlc->data_offs_bytes[0]]);
+		rlc->pan_info.bow = egprs2_fanr->bow;
+
+		rlc->pan_info.short_ssn_a = egprs2_fanr->short_ssn_a;
+		rlc->pan_info.short_ssn_rb = egprs2_fanr->short_ssn_rb;
+
+		rlc->pan_info.rb_a = egprs2_fanr->rb_a;
+		rlc->pan_info.rb_b = egprs2_fanr->rb_b;
+		rlc->pan_info.tfi = (egprs2_fanr->tfi_a << 0) | (egprs2_fanr->tfi_b << 4);
+	}
 	if(*cs == GprsCodingScheme::MCS6){
 		if(rlc->cps == 2 || rlc->cps == 3 ){
 			rlc->block_info[0].data_len -= pad_bytes;
@@ -588,6 +614,20 @@ int Decoding::decode_ul_data_fanr_type3(struct gprs_rlc_ul_header_generic *rlc,
 	rlc->block_info[0].data_len = data_len;
 	rlc->data_offs_bytes[0] = 5;
 
+	if ( rlc->pani == 1) {
+		const struct egprs_ssn_based_pan_header *egprs3_fanr;
+		egprs3_fanr = static_cast<struct egprs_ssn_based_pan_header*>
+			((void *)&data[rlc->block_info[0].data_len + rlc->data_offs_bytes[0]]);
+
+		rlc->pan_info.bow = egprs3_fanr->bow;
+
+		rlc->pan_info.short_ssn_a = egprs3_fanr->short_ssn_a;
+		rlc->pan_info.short_ssn_rb = egprs3_fanr->short_ssn_rb;
+
+		rlc->pan_info.rb_a = egprs3_fanr->rb_a;
+		rlc->pan_info.rb_b = egprs3_fanr->rb_b;
+		rlc->pan_info.tfi = (egprs3_fanr->tfi_a << 0) | (egprs3_fanr->tfi_b << 4);
+	}
 	if(rlc->block_info[0].spb == 2){
 		if(*cs == GprsCodingScheme::MCS3){
 			if(rlc->cps == 6 || rlc->cps == 7 || rlc->cps == 8){
diff --git a/src/tbf.cpp b/src/tbf.cpp
index 05f5c82..559e565 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -53,6 +53,8 @@ uint16_t windowsizebyTS[9] = {
         1024 // 8 TS
         };
 
+uint16_t log2ws[9] = {6,7,8,8,9,9,9,9,10};
+
 gprs_rlcmac_tbf::Meas::Meas() :
 	rssi_sum(0),
 	rssi_num(0)
diff --git a/src/tbf.h b/src/tbf.h
index a6878d7..ba0dce1 100644
--- a/src/tbf.h
+++ b/src/tbf.h
@@ -504,6 +504,7 @@ struct gprs_rlcmac_ul_tbf : public gprs_rlcmac_tbf {
 	uint8_t m_usf[8];	/* list USFs per PDCH (timeslot) */
 	uint8_t m_contention_resolution_done; /* set after done */
 	uint8_t m_final_ack_sent; /* set if we sent final ack */
+	int uplink_pan_handling(const gprs_rlc_ul_header_generic *rlc);
 
 protected:
 	void maybe_schedule_uplink_acknack(const gprs_rlc_ul_header_generic *rlc);
diff --git a/src/tbf_ul.cpp b/src/tbf_ul.cpp
index e89ac14..e56dccf 100644
--- a/src/tbf_ul.cpp
+++ b/src/tbf_ul.cpp
@@ -41,7 +41,8 @@ extern "C" {
 #define SEND_ACK_AFTER_FRAMES 20
 
 extern void *tall_pcu_ctx;
-
+extern uint16_t  log2ws[];
+extern uint16_t windowsizebyTS[];
 
 /*
  * Store received block data in LLC message(s) and forward to SGSN
@@ -392,9 +393,96 @@ int gprs_rlcmac_ul_tbf::rcv_data_block_acknowledged(
 	/* If TLLI is included or if we received half of the window, we send
 	 * an ack/nack */
 	maybe_schedule_uplink_acknack(rlc);
-
+	/*Uplink PAN info handling for downlink data, Need to update Ack/Nack
+	based on recieved bitmap */
+	if (rlc->pani == 1) {
+		uplink_pan_handling(rlc);
+	} else {
+		LOGP(DRLCMACUL, LOGL_ERROR, "No PAN info present \n");
+	}
 	return 0;
+}
 
+int gprs_rlcmac_ul_tbf::uplink_pan_handling(
+		const gprs_rlc_ul_header_generic *rlc)
+{
+	bool bit;
+	uint16_t bsn;
+	int i = 0, j;
+	int8_t rb_length, bits_left, shortSSNsize, mask, rb_mask;
+	int ssn = 0, ssn_base_va, ssn_base_vs;
+
+	gprs_rlcmac_dl_tbf *tbf;
+	tbf = gprs_rlcmac_ul_tbf::ms()->dl_tbf();
+	if (!tbf) {
+		LOGP(DRLCMACUL, LOGL_ERROR, "DL DATA unknown TFI=%d\n",
+				rlc->pan_info.tfi);
+		return 0;
+	}
+	if (tbf->tfi() != rlc->pan_info.tfi) {
+		LOGP(DRLCMACUL, LOGL_ERROR, "Received TFI %d and DL TBF Tfi %d are not\n"
+				"matching \n", tbf->tfi(), rlc->pan_info.tfi);
+		return 0;
+	}
+	for (j = 0; j < 9; j++) {
+		if (tbf->m_window.ws() == windowsizebyTS[j]) {
+			break;
+		}
+	}
+	shortSSNsize = log2ws[j] + 1;
+	mask = (1 << (shortSSNsize -7)) -1 ;
+	//Short SSN
+	int16_t short_ssn = ((rlc->pan_info.short_ssn_a) |
+			((rlc->pan_info.short_ssn_rb << 8) & mask ));
+	//RB
+	rb_mask = (1 << (4 - (shortSSNsize -7))) -1 ;
+
+	int16_t rb = ((rlc->pan_info.rb_b << (8 - (shortSSNsize -7))) |
+			(rlc->pan_info.rb_a << (4 - (shortSSNsize -7))) |
+			((rlc->pan_info.short_ssn_rb >> (shortSSNsize -7)) & rb_mask ));
+
+	//Get SSN from short SSN
+	ssn_base_va = (tbf->m_window.v_a() & (((1 << (11-shortSSNsize))-1) << shortSSNsize)) ;
+	ssn_base_vs = (tbf->m_window.v_s() & (((1 << (11-shortSSNsize))-1) << shortSSNsize)) ;
+
+	if ( ssn_base_va == ssn_base_vs ) {
+		ssn = MOD2048((ssn_base_va|short_ssn));
+	}
+	else {
+	 /*Algorithm to be modified for the case V(A) is less than 2048 and V(S) is greater than
+	2048 and RB comes in between these two */
+	//TODO different cases to be handled
+		return 0;
+	}
+	/* if Beginning of window is set 1, Mark Acked between SSN-2 ( V(Q)-1) to V(A)*/
+	if (rlc->pan_info.bow) {
+		for (int i = tbf->m_window.v_a(); i <= (ssn -2); i++  ) {
+			uint16_t bsn = tbf->m_window.mod_sns(i);
+			tbf->m_window.m_v_b.mark_tentative_acked(bsn);
+		}
+	}
+
+	rb_length = 8 + (4 - (shortSSNsize -7));
+
+	//Mark TENTATIVE_ACK
+	rb = rb << (16 - rb_length);
+	bits_left = rb_length;
+
+	while (bits_left != 0) {
+		bsn = tbf->m_window.mod_sns(ssn + i);
+		if (tbf->m_window.mod_sns(tbf->m_window.v_s() - bsn) >= tbf->m_window.distance())
+			 break;
+		bit = !!(rb & 0x8000);
+		if (bit) {
+			tbf->m_window.m_v_b.mark_tentative_acked(bsn);
+		} else {
+			tbf->m_window.m_v_b.mark_nacked(bsn);
+		}
+		rb = rb << 1;
+		bits_left--;
+		i++;
+	}
+	return 1;
 }
 
 void gprs_rlcmac_ul_tbf::maybe_schedule_uplink_acknack(
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index 7177832..924728f 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -1641,7 +1641,74 @@ static gprs_rlcmac_ul_tbf *establish_ul_tbf_two_phase_cv0(BTS *the_bts,
 	return ul_tbf;
 }
 
+void fanr_handling(gprs_rlcmac_ul_tbf *ul_tbf, BTS *the_bts, uint32_t *fn, uint8_t ts_no,
+			 GprsMs *ms , uint32_t tlli, uint16_t qta)
+{
+	uint8_t data_msg[200] = {0};
+	int tfi = 0;
+	struct gprs_rlcmac_pdch *pdch;
+	uint32_t rach_fn = *fn - 51;
+	uint32_t sba_fn = *fn + 52;
+	uint8_t trx_no = 0;
+
+	tfi = ul_tbf->tfi();
+	struct pcu_l1_meas meas;
+	meas.set_rssi(31);
+
+	ul_tbf->enable_fanr();
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 6); /* BSN:7, E:1 */
+	data_msg[4] = 0x2b; /* E: 1 */
+	data_msg[5] = 0x2b; /* E: 1 */
+	data_msg[6] = 0x2b; /* E: 1 */
+	data_msg[7] = 0x2b; /* E: 1 */
+	data_msg[8] = 0x2b; /* E: 1 */
+	data_msg[9] = 0x2b; /* E: 1 */
+	data_msg[10] = 0x2b; /* E: 1 */
+	data_msg[11] = 0x2b; /* E: 1 */
+	data_msg[12] = 0x2b; /* E: 1 */
+	data_msg[13] = 0x2b; /* E: 1 */
+	data_msg[14] = 0x2b; /* E: 1 */
+	data_msg[15] = 0x2b; /* E: 1 */
+	data_msg[16] = 0x2b; /* E: 1 */
+	data_msg[17] = 0x2b; /* E: 1 */
+	data_msg[18] = 0x2b; /* E: 1 */
+	data_msg[19] = 0x2b; /* E: 1 */
+	data_msg[20] = 0x2b; /* E: 1 */
+	data_msg[21] = 0x2b; /* E: 1 */
+	data_msg[22] = 0x2b; /* E: 1 */
+	data_msg[23] = 0x2b; /* E: 1 */
+	data_msg[24] = 0x2b; /* E: 1 */
+	data_msg[25] = 0x2b; /* E: 1 */
+	data_msg[26] = 0x2b;
+	data_msg[27] = 0x02; /* Fanr SSN & BOW */
+	data_msg[28] = 0xff; /* RB & SSN */
+	data_msg[29] = 0x0f; /* TFI & RB */
+	data_msg[30] = 0x00; /* TFI */
+	data_msg[31] = 0x00;
+
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 31, *fn, &meas);
+
+	ms = the_bts->ms_by_tlli(tlli);
+	OSMO_ASSERT(ms != NULL);
+	OSMO_ASSERT(ms->ta() == qta/4);
+	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);
+
+
+	/* send fake data */
+	data_msg[0] = 0x00 | 0xf << 2;
+	data_msg[1] = uint8_t(0 | (tfi << 1));
+	data_msg[2] = uint8_t(0);/* BSN:7, E:1 */
+	data_msg[3] =uint8_t(1 << 6); /* BSN:7, E:1 */
+	data_msg[4] = uint8_t(1); /* E: 1 */
 
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data_msg[0], 37, *fn, &meas);
+}
 void test_tbf_two_phase()
 {
 	BTS the_bts;
@@ -1669,6 +1736,7 @@ void test_tbf_two_phase()
 
 	/* Send Packet Downlink Assignment to MS */
 	request_dl_rlc_block(ul_tbf, &fn);
+	fanr_handling (ul_tbf, &the_bts, &fn, ts_no, ms, tlli, qta);
 	printf("=== end %s ===\n", __func__);
 }
 
-- 
1.7.9.5




From Bhargava.Abhyankar at radisys.com  Thu Mar 10 14:12:06 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Thu, 10 Mar 2016 14:12:06 +0000
Subject: [PATCH] Support of 11 bit RACH
In-Reply-To: <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>
References: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>
Message-ID: <DM2PR0801MB0959DB8738E177764914B6AA91B40@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hello holger,
	          Thanks for your comments.
We see that in latest osmo-bts,  PCU_IF_VERSION is defined as 0x06 whereas in latest osmo-pcu, it is defined as 0x05.  Let us know the value  to be taken for 11 bit RACH support.

Regards
Bhargava Abhyankar

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Tuesday, March 08, 2016 11:12 PM
To: Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org; Prasad Kaup <Prasad.Kaup at radisys.com>
Subject: Re: [PATCH] Support of 11 bit RACH


> On 08 Mar 2016, at 14:15, Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com> wrote:


Dear Bhargava,


> 
> This patch is first of series of patches to support 11 bit RACH.
> This includes interface structure changes between osmo-pcu and 
> osmo-bts to support 11 bit RACH.Processing of 11 bit RACH for GPRS is 
> added in bts.cpp.
> Unit test for the same shall be sent as separate patch.
> EGPRS PACKET CHANNEL REQUEST is not part of this patch.Note also that 
> this feature requires changes in osmo-bts and versioning needs to be 
> addressed further.


could you start by sending a patch for both osmo-bts and osmo-pcu to modify the pcuif_proto.h with the new protocol and the version number increase and osmo-bts to set it as GPRS_8_BIT_RACH (to match current behavior if that makes sense)?



> ---
> src/bts.cpp       | 36 +++++++++++++++++++++++++++---------
> src/bts.h         |  9 ++++++++-
> src/pcu_l1_if.cpp |  2 +-
> src/pcuif_proto.h |  3 ++-
> 4 files changed, 38 insertions(+), 12 deletions(-)
> 
> diff --git a/src/bts.cpp b/src/bts.cpp index 715fb51..a999c48 100644
> --- a/src/bts.cpp
> +++ b/src/bts.cpp
> @@ -459,7 +459,7 @@ int BTS::rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn)
> 	return 0;
> }
> 
> -int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
> +int BTS::rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta, uint8_t 
> +rach_type)
> {
> 

> +	} else if(rach_type == GPRS_11_BIT_RACH ) {
> +		if((ra & RACH_CAUSE_SINGLE_BLOCK) == 0x0600) {

please have a look at the Linux Kernel CodingStyle guidelines about necessary spaces between the if keyword and the opening parenthesis.

In terms of style, could you move the code that select the 'sb' into a separate (static inline) helper function. Not that we do it right now but in general this allows us to unit test such things more easily.




> +	} else if (rach_type == EGPRS_11_BIT_RACH) {
> +		/*TODO*/
> +


Do you think a log message is necessary here? Also in terms of TODO, maybe describe what someone in the future should put there?


kind regards
	holger


From laforge at gnumonks.org  Fri Mar 11 10:58:09 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 11 Mar 2016 17:58:09 +0700
Subject: [PATCH] VTY changes for FANR feature
In-Reply-To: <1457527034-12235-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1457527034-12235-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <20160311105809.GT26794@nataraja>

Hi Aravind,

On Wed, Mar 09, 2016 at 06:07:14PM +0530, Aravind Sirsikar wrote:
>  	uint8_t egprs_enabled;
> +	uint8_t fanr_enabled;

you are adding only one field: fanr_enabled.

> +	bts->egprs_enabled = true;
> +	bts->fanr_enabled = false;

here you are enabling egprs in main.c, which is unrelated to the FANR
change.  Please make sure you don't introduce chanes unrelated to the
currently worked on feature.

> +	if (bts->fanr_enabled)
> +		vty_out(vty, " egprs fanr %s", VTY_NEWLINE);
> +	else
> +		vty_out(vty, " no egprs fanr%s", VTY_NEWLINE);
> +

> +DEFUN(cfg_pcu_egprs_fanr,
> +      cfg_pcu_egprs_fanr_cmd,
> +      "egprs_fanr",
> +      EGPRS_FANR_STR)

> +DEFUN(cfg_pcu_no_egprs_fanr,
> +      cfg_pcu_no_egprs_fanr_cmd,
> +      "no egprs fanr",
> +      NO_STR EGPRS_FANR_STR)

So you add a command "egprs_fanr", but you write to the config file as
"egprs fanr".  Once you save the config file, it will fail to parse and
thus the PCU system ends up being unusable.  Please be careful with such
changes and try to manually re-read a configuration file before sending
patches for submission next time :)  Thanks!

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Mar 11 10:54:15 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 11 Mar 2016 17:54:15 +0700
Subject: [PATCH] Support of 11 bit RACH
In-Reply-To: <DM2PR0801MB0959DB8738E177764914B6AA91B40@DM2PR0801MB0959.namprd08.prod.outlook.com>
References: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>
 <DM2PR0801MB0959DB8738E177764914B6AA91B40@DM2PR0801MB0959.namprd08.prod.outlook.com>
Message-ID: <20160311105415.GS26794@nataraja>

Hi Bhargava,

On Thu, Mar 10, 2016 at 02:12:06PM +0000, Bhargava Abhyankar wrote:

> We see that in latest osmo-bts,  PCU_IF_VERSION is defined as 0x06
> whereas in latest osmo-pcu, it is defined as 0x05.  

I canno find 0x06 used in osmo-bts.  On master, both bts and PCU are
using 0x05. Can you please indicate which version/branch you ar using?

> Let us know the value  to be taken for 11 bit RACH support.

I would argue that you should bump to 0x07 on both sides if 0x06 was
ever used anywhere.  If 0x06 was not used (I couldn't find it), bump to
0x06.

Also if you really have seen different versions, it seems we need to
cheeck if we really make sure that the version information is actually
checked.  Any different version should make the OsmoPCU start-up fail
with a corresponding error message.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Mar 11 11:00:09 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 11 Mar 2016 18:00:09 +0700
Subject: [PATCH] Structure modifications for FANR feature
In-Reply-To: <1457585831-25853-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1457585831-25853-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <20160311110009.GU26794@nataraja>

On Thu, Mar 10, 2016 at 10:27:11AM +0530, Aravind Sirsikar wrote:
> +		case 27: return GprsCodingScheme(MCS1, EGPRS);
> +		case 31: return GprsCodingScheme(MCS1,EGPRS);

please be consistent in always usin a space after comma, thanks.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Fri Mar 11 11:13:08 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 11 Mar 2016 12:13:08 +0100
Subject: [PATCH] Support of 11 bit RACH
In-Reply-To: <20160311105415.GS26794@nataraja>
References: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>
 <DM2PR0801MB0959DB8738E177764914B6AA91B40@DM2PR0801MB0959.namprd08.prod.outlook.com>
 <20160311105415.GS26794@nataraja>
Message-ID: <27547A54-BAD4-46A3-ABBB-FA83B165EED9@freyther.de>


> On 11 Mar 2016, at 11:54, Harald Welte <laforge at gnumonks.org> wrote:
> 
> 
>> We see that in latest osmo-bts,  PCU_IF_VERSION is defined as 0x06
>> whereas in latest osmo-pcu, it is defined as 0x05.  
> 
> I canno find 0x06 used in osmo-bts.  On master, both bts and PCU are
> using 0x05. Can you please indicate which version/branch you ar using

look at the last commit i made. I bumped the version during review of Max's changes and then noticed it doesn't need to be bumped. When making the push I forgot to ammend the revert for the version number increase. As no packages has been built and the PCU was never upgraded, I moved back to 0x05 and think that 0x06 can be used for the 11bit RACH changes.

holger





From Prasad.Kaup at radisys.com  Fri Mar 11 11:51:02 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 11 Mar 2016 11:51:02 +0000
Subject: Regarding integration of NURAN L1 1.0
Message-ID: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160311/6ea3dff8/attachment.htm>

From Saurabh.Sharan at radisys.com  Fri Mar 11 13:34:08 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Fri, 11 Mar 2016 13:34:08 +0000
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net> <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
Message-ID: <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello All,
Based on your inputs and our analysis of the code bases( current master versus Radisys EGPRS) we propose following elements, each to be submitted in incremental patches for merge to master branch
1.      Compression algorithm based on code tree
2.      EPDAN decoding based on the code tree
3.      PUAN encoding based on code tree
4.      MCS 5-9 support in UL
5.      Split block handling in UL
6.      Split block generation in DL
7.      Retransmission with Incremental redundancy
8.      Relevant test suite updates as part of each of the item above

Please let us know your feedback/suggestions for the same.

Regards
Saurabh

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de]
Sent: Friday, March 04, 2016 10:35 PM
To: Jacob Erlbeck <jacob01 at gmx.net>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: Padding patch and moving forward with EGPRS support/merge


> On 03 Mar 2016, at 14:40, Jacob Erlbeck <jacob01 at gmx.net<mailto:jacob01 at gmx.net>> wrote:
>
> Hi,
>
> On 02.03.2016 20:14, Holger Freyther wrote:
>> * Jacob has not implemented compressed bitmaps in the DL TBF handling.
>
> More precisely, compressed bitmaps (decoding) are supported for DL
> TBFs only, since it is required to decode them DL Ack/Nack if the
> window size is increased which makes sense with multiple PDCH.
>
>> 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.
>
> The reason for not implementing them for UL TBF ACK yet was the fact
> that we only support single slot only in that direction and that the
> imposed restriction won't probably hurt in most cases. We can still
> send URBB even if the window size were larger than 96, so there are
> only some cases with long runs of NACKs and very few ACKs which might
> suffer from a slightly increased latency.
>
>> 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.
>
> -> UL TBF ACK handling

thanks for the correction.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160311/9ac26752/attachment.htm>

From holger at freyther.de  Fri Mar 11 22:27:31 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 11 Mar 2016 23:27:31 +0100
Subject: [PATCH] Add test vectors for EGPRS messages
Message-ID: <F5FA4950-8AEF-4DEE-9CEA-BDAD41B9C3D7@freyther.de>


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(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-test-vectors-for-EGPRS-messages.patch
Type: text/x-patch
Size: 3429 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160311/b5c112f2/attachment.bin>

From holger at freyther.de  Fri Mar 11 22:50:26 2016
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Fri, 11 Mar 2016 23:50:26 +0100
Subject: [PATCH] WIP: test patchwork test setup please ignore..
Message-ID: <1457736626-52545-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at 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 at freyther.de  Fri Mar 11 22:55:35 2016
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Fri, 11 Mar 2016 23:55:35 +0100
Subject: [PATCH] WIP: test patchwork test setup please ignore..
Message-ID: <1457736935-52594-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at 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 at freyther.de  Fri Mar 11 22:56:17 2016
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Fri, 11 Mar 2016 23:56:17 +0100
Subject: [PATCH] WIP: test patchwork test setup please ignore..
Message-ID: <1457736977-52640-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at 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 at freyther.de  Fri Mar 11 23:00:04 2016
From: holger at freyther.de (Holger Freyther)
Date: Sat, 12 Mar 2016 00:00:04 +0100
Subject: [PATCH] Add test vectors for EGPRS messages
In-Reply-To: <F5FA4950-8AEF-4DEE-9CEA-BDAD41B9C3D7@freyther.de>
References: <F5FA4950-8AEF-4DEE-9CEA-BDAD41B9C3D7@freyther.de>
Message-ID: <BE38ABA4-FEE5-4FC3-9811-EF24300C5367@freyther.de>


> On 11 Mar 2016, at 23:27, Holger Freyther <holger at freyther.de> wrote:
> 
> 
> 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.

reject test?



From holger at freyther.de  Sat Mar 12 19:33:31 2016
From: holger at freyther.de (Holger Freyther)
Date: Sat, 12 Mar 2016 20:33:31 +0100
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net> <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
 <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>


> On 11 Mar 2016, at 14:34, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello All,

Dear Saurabh,

> Based on your inputs and our analysis of the code bases( current master versus Radisys EGPRS) we propose following elements, each to be submitted in incremental patches for merge to master branch
> 	? Compression algorithm based on code tree
> 	? EPDAN decoding based on the code tree 
> 	? PUAN encoding based on code tree
> 	? MCS 5-9 support in UL
> 	? Split block handling in UL
> 	? Split block generation in DL
> 	? Retransmission with Incremental redundancy
> 	? Relevant test suite updates as part of each of the item above
>  
> Please let us know your feedback/suggestions for the same.

looks good in general. Please follow the general guideline, try to make small commits, update test results, add new tests. After each of the elements we should not only have a new feature, but better structure, better test coverage and throughput.

kind regards
	holger

From holger at freyther.de  Sun Mar 13 21:12:05 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 13 Mar 2016 22:12:05 +0100
Subject: [PATCH 1/2] WIP..
Message-ID: <1457903526-63933-1-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at moiji-mobile.com>

---
 tests/rlcmac/RLCMACTest.cpp |  8 ++++----
 tests/rlcmac/RLCMACTest.ok  | 26 +++++++++++++++++---------
 2 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/tests/rlcmac/RLCMACTest.cpp b/tests/rlcmac/RLCMACTest.cpp
index 66bc53c..124e643 100644
--- a/tests/rlcmac/RLCMACTest.cpp
+++ b/tests/rlcmac/RLCMACTest.cpp
@@ -89,7 +89,7 @@ void testRlcMacDownlink()
 
 	std::string testData[] = {
 	"4e082500e3f1a81d080820800b2b2b2b2b2b2b2b2b2b2b", // Packet Downlink Assignment
-	"48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Assignment
+	"48282407a6a07422720100032b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Assignment
 	"47240c00400000000000000079eb2ac9402b2b2b2b2b2b", // Packet Uplink Ack Nack
 	"47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b"  // Packet Uplink Assignment
 	"4913e00850884013a8048b2b2b2b2b2b2b2b2b2b2b2b2b"
@@ -152,9 +152,9 @@ void testRlcMacUplink()
 	bitvec_unhex(resultVector, "2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b");
 
 	std::string testData[] = {
-	"400e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Dummy Control Block
-	"400b8020000000000000002480e00b2b2b2b2b2b2b2b2b", // Packet Downlink Ack/Nack
-	"4016713dc094270ca2ae57ef909006aa0fc0001f80222b"  // Packet Resource Request
+	"400e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Dummy Control Block
+	"400b8020000000000000002480e0032b2b2b2b2b2b2b2b", // Packet Downlink Ack/Nack
+	"4016713dc094270ca2ae57ef909006aa0fc0001f80222b", // Packet Resource Request
 	"400a9020000000000000003010012a0800132b2b2b2b2b"
 	};
 
diff --git a/tests/rlcmac/RLCMACTest.ok b/tests/rlcmac/RLCMACTest.ok
index 99117ff..801de42 100644
--- a/tests/rlcmac/RLCMACTest.ok
+++ b/tests/rlcmac/RLCMACTest.ok
@@ -7,13 +7,13 @@ vector1 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b
 vector1 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b
 vector2 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
-vector1 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b
+vector1 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b
 =========Start DECODE===========
 +++++++++Finish DECODE++++++++++
 =========Start ENCODE=============
 +++++++++Finish ENCODE+++++++++++
-vector1 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b
-vector2 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b
+vector1 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b
+vector2 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
 vector1 = 4724c040000000079eb2ac9402b2b2b2b2b2b
 =========Start DECODE===========
@@ -32,21 +32,21 @@ vector1 = 47283c367513ba33304242b2b2b2b2b2b2b2b2b2b2b2b
 vector2 = 47283c367513ba33304242b2b2b2b2b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
  UPLINK 
-vector1 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+vector1 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
 =========Start DECODE===========
 +++++++++Finish DECODE++++++++++
 =========Start ENCODE=============
 +++++++++Finish ENCODE+++++++++++
-vector1 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
-vector2 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+vector1 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+vector2 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
-vector1 = 40b802000000002480e0b2b2b2b2b2b2b2b2b
+vector1 = 40b802000000002480e032b2b2b2b2b2b2b2b
 =========Start DECODE===========
 +++++++++Finish DECODE++++++++++
 =========Start ENCODE=============
 +++++++++Finish ENCODE+++++++++++
-vector1 = 40b802000000002480e0b2b2b2b2b2b2b2b2b
-vector2 = 40b802000000002480e0b2b2b2b2b2b2b2b2b
+vector1 = 40b802000000002480e032b2b2b2b2b2b2b2b
+vector2 = 40b802000000002480e032b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
 vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b
 =========Start DECODE===========
@@ -56,3 +56,11 @@ vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b
 vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b
 vector2 = 4016713dc09427ca2ae57ef90906aafc001f80222b
 vector1 == vector2 : TRUE
+vector1 = 40a90200000000301012a80132b2b2b2b2b
+=========Start DECODE===========
++++++++++Finish DECODE++++++++++
+=========Start ENCODE=============
++++++++++Finish ENCODE+++++++++++
+vector1 = 40a90200000000301012a80132b2b2b2b2b
+vector2 = 40a90200000000301012a80132b2b2b2b2b
+vector1 == vector2 : TRUE
-- 
2.6.3



From holger at freyther.de  Sun Mar 13 21:12:06 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 13 Mar 2016 22:12:06 +0100
Subject: [PATCH 2/2] WIP: test patchwork test setup please ignore..
In-Reply-To: <1457903526-63933-1-git-send-email-holger@freyther.de>
References: <1457903526-63933-1-git-send-email-holger@freyther.de>
Message-ID: <1457903526-63933-2-git-send-email-holger@freyther.de>

From: Holger Hans Peter Freyther <holger at 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 at freyther.de  Tue Mar 15 09:06:46 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 15 Mar 2016 10:06:46 +0100
Subject: [PATCH] Fix encoding of padding bits to start with 0 bit
In-Reply-To: <1457599529-19440-1-git-send-email-saurabh.sharan@radisys.com>
References: <1457599529-19440-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <0FCDE602-C25F-49D9-93D8-91B35B7A48BE@freyther.de>


> On 10 Mar 2016, at 09:45, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 

Good Morning Saurabh,

> 
> 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.
> 
> 
> <0001-Fix-encoding-of-padding-bits-to-start-with-0-bit.patch>

I have applied this patch and pushed it to master. Could you please use git send-email. I had to manually copy/paste the commit message and I would like to avoid doing this in the future.

thank you

holger

From holger at freyther.de  Tue Mar 15 09:07:21 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 15 Mar 2016 10:07:21 +0100
Subject: [PATCH] Add test vectors for EGPRS messages
In-Reply-To: <1457610889-24464-1-git-send-email-saurabh.sharan@radisys.com>
References: <1457610889-24464-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <1F821686-7D8A-4379-89E4-87454DC4D017@freyther.de>


> On 10 Mar 2016, at 12:54, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 

Good Morning 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.
> ---
> tests/rlcmac/RLCMACTest.cpp |    7 +++++--
> tests/rlcmac/RLCMACTest.ok  |   32 ++++++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 2 deletions(-)
> 
> <0001-Add-test-vectors-for-EGPRS-messages.patch>


I have applied your patch and pushed it to master. Please use git send-email in the future without an additional attachment.

thank you
	holger

From Prasad.Kaup at radisys.com  Tue Mar 15 14:03:42 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Tue, 15 Mar 2016 14:03:42 +0000
Subject: Regarding integration of NURAN L1 1.0
In-Reply-To: <20160314001234.GE10039@dub6>
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
Message-ID: <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>

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 at lists.osmocom.org] On Behalf Of Neels Hofmeyr
Sent: Monday, March 14, 2016 5:43 AM
To: Prasad Kaup <Prasad.Kaup at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org; Yves Godin <Yves.Godin at 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



From laforge at gnumonks.org  Wed Mar 16 11:05:18 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Mar 2016 12:05:18 +0100
Subject: Regarding integration of NURAN L1 1.0
In-Reply-To: <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <20160316110518.GQ15482@nataraja>

Hi Prasad,

On Tue, Mar 15, 2016 at 02:03:42PM +0000, Prasad Kaup wrote:
> 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.

I suggest you kindly contact the supplier of this product for related
support.

> 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.

This is up to you.  The focus in the community has so far been to work
on autonomous GSM/GPRS networks using OsmoNITB, OsmoSGSN and OpenGGSN,
and without external MSC/SGSN/GGSN.

sysmocom as a company has been contracted by some of its customers to
integrate with specific other pre-existing MSC/SGSN/GGSN components, and
all related changes have been developed and integrated into the Osmocom
projects.

If you have a requirement to integrate with any other MSC/SGSN/GGSN, we
are more than welcome to receive feedback about your progress/status and
we're looking forward for your contribution of related patches for
integration into the Osmocom components.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Yves.Godin at nutaq.com  Wed Mar 16 12:26:59 2016
From: Yves.Godin at nutaq.com (Yves Godin)
Date: Wed, 16 Mar 2016 08:26:59 -0400
Subject: Regarding integration of NURAN L1 1.0
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160316110518.GQ15482@nataraja>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F03731C74@NTWAEX01.interne.lyrtech.com>

Prasad,
Do you have the Yocto ADT to cross-compile the applications ?
If not, Harald, can you share it with them ?

Best Regards,
Yves


> -----Message d'origine-----
> De?: osmocom-net-gprs [mailto:osmocom-net-gprs-bounces at lists.osmocom.org] De
> la part de Harald Welte
> Envoy??: March-16-16 7:05 AM
> ??: Prasad Kaup
> Cc?: osmocom-net-gprs at lists.osmocom.org; Saurabh Sharan; Abhinav Pragya Rishi
> Objet?: Re: Regarding integration of NURAN L1 1.0
> 
> Hi Prasad,
> 
> On Tue, Mar 15, 2016 at 02:03:42PM +0000, Prasad Kaup wrote:
> > 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.
> 
> I suggest you kindly contact the supplier of this product for related support.
> 
> > 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.
> 
> This is up to you.  The focus in the community has so far been to work on
> autonomous GSM/GPRS networks using OsmoNITB, OsmoSGSN and OpenGGSN, and
> without external MSC/SGSN/GGSN.
> 
> sysmocom as a company has been contracted by some of its customers to
> integrate with specific other pre-existing MSC/SGSN/GGSN components, and all
> related changes have been developed and integrated into the Osmocom projects.
> 
> If you have a requirement to integrate with any other MSC/SGSN/GGSN, we are
> more than welcome to receive feedback about your progress/status and we're
> looking forward for your contribution of related patches for integration into
> the Osmocom components.
> 
> Regards,
> 	Harald
> --
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)




From Sangamesh.Sajjan at radisys.com  Wed Mar 16 12:48:59 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Wed, 16 Mar 2016 12:48:59 +0000
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net> <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
 <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>
 <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>
Message-ID: <BLUPR08MB711602B7A104BE6C8EC7E34888A0@BLUPR08MB711.namprd08.prod.outlook.com>

Hello,

Following patches are identified for the activity ?compression algorithm based on code tree?.

?	Structure definition for Tree node,  declaration of zero run length code list and one run length code list
?	Building a tree of code words to save run length during initialization and addition of Test cases in Unit test framework
?	Utility to Search the run length according to the received code word from the tree,  when CRBB_STARTING_COLOR_CODE is One during decoding of EPDAN and addition of test case in Unit test framework
?	Utility to Search the run length according to the received code word from the tree,  when CRBB_STARTING_COLOR_CODE is Zero during decoding of EPDAN and addition of test case in Unit test framework
?	Utility to find runlength of one?s or zero?s and addition of Test cases in Unit test framework
?	Utility to find  code word of runlength during encoding of PUAN and addition of Test cases in Unit test framework

Regards,
Sangamesh

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Sunday, March 13, 2016 1:04 AM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: Padding patch and moving forward with EGPRS support/merge


> On 11 Mar 2016, at 14:34, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello All,

Dear Saurabh,

> Based on your inputs and our analysis of the code bases( current master versus Radisys EGPRS) we propose following elements, each to be submitted in incremental patches for merge to master branch
> 	? Compression algorithm based on code tree
> 	? EPDAN decoding based on the code tree 
> 	? PUAN encoding based on code tree
> 	? MCS 5-9 support in UL
> 	? Split block handling in UL
> 	? Split block generation in DL
> 	? Retransmission with Incremental redundancy
> 	? Relevant test suite updates as part of each of the item above
>  
> Please let us know your feedback/suggestions for the same.

looks good in general. Please follow the general guideline, try to make small commits, update test results, add new tests. After each of the elements we should not only have a new feature, but better structure, better test coverage and throughput.

kind regards
	holger

From Arvind.Sirsikar at radisys.com  Wed Mar 16 13:08:24 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 16 Mar 2016 13:08:24 +0000
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net> <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
 <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>
 <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>
Message-ID: <BN3PR08MB1173EECA6B771A8C9B857C79F08A0@BN3PR08MB1173.namprd08.prod.outlook.com>

Hi

Below are the patches we have identified  for the MCS5 - MCS9 in UL activity for EGPRS.

1.	Structure definition for EGPRS Header type 1 and 2 in UL. 
2.	Removing GMSK only check from UL TBF path present in  gprs_rlcmac_pdch::rcv_data_block function. 
3.	Moving  "LOGP(DRLCMACUL, LOGL_DEBUG, "  UL data: %s\n", osmo_hexdump(data, len));"  from function gprs_rlcmac_pdch::rcv_data_block 
	to entry of gprs_rlcmac_pdch::rcv_block  function for ease in debugging and the TbfTest.err file modification.
4.	Replacing Unnecessary copy constructor for GprsCodingScheme class objects by modifying the function prototype using reference variables.
	Ex: 
		int gprs_rlcmac_pdch::rcv_block_gprs(uint8_t *data, uint32_t fn,
  		      struct pcu_l1_meas *meas, GprsCodingScheme cs);
			Will be changed to
		Int gprs_rlcmac_pdch::rcv_block_gprs(uint8_t *data, uint32_t fn,
   		     struct pcu_l1_meas *meas, GprsCodingScheme &cs);
5.	Decoding::rlc_parse_ul_data_header will be modified with calling separate parser function for 
	GprsCodingScheme::HEADER_GPRS_DATA
			AND
	GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3 cases.
6.	Member variable enum Mode  m_scheme_type; will be added in class GprsCodingScheme and constructor GprsCodingScheme(Scheme s = UNKNOWN); 
	will be modified to GprsCodingScheme(Scheme s = UNKNOWN,Mode scheme_type = GPRS);  and object creation will be modified  accordingly along with 
	changes in isGprs() and  isEgprs() member functions.
7.	New parser function for GprsCodingScheme::HEADER_GPRS_DATA_TYPE_2 case with addition of Test cases in Unit test framework excluding padding case.
8.	New parser function for GprsCodingScheme::HEADER_GPRS_DATA_TYPE_1 case with addition of new Test cases  Unit test framework.
9.	Handling of padding case in Header type 2 including Test case addition in Unit Test framework.

Thanks,
Aravind Sirsikar


-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Sunday, March 13, 2016 1:04 AM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: Padding patch and moving forward with EGPRS support/merge


> On 11 Mar 2016, at 14:34, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello All,

Dear Saurabh,

> Based on your inputs and our analysis of the code bases( current master versus Radisys EGPRS) we propose following elements, each to be submitted in incremental patches for merge to master branch
> 	? Compression algorithm based on code tree
> 	? EPDAN decoding based on the code tree 
> 	? PUAN encoding based on code tree
> 	? MCS 5-9 support in UL
> 	? Split block handling in UL
> 	? Split block generation in DL
> 	? Retransmission with Incremental redundancy
> 	? Relevant test suite updates as part of each of the item above
>  
> Please let us know your feedback/suggestions for the same.

looks good in general. Please follow the general guideline, try to make small commits, update test results, add new tests. After each of the elements we should not only have a new feature, but better structure, better test coverage and throughput.

kind regards
	holger

From msuraev at sysmocom.de  Wed Mar 16 13:14:14 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 16 Mar 2016 14:14:14 +0100
Subject: Padding patch and moving forward with EGPRS support/merge
In-Reply-To: <BLUPR08MB711602B7A104BE6C8EC7E34888A0@BLUPR08MB711.namprd08.prod.outlook.com>
References: <DBE25BB0-233F-41FC-BBF2-FD2001DDC7C2@freyther.de>
 <56D83EC4.9010802@gmx.net> <8466B09E-8B54-4F6E-B825-13FD2A91FE1D@freyther.de>
 <BY1PR08MB130854901A84E6AB8A9B78E085B50@BY1PR08MB1308.namprd08.prod.outlook.com>
 <C54F4A4D-CB49-41DA-89DF-174489066F1A@freyther.de>
 <BLUPR08MB711602B7A104BE6C8EC7E34888A0@BLUPR08MB711.namprd08.prod.outlook.com>
Message-ID: <56E95C26.9020801@sysmocom.de>

That's already implemented in bitvec_rl(const struct bitvec *bv, bool
b); from bitvec.h in libosmocore.
See also bitcomp.h for usage details.

On 03/16/2016 01:48 PM, Sangamesh Sajjan wrote:
> ?	Utility to find runlength of one?s or zero?s and addition of Test cases in Unit test framework
>

-- 
Max Suraev <msuraev at 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 



From saurabh.sharan at radisys.com  Wed Mar 16 13:47:32 2016
From: saurabh.sharan at radisys.com (Saurabh Sharan)
Date: Wed, 16 Mar 2016 19:17:32 +0530
Subject: [PATCH] Fix issue in encoding CSN_RECURSIVE_ARRAY
Message-ID: <1458136052-13448-1-git-send-email-saurabh.sharan@radisys.com>

The remaining_bits_len is correctly decremented while encoding
CSN_RECURSIVE_ARRAY for fixing the bug.
Details of the bug is in https://projects.osmocom.org/issues/1641

During introduction of basic EGPRS feature new hex dump message
PUASS, from a different working network log was used in Unit test.
It exposed the issue of incorrect handling of recursive array
encoding in osmo-pcu.
---
 src/csn1.cpp                |    1 +
 tests/rlcmac/RLCMACTest.cpp |    1 +
 tests/rlcmac/RLCMACTest.ok  |    8 ++++++++
 3 files changed, 10 insertions(+)

diff --git a/src/csn1.cpp b/src/csn1.cpp
index 82bf17f..d51fe83 100644
--- a/src/csn1.cpp
+++ b/src/csn1.cpp
@@ -2504,6 +2504,7 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector
         bitvec_write_field(vector, writeIndex, !Tag, 1);
         LOGPC(DCSN1, LOGL_NOTICE, "%s = %u | ", pDescr->sz , (unsigned)(!Tag));
         bit_offset++;
+        remaining_bits_len--;
 
         pDescr++;
         break;
diff --git a/tests/rlcmac/RLCMACTest.cpp b/tests/rlcmac/RLCMACTest.cpp
index 26d35ec..466b89e 100644
--- a/tests/rlcmac/RLCMACTest.cpp
+++ b/tests/rlcmac/RLCMACTest.cpp
@@ -93,6 +93,7 @@ void testRlcMacDownlink()
 	"47240c00400000000000000079eb2ac9402b2b2b2b2b2b", // Packet Uplink Ack Nack
 	"47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Assignment
 	"400820001a3904df0680efb3300b2b2b2b2b2b2b2b2b2b", // Packet Downlink Assignment (EGPRS)
+	"40284f0000001009810c826f4406809dcecb2b2b2b2b2b", // Packet Uplink Assignment (EGPRS)
 	"4024030f2f0000000087b0042b2b2b2b2b2b2b2b2b2b2b"  // Packet Uplink Ack Nack (EGPRS)
 	"4913e00850884013a8048b2b2b2b2b2b2b2b2b2b2b2b2b"
 	"412430007fffffffffffffffefd19c7ba12b2b2b2b2b2b"
diff --git a/tests/rlcmac/RLCMACTest.ok b/tests/rlcmac/RLCMACTest.ok
index 4deced7..896982d 100644
--- a/tests/rlcmac/RLCMACTest.ok
+++ b/tests/rlcmac/RLCMACTest.ok
@@ -39,6 +39,14 @@ vector1 = 4082001a394df680efb330b2b2b2b2b2b2b2b2b2b
 vector1 = 4082001a394df680efb330b2b2b2b2b2b2b2b2b2b
 vector2 = 4082001a394df680efb330b2b2b2b2b2b2b2b2b2b
 vector1 == vector2 : TRUE
+vector1 = 40284f00010981c826f446809dcecb2b2b2b2b2b
+=========Start DECODE===========
++++++++++Finish DECODE++++++++++
+=========Start ENCODE=============
++++++++++Finish ENCODE+++++++++++
+vector1 = 40284f00010981c826f446809dcecb2b2b2b2b2b
+vector2 = 40284f00010981c826f446809dcecb2b2b2b2b2b
+vector1 == vector2 : TRUE
 vector1 = 40243f2f000087b042b2b2b2b2b2b2b2b2b2b2b
 =========Start DECODE===========
 +++++++++Finish DECODE++++++++++
-- 
1.7.9.5



From holger at freyther.de  Wed Mar 16 13:48:14 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Mar 2016 14:48:14 +0100
Subject: [PATCH] Uplink PAN handling for FANR feature
In-Reply-To: <1457619640-32314-1-git-send-email-sangamesh.sajjan@radisys.com>
References: <1457619640-32314-1-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <065CC4EF-7704-4786-BA2E-ABF57FFB1708@freyther.de>


> On 10 Mar 2016, at 15:20, sangamesh sajjan <sangamesh.sajjan at radisys.com> wrote:
> 

Hi,


> Changes includes uplink PAN handling for Downlink tbf and
> bitmap handling to update Tentative ack or nacked

we have been waiting for the second version of it. There are too many coding style violations so it doesn't make sense.


> ---
> src/decoding.cpp        |   40 +++++++++++++++++++++
> src/tbf.cpp             |    2 ++
> src/tbf.h               |    1 +
> src/tbf_ul.cpp          |   92 +++++++++++++++++++++++++++++++++++++++++++++--
> tests/edge/EdgeTest.cpp |   68 +++++++++++++++++++++++++++++++++++
> 5 files changed, 201 insertions(+), 2 deletions(-)
> 
> diff --git a/src/decoding.cpp b/src/decoding.cpp
> index 649f68d..d3d0d89 100644
> --- a/src/decoding.cpp
> +++ b/src/decoding.cpp
> @@ -423,6 +423,19 @@ int Decoding::decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
> 	rlc->block_info[1].data_len = data_len;
> 	rlc->data_offs_bytes[0] = 7;
> 	rlc->data_offs_bytes[1] = 7 + data_len + 1;
> +	if ( rlc->pani == 1) {
> +		const struct egprs_ssn_based_pan_header *egprs1_fanr;
> +		egprs1_fanr = static_cast<struct egprs_ssn_based_pan_header*>
> +			((void *)&data[rlc->block_info[1].data_len + rlc->data_offs_bytes[1]]);

why do you need to combine old C style cast with C++ one?


> +uint16_t log2ws[9] = {6,7,8,8,9,9,9,9,10};


why is it define in tbf.cpp and not used there? ws == window size?


> +
> gprs_rlcmac_tbf::Meas::Meas() :
> 	rssi_sum(0),
> 	rssi_num(0)
> diff --git a/src/tbf.h b/src/tbf.h
> index a6878d7..ba0dce1 100644
> --- a/src/tbf.h
> +++ b/src/tbf.h
> @@ -504,6 +504,7 @@ struct gprs_rlcmac_ul_tbf : public gprs_rlcmac_tbf {
> 	uint8_t m_usf[8];	/* list USFs per PDCH (timeslot) */
> 	uint8_t m_contention_resolution_done; /* set after done */
> 	uint8_t m_final_ack_sent; /* set if we sent final ack */
> +	int uplink_pan_handling(const gprs_rlc_ul_header_generic *rlc);

What should it do? What should this method do? I can not say based on the name.



> +int gprs_rlcmac_ul_tbf::uplink_pan_handling(
> +		const gprs_rlc_ul_header_generic *rlc)
> +{
> 

Code is read a lot more frequently than it is written. For being able to unit test and also for allowing people to read, methods should be small. I think you will find a nice way to split the different concerns and make it more straight forward.

> +	return 1;
> }
> 
> void gprs_rlcmac_ul_tbf::maybe_schedule_uplink_acknack(
> diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
> index 7177832..924728f 100644
> --- a/tests/edge/EdgeTest.cpp
> +++ b/tests/edge/EdgeTest.cpp
> @@ -1641,7 +1641,74 @@ static gprs_rlcmac_ul_tbf *establish_ul_tbf_two_phase_cv0(BTS *the_bts,
> 	return ul_tbf;
> }
> 
> +void fanr_handling(gprs_rlcmac_ul_tbf *ul_tbf, BTS *the_bts, uint32_t *fn, uint8_t ts_no,
> +			 GprsMs *ms , uint32_t tlli, uint16_t qta)
> +{
> 
> +	ms = the_bts->ms_by_tlli(tlli);
> +	OSMO_ASSERT(ms != NULL);
> +	OSMO_ASSERT(ms->ta() == qta/4);
> +	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);

these are the only asserts in the testcase and they do not concern to anything related to FANR. Could you please elaborate about it?


holger

From holger at freyther.de  Wed Mar 16 13:52:03 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Mar 2016 14:52:03 +0100
Subject: [PATCH] UT Expected error files TbfTest.err, EdgeTest.err for FANR
In-Reply-To: <1457599944-24309-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1457599944-24309-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <01866EFC-A9B0-43A8-B80D-D683857D620E@freyther.de>


> On 10 Mar 2016, at 09:52, Aravind Sirsikar <Arvind.Sirsikar at radisys.com> wrote:
> 
> 

Hi,


> Modifies TbfTest.err, EdgeTest.err for FANR feature

* please send the patch as inline with the commit message as otherwise we lose the commit message as part of the commit.

* Test results should be updated with the change that causes the change

* Changes should be minimal. You are adding support that should not have effect when not being enabled, at the same time there are lot of changes.

-Got RLC block, coding scheme: MCS-3, length: 42 (41))
-  UL data: 28 90 00 2b 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
+Got RLC block, coding scheme: MCS-3, length: 42 
+UL data: 28 90 00 2b 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 

this doesn't help with actually seeing/finding regressions.


kind regards
	holger




From arvind.sirsikar at radisys.com  Wed Mar 16 13:49:17 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 16 Mar 2016 19:19:17 +0530
Subject: [PATCH] Introduce EGPRS header type1 and type2 in UL
Message-ID: <1458136157-5293-1-git-send-email-arvind.sirsikar@radisys.com>

Defines new structures for UL EGPRS header type1 and type2 for
supporting MCS5-MCS9
---
 src/rlc.h |   38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/src/rlc.h b/src/rlc.h
index 54f28df..3f10f8c 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -288,6 +288,44 @@ struct rlc_li_field_egprs {
 		 li:7;
 } __attribute__ ((packed));
 
+/* TS 44.060  10.3a.4.1.1 */
+struct gprs_rlc_ul_header_egprs_1 {
+	uint8_t r:1,
+		si:1,
+		cv:4,
+		tfi_a:2;
+	uint8_t tfi_b:3,
+		bsn1_a:5;
+	uint8_t bsn1_b:6,
+		bsn2_a:2;
+	uint8_t bsn2_b;
+	uint8_t cps:5,
+		rsb:1,
+		pi:1,
+		spare_a:1;
+	uint8_t spare_b:6,
+		dummy:2;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.4.2.1 */
+struct gprs_rlc_ul_header_egprs_2 {
+	uint8_t r:1,
+		si:1,
+		cv:4,
+		tfi_a:2;
+	uint8_t tfi_b:3,
+		bsn1_a:5;
+	uint8_t bsn1_b:6,
+		cps_a:2;
+	uint8_t cps_b:1,
+		rsb:1,
+		pi:1,
+		spare_a:5;
+	uint8_t spare_b:5,
+		dummy:3;
+} __attribute__ ((packed));
+
+/* TS 44.060  10.3a.4.3.1 */
 struct gprs_rlc_ul_header_egprs_3 {
 	uint8_t r:1,
 		si:1,
-- 
1.7.9.5




From holger at freyther.de  Wed Mar 16 14:01:05 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Mar 2016 15:01:05 +0100
Subject: [PATCH] Fix issue in encoding CSN_RECURSIVE_ARRAY
In-Reply-To: <1458136052-13448-1-git-send-email-saurabh.sharan@radisys.com>
References: <1458136052-13448-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <89E2F636-0553-4BF2-B72A-8E7DA8426A9D@freyther.de>


> On 16 Mar 2016, at 14:47, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:


Dear Saurabh,


> 
> The remaining_bits_len is correctly decremented while encoding
> CSN_RECURSIVE_ARRAY for fixing the bug.
> Details of the bug is in https://projects.osmocom.org/issues/1641
> 
> During introduction of basic EGPRS feature new hex dump message
> PUASS, from a different working network log was used in Unit test.
> It exposed the issue of incorrect handling of recursive array
> encoding in osmo-pcu.


great! It is not documented (we need to fix it) we generally refer to bug reports like:

Fixes: OS#1641


> ---
> src/csn1.cpp                |    1 +
> tests/rlcmac/RLCMACTest.cpp |    1 +
> tests/rlcmac/RLCMACTest.ok  |    8 ++++++++
> 3 files changed, 10 insertions(+)
> 
> diff --git a/src/csn1.cpp b/src/csn1.cpp
> index 82bf17f..d51fe83 100644
> --- a/src/csn1.cpp
> +++ b/src/csn1.cpp
> @@ -2504,6 +2504,7 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector
>         bitvec_write_field(vector, writeIndex, !Tag, 1);
>         LOGPC(DCSN1, LOGL_NOTICE, "%s = %u | ", pDescr->sz , (unsigned)(!Tag));
>         bit_offset++;
> +        remaining_bits_len--;


great. and thanks for debugging it. Could you elaborate if CSN_RECURSIVE_TARRAY needs a similiar fix?


holger

From holger at freyther.de  Wed Mar 16 14:16:04 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Mar 2016 15:16:04 +0100
Subject: [PATCH] FANR UL and DL flow changes and UT fixes
In-Reply-To: <1457588714-14527-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1457588714-14527-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <C1AE24F6-5EC7-41F3-BF59-2D99607F497E@freyther.de>


> On 10 Mar 2016, at 06:45, Aravind Sirsikar <Arvind.Sirsikar at radisys.com> wrote:


Hi,

the main issue is already in the subject of the patch. "Do this ... and ... that" is better done as two separate patches.

Let me just give you one example



> -int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
> -	const uint8_t *data, GprsCodingScheme cs)
> +int Decoding::decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
> +		const uint8_t *data, GprsCodingScheme* cs)
> {
> -	const struct rlc_ul_header *gprs;
> 	unsigned int data_len = 0;
> +	data_len = cs->maxDataBlockBytes();
> +
> +	const struct gprs_rlc_ul_header_egprs_fanr_type1 *egprs1;
> +	egprs1 = static_cast<struct gprs_rlc_ul_header_egprs_fanr_type1*>
> +		((void *)data);
> +	rlc->r      = egprs1->r;
> +	rlc->si     = egprs1->si;
> +	rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
> +	rlc->cps    = egprs1->cps;
> +	rlc->rsb    = egprs1->rsb;
> +	rlc->cv     = egprs1->cv;
> +	rlc->pani     = egprs1->pani;
> +
> +	rlc->num_data_blocks = 2;
> +	rlc->block_info[0].cv  = egprs1->cv;
> +	rlc->block_info[0].pi  = egprs1->pi;
> +	rlc->block_info[0].bsn =
> +		(egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
> +
> +	rlc->block_info[0].spb = 0;
> +
> +	rlc->block_info[1].cv  = egprs1->cv;
> +	rlc->block_info[1].pi  = egprs1->pi;
> +
> +	rlc->block_info[1].bsn = rlc->block_info[0].bsn + ((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
> +	rlc->block_info[1].bsn = (rlc->block_info[1].bsn + 2048) % 2047;
> +
> +	rlc->block_info[0].e   = (data[6] & 0x01);
> +	rlc->block_info[0].ti  = (data[6] &  0x02) >> 1;
> +	rlc->block_info[1].e   = (data[6 + data_len + 1] & 0x01);
> +	rlc->block_info[1].ti  = (data[6 + data_len + 1] &  0x02) >> 1;
> +	rlc->block_info[1].spb = 0;
> +
> +	rlc->block_info[0].data_len = data_len;
> +	rlc->block_info[1].data_len = data_len;
> +	rlc->data_offs_bytes[0] = 7;
> +	rlc->data_offs_bytes[1] = 7 + data_len + 1;
> +	return 0;
> +}
> +




> +int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_ul_header_generic *rlc,
> +	const uint8_t *data, GprsCodingScheme cs)


> -		rlc->pani= 0;
> +		rlc->pani   = 0;

please don't do drive-by changes.



> -	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3:
> -		const struct gprs_rlc_ul_header_egprs_3 *egprs3;
> -		egprs3 = static_cast<struct gprs_rlc_ul_header_egprs_3 *>
> -                        ((void *)data);
> -                rlc->r      = egprs3->r;
> -                rlc->si     = egprs3->si;
> -                rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
> -                rlc->cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
> -                rlc->rsb    = egprs3->rsb;
> -                rlc->cv     = egprs3->cv;
> -                /* pani 0 for fanr inactive */
> -		rlc->pani     = 0;
> -
> -                rlc->num_data_blocks = 1;
> -                rlc->block_info[0].cv  = egprs3->cv;
> -                rlc->block_info[0].pi  = egprs3->pi;
> -                rlc->block_info[0].spb = egprs3->spb;
> -                rlc->block_info[0].bsn =
> -                        (egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
> -
> -                rlc->block_info[0].e   = (data[4] & 0x01);
> -                rlc->block_info[0].ti  = (data[4] &  0x02) >> 1;
> -
> -                rlc->block_info[0].data_len = data_len;
> -                rlc->data_offs_bytes[0] = 5;
> -
> -		if(rlc->block_info[0].spb == 2){
> -			if(cs == GprsCodingScheme::MCS3){ 
> -				if(rlc->cps == 6 || rlc->cps == 7 || rlc->cps == 8){
> -        	        		rlc->block_info[0].data_len -= pad_bytes;
> -               				rlc->data_offs_bytes[0] += pad_bytes;
> -                			rlc->block_info[0].e   = (data[4 + pad_bytes] & 0x01);
> -			                rlc->block_info[0].ti  = (data[4 + pad_bytes] &  0x02) >> 1;
> -				}
> -			}
> -		}
> -		break;



Okay, it is not the same method that was moved but as a rule of thumb. if you move code, first copy the code in a commit and then modify it. This makes the actual change visible.

With a patch series you tell a story and need to leave the code in a better state than it was before and additional features. To do this we have small commits.


holger



From Bhargava.Abhyankar at radisys.com  Wed Mar 16 14:06:04 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Wed, 16 Mar 2016 14:06:04 +0000
Subject: [PATCH] Support of 11 bit RACH
In-Reply-To: <27547A54-BAD4-46A3-ABBB-FA83B165EED9@freyther.de>
References: <1457442958-19870-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <F494F133-FAEE-4359-8B40-F3F81A5F22C9@freyther.de>
 <DM2PR0801MB0959DB8738E177764914B6AA91B40@DM2PR0801MB0959.namprd08.prod.outlook.com>
 <20160311105415.GS26794@nataraja>
 <27547A54-BAD4-46A3-ABBB-FA83B165EED9@freyther.de>
Message-ID: <CY1PR0801MB0953D77B6ECAF9D6D2E8DDEA918A0@CY1PR0801MB0953.namprd08.prod.outlook.com>

Hello Holger,

	The comments on 11 bit RACH support will be incorporated in next patches. We have identified below mentioned 
patches for the initial support of 11 bit RACH, and plan to release in series. 
Please give your feedback.  

*  Interface changes and versioning increment in osmo-pcu.
*  Interface changes and versioning increment in osmo-bts.
*  11 bit RACH handling in osmo-pcu.
*  11 bit RACH in osmo-bts.
*  EGPRS 11 bit RACH handling in osmo-pcu.
*  EGPRS 11 bit RACH handling in osmo-bts.

Thanks
Bhargava Abhyankar

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Friday, March 11, 2016 4:43 PM
To: Harald Welte <laforge at gnumonks.org>
Cc: Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com>; Prasad Kaup <Prasad.Kaup at radisys.com>; osmocom-net-gprs at lists.osmocom.org
Subject: Re: [PATCH] Support of 11 bit RACH


> On 11 Mar 2016, at 11:54, Harald Welte <laforge at gnumonks.org> wrote:
> 
> 
>> We see that in latest osmo-bts,  PCU_IF_VERSION is defined as 0x06 
>> whereas in latest osmo-pcu, it is defined as 0x05.
> 
> I canno find 0x06 used in osmo-bts.  On master, both bts and PCU are 
> using 0x05. Can you please indicate which version/branch you ar using

look at the last commit i made. I bumped the version during review of Max's changes and then noticed it doesn't need to be bumped. When making the push I forgot to ammend the revert for the version number increase. As no packages has been built and the PCU was never upgraded, I moved back to 0x05 and think that 0x06 can be used for the 11bit RACH changes.

holger





From holger at freyther.de  Wed Mar 16 14:34:18 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Mar 2016 15:34:18 +0100
Subject: [PATCH] Fix issue in encoding CSN_RECURSIVE_ARRAY
In-Reply-To: <BY1PR08MB1308F4998E12C4D9E061FD7F858A0@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <1458136052-13448-1-git-send-email-saurabh.sharan@radisys.com>
 <89E2F636-0553-4BF2-B72A-8E7DA8426A9D@freyther.de>
 <BY1PR08MB1308F4998E12C4D9E061FD7F858A0@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <A04DB540-9A3B-46AE-B47D-F8634A67FA96@freyther.de>


> On 16 Mar 2016, at 15:32, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello Holger,

Hi!


> From the code analysis it seems CSN_RECURSIVE_TARRAY also requires similar fix. But we need to find a proper test vector to validate the fix.

i have pushed the CSN_RECURSIVE_ARRAY fix but it would be very nice if you could see if the _TARRAY variant is already used and if you can find a test vector.

thank you
	holger

From Saurabh.Sharan at radisys.com  Wed Mar 16 14:32:35 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Wed, 16 Mar 2016 14:32:35 +0000
Subject: [PATCH] Fix issue in encoding CSN_RECURSIVE_ARRAY
In-Reply-To: <89E2F636-0553-4BF2-B72A-8E7DA8426A9D@freyther.de>
References: <1458136052-13448-1-git-send-email-saurabh.sharan@radisys.com>
 <89E2F636-0553-4BF2-B72A-8E7DA8426A9D@freyther.de>
Message-ID: <BY1PR08MB1308F4998E12C4D9E061FD7F858A0@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello Holger,
Thanks for your feedback.

>From the code analysis it seems CSN_RECURSIVE_TARRAY also requires similar fix. But we need to find a proper test vector to validate the fix.

Regards
Saurabh

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Wednesday, March 16, 2016 7:31 PM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: [PATCH] Fix issue in encoding CSN_RECURSIVE_ARRAY


> On 16 Mar 2016, at 14:47, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:


Dear Saurabh,


> 
> The remaining_bits_len is correctly decremented while encoding 
> CSN_RECURSIVE_ARRAY for fixing the bug.
> Details of the bug is in https://projects.osmocom.org/issues/1641
> 
> During introduction of basic EGPRS feature new hex dump message PUASS, 
> from a different working network log was used in Unit test.
> It exposed the issue of incorrect handling of recursive array encoding 
> in osmo-pcu.


great! It is not documented (we need to fix it) we generally refer to bug reports like:

Fixes: OS#1641


> ---
> src/csn1.cpp                |    1 +
> tests/rlcmac/RLCMACTest.cpp |    1 +
> tests/rlcmac/RLCMACTest.ok  |    8 ++++++++
> 3 files changed, 10 insertions(+)
> 
> diff --git a/src/csn1.cpp b/src/csn1.cpp index 82bf17f..d51fe83 100644
> --- a/src/csn1.cpp
> +++ b/src/csn1.cpp
> @@ -2504,6 +2504,7 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector
>         bitvec_write_field(vector, writeIndex, !Tag, 1);
>         LOGPC(DCSN1, LOGL_NOTICE, "%s = %u | ", pDescr->sz , (unsigned)(!Tag));
>         bit_offset++;
> +        remaining_bits_len--;


great. and thanks for debugging it. Could you elaborate if CSN_RECURSIVE_TARRAY needs a similiar fix?


holger


From Sangamesh.Sajjan at radisys.com  Thu Mar 17 06:24:56 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Thu, 17 Mar 2016 06:24:56 +0000
Subject: [PATCH] Uplink PAN handling for FANR feature
In-Reply-To: <065CC4EF-7704-4786-BA2E-ABF57FFB1708@freyther.de>
References: <1457619640-32314-1-git-send-email-sangamesh.sajjan@radisys.com>
 <065CC4EF-7704-4786-BA2E-ABF57FFB1708@freyther.de>
Message-ID: <BY2PR08MB713B40819C83F6F574B9386888B0@BY2PR08MB713.namprd08.prod.outlook.com>

Hello,

Thank you for the comments,
Currently I'm working on merging of compression algorithm to master branch.
I will resubmit the patch by considering all your comments after completion of current activity.

Thanks,
Sangamesh

-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Wednesday, March 16, 2016 7:18 PM
To: Sangamesh Sajjan <Sangamesh.Sajjan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: [PATCH] Uplink PAN handling for FANR feature


> On 10 Mar 2016, at 15:20, sangamesh sajjan <sangamesh.sajjan at radisys.com> wrote:
> 

Hi,


> Changes includes uplink PAN handling for Downlink tbf and bitmap 
> handling to update Tentative ack or nacked

we have been waiting for the second version of it. There are too many coding style violations so it doesn't make sense.


> ---
> src/decoding.cpp        |   40 +++++++++++++++++++++
> src/tbf.cpp             |    2 ++
> src/tbf.h               |    1 +
> src/tbf_ul.cpp          |   92 +++++++++++++++++++++++++++++++++++++++++++++--
> tests/edge/EdgeTest.cpp |   68 +++++++++++++++++++++++++++++++++++
> 5 files changed, 201 insertions(+), 2 deletions(-)
> 
> diff --git a/src/decoding.cpp b/src/decoding.cpp index 
> 649f68d..d3d0d89 100644
> --- a/src/decoding.cpp
> +++ b/src/decoding.cpp
> @@ -423,6 +423,19 @@ int Decoding::decode_ul_data_fanr_type1(struct gprs_rlc_ul_header_generic *rlc,
> 	rlc->block_info[1].data_len = data_len;
> 	rlc->data_offs_bytes[0] = 7;
> 	rlc->data_offs_bytes[1] = 7 + data_len + 1;
> +	if ( rlc->pani == 1) {
> +		const struct egprs_ssn_based_pan_header *egprs1_fanr;
> +		egprs1_fanr = static_cast<struct egprs_ssn_based_pan_header*>
> +			((void *)&data[rlc->block_info[1].data_len + 
> +rlc->data_offs_bytes[1]]);

why do you need to combine old C style cast with C++ one?


> +uint16_t log2ws[9] = {6,7,8,8,9,9,9,9,10};


why is it define in tbf.cpp and not used there? ws == window size?


> +
> gprs_rlcmac_tbf::Meas::Meas() :
> 	rssi_sum(0),
> 	rssi_num(0)
> diff --git a/src/tbf.h b/src/tbf.h
> index a6878d7..ba0dce1 100644
> --- a/src/tbf.h
> +++ b/src/tbf.h
> @@ -504,6 +504,7 @@ struct gprs_rlcmac_ul_tbf : public gprs_rlcmac_tbf {
> 	uint8_t m_usf[8];	/* list USFs per PDCH (timeslot) */
> 	uint8_t m_contention_resolution_done; /* set after done */
> 	uint8_t m_final_ack_sent; /* set if we sent final ack */
> +	int uplink_pan_handling(const gprs_rlc_ul_header_generic *rlc);

What should it do? What should this method do? I can not say based on the name.



> +int gprs_rlcmac_ul_tbf::uplink_pan_handling(
> +		const gprs_rlc_ul_header_generic *rlc) {
> 

Code is read a lot more frequently than it is written. For being able to unit test and also for allowing people to read, methods should be small. I think you will find a nice way to split the different concerns and make it more straight forward.

> +	return 1;
> }
> 
> void gprs_rlcmac_ul_tbf::maybe_schedule_uplink_acknack(
> diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp index 
> 7177832..924728f 100644
> --- a/tests/edge/EdgeTest.cpp
> +++ b/tests/edge/EdgeTest.cpp
> @@ -1641,7 +1641,74 @@ static gprs_rlcmac_ul_tbf *establish_ul_tbf_two_phase_cv0(BTS *the_bts,
> 	return ul_tbf;
> }
> 
> +void fanr_handling(gprs_rlcmac_ul_tbf *ul_tbf, BTS *the_bts, uint32_t *fn, uint8_t ts_no,
> +			 GprsMs *ms , uint32_t tlli, uint16_t qta) {
> 
> +	ms = the_bts->ms_by_tlli(tlli);
> +	OSMO_ASSERT(ms != NULL);
> +	OSMO_ASSERT(ms->ta() == qta/4);
> +	OSMO_ASSERT(ms->ul_tbf() == ul_tbf);

these are the only asserts in the testcase and they do not concern to anything related to FANR. Could you please elaborate about it?


holger


From Sangamesh.Sajjan at radisys.com  Thu Mar 17 15:43:36 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Thu, 17 Mar 2016 15:43:36 +0000
Subject: Proposal for new structure definition for compression algorithm
Message-ID: <BY2PR08MB71308C3CC0D5B4FE8BB14FC888B0@BY2PR08MB713.namprd08.prod.outlook.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160317/27a4d598/attachment.htm>

From sangamesh.sajjan at radisys.com  Thu Mar 17 15:41:21 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Thu, 17 Mar 2016 21:11:21 +0530
Subject: [PATCH] Add structure definition for compression algorithm
Message-ID: <1458229281-27762-1-git-send-email-sangamesh.sajjan@radisys.com>

Defines new structure for Tree node and
Declaration of zero's run length code list and one's run length
code list
---
 src/Makefile.am               |    6 +-
 src/egprs_rlc_compression.cpp |  169 +++++++++++++++++++++++++++++++++++++++++
 src/egprs_rlc_compression.h   |   15 ++++
 3 files changed, 188 insertions(+), 2 deletions(-)
 create mode 100644 src/egprs_rlc_compression.cpp
 create mode 100644 src/egprs_rlc_compression.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 6428bef..981d5b1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -57,7 +57,8 @@ libgprs_la_SOURCES = \
 	rlc.cpp \
 	osmobts_sock.cpp \
 	gprs_codel.c \
-	gprs_coding_scheme.cpp
+	gprs_coding_scheme.cpp \
+	egprs_rlc_compression.cpp
 
 bin_PROGRAMS = \
 	osmo-pcu
@@ -96,7 +97,8 @@ noinst_HEADERS = \
 	pcu_utils.h \
 	cxx_linuxlist.h \
 	gprs_codel.h \
-	gprs_coding_scheme.h
+	gprs_coding_scheme.h \
+	egprs_rlc_compression.h
 
 osmo_pcu_SOURCES = pcu_main.cpp
 
diff --git a/src/egprs_rlc_compression.cpp b/src/egprs_rlc_compression.cpp
new file mode 100644
index 0000000..55ff595
--- /dev/null
+++ b/src/egprs_rlc_compression.cpp
@@ -0,0 +1,169 @@
+/* egprs_rlc_compression.h
+*  Routines for EGPRS RLC bitmap compression handling
+*/
+#include <egprs_rlc_compression.h>
+#include <errno.h>
+
+const char *one_run_len_code_list[MAX_CDWDTBL_LEN] = {
+	"00110101",
+	"000111",
+	"0111",
+	"1000",
+	"1011",
+	"1100",
+	"1110",
+	"1111",
+	"10011",
+	"10100",
+	"00111",
+	"01000",
+	"001000",
+	"000011",
+	"110100",
+	"110101",
+	"101010",
+	"101011",
+	"0100111",
+	"0001100",
+	"0001000",
+	"0010111",
+	"0000011",
+	"0000100",
+	"0101000",
+	"0101011",
+	"0010011",
+	"0100100",
+	"0011000",
+	"00000010",
+	"00000011",
+	"00011010",
+	"00011011",
+	"00010010",
+	"00010011",
+	"00010100",
+	"00010101",
+	"00010110",
+	"00010111",
+	"00101000",
+	"00101001",
+	"00101010",
+	"00101011",
+	"00101100",
+	"00101101",
+	"00000100",
+	"00000101",
+	"00001010",
+	"00001011",
+	"01010010",
+	"01010011",
+	"01010100",
+	"01010101",
+	"00100100",
+	"00100101",
+	"01011000",
+	"01011001",
+	"01011010",
+	"01011011",
+	"01001010",
+	"01001011",
+	"00110010",
+	"00110011",
+	"00110100",
+	"11011",
+	"10010",
+	"010111",
+	"0110111",
+	"00110110",
+	"00110111",
+	"01100100",
+	"01100101",
+	"01101000",
+	"01100111",
+	"011001100",
+	"011001101",
+	"011010010",
+	"011010011",
+	"011010100"
+};
+
+const char *zero_run_len_code_list[MAX_CDWDTBL_LEN] = {
+	"0000110111",
+	"10",
+	"11",
+	"010",
+	"011",
+	"0011",
+	"0010",
+	"00011",
+	"000101",
+	"000100",
+	"0000100",
+	"0000101",
+	"0000111",
+	"00000100",
+	"00000111",
+	"000011000",
+	"0000010111",
+	"0000011000",
+	"0000001000",
+	"00001100111",
+	"00001101000",
+	"00001101100",
+	"00000110111",
+	"00000101000",
+	"00000010111",
+	"00000011000",
+	"000011001010",
+	"000011001011",
+	"000011001100",
+	"000011001101",
+	"000001101000",
+	"000001101001",
+	"000001101010",
+	"000001101011",
+	"000011010010",
+	"000011010011",
+	"000011010100",
+	"000011010101",
+	"000011010110",
+	"000011010111",
+	"000001101100",
+	"000001101101",
+	"000011011010",
+	"000011011011",
+	"000001010100",
+	"000001010101",
+	"000001010110",
+	"000001010111",
+	"000001100100",
+	"000001100101",
+	"000001010010",
+	"000001010011",
+	"000000100100",
+	"000000110111",
+	"000000111000",
+	"000000100111",
+	"000000101000",
+	"000001011000",
+	"000001011001",
+	"000000101011",
+	"000000101100",
+	"000001011010",
+	"000001100110",
+	"000001100111",
+	"0000001111",
+	"000011001000",
+	"000011001001",
+	"000001011011",
+	"000000110011",
+	"000000110100",
+	"000000110101",
+	"0000001101100",
+	"0000001101101",
+	"0000001001010",
+	"0000001001011",
+	"0000001001100",
+	"0000001001101",
+	"0000001110010",
+	"0000001110011"
+};
diff --git a/src/egprs_rlc_compression.h b/src/egprs_rlc_compression.h
new file mode 100644
index 0000000..32368cb
--- /dev/null
+++ b/src/egprs_rlc_compression.h
@@ -0,0 +1,15 @@
+/* egprs_rlc_compression.h
+*  Routines for EGPRS RLC bitmap compression handling
+*/
+#include "tbf.h"
+#include "bts.h"
+#include "gprs_debug.h"
+#include <errno.h>
+
+#define MAX_CDWDTBL_LEN          79        /* total number of codewords */
+
+struct node {
+	struct node *left;
+	struct node *right;
+	uint16_t *run_length;
+};
-- 
1.7.9.5




From nhofmeyr at sysmocom.de  Fri Mar 18 10:28:38 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 18 Mar 2016 11:28:38 +0100
Subject: Proposal for new structure definition for compression algorithm
In-Reply-To: <BY2PR08MB71308C3CC0D5B4FE8BB14FC888B0@BY2PR08MB713.namprd08.prod.outlook.com>
References: <BY2PR08MB71308C3CC0D5B4FE8BB14FC888B0@BY2PR08MB713.namprd08.prod.outlook.com>
Message-ID: <20160318102837.GC1323@ass40.sysmocom.de>

On Thu, Mar 17, 2016 at 03:43:36PM +0000, Sangamesh Sajjan wrote:
> 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.

Hi Sangamesh,

though I'm not entirely familiar with the compression algorithm, I'm
pretty sure that using an array of strings to store bits will make the
code less efficient by magnitudes.

If I have bits in a primitive like an int, I can compare them to other
bits with a single CPU clock cycle. Even if they are shifted/fragmented to
a different bit position, using shl or shr (<< or >>) and comparing
int-wise will be extremely faster than iterating an array of chars of '1'
and '0' and interpreting those as 1 and 0.

I do see that it might make the code arrays easier to read and understand
for humans, but that wouldn't make up for the humungous performance loss
you're inflicting at the same time.

Please correct me if I'm missing something, but my guess is that you're on
the verge of an abyss here ;)

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160318/373b2b4d/attachment.bin>

From minh-quang.nguyen at nutaq.com  Fri Mar 18 14:13:16 2016
From: minh-quang.nguyen at nutaq.com (Minh-Quang Nguyen)
Date: Fri, 18 Mar 2016 10:13:16 -0400
Subject: Regarding integration of NURAN L1 1.0
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>

Hi Prasad,

In order to cross-compile osmo-bts, osmo-pcu with 3rd party compiler such as CodeSourcery, you will need to do:

- Download toolchain for armv5te from CodeSourcery 
  'arm-2013.11-33-arm-none-linux-gnueabi' Lite edition, https://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ 

- Download and cross-compile libraries 
  ncurses-5.9	https://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz
  gpsd-3.10		git://git.sv.gnu.org/gpsd.git
  ortp-0.16.5	http://download.savannah.gnu.org/releases/linphone/ortp/sources/ortp-0.16.5.tar.gz

  ortp-0.16.5 requires two patches from here https://github.com/sysmocom/meta-telephony/tree/master/recipes-misc/ortp/files

- Clone Osmocom sources from http://git.osmocom.org (I am able to compile with the following hash)

  openbsc (57ee78078905c7499bd4e6857f8981d22badfcac)		git://git.osmocom.org/openbsc
  libosmocore (8649d57f507d359c99a89654aac7e19ce22db282) 	git://git.osmocom.org/libosmocore
  libosmo-abis (3cef39b03cb46de4a7aba65137d724a000b184cb)	git://git.osmocom.org/libosmo-abis
  osmo-bts (dce6c09b30dd709467216d325bf38845a98fe75b)      	git://git.osmocom.org/osmo-bts
  osmo-pcu (08e5d604d3fce75b955549244b36fde62f20894b)      	git://git.osmocom.org/osmo-pcu
  layer1-api (7f0d5697b85340877b127a25e0c8f2a5f5fe66d7)    	git://git.sysmocom.de/sysmo-bts/layer1-api.git

- Cross-compile libosmocore, libosmo-abis 
- Cross-compile osmo-bts
- Finally, cross-compile osmo-pcu

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 at nutaq.com
www.nutaq.com 

 QUEBEC MONTREAL NEW YORK

Facebook Twitter LinkedIn YouTube


-----Original Message-----
From: osmocom-net-gprs [mailto:osmocom-net-gprs-bounces at lists.osmocom.org] On Behalf Of Prasad Kaup
Sent: Tuesday, March 15, 2016 10:04 AM
To: Neels Hofmeyr; osmocom-net-gprs at lists.osmocom.org
Cc: Saurabh Sharan; Yves Godin; Abhinav Pragya Rishi
Subject: RE: Regarding integration of NURAN L1 1.0

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 at lists.osmocom.org] On Behalf Of Neels Hofmeyr
Sent: Monday, March 14, 2016 5:43 AM
To: Prasad Kaup <Prasad.Kaup at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org; Yves Godin <Yves.Godin at 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



From holger at freyther.de  Fri Mar 18 19:59:26 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 18 Mar 2016 20:59:26 +0100
Subject: Time to rename projects.osmocom.org to osmocom.org
Message-ID: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>

Hi,

I think we all liked tnt's proposal to just call it osmocom.org. Are we ready to make the redmine available as osmocom.org (and redirect www.osmocom.org, projects.osmocom.org to it)?

As first step of redirects I propose:

http://bb.osmocom.org/		-> http://osmocom.org/projects/baseband
http://openbsc.osmocom.org/	-> http://osmocom.org/projects/openbsc
http://tetra.osmocom.org/	-> http://osmocom.org/projects/tetra
http://simtrace.osmocom.org/	-> http://osmocom.org/projects/simtrace
http://security.osmocom.org/	-> http://osmocom.org/projects/security
http://gmr.osmocom.org/		-> http://osmocom.org/projects/gmr
http://sdr.osmocom.org/		-> http://osmocom.org/projects/sdr

any objections or corrections to that?


kind regards
	holger

From laforge at gnumonks.org  Mon Mar 21 06:53:08 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 07:53:08 +0100
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
Message-ID: <20160321065308.GD10371@nataraja>

Hi Holger,

On Fri, Mar 18, 2016 at 08:59:26PM +0100, Holger Freyther wrote:
> I think we all liked tnt's proposal to just call it osmocom.org. Are
> we ready to make the redmine available as osmocom.org (and redirect
> www.osmocom.org, projects.osmocom.org to it)?

yes, and also yes for the redirects.

> any objections or corrections to that?

none, please go ahead.  Thanks a lot!

I wonder if it is worth to make the old wiki/issue trac databases
(without the user password hashes!) publicly available, in case somebody
has a need for old content.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From manuelj.munoz at gmail.com  Mon Mar 21 15:00:14 2016
From: manuelj.munoz at gmail.com (=?UTF-8?Q?Manuel_Jos=C3=A9_Mu=C3=B1oz_Calero?=)
Date: Mon, 21 Mar 2016 16:00:14 +0100
Subject: Academic project based on OpenGGSN
Message-ID: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>

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-000421.pdf
)
3GPP Use IPSec to secure GTP messages (
http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_13_yokohama/docs/PDF/S3-000329.pdf
)

Maybe some other security-oriented feature you want to be implemented?

I would love to hear your thoughts!

Thanks for your time,
Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160321/c77db581/attachment.htm>

From Bhargava.Abhyankar at radisys.com  Mon Mar 21 15:03:50 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Mon, 21 Mar 2016 20:33:50 +0530
Subject: [PATCH] Change the interface in osmo-pcu for 11 bit RACH
Message-ID: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>

Interface changes in osmo-pcu towards osmo-bts to
receive 11 bit RACH.
The interface version number is increased by 1.
---
 src/bts.cpp       | 2 +-
 src/bts.h         | 3 ++-
 src/pcu_l1_if.cpp | 2 +-
 src/pcuif_proto.h | 5 +++--
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..9c0871d 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -459,7 +459,7 @@ int BTS::rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn)
 	return 0;
 }
 
-int BTS::rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta)
+int BTS::rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta, uint8_t rach_type)
 {
 	struct gprs_rlcmac_ul_tbf *tbf = NULL;
 	uint8_t trx_no, ts_no = 0;
diff --git a/src/bts.h b/src/bts.h
index c975304..2a1f930 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -275,7 +275,8 @@ public:
 	int tfi_find_free(enum gprs_rlcmac_tbf_direction dir, uint8_t *_trx, int8_t use_trx);
 
 	int rcv_imm_ass_cnf(const uint8_t *data, uint32_t fn);
-	int rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta);
+	int rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta,
+					uint8_t rach_type = 0);
 
 	void trigger_dl_ass(gprs_rlcmac_dl_tbf *tbf, gprs_rlcmac_tbf *old_tbf);
 	void snd_dl_ass(gprs_rlcmac_tbf *tbf, uint8_t poll, const char *imsi);
diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp
index 19dda5c..7d7c914 100644
--- a/src/pcu_l1_if.cpp
+++ b/src/pcu_l1_if.cpp
@@ -313,7 +313,7 @@ static int pcu_rx_rach_ind(struct gsm_pcu_if_rach_ind *rach_ind)
 	case PCU_IF_SAPI_RACH:
 		rc = BTS::main_bts()->rcv_rach(
 			rach_ind->ra, rach_ind->fn,
-			rach_ind->qta);
+			rach_ind->qta, rach_ind->rach_type);
 		break;
 	default:
 		LOGP(DL1IF, LOGL_ERROR, "Received PCU rach request with "
diff --git a/src/pcuif_proto.h b/src/pcuif_proto.h
index 9d740ac..877f507 100644
--- a/src/pcuif_proto.h
+++ b/src/pcuif_proto.h
@@ -1,7 +1,7 @@
 #ifndef _PCUIF_PROTO_H
 #define _PCUIF_PROTO_H
 
-#define PCU_IF_VERSION		0x05
+#define PCU_IF_VERSION		0x06
 
 /* msg_type */
 #define PCU_IF_MSG_DATA_REQ	0x00	/* send data to given channel */
@@ -64,10 +64,11 @@ struct gsm_pcu_if_rts_req {
 
 struct gsm_pcu_if_rach_ind {
 	uint8_t		sapi;
-	uint8_t		ra;
+	uint16_t	ra;
 	int16_t		qta;
 	uint32_t	fn;
 	uint16_t	arfcn;
+	uint8_t		rach_type;
 } __attribute__ ((packed));
 
 struct gsm_pcu_if_info_trx {
-- 
2.5.0




From laforge at gnumonks.org  Mon Mar 21 16:18:41 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 17:18:41 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
Message-ID: <20160321161841.GP10371@nataraja>

Hi Manuel,

On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel Jos? Mu?oz Calero wrote:
> 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.

thanks for reaching out about this.

> Long story short, what about me implementing IPSec for GTP-C in OpenGGSN?
> Do you think it could be useful? Feasible?

I've quickly looked at the documents you linked, and they don't really
state anything beyond "use IPsec for GTP".  Specifically, the do not
specify how to do key distribution, how to set up the SAs, whether they
use a standard IKEv2 or something else, ...

As Linux has a fairly complete IPsec implementation consisting of the
kernel-level IPsec transforms with its netlink interface and e.g. the
Strongswan userland, I don't really think there is anything that would
need to be done in addition to configuring both this IPsec stack and
OpenGGSN.

So what exactly would you want to do?  Am I missing something?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From domi at tomcsanyi.net  Mon Mar 21 08:23:47 2016
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Mon, 21 Mar 2016 09:23:47 +0100 (CET)
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <20160321065308.GD10371@nataraja>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <20160321065308.GD10371@nataraja>
Message-ID: <C02D901B-73A0-41CB-9C07-A9FFF3F64E0D@tomcsanyi.net>

Hi Harald,

> I wonder if it is worth to make the old wiki/issue trac databases
> (without the user password hashes!) publicly available, in case somebody
> has a need for old content.

I think this would be great.

Thanks!

Domi Tomcsanyi


From laforge at gnumonks.org  Mon Mar 21 20:19:45 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 21:19:45 +0100
Subject: [PATCH] Uplink PAN header changes for FANR feature
In-Reply-To: <1457533987-3524-1-git-send-email-sangamesh.sajjan@radisys.com>
References: <1457533987-3524-1-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <20160321201945.GX10371@nataraja>

Hi Sangamesh,

sorry for the late response on this particular patch.

On Wed, Mar 09, 2016 at 08:03:07PM +0530, sangamesh sajjan wrote:
> Added structure definition for handling uplink PAN and added new
> RLC state for Tentative Ack

thanks for this patch.  It looks fine to me. However, I would like to
request to submit it as part of a patch series athat adds more parts of
the FANR feature.  Merging this patch by itself would only add 'dead
code' to the program.  Thanks for your understanding.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Mar 21 20:17:11 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 21:17:11 +0100
Subject: [PATCH] Change the interface in osmo-pcu for 11 bit RACH
In-Reply-To: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <20160321201711.GW10371@nataraja>

Hi Bhargava,

On Mon, Mar 21, 2016 at 08:33:50PM +0530, Bhargava Abhyankar wrote:
> Interface changes in osmo-pcu towards osmo-bts to
> receive 11 bit RACH.
> The interface version number is increased by 1.

your patch looks fine, thanks.

However, when we change the interface, we need to change it on both
sides, on osmo-pcu as well as on osmo-bts.  Please send the
corresponding change along for the osmo-bts side.  Thanks!

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Mar 21 20:23:52 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 21:23:52 +0100
Subject: [PATCH] Add structure definition for compression algorithm
In-Reply-To: <1458229281-27762-1-git-send-email-sangamesh.sajjan@radisys.com>
References: <1458229281-27762-1-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <20160321202352.GY10371@nataraja>

Hi Sangamesh,

On Thu, Mar 17, 2016 at 09:11:21PM +0530, sangamesh sajjan wrote:
> Defines new structure for Tree node and
> Declaration of zero's run length code list and one's run length
> code list

thanks again for this patch.  My feedback towards the PAN related patch
aplpies:  Please group all your patches related to a specific feature
together in a series of patches.   The series should then contain all
the individual change-sets that lead to the addition of a new feature,
or the re-structuring of an existing interface/module, or the like.

Each patch series should be sumitted as one series using git-send-email,
which then shows up on the mailing list like this small series of three
patches:

http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-February/000359.html
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-February/000358.html
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-February/000360.html
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-February/000361.html

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From manuelj.munoz at gmail.com  Tue Mar 22 01:18:48 2016
From: manuelj.munoz at gmail.com (=?UTF-8?Q?Manuel_Jos=C3=A9_Mu=C3=B1oz_Calero?=)
Date: Tue, 22 Mar 2016 02:18:48 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <20160321161841.GP10371@nataraja>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
 <20160321161841.GP10371@nataraja>
Message-ID: <CA+DkyWkoAeFKcEo-qQXs1pma9rV_hsOeAUczKR0B_k+RJPhRhQ@mail.gmail.com>

Well, the idea was to use libipsec to integrate IPSec functionality into
OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start
connection.

Maybe it has no sense or it is not an improvement, this is why I am asking
you. I am no expert as you can see.

What about writting a GTP traffic open source analyzer?
I started writting it a couple of years ago.
I used tcpdump output and parsed it with awk and got statistics about many
things (especially errors, packets per protocols counting...).
It could be written in C this time.

Could be interesting doing it properly?


2016-03-21 17:18 GMT+01:00 Harald Welte <laforge at gnumonks.org>:

> Hi Manuel,
>
> On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel Jos? Mu?oz Calero wrote:
> > 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.
>
> thanks for reaching out about this.
>
> > Long story short, what about me implementing IPSec for GTP-C in OpenGGSN?
> > Do you think it could be useful? Feasible?
>
> I've quickly looked at the documents you linked, and they don't really
> state anything beyond "use IPsec for GTP".  Specifically, the do not
> specify how to do key distribution, how to set up the SAs, whether they
> use a standard IKEv2 or something else, ...
>
> As Linux has a fairly complete IPsec implementation consisting of the
> kernel-level IPsec transforms with its netlink interface and e.g. the
> Strongswan userland, I don't really think there is anything that would
> need to be done in addition to configuring both this IPsec stack and
> OpenGGSN.
>
> So what exactly would you want to do?  Am I missing something?
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/f3beed85/attachment.htm>

From jacob01 at gmx.net  Tue Mar 22 08:58:34 2016
From: jacob01 at gmx.net (Jacob Erlbeck)
Date: Tue, 22 Mar 2016 09:58:34 +0100
Subject: [PATCH] Change the interface in osmo-pcu for 11 bit RACH
In-Reply-To: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <56F1093A.2050407@gmx.net>

Hi,

what exactly is your definition of 'rach_type'? Could you please either
add a reference to the document where this notion is specified, or if
there is none, a specification of its value range.

Is the used TSC (TS1 or TS2 in case of EGPRS) is mapped to this value?
If not, this should IMHO also be added to have all relevant RACH
information included, since this is closely related to the 11 bit RACH
type which cannot be fully used for EGPRS without that information. See
44.060, 11.2.5a for details.

Jacob

On 21.03.2016 16:03, Bhargava Abhyankar wrote:
> Interface changes in osmo-pcu towards osmo-bts to
> receive 11 bit RACH.
> The interface version number is increased by 1.
> -	int rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta);
> +	int rcv_rach(uint16_t ra, uint32_t Fn, int16_t qta,
> +					uint8_t rach_type = 0);


>  struct gsm_pcu_if_rach_ind {
>  	uint8_t		sapi;
> -	uint8_t		ra;
> +	uint16_t	ra;
>  	int16_t		qta;
>  	uint32_t	fn;
>  	uint16_t	arfcn;
> +	uint8_t		rach_type;
>  } __attribute__ ((packed));


From Sangamesh.Sajjan at radisys.com  Tue Mar 22 10:22:59 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Tue, 22 Mar 2016 10:22:59 +0000
Subject: Proposal for new structure definition for compression algorithm
In-Reply-To: <20160318102837.GC1323@ass40.sysmocom.de>
References: <BY2PR08MB71308C3CC0D5B4FE8BB14FC888B0@BY2PR08MB713.namprd08.prod.outlook.com>
 <20160318102837.GC1323@ass40.sysmocom.de>
Message-ID: <BLUPR08MB7115E04ED70C94108D1678F88800@BLUPR08MB711.namprd08.prod.outlook.com>

Hi Neels,

Thanks for the suggestions.

On Friday, March 18, 2016 3:59 PM, Neels Hofmeyr wrote:

> though I'm not entirely familiar with the compression algorithm, I'm pretty sure that using an array of strings to store bits will make the code less efficient by magnitudes.

The proposed structures are being used in following scenario.
    1.	System Init (i.e. During system bootup) 
	*	Array of strings are used to form a tree, it is used only once during system bootup , hence it should not impact the performance. Let me know your opinion on this ?
    2.	Decoding of EGPRS packet downlink Ack/Nack
	*	While decoding there is no string comparison involved, we read every bit from the bitmap and traverse tree generated in init, hence only bit operation involved in decoding.
    3.	Encoding of packet uplink Ack/Nack
	*	 While encoding, first find the number of one's/zero's (i.e. run length of one's or zero's) consecutively and  find the corresponding code word by referring to the code word list
	*	This involves string comparison to find the code word, but based on your feedback we are planning to avoid string operations 
		and adopt existing (i.e. master ) approach to find the code word by using respective tables.

Hence to summarize, the tree based approach is more significant during the decoding of bitmap.
In current master code for decoding,  the function t4_rle_term is used to find the run length for each received code word, 
There could be multiple code words in the received bitmap and each require multiple iterations(i.e. maximum of 64 iterations) to find run length.
Instead if tree based approach is used multiple iterations can be avoided to find run length. 

Patches for the above modification will be sent further.

Thanks,
Sangamesh


From Bhargava.Abhyankar at radisys.com  Tue Mar 22 13:05:28 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Tue, 22 Mar 2016 13:05:28 +0000
Subject: [PATCH] Change the interface in osmo-pcu for 11 bit RACH
In-Reply-To: <56F1093A.2050407@gmx.net>
References: <1458572630-24117-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <56F1093A.2050407@gmx.net>
Message-ID: <DM2PR0801MB095957A06072DD572558EDC491800@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hello Jacob,
Thanks for your inputs.

>what exactly is your definition of 'rach_type'? Could you please either add a reference to the document where this notion is >specified, or if there is none, a specification of its value range.
We propose to use following enum as 'rach_type'
enum {
                GPRS_8_BIT_RACH = 0,
                GPRS_11_BIT_RACH ,
                EGPRS_8_PSK_11_BIT_RACH ,
	EGPRS_NO_8_PSK_11_BIT_RACH
        };

This is not specified in standard, this is introduced as part of proposed interface changes between osmo-bts and osmo-pcu.
Osmo-bts should get the RACH information from L1 APIs and fill the appropriate 'rach_type' and send to osmo-pcu. 
Osmo-bts can distinguish between 8 bit RACH and 11 bit RACH using 'u8Size' parameter in PH-RA-IND premetive.

There is still open point on how osmo-bts distinguishes between types of 11 bit RACH based on received layer 1 message.
Let me know if you have any inputs.

Thanks
Bhargava Abhyankar




From Bhargava.Abhyankar at radisys.com  Tue Mar 22 13:12:31 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Tue, 22 Mar 2016 18:42:31 +0530
Subject: [PATCH 2/2] Avoid copy constructor in uplink tbf path
In-Reply-To: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>

The copy constructor of GprsCodingScheme class object used in
uplink tbf path is replaced by the reference variable.
Appropriate function prototypes and function definition are
changed.
This patch will increase efficiency of the code.
---
 src/bts.cpp                |  4 ++--
 src/bts.h                  |  4 ++--
 src/decoding.cpp           |  4 ++--
 src/decoding.h             |  4 ++--
 src/gprs_coding_scheme.cpp |  4 ++--
 src/gprs_coding_scheme.h   | 24 ++++++++++++------------
 6 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..412d502 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -1316,7 +1316,7 @@ int gprs_rlcmac_pdch::rcv_block(uint8_t *data, uint8_t len, uint32_t fn,
 }
 
 int gprs_rlcmac_pdch::rcv_data_block(uint8_t *data, uint32_t fn,
-	struct pcu_l1_meas *meas, GprsCodingScheme cs)
+	struct pcu_l1_meas *meas, const GprsCodingScheme &cs)
 {
 	int rc;
 	struct gprs_rlc_data_info rlc_dec;
@@ -1375,7 +1375,7 @@ int gprs_rlcmac_pdch::rcv_data_block(uint8_t *data, uint32_t fn,
 }
 
 int gprs_rlcmac_pdch::rcv_block_gprs(uint8_t *data, uint32_t fn,
-	struct pcu_l1_meas *meas, GprsCodingScheme cs)
+	struct pcu_l1_meas *meas, const GprsCodingScheme &cs)
 {
 	unsigned payload = data[0] >> 6;
 	bitvec *block;
diff --git a/src/bts.h b/src/bts.h
index c975304..812419e 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -66,9 +66,9 @@ struct gprs_rlcmac_pdch {
 	int rcv_block(uint8_t *data, uint8_t len, uint32_t fn,
 		struct pcu_l1_meas *meas);
 	int rcv_block_gprs(uint8_t *data, uint32_t fn,
-		struct pcu_l1_meas *meas, GprsCodingScheme cs);
+		struct pcu_l1_meas *meas, const GprsCodingScheme &cs);
 	int rcv_data_block(uint8_t *data, uint32_t fn,
-		struct pcu_l1_meas *meas, GprsCodingScheme cs);
+		struct pcu_l1_meas *meas, const GprsCodingScheme &cs);
 
 	gprs_rlcmac_bts *bts_data() const;
 	BTS *bts() const;
diff --git a/src/decoding.cpp b/src/decoding.cpp
index 0c81b2a..1c94b5e 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -181,7 +181,7 @@ static int parse_extensions_gprs(const uint8_t *data, unsigned int data_len,
 }
 
 int Decoding::rlc_data_from_ul_data(
-	const struct gprs_rlc_data_block_info *rdbi, GprsCodingScheme cs,
+	const struct gprs_rlc_data_block_info *rdbi, const GprsCodingScheme &cs,
 	const uint8_t *data, RlcData *chunks, unsigned int chunks_size,
 	uint32_t *tlli)
 {
@@ -342,7 +342,7 @@ void Decoding::extract_rbb(const struct bitvec *rbb, char *show_rbb)
 }
 
 int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
-	const uint8_t *data, GprsCodingScheme cs)
+	const uint8_t *data, const GprsCodingScheme &cs)
 {
 	unsigned int cur_bit = 0;
 	switch(cs.headerTypeData()) {
diff --git a/src/decoding.h b/src/decoding.h
index 1043d67..efee4d2 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -36,7 +36,7 @@ public:
 
 	static int rlc_data_from_ul_data(
 		const struct gprs_rlc_data_block_info *rdbi,
-		GprsCodingScheme cs, const uint8_t *data, RlcData *chunks,
+		const GprsCodingScheme &cs, const uint8_t *data, RlcData *chunks,
 		unsigned int chunks_size, uint32_t *tlli);
 	static uint8_t get_ms_class_by_capability(MS_Radio_Access_capability_t *cap);
 	static uint8_t get_egprs_ms_class_by_capability(MS_Radio_Access_capability_t *cap);
@@ -52,7 +52,7 @@ public:
 		const uint8_t *data,
 		const GprsCodingScheme &cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
-		const uint8_t *data, GprsCodingScheme cs);
+		const uint8_t *data, const GprsCodingScheme &cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
 		const struct gprs_rlc_data_info *rlc,
 		unsigned int data_block_idx,
diff --git a/src/gprs_coding_scheme.cpp b/src/gprs_coding_scheme.cpp
index 8601d4f..cb141c1 100644
--- a/src/gprs_coding_scheme.cpp
+++ b/src/gprs_coding_scheme.cpp
@@ -259,7 +259,7 @@ const char *GprsCodingScheme::modeName(Mode mode)
 	}
 }
 
-bool GprsCodingScheme::isFamilyCompatible(GprsCodingScheme o) const
+bool GprsCodingScheme::isFamilyCompatible(const GprsCodingScheme &o) const
 {
 	if (*this == o)
 		return true;
@@ -270,7 +270,7 @@ bool GprsCodingScheme::isFamilyCompatible(GprsCodingScheme o) const
 	return family() == o.family();
 }
 
-bool GprsCodingScheme::isCombinable(GprsCodingScheme o) const
+bool GprsCodingScheme::isCombinable(const GprsCodingScheme &o) const
 {
 	return numDataBlocks() == o.numDataBlocks();
 }
diff --git a/src/gprs_coding_scheme.h b/src/gprs_coding_scheme.h
index aec3762..1519e12 100644
--- a/src/gprs_coding_scheme.h
+++ b/src/gprs_coding_scheme.h
@@ -64,16 +64,16 @@ public:
 	unsigned int to_num() const;
 
 	GprsCodingScheme& operator =(Scheme s);
-	GprsCodingScheme& operator =(GprsCodingScheme o);
+	GprsCodingScheme& operator =(const GprsCodingScheme &o);
 
 	bool isValid()   const {return UNKNOWN <= m_scheme && m_scheme <= MCS9;}
 	bool isGprs()   const {return CS1 <= m_scheme && m_scheme <= CS4;}
 	bool isEgprs()  const {return m_scheme >= MCS1;}
 	bool isEgprsGmsk()  const {return isEgprs() && m_scheme <= MCS4;}
 	bool isCompatible(Mode mode) const;
-	bool isCompatible(GprsCodingScheme o) const;
-	bool isFamilyCompatible(GprsCodingScheme o) const;
-	bool isCombinable(GprsCodingScheme o) const;
+	bool isCompatible(const GprsCodingScheme &o) const;
+	bool isFamilyCompatible(const GprsCodingScheme &o) const;
+	bool isCombinable(const GprsCodingScheme &o) const;
 
 	void inc(Mode mode);
 	void dec(Mode mode);
@@ -133,7 +133,7 @@ inline bool GprsCodingScheme::isCompatible(Mode mode) const
 	return false;
 }
 
-inline bool GprsCodingScheme::isCompatible(GprsCodingScheme o) const
+inline bool GprsCodingScheme::isCompatible(const GprsCodingScheme &o) const
 {
 	return (isGprs() && o.isGprs()) || (isEgprs() && o.isEgprs());
 }
@@ -160,7 +160,7 @@ inline GprsCodingScheme& GprsCodingScheme::operator =(Scheme s)
 	return *this;
 }
 
-inline GprsCodingScheme& GprsCodingScheme::operator =(GprsCodingScheme o)
+inline GprsCodingScheme& GprsCodingScheme::operator =(const GprsCodingScheme &o)
 {
 	m_scheme = o.m_scheme;
 	return *this;
@@ -183,33 +183,33 @@ inline GprsCodingScheme GprsCodingScheme::getEgprsByNum(unsigned num)
 }
 
 /* The coding schemes form a partial ordering */
-inline bool operator ==(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator ==(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return GprsCodingScheme::Scheme(a) == GprsCodingScheme::Scheme(b);
 }
 
-inline bool operator !=(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator !=(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return !(a == b);
 }
 
-inline bool operator <(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator <(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return a.isCompatible(b) &&
 		GprsCodingScheme::Scheme(a) < GprsCodingScheme::Scheme(b);
 }
 
-inline bool operator >(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator >(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return b < a;
 }
 
-inline bool operator <=(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator <=(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return a == b || a < b;
 }
 
-inline bool operator >=(GprsCodingScheme a, GprsCodingScheme b)
+inline bool operator >=(const GprsCodingScheme &a, const GprsCodingScheme &b)
 {
 	return a == b || a > b;
 }
-- 
2.5.0




From Bhargava.Abhyankar at radisys.com  Tue Mar 22 13:12:30 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Tue, 22 Mar 2016 18:42:30 +0530
Subject: [PATCH 1/2] Refactor the Uplink RLC header parsing function
Message-ID: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>

Parsing the uplink data header for GPRS and EGPRS header type 3
is handled in separate functions.
This patch will enhance modularity of the code.
---
 src/decoding.cpp | 140 ++++++++++++++++++++++++++++++-------------------------
 src/decoding.h   |   9 +++-
 2 files changed, 84 insertions(+), 65 deletions(-)

diff --git a/src/decoding.cpp b/src/decoding.cpp
index f2b548c..0c81b2a 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -344,74 +344,14 @@ void Decoding::extract_rbb(const struct bitvec *rbb, char *show_rbb)
 int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 	const uint8_t *data, GprsCodingScheme cs)
 {
-	const struct gprs_rlc_ul_header_egprs_3 *egprs3;
-	const struct rlc_ul_header *gprs;
-	unsigned int e_ti_header;
 	unsigned int cur_bit = 0;
-	int punct, punct2, with_padding, cps;
-	unsigned int offs;
-
 	switch(cs.headerTypeData()) {
-	case GprsCodingScheme::HEADER_GPRS_DATA:
-		gprs = static_cast<struct rlc_ul_header *>
-			((void *)data);
-
-		gprs_rlc_data_info_init_ul(rlc, cs, false);
-
-		rlc->r      = gprs->r;
-		rlc->si     = gprs->si;
-		rlc->tfi    = gprs->tfi;
-		rlc->cps    = 0;
-		rlc->rsb    = 0;
-
-		rlc->num_data_blocks = 1;
-		rlc->block_info[0].cv  = gprs->cv;
-		rlc->block_info[0].pi  = gprs->pi;
-		rlc->block_info[0].bsn = gprs->bsn;
-		rlc->block_info[0].e   = gprs->e;
-		rlc->block_info[0].ti  = gprs->ti;
-		rlc->block_info[0].spb = 0;
-
-		cur_bit += rlc->data_offs_bits[0];
-
-		/* skip data area */
-		cur_bit += cs.maxDataBlockBytes() * 8;
+	case GprsCodingScheme::HEADER_GPRS_DATA :
+		cur_bit = rlc_parse_ul_data_header_gprs(rlc, data, cs);
 		break;
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3:
-		egprs3 = static_cast<struct gprs_rlc_ul_header_egprs_3 *>
-			((void *)data);
-
-		cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
-		gprs_rlc_mcs_cps_decode(cps, cs, &punct, &punct2, &with_padding);
-		gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
-
-		rlc->r      = egprs3->r;
-		rlc->si     = egprs3->si;
-		rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
-		rlc->cps    = cps;
-		rlc->rsb    = egprs3->rsb;
-
-		rlc->num_data_blocks = 1;
-		rlc->block_info[0].cv  = egprs3->cv;
-		rlc->block_info[0].pi  = egprs3->pi;
-		rlc->block_info[0].spb = egprs3->spb;
-		rlc->block_info[0].bsn =
-			(egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
-
-		cur_bit += rlc->data_offs_bits[0] - 2;
-
-		offs = rlc->data_offs_bits[0] / 8;
-		OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 1);
-
-		e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
-		rlc->block_info[0].e   = !!(e_ti_header & 0x01);
-		rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
-		cur_bit += 2;
-
-		/* skip data area */
-		cur_bit += cs.maxDataBlockBytes() * 8;
+	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3 :
+		cur_bit = rlc_parse_ul_data_header_egprs_type_3(rlc, data, cs);
 		break;
-
 	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1:
 	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2:
 		/* TODO: Support both header types */
@@ -426,6 +366,78 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 	return cur_bit;
 }
 
+int Decoding::rlc_parse_ul_data_header_egprs_type_3(
+	struct gprs_rlc_data_info *rlc,
+	const uint8_t *data,
+	const GprsCodingScheme &cs)
+{
+	int punct, punct2, with_padding, cps;
+	unsigned int e_ti_header, offs, cur_bit = 0;
+	const struct gprs_rlc_ul_header_egprs_3 *egprs3;
+
+	egprs3 = static_cast < struct gprs_rlc_ul_header_egprs_3 * >
+			((void *)data);
+
+	cps    = (egprs3->cps_a << 0)  | (egprs3->cps_b << 2);
+	gprs_rlc_mcs_cps_decode(cps, cs, &punct, &punct2, &with_padding);
+	gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
+
+	rlc->r      = egprs3->r;
+	rlc->si     = egprs3->si;
+	rlc->tfi    = (egprs3->tfi_a << 0)  | (egprs3->tfi_b << 2);
+	rlc->cps    = cps;
+	rlc->rsb    = egprs3->rsb;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs3->cv;
+	rlc->block_info[0].pi  = egprs3->pi;
+	rlc->block_info[0].spb = egprs3->spb;
+	rlc->block_info[0].bsn =
+			(egprs3->bsn1_a << 0) | (egprs3->bsn1_b << 5);
+
+	cur_bit += rlc->data_offs_bits[0] - 2;
+	offs = rlc->data_offs_bits[0] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 1);
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[0].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
+
+int Decoding::rlc_parse_ul_data_header_gprs(struct gprs_rlc_data_info *rlc,
+	const uint8_t *data, const GprsCodingScheme &cs)
+{
+	const struct rlc_ul_header *gprs;
+	unsigned int cur_bit = 0;
+
+	gprs = static_cast < struct rlc_ul_header * >
+		((void *)data);
+
+	gprs_rlc_data_info_init_ul(rlc, cs, false);
+
+	rlc->r      = gprs->r;
+	rlc->si     = gprs->si;
+	rlc->tfi    = gprs->tfi;
+	rlc->cps    = 0;
+	rlc->rsb    = 0;
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = gprs->cv;
+	rlc->block_info[0].pi  = gprs->pi;
+	rlc->block_info[0].bsn = gprs->bsn;
+	rlc->block_info[0].e   = gprs->e;
+	rlc->block_info[0].ti  = gprs->ti;
+	rlc->block_info[0].spb = 0;
+	cur_bit += rlc->data_offs_bits[0];
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
+
 /**
  * \brief Copy LSB bitstream RLC data block to byte aligned buffer.
  *
diff --git a/src/decoding.h b/src/decoding.h
index 58ecd18..1043d67 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -43,7 +43,14 @@ public:
 
 	static void extract_rbb(const uint8_t *rbb, char *extracted_rbb);
 	static void extract_rbb(const struct bitvec *rbb, char *show_rbb);
-
+	static int rlc_parse_ul_data_header_egprs_type_3(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		const GprsCodingScheme &cs);
+	static int rlc_parse_ul_data_header_gprs(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		const GprsCodingScheme &cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
-- 
2.5.0




From Prasad.Kaup at radisys.com  Tue Mar 22 13:38:12 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Tue, 22 Mar 2016 13:38:12 +0000
Subject: Regarding integration of NURAN L1 1.0
In-Reply-To: <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>
Message-ID: <BN3PR08MB12372B26906C10064211C64EE6800@BN3PR08MB1237.namprd08.prod.outlook.com>

Hi  Minh-Quang Nguyen,
			  Thanks for the information. I see from the site that Sourcery  CodeBench Lite releases for ARM EABI is no longer available. Instead  there  is a trial  version of Sourcery CodeBench for ARM available.   We have downloaded it and trying to use it.

Let me know the procedure for download of binaries to target and other details of integration test setup, For example
	-   other components to be connected to target (Any mandatory components like GPS)
	-  board configuration details
	-  debug terminal connections
	-  LAN1 /LAN2 connection usage details
	-   precautions  to be taken

Regards
Prasad


From laforge at gnumonks.org  Tue Mar 22 14:08:07 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Mar 2016 15:08:07 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <CA+DkyWkoAeFKcEo-qQXs1pma9rV_hsOeAUczKR0B_k+RJPhRhQ@mail.gmail.com>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
 <20160321161841.GP10371@nataraja>
 <CA+DkyWkoAeFKcEo-qQXs1pma9rV_hsOeAUczKR0B_k+RJPhRhQ@mail.gmail.com>
Message-ID: <20160322140807.GS10371@nataraja>

Hi Manuel,

On Tue, Mar 22, 2016 at 02:18:48AM +0100, Manuel Jos? Mu?oz Calero wrote:
> Well, the idea was to use libipsec to integrate IPSec functionality into
> OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start
> connection.

I don't think this is a good idea at all, sorry.

IPsec is a feature provided by the operating system, and it is very well
(and efficiently) handled by doing all the per-packet operations inside
the kernel itself.  Only the control (key handshake) is done in
userspace, and three are several implementations of the IKEv1/IKEv2
protocols out there.  There's no need to replicat that functionality in
OpenGGSN.

> What about writting a GTP traffic open source analyzer?
> I started writting it a couple of years ago.
> I used tcpdump output and parsed it with awk and got statistics about many
> things (especially errors, packets per protocols counting...).
> It could be written in C this time.

I suggest you to have a look at the wireshark infastructure in the
'Statistics' / 'Telephony' menus.  They do pretty nice for other
protocols like TCP or SIP.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From manuelj.munoz at gmail.com  Tue Mar 22 14:22:07 2016
From: manuelj.munoz at gmail.com (=?UTF-8?Q?Manuel_Jos=C3=A9_Mu=C3=B1oz_Calero?=)
Date: Tue, 22 Mar 2016 15:22:07 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <20160322140807.GS10371@nataraja>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
 <20160321161841.GP10371@nataraja>
 <CA+DkyWkoAeFKcEo-qQXs1pma9rV_hsOeAUczKR0B_k+RJPhRhQ@mail.gmail.com>
 <20160322140807.GS10371@nataraja>
Message-ID: <CA+DkyWne+oc2VobN-iDqFc5m6UPozgFREwP8+_8EjJ5_wF2xFA@mail.gmail.com>

Fair enough.
Thanks for your time and comments.
El 22/3/2016 15:15, "Harald Welte" <laforge at gnumonks.org> escribi?:

> Hi Manuel,
>
> On Tue, Mar 22, 2016 at 02:18:48AM +0100, Manuel Jos? Mu?oz Calero wrote:
> > Well, the idea was to use libipsec to integrate IPSec functionality into
> > OpenGGSN code, so OpenGGSN itself could set IPSec parameters and start
> > connection.
>
> I don't think this is a good idea at all, sorry.
>
> IPsec is a feature provided by the operating system, and it is very well
> (and efficiently) handled by doing all the per-packet operations inside
> the kernel itself.  Only the control (key handshake) is done in
> userspace, and three are several implementations of the IKEv1/IKEv2
> protocols out there.  There's no need to replicat that functionality in
> OpenGGSN.
>
> > What about writting a GTP traffic open source analyzer?
> > I started writting it a couple of years ago.
> > I used tcpdump output and parsed it with awk and got statistics about
> many
> > things (especially errors, packets per protocols counting...).
> > It could be written in C this time.
>
> I suggest you to have a look at the wireshark infastructure in the
> 'Statistics' / 'Telephony' menus.  They do pretty nice for other
> protocols like TCP or SIP.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/28c85dbc/attachment.htm>

From minh-quang.nguyen at nutaq.com  Tue Mar 22 14:34:12 2016
From: minh-quang.nguyen at nutaq.com (Minh-Quang Nguyen)
Date: Tue, 22 Mar 2016 10:34:12 -0400
Subject: Regarding integration of NURAN L1 1.0
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12372B26906C10064211C64EE6800@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F0373244D@NTWAEX01.interne.lyrtech.com>

Hi Prasad,

> Let me know the procedure for download of binaries to target

1) Stop BTS and PCU services by typing 'systemctl stop sysmobts' and 'systemctl stop sysmopcu', respectively

2) Copy sysmobts, sysmobts-mgr and osmo-pcu binaries from your remote host to /usr/bin

3) Start BTS and PCU services by typing 'systemctl start sysmobts' and 'systemctl start sysmopcu', respectively

> other details of integration test setup, For example
>	-   other components to be connected to target (Any mandatory components like GPS)
Connect GPS antenna to SMA connector (yellow) near the power supply connector.

>	-  board configuration details
GSM Rx and Tx antennas are required to connect to Rx and Tx ports of the LC10 unit, respectively. 
(Tx antenna must be able to handle at least 5W of Tx power)

>	-  debug terminal connections
Via SSH, you need to know IP address of the target boards ( master & slave) inside the LC10 unit 
(DHCP lease list in your network DHCP server will tell IP address associated with MAC address labeled on chassis of the LC10 unit)

>	-  LAN1 /LAN2 connection usage details
You can use any of them.

>	-   precautions  to be taken
Make sure both Tx and Rx antennas are properly connected before powering cycle the unit.

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 at nutaq.com
www.nutaq.com 

 QUEBEC MONTREAL NEW YORK

Facebook Twitter LinkedIn YouTube


-----Original Message-----
From: Prasad Kaup [mailto:Prasad.Kaup at radisys.com] 
Sent: Tuesday, March 22, 2016 9:38 AM
To: Minh-Quang Nguyen; Neels Hofmeyr; osmocom-net-gprs at lists.osmocom.org
Cc: Saurabh Sharan; Yves Godin; Abhinav Pragya Rishi
Subject: RE: Regarding integration of NURAN L1 1.0

Hi  Minh-Quang Nguyen,
			  Thanks for the information. I see from the site that Sourcery  CodeBench Lite releases for ARM EABI is no longer available. Instead  there  is a trial  version of Sourcery CodeBench for ARM available.   We have downloaded it and trying to use it.

Let me know the procedure for download of binaries to target and other details of integration test setup, For example
	-   other components to be connected to target (Any mandatory components like GPS)
	-  board configuration details
	-  debug terminal connections
	-  LAN1 /LAN2 connection usage details
	-   precautions  to be taken

Regards
Prasad


From msuraev at sysmocom.de  Tue Mar 22 14:49:53 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 22 Mar 2016 15:49:53 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
Message-ID: <56F15B91.5090004@sysmocom.de>

Hi.

Thanks for your interest. Are you looking into OpenGGSN only or you
might be interested in other parts of the stack as well?

On 03/21/2016 04:00 PM, Manuel Jos? Mu?oz Calero wrote:
> 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-000421.pdf)
> 3GPP Use IPSec to secure GTP messages
> (http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_13_yokohama/docs/PDF/S3-000329.pdf)
>
> Maybe some other security-oriented feature you want to be implemented?
>
> I would love to hear your thoughts!
>
> Thanks for your time,
> Manuel

-- 
Max Suraev <msuraev at 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 



From Bhargava.Abhyankar at radisys.com  Tue Mar 22 14:53:19 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Tue, 22 Mar 2016 14:53:19 +0000
Subject: Queries regarding L1 interface to osmo-bts for 11 bit RACH
Message-ID: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/0f5bc72b/attachment.htm>

From nhofmeyr at sysmocom.de  Tue Mar 22 15:12:52 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 Mar 2016 16:12:52 +0100
Subject: Academic project based on OpenGGSN
In-Reply-To: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
Message-ID: <20160322151252.GA7525@ass40.sysmocom.de>

On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel Jos? Mu?oz Calero wrote:
> 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.

Well, my opinion is that OpenGGSN has fairly bad code structuring. It has
heavy use of code duplication and the code layers aren't separated well
(e.g. I can't use libgtp to decode messages without also using its tx/rx).

So a proper audit and spring cleaning might be a nice project, if not
necessarily super exciting, at least it is well defined in that OpenGGSN
should not (or hardly) change behavior while making the code safer /
easier to maintain / more versatile to re-use. You could analyse the code
structures and/or security holes, academically argue why they are bad and
come up with improvements, while using and/or writing tests to ensure
correctness. If you know your stuff, all OpenGGSN users would arguably
benefit from that.

I'd like to do that if I had the time, but that will probably never be the
case. I'm too busy writing new bugs for 3G :P

That's just my sixpence -- good speed for your project, whichever you
chose! :)

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/93c37834/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Mar 22 16:00:13 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 Mar 2016 17:00:13 +0100
Subject: Proposal for new structure definition for compression algorithm
In-Reply-To: <BLUPR08MB7115E04ED70C94108D1678F88800@BLUPR08MB711.namprd08.prod.outlook.com>
References: <BY2PR08MB71308C3CC0D5B4FE8BB14FC888B0@BY2PR08MB713.namprd08.prod.outlook.com>
 <20160318102837.GC1323@ass40.sysmocom.de>
 <BLUPR08MB7115E04ED70C94108D1678F88800@BLUPR08MB711.namprd08.prod.outlook.com>
Message-ID: <20160322160013.GG7525@ass40.sysmocom.de>

Hi Sangamesh,

I should probably also read all of the code involved, properly, which I
must admit I haven't, but based on general knowledge, my replies are:

On Tue, Mar 22, 2016 at 10:22:59AM +0000, Sangamesh Sajjan wrote:
> The proposed structures are being used in following scenario.
>     1.	System Init (i.e. During system bootup) 
> 	*	Array of strings are used to form a tree, it is used only once during system bootup , hence it should not impact the performance. Let me know your opinion on this ?

Ok, for once-upon-boot a string approach sounds fair enough.

>     2.	Decoding of EGPRS packet downlink Ack/Nack
> 	*	While decoding there is no string comparison involved, we read every bit from the bitmap and traverse tree generated in init, hence only bit operation involved in decoding.

sounds good

>     3.	Encoding of packet uplink Ack/Nack
> 	*	 While encoding, first find the number of one's/zero's (i.e. run length of one's or zero's) consecutively and  find the corresponding code word by referring to the code word list
> 	*	This involves string comparison to find the code word,

Ick! :)

>      but based on your feedback we are planning to avoid string operations 
> 		and adopt existing (i.e. master ) approach to find the code word by using respective tables.

Sounds much better, yes.

> In current master code for decoding,  the function t4_rle_term is used to find the run length for each received code word, 
> There could be multiple code words in the received bitmap and each require multiple iterations(i.e. maximum of 64 iterations) to find run length.
> Instead if tree based approach is used multiple iterations can be avoided to find run length. 

Is this a separate suggestion to introduce a binary tree search? Beware of
too heavy / premature optimizations, but your trajectory sounds way better
now.

Anyway, looking forward to the patches, and I hope to read the patch
context properly, then. Thanks!

~Neels


-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/77874e4a/attachment.bin>

From Yves.Godin at nutaq.com  Tue Mar 22 18:34:43 2016
From: Yves.Godin at nutaq.com (Yves Godin)
Date: Tue, 22 Mar 2016 14:34:43 -0400
Subject: Queries regarding L1 interface to osmo-bts for 11 bit RACH
References: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F037324E4@NTWAEX01.interne.lyrtech.com>

Bhargava,

This answer only applies to platforms that use the NuRAN PHY (SuperFemto, LiteCell 1.x, ...).

 

1.       For 11 bit RACH,  in PH-RA-IND sent from layer 1.

?         Whether 'u8Size' will be 2 in case of 11 bit RACH ?

[YGOD] Yes it will.

 

?         What is the alignment of 11 bits inside 'u8Buffer ?

[YGOD] Data is packed LSB first

 

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

[YGOD] Yes, you are correct. GsmL1_BurstType_Access_0 is for the "normal" access bursts, GsmL1_BurstType_Access_1 is for TS1 and GsmL1_BurstType_Access_2 is for TS2.

 

Best Regards,

Yves

 

 

De : osmocom-net-gprs [mailto:osmocom-net-gprs-bounces at lists.osmocom.org] De la part de Bhargava Abhyankar
Envoy? : March-22-16 10:53 AM
? : osmocom-net-gprs at lists.osmocom.org
Objet : Queries regarding L1 interface to osmo-bts for 11 bit RACH

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160322/2f24a14a/attachment.htm>

From holger at freyther.de  Tue Mar 22 20:26:49 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 22 Mar 2016 21:26:49 +0100
Subject: [PATCH 2/2] Avoid copy constructor in uplink tbf path
In-Reply-To: <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <096AF2E6-23F7-4E4B-8BAD-7C6FFD845CFC@freyther.de>


> On 22 Mar 2016, at 14:12, Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com> wrote:
> 
> The copy constructor of GprsCodingScheme class object used in
> uplink tbf path is replaced by the reference variable.
> Appropriate function prototypes and function definition are
> changed.

yes, it is good style to mark them as const (and pass them as reference).


> This patch will increase efficiency of the code.

Given the size of the member and that the constructor is inlined my first assumption is that for this specific type the runtime cost of copying m_scheme and a pointer will be about the same.


kind regards
	holger

From laforge at gnumonks.org  Tue Mar 22 21:20:07 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Mar 2016 22:20:07 +0100
Subject: Queries regarding L1 interface to osmo-bts for 11 bit RACH
In-Reply-To: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>
References: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>
Message-ID: <20160322212007.GL10371@nataraja>

Hi Bhargava,

On Tue, Mar 22, 2016 at 02:53:19PM +0000, Bhargava Abhyankar wrote:
> 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.

given that the current format relates to the history of the omso-bts
project and the first PHY that we interfaced it with, I think if we make
some changes now to the L1 interface (including L1SAP), we could
actually clean things up.

To do so, I would suggest to

a) on L1SAP, extend ph_rach_ind_param with

* a uint16_t for 'ra'
* add a member 'is_11bit' to indicate 8/11 bit
* an enum to indicate the different burst types

(and change the osmo-bts-* implementations as well as common code to use
 that updated definition)

b) on the PCU socket, perform similar changes to gsm_pcu_if_rach_ind

After performing above-mentioned changes, the formatting of the data
should be self-explanatory.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From jacob01 at gmx.net  Wed Mar 23 10:23:04 2016
From: jacob01 at gmx.net (Jacob)
Date: Wed, 23 Mar 2016 11:23:04 +0100
Subject: [PATCH 2/2] Avoid copy constructor in uplink tbf path
In-Reply-To: <096AF2E6-23F7-4E4B-8BAD-7C6FFD845CFC@freyther.de>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>
 <096AF2E6-23F7-4E4B-8BAD-7C6FFD845CFC@freyther.de>
Message-ID: <56F26E88.6090201@gmx.net>

Hi

On 22.03.2016 21:26, Holger Freyther wrote:
> 
>> On 22 Mar 2016, at 14:12, Bhargava Abhyankar <Bhargava.Abhyankar at radisys.com> wrote:
>>
>> The copy constructor of GprsCodingScheme class object used in
>> uplink tbf path is replaced by the reference variable.
>> Appropriate function prototypes and function definition are
>> changed.
> 
> yes, it is good style to mark them as const (and pass them as reference).

Hmm. I do not agree. Passing as reference doesn't make much sense here
(there is not performance issue and no risk of slicing). It just an
integer/enum disguised as class and it is meant be used like an enum.
But of course, if it was a reference, marking it as const would be good.

> 
> 
>> This patch will increase efficiency of the code.

No, using a reference in general (unless inlining is done) will
eventually result in a larger variable/parameter/field size (depending
on the enum size and the pointer size on the target plattform, where the
pointer size will be >= enum size on all platforms I know of). In
addition, dereferencing is needed which cost additional instructions and
memory accesses (albeit with a high probability for a cache hit, if
there is any).

So in my personal opinion I wouldn't merge this patch, BYMMV.

Kind regards

Jacob

> 
> Given the size of the member and that the constructor is inlined my first assumption is that for this specific type the runtime cost of copying m_scheme and a pointer will be about the same.
> 


From holger at freyther.de  Wed Mar 23 10:34:13 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 23 Mar 2016 11:34:13 +0100
Subject: [PATCH 2/2] Avoid copy constructor in uplink tbf path
In-Reply-To: <56F26E88.6090201@gmx.net>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>
 <096AF2E6-23F7-4E4B-8BAD-7C6FFD845CFC@freyther.de> <56F26E88.6090201@gmx.net>
Message-ID: <DFE263BC-F770-49AE-A236-3E5413AB21F3@freyther.de>


> On 23 Mar 2016, at 11:23, Jacob <jacob01 at gmx.net> wrote:
> 
> Hi

Hi,


>> 
>> yes, it is good style to mark them as const (and pass them as reference).
> 
> Hmm. I do not agree. Passing as reference doesn't make much sense here
> (there is not performance issue and no risk of slicing). It just an
> integer/enum disguised as class and it is meant be used like an enum.
> But of course, if it was a reference, marking it as const would be good.

Given your other argument about the reference I will not merge the patch but could you explain why

	isCompatible(), isFamilyCompatible(), ... and
	pdch::rcv_data_block, rcv_block_gprs

require a mutable argument? I assume that ::inc/::dec should never be called on objects routines? From this point of view I think it is favorable to mark these methods with const parameters? What is your take here?



>>> This patch will increase efficiency of the code.
> 
> No, using a reference in general (unless inlining is done) will
> eventually result in a larger variable/parameter/field size (depending
> on the enum size and the pointer size on the target plattform, where the
> pointer size will be >= enum size on all platforms I know of). In
> addition, dereferencing is needed which cost additional instructions and
> memory accesses (albeit with a high probability for a cache hit, if
> there is any).


good point. I think either way the performance for this one will not be noticeable.

holger

From laforge at gnumonks.org  Wed Mar 23 10:46:55 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 23 Mar 2016 11:46:55 +0100
Subject: [PATCH 2/2] Avoid copy constructor in uplink tbf path
In-Reply-To: <56F26E88.6090201@gmx.net>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <1458652351-19578-2-git-send-email-Bhargava.Abhyankar@radisys.com>
 <096AF2E6-23F7-4E4B-8BAD-7C6FFD845CFC@freyther.de>
 <56F26E88.6090201@gmx.net>
Message-ID: <20160323104655.GW10371@nataraja>

Dear all,

as a general rule, I suggest to refrain from optimizations, unless

a) a performance issue is immediately obvious, or

b) there is actual profiling showing an improvement comparing
   before/after, or at least showing that the existing code is a CPU
   hog.

Everything else is - with all respect - likely to waste time of everyone
involved in preparing the patch, reviewing it, discussing it, etc.

To say it with Donald Knuth:
"Premature optimization is the root of all evil"

Now that of course is no excuse from writing unneccesarily bloated or
inefficient code in the first place, but we generally try to keep things
simple.

Also, keep in mind that a PCU in 1999/2000 had to run on incredibly
small and inefficient hardware, while today I think the smallest system
is the sysmoBTS 1002 on an ARM926EJS processor at 405 MHz.  And it only
has a single TRX at that.

All other systems it runs on have much faster CPU, memory bandwidth, RAM
size.... so let's focus on improving the code functionality and
completeness before optimizing things that are not even proven issues in
the real world

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Bhargava.Abhyankar at radisys.com  Wed Mar 23 11:50:51 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Wed, 23 Mar 2016 11:50:51 +0000
Subject: Queries regarding L1 interface to osmo-bts for 11 bit RACH
In-Reply-To: <20160322212007.GL10371@nataraja>
References: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>
 <20160322212007.GL10371@nataraja>
Message-ID: <DM2PR0801MB0959B1F807972FBA29E7750291810@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hello Harald,
	Thanks for the inputs.

On Wed, Mar 23, 2016 at 2.50 AM, Harald Welte wrote:

> a) on L1SAP, extend ph_rach_ind_param with
> * a uint16_t for 'ra'
> * add a member 'is_11bit' to indicate 8/11 bit
> * an enum to indicate the different burst types

Struct  ph_rach_ind_param will be enhanced as suggested by you. 

> (and change the osmo-bts-* implementations as well as common code to use  that updated definition)

Further patches will be triggered by incorporating the suggested inputs in osmo-pcu and osmo-bts. Initially we are planning to make osmo-bts changes in osmo-bts-sysmo and followed by other platforms.

Regards
Bhargava Abhyankar


From arvind.sirsikar at radisys.com  Wed Mar 23 12:59:47 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 23 Mar 2016 18:29:47 +0530
Subject: [PATCH 3/3] Support puncturing scheme selection for EGPRS DL
In-Reply-To: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <1458737988-4198-3-git-send-email-arvind.sirsikar@radisys.com>

Adds support to find the puncturing scheme for retransmission
with MCS change, retransmission with no MCS change, transmission
case. Puncturing scheme selection for retransmission case with
MCS change is aligned with TS 44.060 9.3.2.1. Puncturing scheme
selection for retransmission without MCS change, fresh transmission
is aligned with TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
---
 src/rlc.cpp           |   74 +++++++++++++++++++++++++++++++++++++++++++++++++
 src/rlc.h             |    6 +++-
 src/tbf_dl.cpp        |   25 +++++++++++++++--
 tests/tbf/TbfTest.err |   52 +++++++++++++++++-----------------
 4 files changed, 127 insertions(+), 30 deletions(-)

diff --git a/src/rlc.cpp b/src/rlc.cpp
index 6ea1597..6770043 100644
--- a/src/rlc.cpp
+++ b/src/rlc.cpp
@@ -399,3 +399,77 @@ void gprs_rlc_mcs_cps_decode(unsigned int cps,
 	default: ;
 	}
 }
+
+/*
+ * Finds the PS value for retransmission with MCS change,
+ * retransmission with no MCS change, fresh transmission cases.
+ * The return value shall be used for current transmission only
+ * 44.060 9.3.2.1 defines the PS selection for MCS change case
+ * cs_current is the output of MCS selection algorithm for retx
+ * cs is coding scheme of previous transmission of RLC data block
+ */
+enum egprs_puncturing_values gprs_get_punct_scheme(
+	enum egprs_puncturing_values punct,
+	const GprsCodingScheme &cs,
+	const GprsCodingScheme &cs_current)
+{
+	/* TS  44.060 9.3.2.1.1 */
+	if ((GprsCodingScheme::Scheme(cs) == GprsCodingScheme::MCS9) &&
+	(GprsCodingScheme::Scheme(cs_current) == GprsCodingScheme::MCS6)) {
+		if ((punct == EGPRS_PS_1) || (punct == EGPRS_PS_3))
+			return EGPRS_PS_1;
+		else if (punct == EGPRS_PS_2)
+			return EGPRS_PS_2;
+	} else if ((GprsCodingScheme::Scheme(cs) == GprsCodingScheme::MCS6) &&
+	(GprsCodingScheme::Scheme(cs_current) == GprsCodingScheme::MCS9)) {
+		if (punct == EGPRS_PS_1)
+			return EGPRS_PS_3;
+		else if (punct == EGPRS_PS_2)
+			return EGPRS_PS_2;
+	} else if ((GprsCodingScheme::Scheme(cs) == GprsCodingScheme::MCS7) &&
+	(GprsCodingScheme::Scheme(cs_current) == GprsCodingScheme::MCS5))
+		return EGPRS_PS_1;
+	else if ((GprsCodingScheme::Scheme(cs) == GprsCodingScheme::MCS5) &&
+	(GprsCodingScheme::Scheme(cs_current) == GprsCodingScheme::MCS7))
+		return EGPRS_PS_2;
+	else if (cs != cs_current)
+		return EGPRS_PS_1;
+	/* TS  44.060 9.3.2.1.1 ends here */
+	/*
+	 * Below else will handle fresh transmission, retransmission with no
+	 * MCS change case
+	 */
+	else
+		return punct;
+	return EGPRS_PS_INVALID;
+}
+
+/*
+ * This function calculates puncturing scheme for retransmission of a RLC
+ * block with same MCS. The computed value shall be used for next transmission
+ * of the same RLC block
+ * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
+ */
+void gprs_update_punct_scheme(enum egprs_puncturing_values *punct,
+	const GprsCodingScheme &cs)
+{
+	switch (GprsCodingScheme::Scheme(cs)) {
+	case GprsCodingScheme::MCS1 :
+	case GprsCodingScheme::MCS2 :
+	case GprsCodingScheme::MCS5 :
+	case GprsCodingScheme::MCS6 :
+		*punct = ((enum egprs_puncturing_values)((*punct + 1) %
+			EGPRS_MAX_PS_NUM_2));
+		break;
+	case GprsCodingScheme::MCS3 :
+	case GprsCodingScheme::MCS4 :
+	case GprsCodingScheme::MCS7 :
+	case GprsCodingScheme::MCS8 :
+	case GprsCodingScheme::MCS9 :
+		*punct = ((enum egprs_puncturing_values)((*punct + 1) %
+			EGPRS_MAX_PS_NUM_3));
+		break;
+	default:
+		break;
+	}
+}
diff --git a/src/rlc.h b/src/rlc.h
index 6a8fd29..8f75588 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -136,7 +136,11 @@ unsigned int gprs_rlc_mcs_cps(GprsCodingScheme cs, enum egprs_puncturing_values
 	punct, enum egprs_puncturing_values punct2, int with_padding);
 void gprs_rlc_mcs_cps_decode(unsigned int cps, GprsCodingScheme cs,
 	int *punct, int *punct2, int *with_padding);
-
+enum egprs_puncturing_values gprs_get_punct_scheme(enum egprs_puncturing_values
+	punct, const GprsCodingScheme &cs,
+	const GprsCodingScheme &cs_current_trans);
+void gprs_update_punct_scheme(enum egprs_puncturing_values *punct,
+	const GprsCodingScheme &cs);
 /*
  * I hold the currently transferred blocks and will provide
  * the routines to manipulate these arrays.
diff --git a/src/tbf_dl.cpp b/src/tbf_dl.cpp
index 56dedd0..9e4d078 100644
--- a/src/tbf_dl.cpp
+++ b/src/tbf_dl.cpp
@@ -587,6 +587,7 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 	bool is_final = false;
 	gprs_rlc_data_info rlc;
 	GprsCodingScheme cs;
+	GprsCodingScheme cs_current_trans;
 	int bsns[ARRAY_SIZE(rlc.block_info)];
 	unsigned num_bsns;
 	enum egprs_puncturing_values punct[ARRAY_SIZE(rlc.block_info)];
@@ -638,6 +639,7 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 		GprsCodingScheme cs_enc;
 		uint8_t *block_data;
 		gprs_rlc_data_block_info *rdbi, *block_info;
+		enum egprs_puncturing_values punct_scheme;
 
 		/* Check if there are more blocks than BSNs */
 		if (data_block_idx < num_bsns)
@@ -650,9 +652,19 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 		/* get data and header from current block */
 		block_data = m_rlc.block(bsn)->block;
 
-		/* TODO: Use real puncturing values */
-		punct[data_block_idx] =
-			(enum egprs_puncturing_values) data_block_idx;
+		/* TODO: Need to support MCS change during retx */
+		cs_current_trans = cs;
+
+		/* Get current puncturing scheme from block */
+		punct_scheme = gprs_get_punct_scheme(
+			m_rlc.block(bsn)->next_ps,
+			cs, cs_current_trans);
+
+		if (cs.isEgprs()) {
+			OSMO_ASSERT(punct_scheme >= EGPRS_PS_1);
+			OSMO_ASSERT(punct_scheme <= EGPRS_PS_3);
+		}
+		punct[data_block_idx] = punct_scheme;
 
 		rdbi = &rlc.block_info[data_block_idx];
 		block_info = &m_rlc.block(bsn)->block_info;
@@ -665,6 +677,13 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 				data_block_idx, bsn, cs_enc.name());
 			OSMO_ASSERT(rdbi->data_len == m_rlc.block(bsn)->len);
 		}
+
+		/* TODO: Need to handle 2 same bsns
+		 * in header type 1
+		 */
+		gprs_update_punct_scheme(&m_rlc.block(bsn)->next_ps,
+					cs_current_trans);
+
 		rdbi->e   = block_info->e;
 		rdbi->cv  = block_info->cv;
 		rdbi->bsn = bsn;
diff --git a/tests/tbf/TbfTest.err b/tests/tbf/TbfTest.err
index de9b775..9bea2fd 100644
--- a/tests/tbf/TbfTest.err
+++ b/tests/tbf/TbfTest.err
@@ -4755,8 +4755,8 @@ data block (BSN 1, MCS-7): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 1)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 0, MCS-7): 07 00 00 02 a8 50 64 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 a8 50 64 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 0, MCS-7): 07 00 00 02 b8 50 64 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 b8 50 64 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==2)
 - Sending new block at BSN 2, CS=MCS-7
@@ -4769,8 +4769,8 @@ data block (BSN 3, MCS-7): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 3)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 2, MCS-7): 07 80 00 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 2, MCS-7): 07 80 00 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==4)
 - Sending new block at BSN 4, CS=MCS-7
@@ -4783,8 +4783,8 @@ data block (BSN 5, MCS-7): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 5)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 4, MCS-7): 07 00 01 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 4, MCS-7): 07 00 01 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==6)
 - Sending new block at BSN 6, CS=MCS-7
@@ -4797,8 +4797,8 @@ data block (BSN 7, MCS-7): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 7)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 6, MCS-7): 07 80 01 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 6, MCS-7): 07 80 01 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==8)
 - Sending new block at BSN 8, CS=MCS-7
@@ -4811,8 +4811,8 @@ data block (BSN 9, MCS-7): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 9)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 8, MCS-7): 07 00 02 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=26 block=6 data=07 00 02 02 a8 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 8, MCS-7): 07 00 02 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=26 block=6 data=07 00 02 02 a0 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==10)
 - Sending new block at BSN 10, CS=MCS-7
@@ -4904,8 +4904,8 @@ data block (BSN 1, MCS-8): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 1)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 0, MCS-8): 07 00 00 02 60 50 c4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 60 50 c4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 0, MCS-8): 07 00 00 02 88 50 c4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 88 50 c4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==2)
 - Sending new block at BSN 2, CS=MCS-8
@@ -4918,8 +4918,8 @@ data block (BSN 3, MCS-8): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 3)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 2, MCS-8): 07 80 00 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 2, MCS-8): 07 80 00 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==4)
 - Sending new block at BSN 4, CS=MCS-8
@@ -4932,8 +4932,8 @@ data block (BSN 5, MCS-8): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 5)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 4, MCS-8): 07 00 01 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 4, MCS-8): 07 00 01 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==6)
 - Sending new block at BSN 6, CS=MCS-8
@@ -4946,8 +4946,8 @@ data block (BSN 7, MCS-8): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 7)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 6, MCS-8): 07 80 01 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 60 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 6, MCS-8): 07 80 01 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 58 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==8)
 - Sending new block at BSN 8, CS=MCS-8
@@ -5039,8 +5039,8 @@ data block (BSN 1, MCS-9): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 1)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 0, MCS-9): 07 00 00 02 08 50 f4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 08 50 f4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 0, MCS-9): 07 00 00 02 20 50 f4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=8 block=2 data=07 00 00 02 20 50 f4 05 04 04 04 04 04 04 04 04 04 0c 01 07 ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac ac 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==2)
 - Sending new block at BSN 2, CS=MCS-9
@@ -5053,8 +5053,8 @@ data block (BSN 3, MCS-9): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 3)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 2, MCS-9): 07 80 00 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 2, MCS-9): 07 80 00 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=13 block=3 data=07 80 00 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==4)
 - Sending new block at BSN 4, CS=MCS-9
@@ -5067,8 +5067,8 @@ data block (BSN 5, MCS-9): 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 5)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 4, MCS-9): 07 00 01 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+msg block (BSN 4, MCS-9): 07 00 01 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=17 block=4 data=07 00 01 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 14 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==6)
 - Sending new block at BSN 6, CS=MCS-9
@@ -5084,8 +5084,8 @@ data block (BSN 7, MCS-9): 89 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
 - Copying data unit 1 (BSN 7)
 - Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).
 Polling is already scheduled for TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS)
-msg block (BSN 6, MCS-9): 07 80 01 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 90 18 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 30 04 1c b0 b2 02 
-Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 08 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 90 18 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 30 04 1c b0 b2 02 
+msg block (BSN 6, MCS-9): 07 80 01 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 90 18 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 30 04 1c b0 b2 02 
+Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=21 block=5 data=07 80 01 02 00 05 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 90 18 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 30 04 1c b0 b2 02 
 Scheduling data message at RTS for DL TFI=0 (TRX=0, TS=4) prio=3
 TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink (V(A)==0 .. V(S)==8)
 - Sending new block at BSN 8, CS=MCS-9
-- 
1.7.9.5




From Bhargava.Abhyankar at radisys.com  Wed Mar 23 13:28:59 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Wed, 23 Mar 2016 13:28:59 +0000
Subject: Queries regarding L1 interface to osmo-bts for 11 bit RACH
In-Reply-To: <86E210CFD3EEDE46A58DE4793CFA6C3F037324E4@NTWAEX01.interne.lyrtech.com>
References: <DM2PR0801MB0959B6D2EC6602497E9D6E3691800@DM2PR0801MB0959.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F037324E4@NTWAEX01.interne.lyrtech.com>
Message-ID: <DM2PR0801MB0959711313AE0197C80D79EA91810@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hello Yves,
                Thanks for the clarifications on the queries. We will use these inputs for implementation of 11 bit RACH patches.

Regards
Bhargava Abhyankar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160323/b7191b47/attachment.htm>

From arvind.sirsikar at radisys.com  Wed Mar 23 12:59:46 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 23 Mar 2016 18:29:46 +0530
Subject: [PATCH 2/3] Update CPS calculation with new data structures
In-Reply-To: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <1458737988-4198-2-git-send-email-arvind.sirsikar@radisys.com>

Update existing CPS calculation function to align with new data
structure introduced
---
 src/rlc.cpp    |   33 ++++++++++++++++++++++-----------
 src/rlc.h      |    4 ++--
 src/tbf_dl.cpp |    5 +++--
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/src/rlc.cpp b/src/rlc.cpp
index 0e16ee8..6ea1597 100644
--- a/src/rlc.cpp
+++ b/src/rlc.cpp
@@ -339,21 +339,32 @@ void gprs_rlc_data_block_info_init(struct gprs_rlc_data_block_info *rdbi,
 	rdbi->spb = 0;
 }
 
-unsigned int gprs_rlc_mcs_cps(GprsCodingScheme cs, int punct, int punct2,
-	int with_padding)
+unsigned int gprs_rlc_mcs_cps(GprsCodingScheme cs,
+	enum egprs_puncturing_values punct,
+	enum egprs_puncturing_values punct2, int with_padding)
 {
 	switch (GprsCodingScheme::Scheme(cs)) {
-	case GprsCodingScheme::MCS1: return 0b1011 + punct % 2;
-	case GprsCodingScheme::MCS2: return 0b1001 + punct % 2;
+	case GprsCodingScheme::MCS1: return 0b1011 +
+		punct % EGPRS_MAX_PS_NUM_2;
+	case GprsCodingScheme::MCS2: return 0b1001 +
+		punct % EGPRS_MAX_PS_NUM_2;
 	case GprsCodingScheme::MCS3: return (with_padding ? 0b0110 : 0b0011) +
-					    punct % 3;
-	case GprsCodingScheme::MCS4: return 0b0000 + punct % 3;
-	case GprsCodingScheme::MCS5: return  0b100 + punct % 2;
+		punct % EGPRS_MAX_PS_NUM_3;
+	case GprsCodingScheme::MCS4: return 0b0000 +
+		punct % EGPRS_MAX_PS_NUM_3;
+	case GprsCodingScheme::MCS5: return  0b100 +
+		punct % EGPRS_MAX_PS_NUM_2;
 	case GprsCodingScheme::MCS6: return (with_padding ? 0b010 : 0b000) +
-					    punct % 2;
-	case GprsCodingScheme::MCS7: return 0b10100 + 3 * (punct % 3) + punct2 % 3;
-	case GprsCodingScheme::MCS8: return 0b01011 + 3 * (punct % 3) + punct2 % 3;
-	case GprsCodingScheme::MCS9: return 0b00000 + 4 * (punct % 3) + punct2 % 3;
+		punct % EGPRS_MAX_PS_NUM_2;
+	case GprsCodingScheme::MCS7: return 0b10100 +
+		3 * (punct % EGPRS_MAX_PS_NUM_3) +
+		punct2 % EGPRS_MAX_PS_NUM_3;
+	case GprsCodingScheme::MCS8: return 0b01011 +
+		3 * (punct % EGPRS_MAX_PS_NUM_3) +
+		punct2 % EGPRS_MAX_PS_NUM_3;
+	case GprsCodingScheme::MCS9: return 0b00000 +
+		4 * (punct % EGPRS_MAX_PS_NUM_3) +
+		punct2 % EGPRS_MAX_PS_NUM_3;
 	default: ;
 	}
 
diff --git a/src/rlc.h b/src/rlc.h
index 19dccbe..6a8fd29 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -132,8 +132,8 @@ void gprs_rlc_data_info_init_ul(struct gprs_rlc_data_info *rlc,
 	GprsCodingScheme cs, bool with_padding);
 void gprs_rlc_data_block_info_init(struct gprs_rlc_data_block_info *rdbi,
 	GprsCodingScheme cs, bool with_padding);
-unsigned int gprs_rlc_mcs_cps(GprsCodingScheme cs, int punct, int punct2,
-	int with_padding);
+unsigned int gprs_rlc_mcs_cps(GprsCodingScheme cs, enum egprs_puncturing_values
+	punct, enum egprs_puncturing_values punct2, int with_padding);
 void gprs_rlc_mcs_cps_decode(unsigned int cps, GprsCodingScheme cs,
 	int *punct, int *punct2, int *with_padding);
 
diff --git a/src/tbf_dl.cpp b/src/tbf_dl.cpp
index 7540d1b..56dedd0 100644
--- a/src/tbf_dl.cpp
+++ b/src/tbf_dl.cpp
@@ -589,7 +589,7 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 	GprsCodingScheme cs;
 	int bsns[ARRAY_SIZE(rlc.block_info)];
 	unsigned num_bsns;
-	int punct[ARRAY_SIZE(rlc.block_info)];
+	enum egprs_puncturing_values punct[ARRAY_SIZE(rlc.block_info)];
 	bool need_padding = false;
 
 	/*
@@ -651,7 +651,8 @@ struct msgb *gprs_rlcmac_dl_tbf::create_dl_acked_block(
 		block_data = m_rlc.block(bsn)->block;
 
 		/* TODO: Use real puncturing values */
-		punct[data_block_idx] = data_block_idx;
+		punct[data_block_idx] =
+			(enum egprs_puncturing_values) data_block_idx;
 
 		rdbi = &rlc.block_info[data_block_idx];
 		block_info = &m_rlc.block(bsn)->block_info;
-- 
1.7.9.5




From arvind.sirsikar at radisys.com  Wed Mar 23 12:59:45 2016
From: arvind.sirsikar at radisys.com (Aravind Sirsikar)
Date: Wed, 23 Mar 2016 18:29:45 +0530
Subject: [PATCH 1/3] Add data structure for CPS calculation in DL
Message-ID: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>

Define new data structure with respect to TS 44.060
10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1 for puncturing scheme values
and initialize the variable introduced
---
 src/rlc.cpp |    3 +++
 src/rlc.h   |   24 ++++++++++++++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/src/rlc.cpp b/src/rlc.cpp
index 79d8f48..0e16ee8 100644
--- a/src/rlc.cpp
+++ b/src/rlc.cpp
@@ -33,6 +33,9 @@ uint8_t *gprs_rlc_data::prepare(size_t block_data_len)
 	memset(block, 0x0, sizeof(block));
 	memset(block, 0x2b, block_data_len);
 
+	/* Initial value of puncturing scheme */
+	next_ps = EGPRS_PS_1;
+
 	return block;
 }
 
diff --git a/src/rlc.h b/src/rlc.h
index 3f10f8c..19dccbe 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -56,6 +56,27 @@ enum gprs_rlc_dl_bsn_state {
 	GPRS_RLC_DL_BSN_MAX,
 };
 
+/*
+ * Valid puncturing scheme values
+ * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
+ */
+enum egprs_puncturing_values {
+	EGPRS_PS_1,
+	EGPRS_PS_2,
+	EGPRS_PS_3,
+	EGPRS_PS_INVALID,
+};
+
+/*
+ * EGPRS_MAX_PS_NUM_2 is valid for MCS 1,2,5,6.
+ * And EGPRS_MAX_PS_NUM_3 is valid for MCS 3,4,7,8,9
+ * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
+ */
+enum egprs_puncturing_types {
+	EGPRS_MAX_PS_NUM_2 = 2,
+	EGPRS_MAX_PS_NUM_3,
+	EGPRS_MAX_PS_NUM_INVALID,
+};
 
 static inline uint16_t mod_sns_half()
 {
@@ -100,6 +121,9 @@ struct gprs_rlc_data {
 
 	struct gprs_rlc_data_block_info block_info;
 	GprsCodingScheme cs;
+
+	/* puncturing scheme value to be used for next transmission*/
+	enum egprs_puncturing_values next_ps;
 };
 
 void gprs_rlc_data_info_init_dl(struct gprs_rlc_data_info *rlc,
-- 
1.7.9.5




From Bhargava.Abhyankar at radisys.com  Thu Mar 24 13:23:25 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Thu, 24 Mar 2016 13:23:25 +0000
Subject: [PATCH 1/2] Refactor the Uplink RLC header parsing function
In-Reply-To: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <DM2PR0801MB095910A47DCEA10A390C8E0C91820@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hello,
	Please let me know the feedback for this patch. I would like to send further patches of mcs 5 to mcs 9 support in uplink on top of this patch.

Regards
Bhargava Abhyankar



From laforge at gnumonks.org  Thu Mar 24 22:45:06 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Mar 2016 23:45:06 +0100
Subject: [PATCH 1/2] Refactor the Uplink RLC header parsing function
In-Reply-To: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <20160324224506.GB27418@nataraja>

Hi Bhargava,

On Tue, Mar 22, 2016 at 06:42:30PM +0530, Bhargava Abhyankar wrote:
> Parsing the uplink data header for GPRS and EGPRS header type 3
> is handled in separate functions.
> This patch will enhance modularity of the code.

I'm not an expert on OsmoPCU, but this patch looks pretty
straight-forward and undisputable.  Moving away from large switch
statements towards separate functions/methods is generally appreciated
a lot, as is increasing modularity.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Mar 27 09:00:59 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 27 Mar 2016 11:00:59 +0200
Subject: [PATCH 1/3] Add data structure for CPS calculation in DL
In-Reply-To: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <20160327090059.GU27418@nataraja>

Dear all,

does somebody have objections against merging the entire 3-patch set as
poposed by Aravind?  It looks fine to me, but I'm not the person with
most of the PCU implementation knowledge, so I'd appreciate review (or
even merging) from those more familiar with it...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Sun Mar 27 13:35:25 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 15:35:25 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
Message-ID: <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>


> On 18 Mar 2016, at 20:59, Holger Freyther <holger at freyther.de> wrote:
> 
> Hi,
> 

> any objections or corrections to that?

this is now in place and the old domains are now using X509 certs of letsencrypt.

holger

From holger at freyther.de  Sun Mar 27 16:40:33 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 18:40:33 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
 <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
Message-ID: <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>


> On 27 Mar 2016, at 16:30, Sylvain Munaut <246tnt at 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

From holger at freyther.de  Sun Mar 27 16:46:40 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 18:46:40 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
 <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
 <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>
Message-ID: <24432F59-2C05-4B90-8EF1-72048E9CEEB0@freyther.de>


> On 27 Mar 2016, at 18:40, Holger Freyther <holger at freyther.de> wrote:
> 
> 
> 
> 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.
> 

ah lol... http://www.redmine.org/projects/redmine/wiki/RedmineSettings#Protocol says it is for http vs. https in email notifications. :}

From manuelj.munoz at gmail.com  Tue Mar 29 15:31:44 2016
From: manuelj.munoz at gmail.com (=?UTF-8?Q?Manuel_Jos=C3=A9_Mu=C3=B1oz_Calero?=)
Date: Tue, 29 Mar 2016 17:31:44 +0200
Subject: Academic project based on OpenGGSN
In-Reply-To: <20160322151252.GA7525@ass40.sysmocom.de>
References: <CA+DkyWn6iK=gLAe2vjGtymhi5kLLTDEDsvuwZ6_wmNR5EWnaQg@mail.gmail.com>
 <20160322151252.GA7525@ass40.sysmocom.de>
Message-ID: <CA+DkyWnTn-CobinjmpTq6fhKfdL7VHv9fCYbh20tfs63o4XZRw@mail.gmail.com>

Hi guys,

I will do my project about some other topic.
But it has been nice to find this project so I will gladly work in making
OpenGGSN code better.

I will come back with my findings and plan.

Regards,
Manuel

2016-03-22 16:12 GMT+01:00 Neels Hofmeyr <nhofmeyr at sysmocom.de>:

> On Mon, Mar 21, 2016 at 04:00:14PM +0100, Manuel Jos? Mu?oz Calero wrote:
> > 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.
>
> Well, my opinion is that OpenGGSN has fairly bad code structuring. It has
> heavy use of code duplication and the code layers aren't separated well
> (e.g. I can't use libgtp to decode messages without also using its tx/rx).
>
> So a proper audit and spring cleaning might be a nice project, if not
> necessarily super exciting, at least it is well defined in that OpenGGSN
> should not (or hardly) change behavior while making the code safer /
> easier to maintain / more versatile to re-use. You could analyse the code
> structures and/or security holes, academically argue why they are bad and
> come up with improvements, while using and/or writing tests to ensure
> correctness. If you know your stuff, all OpenGGSN users would arguably
> benefit from that.
>
> I'd like to do that if I had the time, but that will probably never be the
> case. I'm too busy writing new bugs for 3G :P
>
> That's just my sixpence -- good speed for your project, whichever you
> chose! :)
>
> ~Neels
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160329/f2991dc8/attachment.htm>

From Prasad.Kaup at radisys.com  Tue Mar 29 15:48:10 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Tue, 29 Mar 2016 15:48:10 +0000
Subject: Regarding integration of NURAN L1 1.0
In-Reply-To: <86E210CFD3EEDE46A58DE4793CFA6C3F0373244D@NTWAEX01.interne.lyrtech.com>
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12372B26906C10064211C64EE6800@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373244D@NTWAEX01.interne.lyrtech.com>
Message-ID: <CY1PR08MB1248195CAB81775037416975E6870@CY1PR08MB1248.namprd08.prod.outlook.com>

Hi Minh-Quang Nguyen,
		Thanks for the information. We are able to connect to the board and execute the commands.

Regarding cross compilation we have some queries
1.  We are able to cross compile  libosmocore commit  8649d57f507d359c99a89654aac7e19ce22db282 and some of later versions using local talloc files,  but there is a dependency of talloc  library in latest version.
Let us know which talloc version to pick and any specific procedure to cross compile talloc source.

2.  We see that there is ARM cross compiler described at  http://bb.osmocom.org/trac/wiki/GnuArmToolchain.  Let us know if this is usable with NURAN boards.

3.  There is an  error while linking  osmo-pcu 
	arm-none-linux-gnueabi/bin/ld: ./.libs/libgprs.a(gprs_bssgp_pcu.o): undefined reference to symbol 'tlv_parse@@LIBOSMOGSM_1.0'
	/home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so: error adding symbols: DSO missing from command line

And the final linking command for osmo-pcu  is 
	echo "  CXXLD   " osmo-pcu;/bin/bash ../libtool --silent --tag=CXX   --mode=link arm-none-linux-gnueabi-g++  -march=armv5te -marm -mthumb-interwork -Wall -ldl -pthread -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -lrt -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o osmo-pcu pcu_main.o  libgprs.la /home/pkaup/osmo/latest/libosmocore/src/gb/.libs/libosmogb.so /home/pkaup/osmo/latest/libosmocore/src/.libs/libosmocore.so /home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so 

As I see, tlv_parse   is part of libosmogsm which is getting linked.  
Can you let me know the final linking command (corresponding output as above of  "make -n"  in your setup ) so that I can cross-verify ?

Regards
Prasad


From minh-quang.nguyen at nutaq.com  Tue Mar 29 20:39:00 2016
From: minh-quang.nguyen at nutaq.com (Minh-Quang Nguyen)
Date: Tue, 29 Mar 2016 16:39:00 -0400
Subject: Regarding integration of NURAN L1 1.0
References: <BN3PR08MB1237A3A25185CBF71C8ABCA9E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373171A@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12371DF23DF46CC2D267CE20E6B50@BN3PR08MB1237.namprd08.prod.outlook.com>
 <20160314001234.GE10039@dub6>
 <BN3PR08MB12374A20869A6E55100E76FEE6890@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F03732069@NTWAEX01.interne.lyrtech.com>
 <BN3PR08MB12372B26906C10064211C64EE6800@BN3PR08MB1237.namprd08.prod.outlook.com>
 <86E210CFD3EEDE46A58DE4793CFA6C3F0373244D@NTWAEX01.interne.lyrtech.com>
 <CY1PR08MB1248195CAB81775037416975E6870@CY1PR08MB1248.namprd08.prod.outlook.com>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F037CBC9E@NTWAEX01.interne.lyrtech.com>

Hi Prasad,


>Regarding cross compilation we have some queries 1.  We are able to cross compile  libosmocore commit  8649d57f507d359c99a89654aac7e19ce22db282 and some of later versions using local >talloc files,  but there is a dependency of talloc  library in latest version.
>Let us know which talloc version to pick and any specific procedure to cross compile talloc source.

New libosmocore requires talloc version > 2.0.1. I followed instruction here https://wiki.samba.org/index.php/Waf#cross-compiling to cross-compile talloc 2.0.8

export CC=~/MentorGraphics/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-gcc
./configure --cross-compile --cross-answers=arm.txt --hostcc=arm-none-linux-gnueabi-gcc --disable-python --prefix=$SYSROOT/usr
make
make install

NOTE: Replace UNKNOWN to OK in arm.txt until the configuration has no error

>2.  We see that there is ARM cross compiler described at  http://bb.osmocom.org/trac/wiki/GnuArmToolchain.  Let us know if this is usable with NURAN boards.

I have never tried this compiler yet.

>3.  There is an  error while linking  osmo-pcu 
>	arm-none-linux-gnueabi/bin/ld: ./.libs/libgprs.a(gprs_bssgp_pcu.o): undefined reference to symbol 'tlv_parse@@LIBOSMOGSM_1.0'
>	/home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so: error adding symbols: DSO missing from command line
>And the final linking command for osmo-pcu  is 
>	echo "  CXXLD   " osmo-pcu;/bin/bash ../libtool --silent --tag=CXX   --mode=link arm-none-linux-gnueabi-g++  -march=armv5te -marm -mthumb-interwork -Wall -ldl -pthread -O2 -pipe -g >-feliminate-unused-debug-types -fpermissive -lrt -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o osmo-pcu pcu_main.o  libgprs.la >/home/pkaup/osmo/latest/libosmocore/src/gb/.libs/libosmogb.so /home/pkaup/osmo/latest/libosmocore/src/.libs/libosmocore.so >/home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so 
>As I see, tlv_parse   is part of libosmogsm which is getting linked.  
>Can you let me know the final linking command (corresponding output as above of  "make -n"  in your setup ) so that I can cross-verify ?

Please see attachment.


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 at nutaq.com
www.nutaq.com 

 QUEBEC MONTREAL NEW YORK

Facebook Twitter LinkedIn YouTube


-----Original Message-----
From: Prasad Kaup [mailto:Prasad.Kaup at radisys.com] 
Sent: Tuesday, March 29, 2016 11:48 AM
To: Minh-Quang Nguyen; Neels Hofmeyr; osmocom-net-gprs at lists.osmocom.org
Cc: Saurabh Sharan; Yves Godin; Abhinav Pragya Rishi
Subject: RE: Regarding integration of NURAN L1 1.0

Hi Minh-Quang Nguyen,
		Thanks for the information. We are able to connect to the board and execute the commands.

Regarding cross compilation we have some queries 1.  We are able to cross compile  libosmocore commit  8649d57f507d359c99a89654aac7e19ce22db282 and some of later versions using local talloc files,  but there is a dependency of talloc  library in latest version.
Let us know which talloc version to pick and any specific procedure to cross compile talloc source.

2.  We see that there is ARM cross compiler described at  http://bb.osmocom.org/trac/wiki/GnuArmToolchain.  Let us know if this is usable with NURAN boards.

3.  There is an  error while linking  osmo-pcu 
	arm-none-linux-gnueabi/bin/ld: ./.libs/libgprs.a(gprs_bssgp_pcu.o): undefined reference to symbol 'tlv_parse@@LIBOSMOGSM_1.0'
	/home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so: error adding symbols: DSO missing from command line

And the final linking command for osmo-pcu  is 
	echo "  CXXLD   " osmo-pcu;/bin/bash ../libtool --silent --tag=CXX   --mode=link arm-none-linux-gnueabi-g++  -march=armv5te -marm -mthumb-interwork -Wall -ldl -pthread -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -lrt -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o osmo-pcu pcu_main.o  libgprs.la /home/pkaup/osmo/latest/libosmocore/src/gb/.libs/libosmogb.so /home/pkaup/osmo/latest/libosmocore/src/.libs/libosmocore.so /home/pkaup/osmo/latest/libosmocore/src/gsm/.libs/libosmogsm.so 

As I see, tlv_parse   is part of libosmogsm which is getting linked.  
Can you let me know the final linking command (corresponding output as above of  "make -n"  in your setup ) so that I can cross-verify ?

Regards
Prasad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-pcu-linking.png
Type: image/png
Size: 220691 bytes
Desc: osmo-pcu-linking.png
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160329/30e83b14/attachment.png>

From Bhargava.Abhyankar at radisys.com  Wed Mar 30 13:28:41 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Wed, 30 Mar 2016 18:58:41 +0530
Subject: [PATCH 1/2] Add EGPRS header type 2 parsing function in uplink
Message-ID: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>

Function is added to parse the EGPRS header type 2 in uplink tbf path.
This is added to further support mcs 5 to mcs 9 in uplink.
---
 src/decoding.cpp        |  54 +++++++++++++++--
 src/decoding.h          |   5 +-
 tests/edge/EdgeTest.cpp | 151 +++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 203 insertions(+), 7 deletions(-)

diff --git a/src/decoding.cpp b/src/decoding.cpp
index f2b548c..ad5b05f 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -411,11 +411,11 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		/* skip data area */
 		cur_bit += cs.maxDataBlockBytes() * 8;
 		break;
-
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1:
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2:
-		/* TODO: Support both header types */
-		/* fall through */
+	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2 :
+		cur_bit = rlc_parse_ul_data_header_egprs_type_2(rlc,
+				data, cs);
+		break;
+	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 :
 	default:
 		LOGP(DRLCMACDL, LOGL_ERROR,
 			"Decoding of uplink %s data blocks not yet supported.\n",
@@ -426,6 +426,50 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 	return cur_bit;
 }
 
+int Decoding::rlc_parse_ul_data_header_egprs_type_2(
+	struct gprs_rlc_data_info *rlc,
+	const uint8_t *data,
+	GprsCodingScheme cs)
+{
+	const struct gprs_rlc_ul_header_egprs_2 *egprs2;
+	unsigned int e_ti_header, offs, cur_bit = 0;
+	int punct, punct2, with_padding, cps;
+
+	egprs2 = static_cast < struct gprs_rlc_ul_header_egprs_2 * >
+			((void *)data);
+
+	cps    = (egprs2->cps_a << 0)  | (egprs2->cps_b << 2);
+	gprs_rlc_mcs_cps_decode(cps, cs, &punct, &punct2, &with_padding);
+	gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
+
+	rlc->r      = egprs2->r;
+	rlc->si     = egprs2->si;
+	rlc->tfi    = (egprs2->tfi_a << 0)  | (egprs2->tfi_b << 2);
+	rlc->cps    = cps;
+	rlc->rsb    = egprs2->rsb;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs2->cv;
+	rlc->block_info[0].pi  = egprs2->pi;
+	rlc->block_info[0].bsn =
+		(egprs2->bsn1_a << 0) | (egprs2->bsn1_b << 5);
+
+	cur_bit += rlc->data_offs_bits[0] - 2;
+
+	offs = rlc->data_offs_bits[0] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 1);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[0].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
+
 /**
  * \brief Copy LSB bitstream RLC data block to byte aligned buffer.
  *
diff --git a/src/decoding.h b/src/decoding.h
index 58ecd18..2cb053d 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -43,7 +43,10 @@ public:
 
 	static void extract_rbb(const uint8_t *rbb, char *extracted_rbb);
 	static void extract_rbb(const struct bitvec *rbb, char *show_rbb);
-
+	static int rlc_parse_ul_data_header_egprs_type_2(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		GprsCodingScheme cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index 96ea0c1..c2dfc0b 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -26,7 +26,7 @@
 #include "encoding.h"
 #include "rlc.h"
 #include "llc.h"
-
+#include "bts.h"
 extern "C" {
 #include "pcu_vty.h"
 
@@ -495,6 +495,155 @@ static void test_rlc_unit_decoder()
 	OSMO_ASSERT(chunks[2].length == 1);
 	OSMO_ASSERT(!chunks[2].is_complete);
 
+	cs = GprsCodingScheme::MCS5;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (15 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 1);
+	OSMO_ASSERT(chunks[0].length == 15);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 16);
+	OSMO_ASSERT(chunks[1].length == 40);
+	OSMO_ASSERT(!chunks[1].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 1;
+	offs = 0;
+	data[offs++] = (0 << 1) | (0 << 0);
+	data[offs++] = (7 << 1) | (0 << 0);
+	data[offs++] = (18 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+			chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 4);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].length == 0);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 3);
+	OSMO_ASSERT(chunks[1].length == 7);
+	OSMO_ASSERT(chunks[1].is_complete);
+	OSMO_ASSERT(chunks[2].offset == 10);
+	OSMO_ASSERT(chunks[2].length == 18);
+	OSMO_ASSERT(chunks[2].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (6 << 1) | (0 << 0);
+	data[offs++] = (12 << 1) | (0 << 0);
+	data[offs++] = (127 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 3);
+	OSMO_ASSERT(chunks[0].length == 6);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 9);
+	OSMO_ASSERT(chunks[1].length == 12);
+	OSMO_ASSERT(chunks[1].is_complete);
+
+	cs = GprsCodingScheme::MCS5;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 1;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 1);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 0);
+	OSMO_ASSERT(chunks[0].length == 56);
+	OSMO_ASSERT(chunks[0].is_complete);
+
+	cs = GprsCodingScheme::MCS6;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (15 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 1);
+	OSMO_ASSERT(chunks[0].length == 15);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 16);
+	OSMO_ASSERT(chunks[1].length == 58);
+	OSMO_ASSERT(!chunks[1].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 1;
+	offs = 0;
+	data[offs++] = (0 << 1) | (0 << 0);
+	data[offs++] = (7 << 1) | (0 << 0);
+	data[offs++] = (18 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+
+	OSMO_ASSERT(num_chunks == 4);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].length == 0);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 3);
+	OSMO_ASSERT(chunks[1].length == 7);
+	OSMO_ASSERT(chunks[1].is_complete);
+	OSMO_ASSERT(chunks[2].offset == 10);
+	OSMO_ASSERT(chunks[2].length == 18);
+	OSMO_ASSERT(chunks[2].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (6 << 1) | (0 << 0);
+	data[offs++] = (12 << 1) | (0 << 0);
+	data[offs++] = (127 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 3);
+	OSMO_ASSERT(chunks[0].length == 6);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 9);
+	OSMO_ASSERT(chunks[1].length == 12);
+	OSMO_ASSERT(chunks[1].is_complete);
+
+	cs = GprsCodingScheme::MCS6;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 1;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 1);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 0);
+	OSMO_ASSERT(chunks[0].length == 74);
+	OSMO_ASSERT(chunks[0].is_complete);
+
 	printf("=== end %s ===\n", __func__);
 }
 
-- 
2.5.0




From Bhargava.Abhyankar at radisys.com  Wed Mar 30 13:28:42 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Wed, 30 Mar 2016 18:58:42 +0530
Subject: [PATCH 2/2] Add EGPRS header type 1 parsing function in uplink
In-Reply-To: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <1459344522-15503-2-git-send-email-Bhargava.Abhyankar@radisys.com>

Function is added to parse the EGPRS header type 1 in uplink tbf path.
This is added to further support mcs 5 to mcs 9 in uplink.
---
 src/bts.cpp             |   9 ---
 src/decoding.cpp        |  56 +++++++++++++++++
 src/decoding.h          |   4 ++
 tests/edge/EdgeTest.cpp | 164 +++++++++++++++++++++++++++++++++++++++++++++++-
 tests/edge/EdgeTest.ok  |   2 +
 5 files changed, 225 insertions(+), 10 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..f818ee2 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -1333,15 +1333,6 @@ int gprs_rlcmac_pdch::rcv_data_block(uint8_t *data, uint32_t fn,
 				cs.name());
 			return -EINVAL;
 		}
-
-		if (!cs.isEgprsGmsk()) {
-			LOGP(DRLCMACUL, LOGL_ERROR,
-				"Got %s RLC block but EGPRS is not implemented "
-				"for 8PSK yet\n",
-				cs.name());
-			bts()->decode_error();
-			return -EINVAL;
-		}
 	}
 
 	LOGP(DRLCMACUL, LOGL_DEBUG, "  UL data: %s\n", osmo_hexdump(data, len));
diff --git a/src/decoding.cpp b/src/decoding.cpp
index ad5b05f..f3d5515 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -416,6 +416,8 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 				data, cs);
 		break;
 	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 :
+		cur_bit = rlc_parse_ul_data_header_egprs_type_1(rlc, data, cs);
+		break;
 	default:
 		LOGP(DRLCMACDL, LOGL_ERROR,
 			"Decoding of uplink %s data blocks not yet supported.\n",
@@ -470,6 +472,60 @@ int Decoding::rlc_parse_ul_data_header_egprs_type_2(
 	return cur_bit;
 }
 
+int Decoding::rlc_parse_ul_data_header_egprs_type_1(
+	struct gprs_rlc_data_info *rlc,
+	const uint8_t *data, GprsCodingScheme cs)
+{
+	struct gprs_rlc_ul_header_egprs_1 *egprs1;
+	unsigned int e_ti_header, cur_bit = 0, offs;
+	int punct, punct2, with_padding;
+
+	egprs1 = static_cast < struct gprs_rlc_ul_header_egprs_1 * >
+		((void *)data);
+	gprs_rlc_mcs_cps_decode(egprs1->cps, cs, &punct, &punct2,
+		&with_padding);
+	gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
+
+	rlc->r      = egprs1->r;
+	rlc->si     = egprs1->si;
+	rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
+	rlc->cps    = egprs1->cps;
+	rlc->rsb    = egprs1->rsb;
+	rlc->num_data_blocks = 2;
+	rlc->block_info[0].cv  = egprs1->cv;
+	rlc->block_info[0].pi  = egprs1->pi;
+	rlc->block_info[0].bsn =
+			(egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
+
+	cur_bit += rlc->data_offs_bits[0] - 2;
+	offs = rlc->data_offs_bits[0] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 0);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[0].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+
+	rlc->block_info[1].cv  = egprs1->cv;
+	rlc->block_info[1].pi  = egprs1->pi;
+	rlc->block_info[1].bsn = rlc->block_info[0].bsn +
+		((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
+	rlc->block_info[1].bsn = rlc->block_info[1].bsn &  (RLC_EGPRS_SNS - 1);
+
+	cur_bit += rlc->data_offs_bits[1] - 2;
+
+	offs = rlc->data_offs_bits[1] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[1] % 8 == 2);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[1].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[1].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
 /**
  * \brief Copy LSB bitstream RLC data block to byte aligned buffer.
  *
diff --git a/src/decoding.h b/src/decoding.h
index 2cb053d..9c74953 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -47,6 +47,10 @@ public:
 		struct gprs_rlc_data_info *rlc,
 		const uint8_t *data,
 		GprsCodingScheme cs);
+	static int rlc_parse_ul_data_header_egprs_type_1(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		GprsCodingScheme cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index c2dfc0b..daaaed2 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -1250,6 +1250,168 @@ const struct log_info debug_log_info = {
 	ARRAY_SIZE(default_categories),
 };
 
+static void setup_bts(BTS *the_bts, uint8_t ts_no, uint8_t cs = 1)
+{
+	gprs_rlcmac_bts *bts;
+	gprs_rlcmac_trx *trx;
+
+	bts = the_bts->bts_data();
+	bts->egprs_enabled = true;
+	bts->alloc_algorithm = alloc_algorithm_a;
+	bts->initial_cs_dl = cs;
+	bts->initial_cs_ul = cs;
+	trx = &bts->trx[0];
+	trx->pdch[ts_no].enable();
+}
+
+static void send_ul_mac_block(BTS *the_bts, unsigned trx_no, unsigned ts_no,
+	RlcMacUplink_t *ulreq, unsigned fn)
+{
+	bitvec *rlc_block;
+	uint8_t buf[64];
+	int num_bytes;
+	struct gprs_rlcmac_pdch *pdch;
+	struct pcu_l1_meas meas;
+
+	meas.set_rssi(31);
+	rlc_block = bitvec_alloc(23);
+	encode_gsm_rlcmac_uplink(rlc_block, ulreq);
+	num_bytes = bitvec_pack(rlc_block, &buf[0]);
+	OSMO_ASSERT(size_t(num_bytes) < sizeof(buf));
+	bitvec_free(rlc_block);
+	the_bts->set_current_block_frame_number(fn, 0);
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&buf[0], num_bytes, fn, &meas);
+}
+
+static unsigned fn2bn(unsigned fn)
+{
+	return (fn % 52) / 4;
+}
+
+static unsigned fn_add_blocks(unsigned fn, unsigned blocks)
+{
+	unsigned bn = fn2bn(fn) + blocks;
+
+	fn = fn - (fn % 52);
+	fn += bn * 4 + bn / 3;
+	return fn % 2715648;
+}
+
+static void request_dl_rlc_block(struct gprs_rlcmac_bts *bts,
+	uint8_t trx_no, uint8_t ts_no, uint16_t arfcn,
+	uint32_t *fn, uint8_t *block_nr = NULL)
+{
+	uint8_t bn = fn2bn(*fn);
+
+	gprs_rlcmac_rcv_rts_block(bts, trx_no, ts_no, arfcn, *fn, bn);
+	*fn = fn_add_blocks(*fn, 1);
+	bn += 1;
+	if (block_nr)
+		*block_nr = bn;
+}
+
+static gprs_rlcmac_ul_tbf *uplink_header_parsing_test(BTS *the_bts,
+	uint8_t ts_no, uint32_t tlli, uint32_t *fn, uint16_t qta,
+	uint8_t ms_class)
+{
+	GprsMs *ms;
+	struct pcu_l1_meas meas;
+	uint32_t rach_fn = *fn - 51;
+	uint32_t sba_fn = *fn + 52;
+	uint8_t trx_no = 0;
+	int tfi = 0;
+	gprs_rlcmac_ul_tbf *ul_tbf;
+	struct gprs_rlcmac_pdch *pdch;
+	gprs_rlcmac_bts *bts;
+	RlcMacUplink_t ulreq = {0};
+	uint8_t data[144] = {0};
+	struct gprs_rlc_ul_header_egprs_1 *egprs1  = NULL;
+
+	meas.set_rssi(31);
+	egprs1 = (struct gprs_rlc_ul_header_egprs_1 *) data;
+	bts = the_bts->bts_data();
+
+	/* needed to set last_rts_fn in the PDCH object */
+	request_dl_rlc_block(bts, trx_no, ts_no, 0, fn);
+
+	/* simulate RACH,this sends a Immediate Assignment Uplink on the AGCH */
+	the_bts->rcv_rach(0x73, rach_fn, qta);
+
+	/* get next free TFI */
+	tfi = the_bts->tfi_find_free(GPRS_RLCMAC_UL_TBF, &trx_no, -1);
+
+	/* fake a resource request */
+	ulreq.u.MESSAGE_TYPE = MT_PACKET_RESOURCE_REQUEST;
+	ulreq.u.Packet_Resource_Request.PayloadType = GPRS_RLCMAC_CONTROL_BLOCK;
+	ulreq.u.Packet_Resource_Request.ID.UnionType = 1; /* != 0 */
+	ulreq.u.Packet_Resource_Request.ID.u.TLLI = tlli;
+	ulreq.u.Packet_Resource_Request.Exist_MS_Radio_Access_capability = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+			Count_MS_RA_capability_value = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.
+		Exist_Multislot_capability = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		Exist_GPRS_multislot_class = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		GPRS_multislot_class = ms_class;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		Exist_EGPRS_multislot_class = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		EGPRS_multislot_class = ms_class;
+
+	send_ul_mac_block(the_bts, trx_no, ts_no, &ulreq, sba_fn);
+	send_ul_mac_block(the_bts, trx_no, ts_no, &ulreq, sba_fn);
+
+	/* check the TBF */
+	ul_tbf = the_bts->ul_tbf_by_tfi(tfi, trx_no, ts_no);
+	OSMO_ASSERT(ul_tbf != NULL);
+	OSMO_ASSERT(ul_tbf->ta() == qta / 4);
+
+	egprs1->si = 1;
+	egprs1->r = 1;
+	egprs1->cv = 7;
+	egprs1->tfi_a = tfi & (~((~0) << 2));
+	egprs1->tfi_b = tfi & (~((~0) << 3)) << 2;
+	egprs1->bsn1_a = 10;
+	egprs1->bsn1_b = 17;
+	egprs1->bsn2_a = 0;
+	egprs1->bsn2_b = 25;
+	egprs1->cps = 15;
+	egprs1->rsb = 0;
+	egprs1->pi = 0;
+	data[6] = 1;
+	data[6 + 68] = 1;
+	data[75] = 1;
+	data[75 + 68] = 1;
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data[0], 143, *fn, &meas);
+}
+
+void uplink_header_type1_test(void)
+{
+	BTS the_bts;
+	int ts_no = 7;
+	uint32_t fn = 2654218;
+	uint16_t qta = 31;
+	uint32_t tlli = 0xf1223344;
+	const char *imsi = "0011223344";
+	uint8_t ms_class = 1;
+	gprs_rlcmac_ul_tbf *ul_tbf;
+	GprsMs *ms;
+
+	printf("=== start %s ===\n", __func__);
+	setup_bts(&the_bts, ts_no, 12);
+	ul_tbf = uplink_header_parsing_test(&the_bts, ts_no, tlli, &fn,
+			qta, ms_class);
+	printf("=== end %s ===\n", __func__);
+}
+
 int main(int argc, char **argv)
 {
 	struct vty_app_info pcu_vty_info = {0};
@@ -1271,7 +1433,7 @@ int main(int argc, char **argv)
 	test_rlc_unit_decoder();
 	test_rlc_unaligned_copy();
 	test_rlc_unit_encoder();
-
+	uplink_header_type1_test();
 	if (getenv("TALLOC_REPORT_FULL"))
 		talloc_report_full(tall_pcu_ctx, stderr);
 	return EXIT_SUCCESS;
diff --git a/tests/edge/EdgeTest.ok b/tests/edge/EdgeTest.ok
index 9554df3..353f55d 100644
--- a/tests/edge/EdgeTest.ok
+++ b/tests/edge/EdgeTest.ok
@@ -6,3 +6,5 @@
 === end test_rlc_unit_decoder ===
 === start test_rlc_unit_encoder ===
 === end test_rlc_unit_encoder ===
+=== start uplink_header_type1_test ===
+=== end uplink_header_type1_test ===
-- 
2.5.0




From sangamesh.sajjan at radisys.com  Wed Mar 30 13:50:43 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Wed, 30 Mar 2016 19:20:43 +0530
Subject: [PATCH 1/3] Add structure definition for compression algorithm
Message-ID: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>

Defines new structure for Tree node and
Declaration of zero's run length code list and one's run length
code list
---
 src/Makefile.am               |    6 +-
 src/egprs_rlc_compression.cpp |  169 +++++++++++++++++++++++++++++++++++++++++
 src/egprs_rlc_compression.h   |   25 ++++++
 3 files changed, 198 insertions(+), 2 deletions(-)
 create mode 100644 src/egprs_rlc_compression.cpp
 create mode 100644 src/egprs_rlc_compression.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 6428bef..981d5b1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -57,7 +57,8 @@ libgprs_la_SOURCES = \
 	rlc.cpp \
 	osmobts_sock.cpp \
 	gprs_codel.c \
-	gprs_coding_scheme.cpp
+	gprs_coding_scheme.cpp \
+	egprs_rlc_compression.cpp
 
 bin_PROGRAMS = \
 	osmo-pcu
@@ -96,7 +97,8 @@ noinst_HEADERS = \
 	pcu_utils.h \
 	cxx_linuxlist.h \
 	gprs_codel.h \
-	gprs_coding_scheme.h
+	gprs_coding_scheme.h \
+	egprs_rlc_compression.h
 
 osmo_pcu_SOURCES = pcu_main.cpp
 
diff --git a/src/egprs_rlc_compression.cpp b/src/egprs_rlc_compression.cpp
new file mode 100644
index 0000000..55ff595
--- /dev/null
+++ b/src/egprs_rlc_compression.cpp
@@ -0,0 +1,169 @@
+/* egprs_rlc_compression.h
+*  Routines for EGPRS RLC bitmap compression handling
+*/
+#include <egprs_rlc_compression.h>
+#include <errno.h>
+
+const char *one_run_len_code_list[MAX_CDWDTBL_LEN] = {
+	"00110101",
+	"000111",
+	"0111",
+	"1000",
+	"1011",
+	"1100",
+	"1110",
+	"1111",
+	"10011",
+	"10100",
+	"00111",
+	"01000",
+	"001000",
+	"000011",
+	"110100",
+	"110101",
+	"101010",
+	"101011",
+	"0100111",
+	"0001100",
+	"0001000",
+	"0010111",
+	"0000011",
+	"0000100",
+	"0101000",
+	"0101011",
+	"0010011",
+	"0100100",
+	"0011000",
+	"00000010",
+	"00000011",
+	"00011010",
+	"00011011",
+	"00010010",
+	"00010011",
+	"00010100",
+	"00010101",
+	"00010110",
+	"00010111",
+	"00101000",
+	"00101001",
+	"00101010",
+	"00101011",
+	"00101100",
+	"00101101",
+	"00000100",
+	"00000101",
+	"00001010",
+	"00001011",
+	"01010010",
+	"01010011",
+	"01010100",
+	"01010101",
+	"00100100",
+	"00100101",
+	"01011000",
+	"01011001",
+	"01011010",
+	"01011011",
+	"01001010",
+	"01001011",
+	"00110010",
+	"00110011",
+	"00110100",
+	"11011",
+	"10010",
+	"010111",
+	"0110111",
+	"00110110",
+	"00110111",
+	"01100100",
+	"01100101",
+	"01101000",
+	"01100111",
+	"011001100",
+	"011001101",
+	"011010010",
+	"011010011",
+	"011010100"
+};
+
+const char *zero_run_len_code_list[MAX_CDWDTBL_LEN] = {
+	"0000110111",
+	"10",
+	"11",
+	"010",
+	"011",
+	"0011",
+	"0010",
+	"00011",
+	"000101",
+	"000100",
+	"0000100",
+	"0000101",
+	"0000111",
+	"00000100",
+	"00000111",
+	"000011000",
+	"0000010111",
+	"0000011000",
+	"0000001000",
+	"00001100111",
+	"00001101000",
+	"00001101100",
+	"00000110111",
+	"00000101000",
+	"00000010111",
+	"00000011000",
+	"000011001010",
+	"000011001011",
+	"000011001100",
+	"000011001101",
+	"000001101000",
+	"000001101001",
+	"000001101010",
+	"000001101011",
+	"000011010010",
+	"000011010011",
+	"000011010100",
+	"000011010101",
+	"000011010110",
+	"000011010111",
+	"000001101100",
+	"000001101101",
+	"000011011010",
+	"000011011011",
+	"000001010100",
+	"000001010101",
+	"000001010110",
+	"000001010111",
+	"000001100100",
+	"000001100101",
+	"000001010010",
+	"000001010011",
+	"000000100100",
+	"000000110111",
+	"000000111000",
+	"000000100111",
+	"000000101000",
+	"000001011000",
+	"000001011001",
+	"000000101011",
+	"000000101100",
+	"000001011010",
+	"000001100110",
+	"000001100111",
+	"0000001111",
+	"000011001000",
+	"000011001001",
+	"000001011011",
+	"000000110011",
+	"000000110100",
+	"000000110101",
+	"0000001101100",
+	"0000001101101",
+	"0000001001010",
+	"0000001001011",
+	"0000001001100",
+	"0000001001101",
+	"0000001110010",
+	"0000001110011"
+};
diff --git a/src/egprs_rlc_compression.h b/src/egprs_rlc_compression.h
new file mode 100644
index 0000000..00d850e
--- /dev/null
+++ b/src/egprs_rlc_compression.h
@@ -0,0 +1,25 @@
+/* egprs_rlc_compression.h
+ *  Routines for EGPRS RLC bitmap compression handling
+ */
+#include <gprs_rlcmac.h>
+#include <gprs_debug.h>
+
+extern "C" {
+#include <osmocom/core/talloc.h>
+#include <osmocom/core/msgb.h>
+#include <osmocom/core/stats.h>
+}
+
+#include <arpa/inet.h>
+#include <errno.h>
+#include <string.h>
+
+#define	MAX_CDWDTBL_LEN          79        /* total number of codewords */
+#define	BITS_TO_BYTES(X)      (X ? (X/8):0)+1
+#define	MOD8(X)             (((X)+8) & (0x07))
+
+typedef struct node {
+	struct node *left;
+	struct node *right;
+	uint16_t *run_length;
+} Node;
-- 
1.7.9.5




From sangamesh.sajjan at radisys.com  Wed Mar 30 13:50:45 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Wed, 30 Mar 2016 19:20:45 +0530
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>

This patch includes the changes for compression algorithm which
decompress the received CRBB bitmap and corresponding modification
of EPDAN handling
---
 src/decoding.cpp              |   30 ++++---------
 src/decoding.h                |   10 ++++-
 src/egprs_rlc_compression.cpp |   96 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 113 insertions(+), 23 deletions(-)

diff --git a/src/decoding.cpp b/src/decoding.cpp
index f2b548c..4535d1b 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -536,7 +536,6 @@ int Decoding::decode_egprs_acknack_bits(const EGPRS_AckNack_Desc_t *desc,
 	bool have_bitmap;
 	int implicitly_acked_blocks;
 	int ssn = desc->STARTING_SEQUENCE_NUMBER;
-	int rc;
 
 	if (desc->FINAL_ACK_INDICATION)
 		return handle_final_ack(bits, bsn_begin, bsn_end, window);
@@ -576,26 +575,15 @@ int Decoding::decode_egprs_acknack_bits(const EGPRS_AckNack_Desc_t *desc,
 
 	if (crbb_len > 0) {
 		int old_len = bits->cur_bit;
-		struct bitvec crbb;
-
-		crbb.data = (uint8_t *)desc->CRBB;
-		crbb.data_len = sizeof(desc->CRBB);
-		crbb.cur_bit = desc->CRBB_LENGTH;
-
-		rc = osmo_t4_decode(&crbb, desc->CRBB_STARTING_COLOR_CODE,
-			bits);
-
-		if (rc < 0) {
-			LOGP(DRLCMACUL, LOGL_NOTICE,
-				"Failed to decode CRBB: "
-				"length %d, data '%s'\n",
-				desc->CRBB_LENGTH,
-				osmo_hexdump(crbb.data, crbb.data_len));
-			/* We don't know the SSN offset for the URBB,
-			 * return what we have so far and assume the
-			 * bitmap has stopped here */
-			goto aborted;
-		}
+
+		LOGP(DRLCMACDL, LOGL_DEBUG, "Compress bitmap exist,"
+			"CRBB LEN =%d and Starting color code =%d",
+			desc->CRBB_LENGTH, desc->CRBB_STARTING_COLOR_CODE);
+
+		decompress_crbb(desc->CRBB_LENGTH,
+				desc->CRBB_STARTING_COLOR_CODE,
+				desc->CRBB,
+				bits);
 
 		LOGP(DRLCMACDL, LOGL_DEBUG,
 			"CRBB len: %d, decoded len: %d, cc: %d, crbb: '%s'\n",
diff --git a/src/decoding.h b/src/decoding.h
index 58ecd18..5989907 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -60,6 +60,12 @@ public:
 		struct gprs_rlc_dl_window *window);
 	static int decode_gprs_acknack_bits(
 		const Ack_Nack_Description_t *desc,
-		bitvec *bits, int *bsn_begin, int *bsn_end,
-		gprs_rlc_dl_window *window);
+		bitvec * bits, int *bsn_begin, int *bsn_end,
+		gprs_rlc_dl_window * window);
+	static void decompress_crbb(
+			int8_t compress_bmap_len,
+			uint8_t clr_code_bit,
+			const uint8_t *orig_buf,
+			bitvec * dest
+			);
 };
diff --git a/src/egprs_rlc_compression.cpp b/src/egprs_rlc_compression.cpp
index 4c17a17..2e4dc05 100644
--- a/src/egprs_rlc_compression.cpp
+++ b/src/egprs_rlc_compression.cpp
@@ -218,3 +218,99 @@ const char *zero_run_len_code_list[MAX_CDWDTBL_LEN] = {
 	"0000001110010",
 	"0000001110011"
 };
+
+int search_runlen(
+		Node    *root,		/* root of Ones or Zeros tree */
+		const uint8_t *bmbuf,	/* Received compressed bitmap buf */
+		uint8_t bit_pos,	/* the start bit pos to read codeword */
+		uint8_t *len_codewd,	/* length of codeword */
+		uint16_t *rlen           /* run length of Ones or Zeros */
+		)
+{
+	Node *iter;
+	uint8_t dir;
+
+	iter = root;
+	*len_codewd = 0;
+
+	while (iter->run_length == 0) {
+		if ((iter->left == NULL) && (iter->right == NULL))
+			return -1;
+
+	/* get the bit value at the bitpos and put it in right most of dir */
+		dir = ((bmbuf[BITS_TO_BYTES(bit_pos)-1]
+				>>(7-(MOD8(bit_pos)))) & 0x01);
+		(bit_pos)++;
+		(*len_codewd)++;
+
+		if (((dir&0x01) == 0) && (iter->left != NULL))
+			iter = iter->left;
+
+		else if (((dir&0x01) == 1) && (iter->right != NULL))
+			iter = iter->right;
+		else
+			return -1;
+	}
+	(*rlen) = *(iter->run_length);
+
+	return 1;
+} /* search_runlen */
+
+void Decoding::decompress_crbb(
+		int8_t compress_bmap_len, /* compressed bitmap length */
+		uint8_t clr_code_bit, /* run length of Ones or Zeros */
+		const uint8_t *orig_crbb_buf, /* received block crbb bitmap */
+		bitvec * dest
+		)
+{
+
+	uint8_t bit_pos = 0;
+	uint8_t nbits = 0; /* number of bits of codeword */
+	uint16_t run_length = 0;
+	uint16_t cbmaplen = 0; /* compressed bitmap part after decompression */
+	unsigned wp = 0;
+
+	egprs_compress *compress = egprs_compress::instance();
+
+	while (compress_bmap_len >= 0) {
+		if (clr_code_bit == 1) {
+			search_runlen(compress->ones_list, orig_crbb_buf,
+					bit_pos, &nbits, &run_length);
+		       /*If run length > 64, need makeup and terminating code*/
+			if (run_length < 64)
+				clr_code_bit = 0;
+			cbmaplen = cbmaplen + run_length;
+			/* put run length of Ones in uncompressed bitmap */
+			while (run_length != 0) {
+				if (run_length > 8) {
+					bitvec_write_field(dest, wp, 0xff, 8);
+					run_length = run_length - 8;
+				} else {
+					bitvec_write_field(dest, wp, 0xff,
+								run_length);
+					run_length = 0;
+				}
+			}
+		} else {
+			search_runlen(compress->zeros_list, orig_crbb_buf,
+					 bit_pos, &nbits, &run_length);
+			/*If run length > 64, need makeup and terminating code*/
+			if (run_length < 64)
+				clr_code_bit = 1;
+			cbmaplen = cbmaplen + run_length;
+			/* put run length of Zeros in uncompressed bitmap */
+			while (run_length != 0) {
+				if (run_length > 8) {
+					bitvec_write_field(dest, wp, 0x00, 8);
+					run_length = run_length - 8;
+				} else {
+					bitvec_write_field(dest, wp, 0x00,
+								 run_length);
+					run_length = 0;
+				}
+			}
+		}
+		bit_pos = bit_pos + nbits;
+		compress_bmap_len = compress_bmap_len - nbits;
+	}
+} /* Decompress_CRBB */
-- 
1.7.9.5




From sangamesh.sajjan at radisys.com  Wed Mar 30 13:50:44 2016
From: sangamesh.sajjan at radisys.com (sangamesh sajjan)
Date: Wed, 30 Mar 2016 19:20:44 +0530
Subject: [PATCH 2/3] Build a tree of code words
In-Reply-To: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <1459345845-25150-2-git-send-email-sangamesh.sajjan@radisys.com>

This patch includes the changes to build the tree of code words
to save run length during BTS initialization
---
 src/egprs_rlc_compression.cpp |   51 +++++++++++++++++++++++++++++++++++++++++
 src/egprs_rlc_compression.h   |   37 +++++++++++++++++++++++++++++-
 src/pcu_main.cpp              |    3 +++
 3 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/src/egprs_rlc_compression.cpp b/src/egprs_rlc_compression.cpp
index 55ff595..4c17a17 100644
--- a/src/egprs_rlc_compression.cpp
+++ b/src/egprs_rlc_compression.cpp
@@ -3,6 +3,57 @@
 */
 #include <egprs_rlc_compression.h>
 #include <errno.h>
+#include <decoding.h>
+
+egprs_compress *egprs_compress::s_instance = 0;
+Node *egprs_compress::ones_list = NULL;
+Node *egprs_compress::zeros_list = NULL;
+
+void egprs_compress::build_codeword(Node *root, const char *cdwd[])
+{
+	Node *iter; /* iterate the node on the tree */
+	int  len;    /* length of the code word */
+	int  i;      /* iterater */
+	uint16_t  idx;    /* interate index of the code word table */
+
+	root->left = NULL;
+	root->right = NULL;
+	root->run_length = NULL;
+
+	for (idx = 0; idx < MAX_CDWDTBL_LEN; idx++) {
+		len = strlen((const char *)cdwd[idx]);
+		iter = root;
+		for (i = 0;  i < len;  i++) {
+			if (cdwd[idx][i] == '0') {
+				if (iter->left == NULL) {
+				 iter->left = (Node *)malloc(sizeof(Node));
+				 /* create a clean node */
+				 iter->left->left = NULL;
+				 iter->left->right = NULL;
+				 iter->left->run_length = NULL;
+				}
+				iter = iter->left;
+			} else if (cdwd[idx][i] == '1') {
+				if (iter->right == NULL) {
+				iter->right = (Node *)malloc(sizeof(Node));
+				/* create a clean node */
+				iter->right->left = NULL;
+				iter->right->right = NULL;
+				iter->right->run_length = NULL;
+				}
+				iter = iter->right;
+			}
+		}
+		if (iter != NULL) {
+			iter->run_length = (uint16_t *)malloc(sizeof(uint16_t));
+			*(iter->run_length) = (uint16_t)NULL;
+			if (idx < 64)
+				*(iter->run_length) = idx;
+			else
+				*(iter->run_length) = (idx - 63) * 64;
+		}
+	}
+}
 
 const char *one_run_len_code_list[MAX_CDWDTBL_LEN] = {
 	"00110101",
diff --git a/src/egprs_rlc_compression.h b/src/egprs_rlc_compression.h
index 00d850e..db1f880 100644
--- a/src/egprs_rlc_compression.h
+++ b/src/egprs_rlc_compression.h
@@ -15,7 +15,7 @@ extern "C" {
 #include <string.h>
 
 #define	MAX_CDWDTBL_LEN          79        /* total number of codewords */
-#define	BITS_TO_BYTES(X)      (X ? (X/8):0)+1
+#define	BITS_TO_BYTES(X)      ((X ? (X/8):0)+1)
 #define	MOD8(X)             (((X)+8) & (0x07))
 
 typedef struct node {
@@ -23,3 +23,38 @@ typedef struct node {
 	struct node *right;
 	uint16_t *run_length;
 } Node;
+
+extern const char *one_run_len_code_list[MAX_CDWDTBL_LEN];
+extern const char *zero_run_len_code_list[MAX_CDWDTBL_LEN];
+
+/* Creating singleton class
+ */
+class egprs_compress
+{
+	static egprs_compress *s_instance;
+
+	egprs_compress()
+	{
+		egprs_compress::ones_list = (Node *)malloc(sizeof(Node));
+		egprs_compress::zeros_list = (Node *)malloc(sizeof(Node));
+	}
+	void build_codeword(Node *root, const char *cdwd[]);
+public:
+	static Node *ones_list;
+	static Node *zeros_list;
+
+	void decode_tree_init(void)
+	{
+		egprs_compress::instance()->build_codeword(
+			egprs_compress::ones_list, one_run_len_code_list);
+		egprs_compress::instance()->build_codeword(
+			egprs_compress::zeros_list, zero_run_len_code_list);
+	}
+	static egprs_compress *instance()
+	{
+		if (!s_instance)
+			s_instance = new egprs_compress;
+
+		return s_instance;
+	}
+};
diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index f66c631..642ab33 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -28,6 +28,7 @@
 #include <signal.h>
 #include <sched.h>
 #include <bts.h>
+#include <egprs_rlc_compression.h>
 extern "C" {
 #include "pcu_vty.h"
 #include <osmocom/vty/telnet_interface.h>
@@ -253,6 +254,8 @@ int main(int argc, char *argv[])
 	if (!bts->alloc_algorithm)
 		bts->alloc_algorithm = alloc_algorithm_dynamic;
 
+	egprs_compress::instance()->decode_tree_init();
+
 	rc = pcu_l1if_open();
 
 	if (rc < 0)
-- 
1.7.9.5




From msuraev at sysmocom.de  Wed Mar 30 15:35:01 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 30 Mar 2016 17:35:01 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
Message-ID: <56FBF225.7030301@sysmocom.de>

Hi.

Thank you for your contribution. Could you clarify - what's the
advantage of this approach over existing osmo_t4_decode() function?
Is there some test case which works for one but not the other?

-- 
Max Suraev <msuraev at 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 



From laforge at gnumonks.org  Wed Mar 30 20:10:21 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Mar 2016 22:10:21 +0200
Subject: [PATCH 1/3] Add data structure for CPS calculation in DL
In-Reply-To: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
References: <1458737988-4198-1-git-send-email-arvind.sirsikar@radisys.com>
Message-ID: <20160330201021.GI23309@nataraja>

Hi Aravind,

On Wed, Mar 23, 2016 at 06:29:45PM +0530, Aravind Sirsikar wrote:
> Define new data structure with respect to TS 44.060
> 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1 for puncturing scheme values
> and initialize the variable introduced

I've merged this series to master now.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Wed Mar 30 20:12:27 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Mar 2016 22:12:27 +0200
Subject: [PATCH 1/2] Add EGPRS header type 2 parsing function in uplink
In-Reply-To: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <20160330201227.GK23309@nataraja>

Hi Bhargava,

On Wed, Mar 30, 2016 at 06:58:41PM +0530, Bhargava Abhyankar wrote:
> Function is added to parse the EGPRS header type 2 in uplink tbf path.
> This is added to further support mcs 5 to mcs 9 in uplink.

The patches look fine to me (keep in mind, I'm not the PCU expert in the
team, so others might disagree).  However, unfortunately your patch
doesn't apply on current master, please re-base and re-submit.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Wed Mar 30 20:11:00 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Mar 2016 22:11:00 +0200
Subject: [PATCH 1/2] Refactor the Uplink RLC header parsing function
In-Reply-To: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1458652351-19578-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <20160330201100.GJ23309@nataraja>

Hi Bhargava,

On Tue, Mar 22, 2016 at 06:42:30PM +0530, Bhargava Abhyankar wrote:
> Parsing the uplink data header for GPRS and EGPRS header type 3
> is handled in separate functions.
> This patch will enhance modularity of the code.

I've merged this to master now, thanks.

The 2/2 of this series is rejected, see the related discussion.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Bhargava.Abhyankar at radisys.com  Thu Mar 31 07:25:13 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Thu, 31 Mar 2016 12:55:13 +0530
Subject: [PATCH 1/2] Add EGPRS header type 2 parsing function in uplink
Message-ID: <1459409114-25865-1-git-send-email-Bhargava.Abhyankar@radisys.com>

Function is added to parse the EGPRS header type 2 in uplink tbf path.
This is added to further support mcs 5 to mcs 9 in uplink.
---
 src/decoding.cpp        |  52 +++++++++++++++--
 src/decoding.h          |   4 ++
 tests/edge/EdgeTest.cpp | 151 +++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/src/decoding.cpp b/src/decoding.cpp
index 0c81b2a..4d61083 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -352,10 +352,10 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3 :
 		cur_bit = rlc_parse_ul_data_header_egprs_type_3(rlc, data, cs);
 		break;
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1:
-	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2:
-		/* TODO: Support both header types */
-		/* fall through */
+	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2 :
+		cur_bit = rlc_parse_ul_data_header_egprs_type_2(rlc, data, cs);
+		break;
+	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 :
 	default:
 		LOGP(DRLCMACDL, LOGL_ERROR,
 			"Decoding of uplink %s data blocks not yet supported.\n",
@@ -438,6 +438,50 @@ int Decoding::rlc_parse_ul_data_header_gprs(struct gprs_rlc_data_info *rlc,
 	return cur_bit;
 }
 
+int Decoding::rlc_parse_ul_data_header_egprs_type_2(
+	struct gprs_rlc_data_info *rlc,
+	const uint8_t *data,
+	const GprsCodingScheme &cs)
+{
+	const struct gprs_rlc_ul_header_egprs_2 *egprs2;
+	unsigned int e_ti_header, offs, cur_bit = 0;
+	int punct, punct2, with_padding, cps;
+
+	egprs2 = static_cast < struct gprs_rlc_ul_header_egprs_2 * >
+			((void *)data);
+
+	cps    = (egprs2->cps_a << 0)  | (egprs2->cps_b << 2);
+	gprs_rlc_mcs_cps_decode(cps, cs, &punct, &punct2, &with_padding);
+	gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
+
+	rlc->r      = egprs2->r;
+	rlc->si     = egprs2->si;
+	rlc->tfi    = (egprs2->tfi_a << 0)  | (egprs2->tfi_b << 2);
+	rlc->cps    = cps;
+	rlc->rsb    = egprs2->rsb;
+
+	rlc->num_data_blocks = 1;
+	rlc->block_info[0].cv  = egprs2->cv;
+	rlc->block_info[0].pi  = egprs2->pi;
+	rlc->block_info[0].bsn =
+		(egprs2->bsn1_a << 0) | (egprs2->bsn1_b << 5);
+
+	cur_bit += rlc->data_offs_bits[0] - 2;
+
+	offs = rlc->data_offs_bits[0] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 1);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[0].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
+
 /**
  * \brief Copy LSB bitstream RLC data block to byte aligned buffer.
  *
diff --git a/src/decoding.h b/src/decoding.h
index 1043d67..9fb2c85 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -51,6 +51,10 @@ public:
 		struct gprs_rlc_data_info *rlc,
 		const uint8_t *data,
 		const GprsCodingScheme &cs);
+	static int rlc_parse_ul_data_header_egprs_type_2(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		const GprsCodingScheme &cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index 96ea0c1..c2dfc0b 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -26,7 +26,7 @@
 #include "encoding.h"
 #include "rlc.h"
 #include "llc.h"
-
+#include "bts.h"
 extern "C" {
 #include "pcu_vty.h"
 
@@ -495,6 +495,155 @@ static void test_rlc_unit_decoder()
 	OSMO_ASSERT(chunks[2].length == 1);
 	OSMO_ASSERT(!chunks[2].is_complete);
 
+	cs = GprsCodingScheme::MCS5;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (15 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 1);
+	OSMO_ASSERT(chunks[0].length == 15);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 16);
+	OSMO_ASSERT(chunks[1].length == 40);
+	OSMO_ASSERT(!chunks[1].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 1;
+	offs = 0;
+	data[offs++] = (0 << 1) | (0 << 0);
+	data[offs++] = (7 << 1) | (0 << 0);
+	data[offs++] = (18 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+			chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 4);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].length == 0);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 3);
+	OSMO_ASSERT(chunks[1].length == 7);
+	OSMO_ASSERT(chunks[1].is_complete);
+	OSMO_ASSERT(chunks[2].offset == 10);
+	OSMO_ASSERT(chunks[2].length == 18);
+	OSMO_ASSERT(chunks[2].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (6 << 1) | (0 << 0);
+	data[offs++] = (12 << 1) | (0 << 0);
+	data[offs++] = (127 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 3);
+	OSMO_ASSERT(chunks[0].length == 6);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 9);
+	OSMO_ASSERT(chunks[1].length == 12);
+	OSMO_ASSERT(chunks[1].is_complete);
+
+	cs = GprsCodingScheme::MCS5;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 1;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 1);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 0);
+	OSMO_ASSERT(chunks[0].length == 56);
+	OSMO_ASSERT(chunks[0].is_complete);
+
+	cs = GprsCodingScheme::MCS6;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (15 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 1);
+	OSMO_ASSERT(chunks[0].length == 15);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 16);
+	OSMO_ASSERT(chunks[1].length == 58);
+	OSMO_ASSERT(!chunks[1].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 15;
+	tlli = 1;
+	offs = 0;
+	data[offs++] = (0 << 1) | (0 << 0);
+	data[offs++] = (7 << 1) | (0 << 0);
+	data[offs++] = (18 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+
+	OSMO_ASSERT(num_chunks == 4);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].length == 0);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 3);
+	OSMO_ASSERT(chunks[1].length == 7);
+	OSMO_ASSERT(chunks[1].is_complete);
+	OSMO_ASSERT(chunks[2].offset == 10);
+	OSMO_ASSERT(chunks[2].length == 18);
+	OSMO_ASSERT(chunks[2].is_complete);
+
+	rdbi.e = 0;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	data[offs++] = (6 << 1) | (0 << 0);
+	data[offs++] = (12 << 1) | (0 << 0);
+	data[offs++] = (127 << 1) | (1 << 0);
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 2);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 3);
+	OSMO_ASSERT(chunks[0].length == 6);
+	OSMO_ASSERT(chunks[0].is_complete);
+	OSMO_ASSERT(chunks[1].offset == 9);
+	OSMO_ASSERT(chunks[1].length == 12);
+	OSMO_ASSERT(chunks[1].is_complete);
+
+	cs = GprsCodingScheme::MCS6;
+	rdbi.data_len = cs.maxDataBlockBytes();
+	rdbi.e = 1;
+	rdbi.ti = 0;
+	rdbi.cv = 0;
+	tlli = 0;
+	offs = 0;
+	num_chunks = Decoding::rlc_data_from_ul_data(&rdbi, cs, data,
+		chunks, ARRAY_SIZE(chunks), &tlli);
+	OSMO_ASSERT(num_chunks == 1);
+	OSMO_ASSERT(tlli == 0);
+	OSMO_ASSERT(chunks[0].offset == 0);
+	OSMO_ASSERT(chunks[0].length == 74);
+	OSMO_ASSERT(chunks[0].is_complete);
+
 	printf("=== end %s ===\n", __func__);
 }
 
-- 
2.5.0




From Bhargava.Abhyankar at radisys.com  Thu Mar 31 07:25:14 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Thu, 31 Mar 2016 12:55:14 +0530
Subject: [PATCH 2/2] Add EGPRS header type 1 parsing function in uplink
In-Reply-To: <1459409114-25865-1-git-send-email-Bhargava.Abhyankar@radisys.com>
References: <1459409114-25865-1-git-send-email-Bhargava.Abhyankar@radisys.com>
Message-ID: <1459409114-25865-2-git-send-email-Bhargava.Abhyankar@radisys.com>

Function is added to parse the EGPRS header type 1 in uplink tbf path.
This is added to further support mcs 5 to mcs 9 in uplink.
---
 src/bts.cpp             |   9 ---
 src/decoding.cpp        |  56 +++++++++++++++++
 src/decoding.h          |   4 ++
 tests/edge/EdgeTest.cpp | 163 +++++++++++++++++++++++++++++++++++++++++++++++-
 tests/edge/EdgeTest.ok  |   2 +
 5 files changed, 224 insertions(+), 10 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..f818ee2 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -1333,15 +1333,6 @@ int gprs_rlcmac_pdch::rcv_data_block(uint8_t *data, uint32_t fn,
 				cs.name());
 			return -EINVAL;
 		}
-
-		if (!cs.isEgprsGmsk()) {
-			LOGP(DRLCMACUL, LOGL_ERROR,
-				"Got %s RLC block but EGPRS is not implemented "
-				"for 8PSK yet\n",
-				cs.name());
-			bts()->decode_error();
-			return -EINVAL;
-		}
 	}
 
 	LOGP(DRLCMACUL, LOGL_DEBUG, "  UL data: %s\n", osmo_hexdump(data, len));
diff --git a/src/decoding.cpp b/src/decoding.cpp
index 4d61083..6844856 100644
--- a/src/decoding.cpp
+++ b/src/decoding.cpp
@@ -356,6 +356,8 @@ int Decoding::rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		cur_bit = rlc_parse_ul_data_header_egprs_type_2(rlc, data, cs);
 		break;
 	case GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1 :
+		cur_bit = rlc_parse_ul_data_header_egprs_type_1(rlc, data, cs);
+		break;
 	default:
 		LOGP(DRLCMACDL, LOGL_ERROR,
 			"Decoding of uplink %s data blocks not yet supported.\n",
@@ -482,6 +484,60 @@ int Decoding::rlc_parse_ul_data_header_egprs_type_2(
 	return cur_bit;
 }
 
+int Decoding::rlc_parse_ul_data_header_egprs_type_1(
+	struct gprs_rlc_data_info *rlc,
+	const uint8_t *data, const GprsCodingScheme &cs)
+{
+	struct gprs_rlc_ul_header_egprs_1 *egprs1;
+	unsigned int e_ti_header, cur_bit = 0, offs;
+	int punct, punct2, with_padding;
+
+	egprs1 = static_cast < struct gprs_rlc_ul_header_egprs_1 * >
+		((void *)data);
+	gprs_rlc_mcs_cps_decode(egprs1->cps, cs, &punct, &punct2,
+		&with_padding);
+	gprs_rlc_data_info_init_ul(rlc, cs, with_padding);
+
+	rlc->r      = egprs1->r;
+	rlc->si     = egprs1->si;
+	rlc->tfi    = (egprs1->tfi_a << 0)  | (egprs1->tfi_b << 2);
+	rlc->cps    = egprs1->cps;
+	rlc->rsb    = egprs1->rsb;
+	rlc->num_data_blocks = 2;
+	rlc->block_info[0].cv  = egprs1->cv;
+	rlc->block_info[0].pi  = egprs1->pi;
+	rlc->block_info[0].bsn =
+			(egprs1->bsn1_a << 0) | (egprs1->bsn1_b << 5);
+
+	cur_bit += rlc->data_offs_bits[0] - 2;
+	offs = rlc->data_offs_bits[0] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[0] % 8 == 0);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[0].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[0].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+
+	rlc->block_info[1].cv  = egprs1->cv;
+	rlc->block_info[1].pi  = egprs1->pi;
+	rlc->block_info[1].bsn = rlc->block_info[0].bsn +
+		((egprs1->bsn2_a << 0) | (egprs1->bsn2_b << 2));
+	rlc->block_info[1].bsn = rlc->block_info[1].bsn &  (RLC_EGPRS_SNS - 1);
+
+	cur_bit += rlc->data_offs_bits[1] - 2;
+
+	offs = rlc->data_offs_bits[1] / 8;
+	OSMO_ASSERT(rlc->data_offs_bits[1] % 8 == 2);
+
+	e_ti_header = (data[offs-1] + (data[offs] << 8)) >> 7;
+	rlc->block_info[1].e   = !!(e_ti_header & 0x01);
+	rlc->block_info[1].ti  = !!(e_ti_header & 0x02);
+	cur_bit += 2;
+	/* skip data area */
+	cur_bit += cs.maxDataBlockBytes() * 8;
+
+	return cur_bit;
+}
 /**
  * \brief Copy LSB bitstream RLC data block to byte aligned buffer.
  *
diff --git a/src/decoding.h b/src/decoding.h
index 9fb2c85..d787494 100644
--- a/src/decoding.h
+++ b/src/decoding.h
@@ -55,6 +55,10 @@ public:
 		struct gprs_rlc_data_info *rlc,
 		const uint8_t *data,
 		const GprsCodingScheme &cs);
+	static int rlc_parse_ul_data_header_egprs_type_1(
+		struct gprs_rlc_data_info *rlc,
+		const uint8_t *data,
+		const GprsCodingScheme &cs);
 	static int rlc_parse_ul_data_header(struct gprs_rlc_data_info *rlc,
 		const uint8_t *data, GprsCodingScheme cs);
 	static unsigned int rlc_copy_to_aligned_buffer(
diff --git a/tests/edge/EdgeTest.cpp b/tests/edge/EdgeTest.cpp
index c2dfc0b..ff080f9 100644
--- a/tests/edge/EdgeTest.cpp
+++ b/tests/edge/EdgeTest.cpp
@@ -1250,6 +1250,167 @@ const struct log_info debug_log_info = {
 	ARRAY_SIZE(default_categories),
 };
 
+static void setup_bts(BTS *the_bts, uint8_t ts_no, uint8_t cs = 1)
+{
+	gprs_rlcmac_bts *bts;
+	gprs_rlcmac_trx *trx;
+
+	bts = the_bts->bts_data();
+	bts->egprs_enabled = true;
+	bts->alloc_algorithm = alloc_algorithm_a;
+	bts->initial_cs_dl = cs;
+	bts->initial_cs_ul = cs;
+	trx = &bts->trx[0];
+	trx->pdch[ts_no].enable();
+}
+
+static void send_ul_mac_block(BTS *the_bts, unsigned trx_no, unsigned ts_no,
+	RlcMacUplink_t *ulreq, unsigned fn)
+{
+	bitvec *rlc_block;
+	uint8_t buf[64];
+	int num_bytes;
+	struct gprs_rlcmac_pdch *pdch;
+	struct pcu_l1_meas meas;
+
+	meas.set_rssi(31);
+	rlc_block = bitvec_alloc(23);
+	encode_gsm_rlcmac_uplink(rlc_block, ulreq);
+	num_bytes = bitvec_pack(rlc_block, &buf[0]);
+	OSMO_ASSERT(size_t(num_bytes) < sizeof(buf));
+	bitvec_free(rlc_block);
+	the_bts->set_current_block_frame_number(fn, 0);
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&buf[0], num_bytes, fn, &meas);
+}
+
+static unsigned fn2bn(unsigned fn)
+{
+	return (fn % 52) / 4;
+}
+
+static unsigned fn_add_blocks(unsigned fn, unsigned blocks)
+{
+	unsigned bn = fn2bn(fn) + blocks;
+
+	fn = fn - (fn % 52);
+	fn += bn * 4 + bn / 3;
+	return fn % 2715648;
+}
+
+static void request_dl_rlc_block(struct gprs_rlcmac_bts *bts,
+	uint8_t trx_no, uint8_t ts_no, uint16_t arfcn,
+	uint32_t *fn, uint8_t *block_nr = NULL)
+{
+	uint8_t bn = fn2bn(*fn);
+
+	gprs_rlcmac_rcv_rts_block(bts, trx_no, ts_no, arfcn, *fn, bn);
+	*fn = fn_add_blocks(*fn, 1);
+	bn += 1;
+	if (block_nr)
+		*block_nr = bn;
+}
+
+static gprs_rlcmac_ul_tbf *uplink_header_parsing_test(BTS *the_bts,
+	uint8_t ts_no, uint32_t tlli, uint32_t *fn, uint16_t qta,
+	uint8_t ms_class)
+{
+	GprsMs *ms;
+	struct pcu_l1_meas meas;
+	uint32_t rach_fn = *fn - 51;
+	uint32_t sba_fn = *fn + 52;
+	uint8_t trx_no = 0;
+	int tfi = 0;
+	gprs_rlcmac_ul_tbf *ul_tbf;
+	struct gprs_rlcmac_pdch *pdch;
+	gprs_rlcmac_bts *bts;
+	RlcMacUplink_t ulreq = {0};
+	uint8_t data[144] = {0};
+	struct gprs_rlc_ul_header_egprs_1 *egprs1  = NULL;
+
+	meas.set_rssi(31);
+	egprs1 = (struct gprs_rlc_ul_header_egprs_1 *) data;
+	bts = the_bts->bts_data();
+
+	/* needed to set last_rts_fn in the PDCH object */
+	request_dl_rlc_block(bts, trx_no, ts_no, 0, fn);
+
+	/* simulate RACH,this sends a Immediate Assignment Uplink on the AGCH */
+	the_bts->rcv_rach(0x73, rach_fn, qta);
+
+	/* get next free TFI */
+	tfi = the_bts->tfi_find_free(GPRS_RLCMAC_UL_TBF, &trx_no, -1);
+
+	/* fake a resource request */
+	ulreq.u.MESSAGE_TYPE = MT_PACKET_RESOURCE_REQUEST;
+	ulreq.u.Packet_Resource_Request.PayloadType = GPRS_RLCMAC_CONTROL_BLOCK;
+	ulreq.u.Packet_Resource_Request.ID.UnionType = 1; /* != 0 */
+	ulreq.u.Packet_Resource_Request.ID.u.TLLI = tlli;
+	ulreq.u.Packet_Resource_Request.Exist_MS_Radio_Access_capability = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+			Count_MS_RA_capability_value = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.
+		Exist_Multislot_capability = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		Exist_GPRS_multislot_class = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		GPRS_multislot_class = ms_class;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		Exist_EGPRS_multislot_class = 1;
+	ulreq.u.Packet_Resource_Request.MS_Radio_Access_capability.
+		MS_RA_capability_value[0].u.Content.Multislot_capability.
+		EGPRS_multislot_class = ms_class;
+
+	send_ul_mac_block(the_bts, trx_no, ts_no, &ulreq, sba_fn);
+
+	/* check the TBF */
+	ul_tbf = the_bts->ul_tbf_by_tfi(tfi, trx_no, ts_no);
+	OSMO_ASSERT(ul_tbf != NULL);
+	OSMO_ASSERT(ul_tbf->ta() == qta / 4);
+
+	egprs1->si = 1;
+	egprs1->r = 1;
+	egprs1->cv = 7;
+	egprs1->tfi_a = tfi & (~((~0) << 2));
+	egprs1->tfi_b = tfi & (~((~0) << 3)) << 2;
+	egprs1->bsn1_a = 10;
+	egprs1->bsn1_b = 17;
+	egprs1->bsn2_a = 0;
+	egprs1->bsn2_b = 25;
+	egprs1->cps = 15;
+	egprs1->rsb = 0;
+	egprs1->pi = 0;
+	data[6] = 1;
+	data[6 + 68] = 1;
+	data[75] = 1;
+	data[75 + 68] = 1;
+	pdch = &the_bts->bts_data()->trx[trx_no].pdch[ts_no];
+	pdch->rcv_block(&data[0], 143, *fn, &meas);
+}
+
+void uplink_header_type1_test(void)
+{
+	BTS the_bts;
+	int ts_no = 7;
+	uint32_t fn = 2654218;
+	uint16_t qta = 31;
+	uint32_t tlli = 0xf1223344;
+	const char *imsi = "0011223344";
+	uint8_t ms_class = 1;
+	gprs_rlcmac_ul_tbf *ul_tbf;
+	GprsMs *ms;
+
+	printf("=== start %s ===\n", __func__);
+	setup_bts(&the_bts, ts_no, 12);
+	ul_tbf = uplink_header_parsing_test(&the_bts, ts_no, tlli, &fn,
+			qta, ms_class);
+	printf("=== end %s ===\n", __func__);
+}
+
 int main(int argc, char **argv)
 {
 	struct vty_app_info pcu_vty_info = {0};
@@ -1271,7 +1432,7 @@ int main(int argc, char **argv)
 	test_rlc_unit_decoder();
 	test_rlc_unaligned_copy();
 	test_rlc_unit_encoder();
-
+	uplink_header_type1_test();
 	if (getenv("TALLOC_REPORT_FULL"))
 		talloc_report_full(tall_pcu_ctx, stderr);
 	return EXIT_SUCCESS;
diff --git a/tests/edge/EdgeTest.ok b/tests/edge/EdgeTest.ok
index 9554df3..353f55d 100644
--- a/tests/edge/EdgeTest.ok
+++ b/tests/edge/EdgeTest.ok
@@ -6,3 +6,5 @@
 === end test_rlc_unit_decoder ===
 === start test_rlc_unit_encoder ===
 === end test_rlc_unit_encoder ===
+=== start uplink_header_type1_test ===
+=== end uplink_header_type1_test ===
-- 
2.5.0




From nhofmeyr at sysmocom.de  Thu Mar 31 10:05:41 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 31 Mar 2016 12:05:41 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <56FBF225.7030301@sysmocom.de>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
Message-ID: <20160331100541.GD1149@ass40.sysmocom.de>

On Wed, Mar 30, 2016 at 05:35:01PM +0200, Max wrote:
> Hi.
> 
> Thank you for your contribution. Could you clarify - what's the
> advantage of this approach over existing osmo_t4_decode() function?
> Is there some test case which works for one but not the other?

Not sure if it answers your question, but Sangamesh has posted a
description of the patch a while ago in this and the following mails:

Date: Thu, 17 Mar 2016 15:43:36 +0000
From: Sangamesh Sajjan <Sangamesh.Sajjan at radisys.com>
To: "osmocom-net-gprs at lists.osmocom.org" <osmocom-net-gprs at lists.osmocom.org>
Subject: Proposal for new structure definition for compression algorithm

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160331/b60a77ae/attachment.bin>

From Sangamesh.Sajjan at radisys.com  Thu Mar 31 10:51:15 2016
From: Sangamesh.Sajjan at radisys.com (Sangamesh Sajjan)
Date: Thu, 31 Mar 2016 10:51:15 +0000
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <56FBF225.7030301@sysmocom.de>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
Message-ID: <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>

Hello Max,

On Wednesday, March 30, 2016 9:05 PM, Max Suraev wrote:

> Thank you for your contribution. Could you clarify - what's the advantage of this approach over existing osmo_t4_decode() function?

To highlight the difference between osmo_t4_decode and Tree based approach consider the example below,
 
if the received code word from the bitmap is ?0111? and 0?s color code, then following steps involved to find run length using osmo_t4_decode
1.	Initially it finds the number of bits based on the color code ( i.e if it is 0 color code, then read 2 bits  or  4 bits if it is 1 color code )
2.	Since it is 0?s color code, read 2 bits from the  received encoded bitmap
3.	Check whether received 2 bits matches to any of the table entry ( i.e Makeup or  Terminating table), if it doesn?t match then increment one more bit.
o	This will require loop of 15 followed by 64, So total of 79 comparison 
4.	Repeat the 3rd step if there is no matching code word

Hence to find 0111 code word from the table, osmo_t4_decode would require
Two iterations of makeup table ( i.e 15 times each ) and terminating table ( i.e 64 times each) = ((15 + 64 )* 2 ) = 158
Third iteration where in exact match of code word is found in terminating table 3rd  position = 15+3  
 So total 176 comparisons required to find the run length.

 Usually there will be multiple code words in the received bitmap and each require multiple iterations to find run length as explained above.

Whereas In tree based approach two trees (i.e. ones list and zero list ) are used and entire code word traversing shall be done in respective tree in single traversal based on color code.
?	Read every bit from the received encoded bitmap and traverse the tree generated in init, If the bit is 0 traverse left and if it is 1 traverse right, Repeat this procedure till we find valid run length.
?	In example above for ?0111? only 4 comparisons are required 

Hence we see advantage in using tree based approach for CRBB decoding.

> Is there some test case which works for one but not the other?
Currently we don?t have this specific test.
 
Regards,
Sangamesh


From msuraev at sysmocom.de  Thu Mar 31 11:04:36 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 31 Mar 2016 13:04:36 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
 <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>
Message-ID: <56FD0444.1070604@sysmocom.de>

Hi and thanks for detailed write-up.

So the code do exactly the same thing just more efficiently under the
assumption that gcc optimization is not working.
Is there a way to quantify this potential difference?

More specifically - is there a test-case which could demonstrate that
this difference actually matters in practice?

I mean if the code in question constitute, for example, 10% of cpu time
spent by osmo-pcu and the replacement would shrink it to 2% it's one thing.
If it's 0.1% and 0.001% it's another: the relative gain in the latter
case is bigger but I'm not sure it justifies allegedly higher code
complexity.

On 03/31/2016 12:51 PM, Sangamesh Sajjan wrote:
> Hello Max,
>
> On Wednesday, March 30, 2016 9:05 PM, Max Suraev wrote:
>
>> Thank you for your contribution. Could you clarify - what's the advantage of this approach over existing osmo_t4_decode() function?
> To highlight the difference between osmo_t4_decode and Tree based approach consider the example below,
>  
> if the received code word from the bitmap is ?0111? and 0?s color code, then following steps involved to find run length using osmo_t4_decode
> 1.	Initially it finds the number of bits based on the color code ( i.e if it is 0 color code, then read 2 bits  or  4 bits if it is 1 color code )
> 2.	Since it is 0?s color code, read 2 bits from the  received encoded bitmap
> 3.	Check whether received 2 bits matches to any of the table entry ( i.e Makeup or  Terminating table), if it doesn?t match then increment one more bit.
> o	This will require loop of 15 followed by 64, So total of 79 comparison 
> 4.	Repeat the 3rd step if there is no matching code word
>
> Hence to find 0111 code word from the table, osmo_t4_decode would require
> Two iterations of makeup table ( i.e 15 times each ) and terminating table ( i.e 64 times each) = ((15 + 64 )* 2 ) = 158
> Third iteration where in exact match of code word is found in terminating table 3rd  position = 15+3  
>  So total 176 comparisons required to find the run length.
>
>  Usually there will be multiple code words in the received bitmap and each require multiple iterations to find run length as explained above.
>
> Whereas In tree based approach two trees (i.e. ones list and zero list ) are used and entire code word traversing shall be done in respective tree in single traversal based on color code.
> ?	Read every bit from the received encoded bitmap and traverse the tree generated in init, If the bit is 0 traverse left and if it is 1 traverse right, Repeat this procedure till we find valid run length.
> ?	In example above for ?0111? only 4 comparisons are required 
>
> Hence we see advantage in using tree based approach for CRBB decoding.
>
>> Is there some test case which works for one but not the other?
> Currently we don?t have this specific test.
>  
> Regards,
> Sangamesh
>

-- 
Max Suraev <msuraev at 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 



From holger at freyther.de  Thu Mar 31 11:25:10 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 31 Mar 2016 13:25:10 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <56FD0444.1070604@sysmocom.de>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
 <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>
 <56FD0444.1070604@sysmocom.de>
Message-ID: <C6257253-A532-40CF-8F81-A70338C02FAC@freyther.de>


> On 31 Mar 2016, at 13:04, Max <msuraev at sysmocom.de> wrote:
> 
> Hi and thanks for detailed write-up.
> 
> So the code do exactly the same thing just more efficiently under the
> assumption that gcc optimization is not working.
> Is there a way to quantify this potential difference?

Hi Sangamesh,

let me refer to Haralds mail on optmization and let me add that any "performance" improvement needs to have a benchmark that proves progress.

Looking at both implementations I am not convinced any of the two will be faster/slower than the other. Now the look-up in a tree might be log(N) in terms of compares but as each tree node is sitting on different memory (between we never use malloc, but always use talloc to allocate) the cache misses might make it slower than Max's version.

Please collect typical bitmaps, create a benchmark and compare the two implementations and we can make a decision.

thank you
	holger





From nhofmeyr at sysmocom.de  Thu Mar 31 13:51:23 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 31 Mar 2016 15:51:23 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <56FD0444.1070604@sysmocom.de>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
 <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>
 <56FD0444.1070604@sysmocom.de>
Message-ID: <20160331135123.GA5023@ass40.sysmocom.de>

On Thu, Mar 31, 2016 at 01:04:36PM +0200, Max wrote:
> Hi and thanks for detailed write-up.
> 
> So the code do exactly the same thing just more efficiently under the
> assumption that gcc optimization is not working.

Correct me if I'm wrong, but I firmly assume gcc optimization wouldn't
implement a tree search algorithm for looking up items in a struct, when
our code walks the struct linearly.

> Is there a way to quantify this potential difference?

Hard besides timing, I guess, and we know how flaky timing based
assumptions in a test suite can be. We'd have to count comparisons or
something, i.e. add code just to prove efficiency. Let's not.

> More specifically - is there a test-case which could demonstrate that
> this difference actually matters in practice?
> 
> I mean if the code in question constitute, for example, 10% of cpu time
> spent by osmo-pcu and the replacement would shrink it to 2% it's one thing.
> If it's 0.1% and 0.001% it's another: the relative gain in the latter
> case is bigger but I'm not sure it justifies allegedly higher code
> complexity.

I'm with Sangamesh here: if 176 comparisons reduce to 4 comparisons
(factor 44!), and assuming a compression algorithm would do this for a
whole stream of message bits, IMHO this justifies code complexity. Right?

I must reserve the fact that I still haven't read the entire code in
detail, I'm just arguing theoretically.

~Neels

> 
> On 03/31/2016 12:51 PM, Sangamesh Sajjan wrote:
> > Hello Max,
> >
> > On Wednesday, March 30, 2016 9:05 PM, Max Suraev wrote:
> >
> >> Thank you for your contribution. Could you clarify - what's the advantage of this approach over existing osmo_t4_decode() function?
> > To highlight the difference between osmo_t4_decode and Tree based approach consider the example below,
> >  
> > if the received code word from the bitmap is ?0111? and 0?s color code, then following steps involved to find run length using osmo_t4_decode
> > 1.	Initially it finds the number of bits based on the color code ( i.e if it is 0 color code, then read 2 bits  or  4 bits if it is 1 color code )
> > 2.	Since it is 0?s color code, read 2 bits from the  received encoded bitmap
> > 3.	Check whether received 2 bits matches to any of the table entry ( i.e Makeup or  Terminating table), if it doesn?t match then increment one more bit.
> > o	This will require loop of 15 followed by 64, So total of 79 comparison 
> > 4.	Repeat the 3rd step if there is no matching code word
> >
> > Hence to find 0111 code word from the table, osmo_t4_decode would require
> > Two iterations of makeup table ( i.e 15 times each ) and terminating table ( i.e 64 times each) = ((15 + 64 )* 2 ) = 158
> > Third iteration where in exact match of code word is found in terminating table 3rd  position = 15+3  
> >  So total 176 comparisons required to find the run length.
> >
> >  Usually there will be multiple code words in the received bitmap and each require multiple iterations to find run length as explained above.
> >
> > Whereas In tree based approach two trees (i.e. ones list and zero list ) are used and entire code word traversing shall be done in respective tree in single traversal based on color code.
> > ?	Read every bit from the received encoded bitmap and traverse the tree generated in init, If the bit is 0 traverse left and if it is 1 traverse right, Repeat this procedure till we find valid run length.
> > ?	In example above for ?0111? only 4 comparisons are required 
> >
> > Hence we see advantage in using tree based approach for CRBB decoding.
> >
> >> Is there some test case which works for one but not the other?
> > Currently we don?t have this specific test.
> >  
> > Regards,
> > Sangamesh
> >
> 
> -- 
> Max Suraev <msuraev at 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 
> 

-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160331/17b1a084/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Mar 31 13:52:26 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 31 Mar 2016 15:52:26 +0200
Subject: [PATCH 3/3] Decompress the CRBB bitmap using tree based approach
In-Reply-To: <C6257253-A532-40CF-8F81-A70338C02FAC@freyther.de>
References: <1459345845-25150-1-git-send-email-sangamesh.sajjan@radisys.com>
 <1459345845-25150-3-git-send-email-sangamesh.sajjan@radisys.com>
 <56FBF225.7030301@sysmocom.de>
 <DM2PR08MB71839EC44F69EAF20DD51D588990@DM2PR08MB718.namprd08.prod.outlook.com>
 <56FD0444.1070604@sysmocom.de>
 <C6257253-A532-40CF-8F81-A70338C02FAC@freyther.de>
Message-ID: <20160331135226.GB5023@ass40.sysmocom.de>

On Thu, Mar 31, 2016 at 01:25:10PM +0200, Holger Freyther wrote:
> Please collect typical bitmaps, create a benchmark and compare the two implementations and we can make a decision.

fair enough. +1.

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160331/fb616f98/attachment.bin>

From Bhargava.Abhyankar at radisys.com  Thu Mar 31 14:39:20 2016
From: Bhargava.Abhyankar at radisys.com (Bhargava Abhyankar)
Date: Thu, 31 Mar 2016 14:39:20 +0000
Subject: [PATCH 1/2] Add EGPRS header type 2 parsing function in uplink
In-Reply-To: <20160330201227.GK23309@nataraja>
References: <1459344522-15503-1-git-send-email-Bhargava.Abhyankar@radisys.com>
 <20160330201227.GK23309@nataraja>
Message-ID: <DM2PR0801MB09594380FA0B03E19F5D440F91990@DM2PR0801MB0959.namprd08.prod.outlook.com>

Hi Harald,

On Thurs, Mar 31, 2016 at 1:45 AM, Harald Welte wrote :
> unfortunately your patch doesn't apply on current master, please re-base and re-submit

As suggested by you, I have re-based and then re-submitted the patches.

Regards
Bhargava Abhyankar



From holger at freyther.de  Thu Mar 31 17:55:43 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 31 Mar 2016 19:55:43 +0200
Subject: ANN: https://patchwork.osmocom.org
Message-ID: <F68DFF5A-B476-4132-BA2E-18558EFA6B21@freyther.de>

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