21 Sep
2015
21 Sep
'15
12:30 p.m.
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(a)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