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