Padding patch and moving forward with EGPRS support/merge

Saurabh Sharan Saurabh.Sharan at radisys.com
Fri Mar 11 13:34:08 UTC 2016


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


More information about the osmocom-net-gprs mailing list