EGPRS(EDGE) data rate is not stable?

historical

On Wed, Oct 14, 2015 at 08:46:08AM +0800, wangpalm wrote:
> With phone attached to my configured EGPRS, sometimes it has a data
> rate around 200kbps (which is near optimal), while frequently it has a
> intolerablly slow data rate.  Is it a common problem, or it's due to
> incorrect configrations or hardware problems?    I run a gsm test
> system with nanobts, and the libosmocore, openbsc, openggsn codes are
> based on the version around end of April 2015. The configuration is
> made accorrding to the instruction from openbsc web. The correction in
> fc_queue_timer_cfg has also been made according to Jacob Erlbeck.

You are running a complex setup (a GSM/EGPRS network), and there can be
many reasons.

* Have you excluded RF interference?  In order to do that, you could
  connect your EGPRS capable MS over coaxial cable, duplexer and
  attenuators directly without any antenna to the BTS.  This way you
  exclude any RF side interference.  you also exclude the possibility
  that any other phones not part of your test setup are meanwhile
  attempting to register or use services of the network

Next point is to obtain protocol traces (pcap) with synchronized
time-stamps on
* the MS side (the IP you get out of your MS)
* the Gb side betwene BTS and SGSN
* the IP side of the GGSN

Recording those pcap files and looking at what happens where in the
timeline can be very useful.

* Have you studied the protocol traces on the Gb level?  Looking at them
  it should be easy to determine if flow control was an issue at the
  time you experience low througput.

* Have you studied the IP level protocol traces on MS side or on the
  GGSN side?  What does a TCP sequence number / RTT analysis give you
  for those traces?  When are packets lost?

* you could use OsmocomBB + bust_ind + gprsdecode to obtain
  air-interface protocol traces to further analyze that interface.

* finally, the nanoBTS telnet debug interface might be of help to
  provide you some insight into what is happening in the (closed source)
  PCU at the time you experience problems.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)