I've done the pcap IP-catching, printed out flow-control information of openbsc, excluded the RF problem,
and checked the layer3 singals with TEMS tools.
Nothing abnormal was found.(Or maybe there was something, but I have not noticed).
It just seems suddenly nothing is flowing in and out nanobts for a while.
After all of that, I replaced the nanobts (software version: 168d502, aquired with ipaccess-find) with another
nanobts (software version: 168a302). The data rate problem never appeared.
However, I ran into another problem occasionally, which has not occurred before. After printing following logs, nanoBTS auto-restarts/reconnects with OpenBSC, and thus causes network interruption.
----- Logs ----
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24410:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 1
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24411:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 2
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24412:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 3
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24413:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 4
----------
At this point, I'm wondering if openbsc has some compatible problems with nanoBTS sw?
Has any body run into this, and what's your sw version of nanoBTS?
> Date: Thu, 5 Nov 2015 10:13:53 +0100
> From: laforge@gnumonks.org
> 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@gnumonks.org> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)