This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sipos Csaba sipos.csaba at kvk.uni-obuda.huHi, > After printing following logs, nanoBTS auto-restarts/reconnects with OpenBSC, and thus causes network interruption. This is probably cause the management software is also trying to use the same OML interface which OpenBSC already using to comunicate with the BTS. If I recall correctly nanoBTS can be set to have two OML interfaces up, one can be used with the BSC, and the other one can be used with the management software. Of corse if you performing tests which are affecting the radio or signalling parts of the BTS, you will abviously loose the connection temporarily with the BTS. Regards, Csaba ----- Eredeti üzenet ----- Feladó: "wangpalm" <palm.wang at hotmail.com> Címzett: "Harald Welte" <laforge at gnumonks.org> Másolatot kap: openbsc at lists.osmocom.org Elküldött üzenetek: Péntek, 2015. November 20. 9:49:00 Tárgy: RE: EGPRS(EDGE) data rate is not stable? 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 at 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 at gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)