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/.
Jacob Erlbeck jerlbeck at sysmocom.deDear 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