Re: [Openbts-discuss] GPRS issues with 5.0

[Ralph A. S. d. <ra...@sc...>]

Hi,

I can confirm your topic 3 with all kinds of hardware, USRP1, BladeRF, RAD1/SDR1. Will get an Ettus B210 soon, then I can see how this one behaves. 

Ralph.


> -----Original Message-----
> From: Sipos Csaba [mailto:dch...@gm...]
> Sent: Monday, 25 August, 2014 23:45
> To: ope...@li...
> Subject: [Openbts-discuss] GPRS issues with 5.0
> 
> Hi all,
> 
> I just wanted to highlight some problems with GPRS and OpenBTS 5.0:
> 
> 1. This is not related to GPRS, but it seems that the release_003_007_002 UHD code is braking OpenBTS (5.0). The symptoms are MSs
> having a hard time to camp, sometimes after camping on the network it is completely not possible to send sms, initiate voice calls
> etc. After reverting to UHD code release_003_007_001, all of these problems are gone. Moving back to the new code broke it again.
> 
> I don't know if someone besides me already noticed it, it would be nice if someone can confirm this. I am using latest master branch
> of OpneBTS (5.0) with an Ettus B200.
> 
> 2. Uplink and/or downlink TBFs being lost occasionally. During an ongoing FTP download, suddenly the transfer just stopped, when I
> did a "gprs list" query there was only downlink TBF listed for that MS, and on the spectrum analyzer there were no uplink traffic at all
> for 5-7 seconds. After that the uplink TBF is reinstated and the stalled FTP download continued.
> 
> It usually happens with the uplink TBF, but I have encountered situations, that during a download, downlink TBF is gone, the transfer
> stops for 1-2 seconds, then the downlink TBF is coming back, then the transfer continues. The only difference between loosing a
> downlink or an uplink TBF is that usually it takes much longer for a lost uplink TBF to be reinstated, so the transfer can continue.
> 
> 3. Continuous uplink transmission even if there is no higher layer traffic at all. I can see this behavior with a spectrum analyzer that
> sometimes even if I firewall all the traffic, the MS keeps transmitting something and eating up the uplink capacity. I encountered this
> with multiple different MSs. Maybe the uplink keepalive function is somehow generating this issue.
> 
> 4. Scheduling of multi-slot operation:
> when I set 4 PDCHs and a maximum of 4 slots for uplink and downlink, the MS only uses the 4/1 combination in favour of the
> downlink and this behavior not changes even if I only want to upload data.
> 
> What is more interesting, if I keep the 4 PDCHs and say use maximum 3 in the downlink and 2 in the uplink, the MS locks to 2/2
> channels. I am using Cat 10 MSs and tried many combinations but I was not able to achieve 3/2 combination which would be the
> best. I was able to get 2/2 and 4/1. I also tried with 3 PDCHs and 3/2 max config, but still the MS uses 2/2.
> 
> I am conducting these tests on a completely clean ARFCN with a duplex filter and a 6dB 900/1800 antenna and the MS is 1m away
> with clear line of site. The BTS is an Ettus B200.
> 
> Any help or suggestion is very welcome.
> 
> I am also happy to try anything, do any sort of debugging if someone can set me on the right corse.
> 
> Regards,
> Csaba
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Openbts-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss