<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Thanks very much for your advice. <div><br><div>I've done the pcap IP-catching, printed out flow-control information of openbsc, excluded the RF problem, </div><div>and checked the layer3 singals with TEMS tools. <br><div>Nothing abnormal was found.(Or maybe there was something, but I have not noticed). </div><div>It just seems suddenly nothing is flowing in and out nanobts for a while. </div><div><br></div><div>After all of that, I replaced the nanobts (software version: 168d502, aquired with ipaccess-find) with another </div><div>nanobts (software version: 168a302). <span style="font-size: 12pt;">The data rate problem never appeared. </span></div><div>However, I ran into another problem occasionally, which has not occurred before. After printing following logs, nanoBTS auto-restarts/reconnects <span style="font-size: 12pt;">with OpenBSC, and thus causes network interruption. </span></div><div><br></div><div>----- Logs ----</div><div>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</div><div><span style="font-size: 12pt;"> </span></div><div>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</div><div><span style="font-size: 12pt;"> </span></div><div>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</div><div><span style="font-size: 12pt;"> </span></div><div>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 </div><div>----------</div><div><br></div><div>At this point, I'm wondering if openbsc has some compatible problems with nanoBTS sw?</div><div>Has any body run into this, and what's your sw version of nanoBTS?</div><div><br></div><div><br></div><div><div>> Date: Thu, 5 Nov 2015 10:13:53 +0100<br>> From: laforge@gnumonks.org<br><br>> You are running a complex setup (a GSM/EGPRS network), and there can be<br>> many reasons.<br>> <br>> * Have you excluded RF interference? In order to do that, you could<br>> connect your EGPRS capable MS over coaxial cable, duplexer and<br>> attenuators directly without any antenna to the BTS. This way you<br>> exclude any RF side interference. you also exclude the possibility<br>> that any other phones not part of your test setup are meanwhile<br>> attempting to register or use services of the network<br>> </div><div>> Next point is to obtain protocol traces (pcap) with synchronized<br>> time-stamps on<br>> * the MS side (the IP you get out of your MS)<br>> * the Gb side betwene BTS and SGSN<br>> * the IP side of the GGSN<br>> <br>> Recording those pcap files and looking at what happens where in the<br>> timeline can be very useful.<br>> <br>> * Have you studied the protocol traces on the Gb level? Looking at them<br>> it should be easy to determine if flow control was an issue at the<br>> time you experience low througput.<br>> <br>> * Have you studied the IP level protocol traces on MS side or on the<br>> GGSN side? What does a TCP sequence number / RTT analysis give you<br>> for those traces? When are packets lost?<br>> <br>> * you could use OsmocomBB + bust_ind + gprsdecode to obtain<br>> air-interface protocol traces to further analyze that interface.<br>> <br>> * finally, the nanoBTS telnet debug interface might be of help to<br>> provide you some insight into what is happening in the (closed source)<br>> PCU at the time you experience problems.<br>> <br>> -- <br>> - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/<br>> ============================================================================<br>> "Privacy in residential applications is a desirable marketing option."<br>> (ETSI EN 300 175-7 Ch. A6)<br></div></div></div></div> </div></body>
</html>