This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Ivan Kluchnikov Ivan.Kluchnikov at fairwaves.ruHi, Andreas! I reviewed your implementation of TBF acknowledged mode and it is a great work! I modified implementation of L1 interface for OpenBTS and we have done some tests. Can you explain, what is the reason of using Time Indication message? As I understand, we use only frame number from this message and call gprs_rlcmac_poll_timeout() function. But when we receive Ready To Send message, we also receive frame number, so why we couldn't use that FN for our purpose and call gprs_rlcmac_poll_timeout() in function, which handling ReadyToSend message? I think for maintain compatibility with different BTS implementations, it is better to use only L1 primitives, which specified in 03.64 Chapter 6.5.3 and Time Indication primitive is not described there. Now I think, it makes sense to merge your branch with master, but we should coordinate this process. When it is better to merge it? Do you plan to make some more fixes, modifications and cleaning of the code at this stage? I believe, for better understanding of further development of the project we should coordinate our efforts and discuss, what should be implemented in the next steps. What plans of development do you have now? 2012/7/3 jolly <andreas at eversberg.eu> > hi, > > finally the TBF acknowledge mode works in up- and downlink. i have > tested it with attachment/detachment and routing area update. changes > are commited to jolly branch. > > don't be shocked, but there great changes to previous gprs_rlcmac.cpp > code. it is split into three sources: > - gprs_rlcmac.cpp: general functions to handle TBF instances, > hand-hacked codings > - gprs_rlcmac_data.cpp: handling of uplink and downlink TBF > - gprs_rlcmac_sched.cpp: scheduler to handle ready-to-send requests. > > during packet idle mode, assignment of up- or downlink TBF is performed > using IMMEDIATE ASSIGMENT on AGCH. during TBF uplink, downlink > assignment is performed using PACKET DOWNLINK ASSIGNMENT on PACCH. after > TBF downlink, further downlink assignment is performed using PACKET > DOWNLINK ASSIGNMENT. during TBF downlink, uplink assignment is performed > using PACKET UPLINK assignment. this way an attachment / RA update / > detach will complete while staying in packet transfer mode, so no > further assignment must be done on AGCH. > > the acknowledged mode keeps states about transmitted and received > blocks, so unreceived or unacknowledged block are retransmitted as > defined in TS 04.60. downlink RLC/MAC data and control blocks are not > queued, but generated at ready-to-send request from layer 1. > > a scheduler is used to schedule next RLC/MAC block. it uses round-robin > scheduling, if more than two flows are active in one direction. in > downlink direction, control blocks are prioized. in uplink direction, > polling of mobile is priorized. (USF is set to apply uplink ressource to > MS.) only one timeslot (first PDCH) is used to share the ressources, > currently. > > there is a short description (tbf.txt) about states and the process of > current code. > > in order to detect missing responses on polling MS, a > gprs_rlcmac_poll_timeout() function is called. layer 1 interface must > implement detection of missed polled uplink control blocks. there are > two ways to perform this: > - The received frame is bad (BFI). > - The GSM indicates that the block should have been already received. > currently pcu_l1_if.c is broken, because none of the detection above is > performed. > > best regards, > > andreas > > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20120705/4992f730/attachment.htm>