Hi,
my clean-ups are not done but there is a basic structure now that can be refined. I started to add statistics to the BTS (and then will add statistics per tbf but they are short lived so one would need to be quick to see them).
E.g. in tbf_free we are freeing still pending llc_frames and I assume that these are related to the "Killing pending DL TBF" and others. I am wondering why:
* there is no indication to the SGSN for dropped frames/octets? * can't the DL-TBF be re-associated/updated after the assignment is done again?
holger
Holger Hans Peter Freyther wrote:
- there is no indication to the SGSN for dropped frames/octets?
- can't the DL-TBF be re-associated/updated after the assignment is done again?
hi holger,
there is one issue about failed downlink TBF: the PCU does not do any retry. when the assignment is sent to the phone and it fails, there is no retry according to the specs. i assume that this is a task for the SGSN. osmo-sgsn/openggsn does not resend any LLC frame in case of LLC-DISCARDED message, if i look at the source code of libosmogb. (LLC-DISCARDED is forwarded at bssgp_rx_llc_disc() of gprs_bssgp.c, but i don't see where it is handled.)
what actually happens is that TCP layer will do the resend, but this is a problem, especially at the border of coverage where many downlink assignments get lost.
i have once enabled the debugging at ipaccess BTS and saw that the PCU itself does the retry of lost downlink assignments (4 or 5 times).
regards,
andreas
On Tue, Nov 05, 2013 at 07:55:29AM +0100, Andreas Eversberg wrote:
dear andreas,
as usual there is more than one dimension to this problem.
1.) Dropping LLC data with no indication. When trying to understand a problem (e.g. Samsung3 traffic stalls) one needs to analyze what is going wrong. The "contract" for the SGSN/PCU is that a LLC frame will be either forwarded to the MS or a discarded message will be sent (frames, octets, etc..).
BUT with the current code this contract is broken. One simply can not know if the LLC frame has actually reached the phone...
2.) Retry or not to retry.
there is one issue about failed downlink TBF: the PCU does not do any retry. when the assignment is sent to the phone and it fails, there is no retry according to the specs. i assume that this is a task for the SGSN. osmo-sgsn/openggsn does not resend any LLC frame in case of LLC-DISCARDED message, if i look at the source code of libosmogb. (LLC-DISCARDED is forwarded at bssgp_rx_llc_disc() of gprs_bssgp.c, but i don't see where it is handled.)
Well, retry or not to retry is an architectural decision. The question is what to do with the frames we are discarding?
(just ignore my last mail. somehow i hit the wrong key...)
hi holger, hi harald,
i looked at the TS 08.18. the LLC-DISCARDED.ind message does not contain any reference to the frame(s) that has been discarded, so SGSN cannot resend specific frames that are dropped. also a resend does not seem to be specified. it is task of the PCU to be sure to deliver LLC frame.
during a downlink TBF, lost downlink blocks are resent by the RLC/MAC protocol, but assignment is not. (at least not correctly)
here is my suggestion: if assignment fails, the PCU should resend downlink TBF assignment several times. the number of retries should be a config option. it may happen that the assignment on PACCH fails, while the MS is in packet transmode. if the MS switches back to packet idle mode in the meantime, the retry must be performed on AGCH. it may also happen that the assignment on AGCH fails because the MS is establishing an uplink TBF. if this happens, the retry must be performed on PACCH. if the number of maximum retries is reached, the LLC frame (or list of) should be discarded and the an LLC-DISCARDED.ind message should be sent to SGSN.
regards,
andreas
On Thu, Nov 07, 2013 at 08:35:49AM +0100, Andreas Eversberg wrote:
i looked at the TS 08.18. the LLC-DISCARDED.ind message does not contain any reference to the frame(s) that has been discarded, so SGSN cannot resend specific frames that are dropped. also a resend does not seem to be specified. it is task of the PCU to be sure to deliver LLC frame.
Thanks for your research and analysis.
Hi Andreas,
On Tue, Nov 05, 2013 at 07:55:29AM +0100, Andreas Eversberg wrote:
there is one issue about failed downlink TBF: the PCU does not do any retry. when the assignment is sent to the phone and it fails, there is no retry according to the specs. i assume that this is a task for the SGSN. osmo-sgsn/openggsn does not resend any LLC frame in case of LLC-DISCARDED message, if i look at the source code of libosmogb. (LLC-DISCARDED is forwarded at bssgp_rx_llc_disc() of gprs_bssgp.c, but i don't see where it is handled.)
what actually happens is that TCP layer will do the resend, but this is a problem, especially at the border of coverage where many downlink assignments get lost.
I'm not sure if I'm mixing up things, but we have three potential protocol layers that can take of reliable delivery:
1) the RLC/MAC layer between PCU and MS 2) the LLC protocol 3) the TCP layer inside user IP
On Tue, Nov 05, 2013 at 07:55:29AM +0100, Andreas Eversberg wrote:
dear andreas,
as usual there is more than one dimension to this problem.
1.) Dropping LLC data with no indication. When trying to understand a problem (e.g. Samsung3 traffic stalls) one needs to analyze what is going wrong. The "contract" for the SGSN/PCU is that a LLC frame will be either forwarded to the MS or a discarded message will be sent (frames, octets, etc..).
BUT with the current code this contract is broken. One simply can not know if the LLC frame has actually reached the phone...
2.) Retry or not to retry.
there is one issue about failed downlink TBF: the PCU does not do any retry. when the assignment is sent to the phone and it fails, there is no retry according to the specs. i assume that this is a task for the SGSN. osmo-sgsn/openggsn does not resend any LLC frame in case of LLC-DISCARDED message, if i look at the source code of libosmogb. (LLC-DISCARDED is forwarded at bssgp_rx_llc_disc() of gprs_bssgp.c, but i don't see where it is handled.)
Well, retry or not to retry is an architectural decision. The question is what to do with the frames we are discarding?
osmocom-net-gprs@lists.osmocom.org
-
Andreas Eversberg -
Harald Welte -
Holger Hans Peter Freyther