20 Nov
2015
20 Nov
'15
8:49 a.m.
Thanks very much for your advice.
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(a)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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)