TBF acknowledged mode is now working

Andreas Eversberg andreas at eversberg.eu
Thu Jul 5 18:04:43 UTC 2012


Ivan Kluchnikov wrote:
> 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?
hi ivan,

the reason is that i need to find out when an uplink control bock is not 
received. this is required to handle counters on dropped frames. the 
problem is, that i did not yet manage to get bad frame indications. in 
order to have a quick workarround, i use gsm time indications. these 
indications are sent in advance of about 10 frames. after 20 frames i 
can be sure that the frame has not been received. using rts message 
would be possible too, but since i cannot be sure how much earlier they 
are sent, i cannot define how many frames i have to wait until timeout. 
if openbts uses an exact definition of how much earlier the rts messages 
are sent. if you look at gprs_rlcmac_poll_timeout(), you will see that i 
wait 20 frames. if rts message would be sent 52 frames in advance, then 
you should use wait something like 60. (add 10 to avoid jitter).
> 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?
yes, i agree that we should coordinate it. my current plans are:

- cleanup of debugging levels: (LOGL_DEBUG=full processing, 
LOGL_INFO=just infos about complete frames, LOGL_NOTICE=abnormal 
timeouts, invalid data and protocol errors, LOGL_ERROR=local errors, 
software errors. (i have already done this, but not yet committed.)
- replace hand-hacked/wireshark transcoding of control blocks by 
generated code from encodix. (i will to try this tomorrow.)
- changing from c++ back to c. (only possible after replacing the 
wireshark code.)
- multislot support.


i also agree with alexander's comment on splitting the commits. 
(especially the support of cell information from socket interface.) i 
can do that and provide seperate patches to this list tomorrow. 
sometimes it is hard to implement new features without doing cleanups at 
the same time, since i don't know what have to be cleaned in order to 
make the new feature work. instead i work on the feature and clean at 
the same time. (like replacing all hardcoded values by the cell 
information from the socket interface (or maybe from config file, one 
day).)


regards,

andreas






More information about the osmocom-net-gprs mailing list