Current list of failures in the pcu

Holger Hans Peter Freyther hfreyther at sysmocom.de
Fri Dec 6 09:26:02 UTC 2013


Good Morning,

we at sysmocom continued to add structure/architecture to the PCU
code and started to systematically test the code (using something
as simple as ICMP ping/reply)

Observations:

* "alloc algorithm b" has little (3kbit/s) more bandwidth than just
  using the single slot assignment with CS4. There are also some
  open coverity issues about this multi slot code.

* Congestion is badly handled. When using a ping that creates IP
  fragments the LLC queue of the TBF gets so long that we expire
  half the IP fragments before sending them. This means the MS at
  the downlink never receives all the IP fragments of a PING.

  We played with the BSVC-FLOW-CONTROL parameters but they don't
  have any influence here. We have added counting of queue size
  and calculation of the average queue delay to the LLC class.

  One option is to drop packages based on the PDU lifetime and the
  current queue delay. 

  $ sudo ping -s 1800 -i 0.1 10.23.42.6
  (CS4, alloc-algorithm a) is enough to re-produce this issue.

* RLC V(Q) V(R) handling. It appears that after and before the
  refactoring the Received Block Bitmap (RBB) is wrongly encoded. The
  encode and decode are not compatible to each other (thanks to the
  architecture sysmocom is adding to the code this can now be unit
  tested!).

  So as soon as we don't receive a frame from the UL. The send window
  at the phone and the PCU is going out of sync.

  After making changes to the window we have also witnesses that on
  a fully received window V(Q) and V(R) were WindowSize away from
  each other.

 <0005> tbf.cpp:1579 UL DATA TFI=0 received (V(Q)=55 .. V(R)=60)
 <0005> tbf.cpp:1624 - BSN 60 storing in window (55..118)
 <0005> rlc.cpp:173 - Raising V(R) to 61
 <0005> tbf.cpp:1690 - Scheduling Ack/Nack, because 20 frames received.
 <0005> encoding.cpp:374 Encoding Ack/Nack for TBF(TFI=0 TLLI=0xfa45049d DIR=UL) (final=0) SSN=61
 <0005> encoding.cpp:408 - V(N): "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR" R=Received N=Not-Received

 This part might be something we broke but we will try to re-produce
 with a unit test.


We will continue to work on unit-testing the RLC window handling if
anyone outside sysmocom interested in getting a more stable PCU?


holger
 

-- 
- Holger Freyther <hfreyther at 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





More information about the osmocom-net-gprs mailing list