hi,
while reading l1_if.c, i found it usefull to move the ready-to-send-req handling to gprs_rlcmac.cpp, because composing of data block (or idle blocks) should be done when they are about to be sent and not stored in a queue for the following reasons:
- USF can be controlled close to the time when the block is transmitted. - acknowledged RLC would require that, it can react directly on acknowledgements and select the right packet. - LLC frames can be flushed by SGSN, so transmission stops immediately. - QoS / control blocks can be scheduled more adequate.
for now, i think it is ok to keep the send-queue, but move it to gprs_rlcmac.cpp. later the queue should be obsolete, if segmentation is performed "just in time", as well as uplink control. a queue should be used for LLC frames _before_ segmentation.
any complains/suggestions? if not, i would provide a patch for that.
regards,
andreas
Andreas,
On Mon, Jun 18, 2012 at 9:19 PM, Andreas Eversberg andreas@eversberg.eu wrote:
while reading l1_if.c, i found it usefull to move the ready-to-send-req handling to gprs_rlcmac.cpp, because composing of data block (or idle blocks) should be done when they are about to be sent and not stored in a queue for the following reasons:
- USF can be controlled close to the time when the block is transmitted.
- acknowledged RLC would require that, it can react directly on
acknowledgements and select the right packet.
- LLC frames can be flushed by SGSN, so transmission stops immediately.
- QoS / control blocks can be scheduled more adequate.
for now, i think it is ok to keep the send-queue, but move it to gprs_rlcmac.cpp. later the queue should be obsolete, if segmentation is performed "just in time", as well as uplink control. a queue should be used for LLC frames _before_ segmentation.
any complains/suggestions? if not, i would provide a patch for that.
Logic looks reasonable for me. If Ivan doesn't see any pitfalls, I'm ok with this.
osmocom-net-gprs@lists.osmocom.org