On Fri, Jan 24, 2014 at 10:59:51AM +0100, Sipos Csaba wrote:

Hi Holger,

Hi!

I need to choose a device for educational purposes, that is capable for packet data with OpenBSC/OpenBTS. This will going to extend our current 2G setup which currently has 3 Nokia Site family units with OpenBSC.

It all depends and being associated with sysmocom i am biased too. SDRs provide the greatest flexibility but unless you have specific RF filters in your frontend you will not pass the harmonized norms of the European Union for GSM. sysmoBTS has a closed source DSP/FPGA image/bitmask. This means you can't easily look at the channel coding/burst creation. So there is reduced flexibility. The benefit is that a single unit can host BTS+PCU+NITB. nanoBTS is a completely closed source product. Their GPRS stack has reliability issues and they try to hide things (e.g. changing the password for their telnet interface). There is no flexibility.

Correct?

On Fri, Jan 24, 2014 at 09:29:21PM +0100, Peter Stuge wrote:

...

nanoBTS is a completely closed source product. Their GPRS stack has reliability issues

Just a note that I've heard that nanoBTS GPRS is perfectly reliable with the ipaccess BSC. I haven't seen it myself though. Maybe some day there will be some analysis of what is actually different.

I can say that this is not true. The 'ipaccess BSC' is a narrow definition and would just include the messages sent by OML to configure the BTS but even in the broader sense of using 'ipaccess' only software it is not true. holger

Holger Hans Peter Freyther wrote:

...

...

nanoBTS is a completely closed source product. Their GPRS stack has reliability issues

Just a note that I've heard that nanoBTS GPRS is perfectly reliable with the ipaccess BSC. I haven't seen it myself though. Maybe some day there will be some analysis of what is actually different.

I can say that this is not true.

I've seen nanoBTS behaving very inconsistently so I'm not excluding that there are some circumstances in which they actually do work reliably, since I have no reason to doubt what I heard about them working fine together with the ipaccess software. But in any case, a detailed analysis of what is really going would be neccessary in order to potentially make them equally reliable with OpenBSC and I would personally much rather use a sysmoBTS and spend that time on other things. :) //Peter

On Sat, Jan 25, 2014 at 12:39:39PM +0100, Sipos Csaba wrote: Hi again,

So there is only GPRS support at the moment, no EDGE. Do you guys have a plan for EDGE? To be clear I am not demanding anything, just kindly asking :-)

The answer is complicated. The current PCU code is not really good and we at sysmocom are the only ones changing that. I am keeping a TODO in the osmo-pcu code and post status reports to the PCU mailinglist from time[1] to time. The current agenda is: * Re-factor code so it can be unit-tested and write tests * Optimize bandwidth usage * Dynamic CS mode switch After this we will support EDGE (in a non-mixed mode config). The structure will not change that much when EDGE is added. The window handling is more dynamic (dl/ul size can be dynamically decided), more codec schemes, new CSN1 messages.

Can someone enlighten me about the current limitations of the GPRS stack?

Please have a look here[2].

For example: what are the slot configuration (or GPRS class) limitations? I am not interested in voice calls so my plan is to configure one (or maybe more than one) TRX with just PDCH channels to gain as much PD bandwidth as much as possible.

Can I use more than one downlink or uplink channels if my terminal is capable of doing that?

The current allocator can assign multiple downlink slots. It will assign only a single uplink though. The bad part is that the same uplink slot will be assigned for all phones. The more phones you have the more problems you will get. E.g. to ACK the TCP frame all phones compete for the same uplink resource.. while all other PDCHs have no uplink usage... It is just one example of the problem space one has to deal with in GPRS/EDGE PCU. cheers holger [1] http://lists.osmocom.org/pipermail/osmocom-pcu/2014-January/thread.html [2] http://openbsc.osmocom.org/trac/wiki/osmo-pcu#Status

On Sun, Jan 26, 2014 at 11:20:25AM +0100, Sipos Csaba wrote:

Is there a plan to change that one behavior (only one UL slot)?

Sure, but talk is cheap. In general one UL slot is just fine, the main issue is that all phones will compete for the same uplink slot.

After browsing the code for a few days, it is clear that currently the main stage of development is the PCU and around packet access in general. And I think a lot of people are interested about your work, but except this mailing list, it is really hard to see that, or find infos. This is why I am keep telling you that a blog or a priority list or something on the site would be important to raise awareness.

In terms of the osmo-pcu my primary goal is to add architecture to the code, to be able to write unit tests and improving the general quality (e.g. when Daniel and me did this on the assignment algorithm we found defects, shortcomings, limitations...) and we still need to do this throughout the code. In terms of blogs. What we really need are people that want to do engineering and want to work on some harder problems. In general this can be either through: a.) Student projects that are mentored by sysmocom b.) More purchases of BTS by customers that want GPRS so we can dedicate more resources to the work on the PCU by an engineers. c.) Dedicated projects on GPRS/EDGE to improve it. cheers holger PS: Make sure to look at the sysmocom/master branch of the osmo-pcu

On Mon, Jan 27, 2014 at 12:55:31AM +0400, Alexander Chemeris wrote:

At this moment we (Fairwaves) are busy with fixing bugs and improving the CS part of NITB (calls and SMS), but I hope we'll get back to GPRS as we get more customers demanding it. As usual, one can support this

Ah that is great news. Do you mind sharing with the community which defects you are experiencing? cheers holger

Hi,

Then, there is an issue with OsmoBTS when there are too many phones are trying to connect to it for LUR. I described this a while ago, but we haven't had time to look more into it yet. So far we just used various workarounds to solve it. We're looking into writing a BS power reduction algorithm, similar to the one used in OpenBTS - If there is a severe congestion for LU's, BS will reduce its power until the load doesn't stabilize. Then it'll slowly increase the power again, until it hits the LU congestion or hits the maximum specified power.

Sure that this is a good idea? It will throw out all users at the edge of the coverage area, maybe cause even more load, when those show up again with their accumulated requests like call attempts, SMS, additional LU, and in fact I have never seen that commercial networks do something like that. Is there not some waiting queue defined in the standards, with some timers, commanding the location updaters to wait for some period of time? Has been a long time when I looked into this, but I mean to remember that even OpenBTS does it this way. Or am I totally wrong?

Hi,

This is for the initial startup of a cell and for a situation of a sudden influx of a huge number of phones. In a normal situation you should not have RACH channel saturated and thus this mechanism is not triggered,

It is a very common situation that for example a train with a few hundred phones enters the tunnel area what is connected to a different location area, and all those phones want to perform a location update. Happens not far from my home every few minutes, for almost 20 hours per day, for about ten years now :) Btw., OpenBTS seems to handle this quite well, I had the situation of about 60 phone jumping onto my poor little USRP1/WBX cell, and I mean to remember that even the console output showed the queue handling. So I am not sure if such a measure like reducing the power would be useful at all in whatever scenario. Commercial systems that I monitored after breakdowns or maintenance shutdowns just came back again with full power, it all sorted out itself within short time. Among them were cells near airports or heavily crowded roads and pedestrian areas. I wonder if we see a problem where in fact there isn't one at all.

-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

Ralph.

It’s not normal operation. It is an emergency measure that takes effect with the network is in a hopeless congestion condition. And in my experience, this approach changes the recovery time from several hours to several minutes.

About what numbers of phones are we talking here to reach a critical mass? Usually a phone transmits two or three access bursts, then it waits for a while, and I mean to remember some slotted aloha scheme, or similar. I hardly can imagine that such a condition could last for_hours_, but of course the real word sometimes offers bad surprises :) Ralph.

On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther <holger@freyther.de> wrote:

SDRs provide the greatest flexibility but unless you have specific RF filters in your frontend you will not pass the harmonized norms of the European Union for GSM.

I think this statement is quite dated. A calibrated USRP N200 running osmo-trx passes RF spectrum and modulation accuracy requirements of 3GPP 05.05 by very large margins and is competitive with commercial GSM equipment in this regard. Other SDR devices are also capable to varying degrees. -TT

On Mon, Jan 27, 2014 at 7:49 AM, Holger Hans Peter Freyther <holger@freyther.de> wrote:

On Sun, Jan 26, 2014 at 06:29:00PM -0500, Tom Tsou wrote:

...

On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther <holger@freyther.de> wrote:

...

SDRs provide the greatest flexibility but unless you have specific RF filters in your frontend you will not pass the harmonized norms of the European Union for GSM.

I think this statement is quite dated.

Ah cool. Can you point me to papers/text showing how the n-th harmonic is being removed from the spectrum?

N-th harmonic of what? For the N200, The GSM baseband signal goes through a number of conversions and filtering stages on the host, FPGA, and DAC chip before reaching the converter at an interpolated rate of 400 Msps. There is 40 MHz of filtering on the WBX daughterboard, which removes aliasing from the DAC output. The older RFX900 daughterboard does have a filter on the front end, however, the performance is worse than the WBX in almost every measure. More recent devices are based on flexible integrated RF chips from Analog Devices and Lime Micro that were specifically designed for commercial 3G and 4G systems. I find it hard to believe that these SDR products are not capable of passing international compliance requirements for GSM.

The policy of FCC vs. European Union is quite different. There are more norms that apply in Europe.

Certain USRP products, notably the National Instruments variants, are CE tested and certified according to applicable European directives for which the product is sold. I am certainly not an expert in the area of compliance, but I assume this certification does not extend to operation of a GSM base station as the product is not sold as such. That brings up the point that for USRP type devices, the user is purchasing a piece of test equipment and not a BTS and is therefore responsible for meeting any subsequent application requirements. This contrasts with nanoBTS or sysmoBTS, which are fixed use GSM products and the burden of compliance lies with the supplier. For users who are concerned about compliance, the classification of the device is probably a larger issue than whether or not the device is technically capable of passing compliance norms. -TT

On Tue, Jan 28, 2014 at 3:49 AM, Ralph A. Schmid, dk5ras <ralph@schmid.xxx> wrote:

...

N-th harmonic of what?

Of the RF carrier. I guess there will be some harmonics, and I will have a look what my WBX produces if you are interested.

Note that the USRP1-WBX combination does not support LO offset or IQ imbalance compensation; those factors will be your largest source of overall signal distortion. In regards to the harmonic distortion, it seems that the concern is over spurious free dynamic range (SFDR) of front end components, which is more of an issue of wideband RF design than SDR in general. Similar issues can exist in any wireless system - SDR or not.

...

More recent devices are based on flexible integrated RF chips from Analog Devices and Lime Micro that were specifically designed for commercial 3G and 4G systems. I find it hard to believe that these SDR products are not capable of passing international compliance requirements for GSM.

Usually there is even for those low power applications some passband filter in the output path.

I will certainly not deny that spurious signals exist in USRP-type boards or that passband filters are used in commercial products. My only issue is the claim that a narrow tuning range limited by front end filters is a mandatory requirement for suitable spectrum compliance. A huge number of frequency bands is required by current and future wireless services and attaching a fixed RF filter for every individual band in use is not a sustainable approach. There has been a very significant amount of development in flexible RF design over the past decade in order to address these issues, which I do not think should be ignored. -TT

On Wed, Jan 29, 2014 at 2:23 AM, Ralph A. Schmid, dk5ras <ralph@schmid.xxx> wrote:

Of course, this is true, but do not forget the strong signals that come backwards, from other transmitters at a populated antenna site. Those can do nasty things in the PAs, so some filters and isolators can hardly be eliminated. A high power wideband system out in the wild is another beast than hooked to your lab setup.

I don't think myself or anyone else was ever implying that *all* front end filtering should be eliminated. Surely, if one is operating a high power transmitter at a populated side, then appropriate precautions would be in order. We've drifted very far off-topic at this point. I have nothing else to add. -TT

Hi Sipos, On Fri, Jan 24, 2014 at 1:59 PM, Sipos Csaba <dchardware@gmail.com> wrote:

For GPRS/EDGE to work I need to choose from the following HW:

- USRP2 (I also heard that USRP1 has timing problems, but as I know, these problems are fixed in USRP2 and the networked series?) - UmTRX - BladeRF (according to them, they are quite close to running OpenBTS) - SysmoBTS - NanoBTS

Correct?

In general, my personal comparison is like that (in random order, not in the order of preference): - Get USRP N (not USRP 2), if you want to have access to variety of daughter boards, available for USRPs. Though it's quite expensive, especially if you add a GPSDO to it. - Get UmTRX if you want a device which is smaller and cheaper than USRP N and with 2 channels and embedded GPS. Though you'll need to take care of enclosure by yourself. - You can also get UmTRAY or UmDESK, but they are more expensive. - Get USRP B200, if you want a small single-channel device. Though you _may_ have issue if you start playing with handover, as it doesn't have GPS or a stable enough reference clock. - Get BladeRF if you like debugging. :) Though you _may_ have issue if you start playing with handover, as it doesn't have GPS or a stable enough reference clock. - Get SysmoBTS if you want an all-in-one device which you could run without a laptop. Though it's single-channel can't support multi-ARFCN. Also be prepared that it has ARM inside, which adds some fun to the development process. - NanoBTS? Why would you ever want that?

I am more convinced to buy an SDR like device, because we can use that for other stuff too. But if you are telling me, that for example SysmoBTS or NanoBTS runs the GRPS stack better, compared to UmTRX or USRP2, than I can respect that.

In terms of GPRS all these devices have the same capabilities, since they share the same PCU/SGSN/GGSN code. EDGE is not supported by PCU and thus can't work on any of these devices. SysmoBTS and NanoBTS has lower levels of EDGE implemented, since they use some proprietary code or that, so they are little bit closer to having EDGE. All of the other devices are fully capable of EDGE in terms of hardware, but there is no software support for that.

I also want to ask one more time, if it is possible to run multiple TRXes on one SDR like device which has enough processing power and bandwidth? Did someone already tried this? Or it is not even possible?

UmTRX has two independent TRXs and we use it in dual-TRX mode in all our installations. All of the SDR devices mentioned above are technically capable of running in the Multi-ARFCN mode. OsmoTRX has support for that, but no one has tested it with OsmoBTS/OsmoNITB yet. IIRC, SysmoBTS is single channel only. Holger could correct me if I'm wrong. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

Matt, On Fri, Jan 24, 2014 at 9:15 PM, Matt Ettus <matt@ettus.com> wrote:

I normally resist talking about our own products on this list, but since there is some incomplete information I will offer some corrections. I won't speak to competitor's products.

Thank you for more details, this is appreciated.

...

- Get USRP N (not USRP 2), if you want to have access to variety of daughter boards, available for USRPs. Though it's quite expensive, especially if you add a GPSDO to it.

These are the highest dynamic range and will have the best RF performance.

...

- Get USRP B200, if you want a small single-channel device. Though you _may_ have issue if you start playing with handover, as it doesn't have GPS or a stable enough reference clock.

A GPSDO is available for B200, or you can use the 10 MHz input from an external source. The B200 is by far the lowest cost option, and it has a high dynamic range in comparison to Lime-based solutions. If you want diversity receive and dual transmit, you can get the B210 which is also a low cost option.

This is all correct. I just want to point that dual-channel with B210 is not (yet) supported by osmo-trx, so one will need a little bit of effort to run it in dual-TRX mode. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru