27 Oct
2013
27 Oct
'13
12:12 p.m.
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 Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
5 Nov
5 Nov
7:55 a.m.
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
9:01 a.m.
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?
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
7 Nov
7 Nov
8:35 a.m.
(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
8:50 a.m.
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5 Nov
5 Nov
5:41 p.m.
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
7 Nov
7 Nov
7:44 a.m.
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?
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
3830
days inactive
3841
days old
osmocom-net-gprs@lists.osmocom.org
6 comments
3 participants
participants (3)
-
Andreas Eversberg -
Harald Welte -
Holger Hans Peter Freyther