DL TBF abnormal release

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/OpenBSC@lists.osmocom.org/.

Sipos Csaba sipos.csaba at kvk.uni-obuda.hu
Mon Sep 21 19:10:16 UTC 2015


Dear Jacob,

I am using the laster master branch of Osmo-PCU. Last commit:

commit 7c8d39a67b7568cda38829c774ea541250f3142f
Author: Jacob Erlbeck <jerlbeck at sysmocom.de>
Date:   Mon Sep 7 14:04:56 2015 +0200

    poll: Count failed procedures

> The UE side log doesn't help much

After I gone through it the second time, thats what I tought too :-)

I added the extra log options to the pcu config and now try to reproduce the error. Will try and give you as much details as possible.

Regards,
Csaba

----- Eredeti üzenet -----
Feladó: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
Címzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
Másolatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elküldött üzenetek: Hétfő, 2015. Szeptember 21. 12:30:31
Tárgy: Re: DL TBF abnormal release

Dear Csaba,

which exact PCU version (git SHA stamp) are you using?

On 20.09.2015 21:15, Sipos Csaba wrote:
> 
> In the past I wrote a little script to test the PRACH stability of OpenBTS, which sends a single ping to the gateway address, waits until the session goes into idle, and then tries again. The goal is to generate as many PRACH as possible and check if there is a response.
> 
> I used this script and it turns out that around 1 out of every 20 requests the ping is not reaching the gateway, and the UE indicates an abnormal DL TBF release.
> 
> I attached the UE side log, so you can take a look.

The UE side log doesn't help much, as I cannot see much differences
between either case (even the time deltas before each
EVENT_GPRS_TBF_RELEASE are similar). It would be very helpful, if I had
the logging output of the PCU, e.g. by adding the following stanza to
the osmo-pcu.cfg file:

====
log file /tmp/pcu.log
  logging filter all 1
  logging color 0
  logging print extended-timestamp 1
  logging level all everything
  logging level rlcmac debug
  logging level rlcmacul debug
  logging level rlcmacdl debug
  logging level l1if info
  logging level bssgp debug
  logging level rlcmacdata debug
  logging level rlcmacmeas debug
  logging level rlcmacsched debug
  logging level pcu debug
====

> 
> During this issue there is no reasonable frequency nor timing variation indicated on the UE side.
> 
> What I noticed is the very high number of RLC resent and RLC restarted. After a few minutes of pinging, this is the result from the PCU:
> 
>  RLC Sent             :    18015 (0/s 0/m 0/h 0/d)
>  RLC Resent           :    17596 (0/s 0/m 0/h 0/d)
>  RLC Restarted        :    15669 (0/s 0/m 0/h 0/d)
>  RLC Stalled          :        0 (0/s 0/m 0/h 0/d)

This probably results from the dl-tbf-idle-time feature. When enabled,
the DL TBF is not closed after the last LLC frame. Instead the DL TBF is
kept open by sending LLC dummy commands at regular intervals. Each of
them creates a single RLC packet which is then resent in every free slot
with a low priority until the corresponding ACK is received. Note that
this rewrapping of the send buffer will not happen, when there is other
data to be sent (this is meant by 'low priority').

Regards

Jacob
-- 
- Jacob Erlbeck <jerlbeck at sysmocom.de>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte



More information about the OpenBSC mailing list