GPRS, EDGE support

[Sipos Csaba]

Hi Guys,

I just wanted to ask a few questions about packet data
availability/support, because I did not find the specifics on the
site.

1. Is there a working GPRS/EDGE implementation in the moment? If not,
what is the plan or the state of the development process?

2. Which hardware should I buy, if I want to play with GPRS/EDGE? I am
thinking about USRP or BladeRF, but maybe there is a better
alternative. I am willing to spend more in order to get a more
future proof unit (for example: to have a unit which is capable of
doing EDGE if and when it is going to be supported).

3. This is not related to packet data. I wonder if I buy a USRP unit
, it is possible to configure and use one USRP device with more than one TRX?

In general, I think a lot of people are interested in packet data and
OpenBSC/OpenBTS, it would be nice to clarify these informations on the
site.

BR,
Csaba

[Don Fanning]

There has been a working GPRS stack for a while now:
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS

As for USRP or OpenBTS, I cannot comment upon having never used either
platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140123/0811a3f2/attachment.html>

[Sipos Csaba]

An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140123/0cd33e4f/attachment.html>

[Ralph A. Schmid, dk5ras]

OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.



Ralph.





From: openbsc-bounces at lists.osmocom.org [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Sipos Csaba
Sent: Thursday, 23 January, 2014 18:37
To: Don Fanning
Cc: openbsc at lists.osmocom.org
Subject: Re[2]: GPRS, EDGE support



Hi Don,



Thanks for the answer.



THe problem with nanobts that it is unaccessible, and even when it turns up on ebay, it costs a fortune.



I'd rather pay that fortune for an USRP or half that fortune for a bladerf, and I will have an SDR which I can use not only as a BTS.



So, at the moment GPRS/EDGE is only possible with nanoBTS? What about USRP or BladeRF running OpenBTS?



BR,

Csaba




There has been a working GPRS stack for a while now:

http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS



As for USRP or OpenBTS, I cannot comment upon having never used either platform.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140123/6c446aa9/attachment.html>

[Sipos Csaba]

An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140123/d230d25a/attachment-0001.html>

[Alexander Chemeris]

Csaba,

We use UmTRX routinely to develop GPRS code for OpenBSC and it works well.
I can't say much about other SDR equipment, but we have some timing related
bugs with USRP1 based devices of one of our customers.

Regarding the official OpenBTS GPRS code - we've never tried to run it, but
looking into the code, it lacks quite a few features the OpenBSC
implementation has.

Thanks for the info!
At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so
any hardware is OK for packet data which can run OpenBTS. That is good news.
Anyway, it is just an educated guess, but don't you think your problem
with GPRS is related to timing? My experience with real life networks
clearly shows that even a slight timing related problem or inaccuracy can
led to something like that.
My other experience is with R&S CMW500, which I used with a little
external antenna and encountered the same problem. After a few meters even
the voice calls started to drop with -60 RSSI. The reason was obvious: the
device lacks any filters on the input chain (it is designed for production
mode), and when all the received RF energy hits the receiver from all the
bands, it causes problems like that. And the packet data was way more
sensitive to this than voice calls. After installing proper filters, the
problem is gone.
BR,
Csaba
OpenBTS supports GPRS, but at least for me it does not work very
reliably, I consider this only a proof of concept. While voice/SMS range is
up to 200m, GPRS breaks down after 5m (!) distance, and the connection
stalls after a while, requiring a restart of OpenBTS. I am using an USRP1
with WBX board.
Ralph.

[Ralph A. Schmid, dk5ras]

Well, at least voice and SMS is not affected and works just great. GPRS uses only an open power control, no closed loop, maybe it has to do with this? At the moment I do not have other hardware for comparison, so digging deeper into this may be not so useful. The issue is discussed on the OpenBTS mailing list, with no clear results at the moment.

Ralph.



From: Sipos Csaba [mailto:dchardware at gmail.com]
Sent: Thursday, 23 January, 2014 22:01
To: Ralph A. Schmid, dk5ras
Cc: 'Don Fanning'; openbsc at lists.osmocom.org
Subject: Re[4]: GPRS, EDGE support



Thanks for the info!



At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so any hardware is OK for packet data which can run OpenBTS. That is good news.



Anyway, it is just an educated guess, but don't you think your problem with GPRS is related to timing? My experience with real life networks clearly shows that even a slight timing related problem or inaccuracy can led to something like that.



My other experience is with R&S CMW500, which I used with a little external antenna and encountered the same problem. After a few meters even the voice calls started to drop with -60 RSSI. The reason was obvious: the device lacks any filters on the input chain (it is designed for production mode), and when all the received RF energy hits the receiver from all the bands, it causes problems like that. And the packet data was way more sensitive to this than voice calls. After installing proper filters, the problem is gone.



BR,

Csaba




OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.



Ralph.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140124/4d283332/attachment.html>

[David A. Burgess]

Ralph -

I realize this is off topic, but if you have such severe range differences between CS and PS performance, it is probably a GPRS uplink power control configuration problem.

Note: I am no longer affiliated with Range Networks, just trying to be helpful.

? David

Post by Ralph A. Schmid, dk5ras
OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.
Ralph.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140124/6387b7d2/attachment.html>

[Ralph A. Schmid, dk5ras]

Yes, this also is my idea, but configuration of this is somehow difficult, and I do not get clear, reliable results from changing the parameters.



I have noticed that you're not a "Ranger" anymore; hopefully your broad knowledge is still available for the GSM world :)



Ralph.



From: David A. Burgess [mailto:dburgess at jcis.net]
Sent: Thursday, 23 January, 2014 23:01
To: Ralph A. Schmid, dk5ras
Cc: metro4; Don Fanning; openbsc at lists.osmocom.org
Subject: Re: GPRS, EDGE support



Ralph -



I realize this is off topic, but if you have such severe range differences between CS and PS performance, it is probably a GPRS uplink power control configuration problem.



Note: I am no longer affiliated with Range Networks, just trying to be helpful.



- David





On Jan 23, 2014, at 20:12, Ralph A. Schmid, dk5ras <ralph at schmid.xxx> wrote:





OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board.



Ralph.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140124/f76486fe/attachment-0001.html>

[Don Fanning]

Again, I can't speak to the USRP or BladeRF. OpenBTS is a completely
different project with a completely different scope. The projects share
very little of a common code base therefore I would consider it
incompatible as architecturally they are night and day. OpenBTS is a hack
of GSM protocol while OpenBSC is a emulation of the GSM/GPRS mobile network
infrastructure.

If I had to recommend available compatible hardware, I would suggest
community based hardware like Harald's own sysmoBTS or Alexander's UmTRX.

Post by Ralph A. Schmid, dk5ras
Hi Don,
Thanks for the answer.
THe problem with nanobts that it is unaccessible, and even when it turns
up on ebay, it costs a fortune.
I'd rather pay that fortune for an USRP or half that fortune for a
bladerf, and I will have an SDR which I can use not only as a BTS.
So, at the moment GPRS/EDGE is only possible with nanoBTS? What about USRP
or BladeRF running OpenBTS?
BR,
Csaba
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
As for USRP or OpenBTS, I cannot comment upon having never used either
platform.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140124/d87716db/attachment.html>

[Holger Hans Peter Freyther]

Post by Sipos Csaba
Hi Guys,

Hi,

Post by Sipos Csaba
1. Is there a working GPRS/EDGE implementation in the moment? If not,
what is the plan or the state of the development process?

the sysmoBTS dsp supports all GPRS and EDGE coding schemes. The
osmo-pcu currently only supports GPRS RLC frames.

Post by Sipos Csaba
2. Which hardware should I buy, if I want to play with GPRS/EDGE? I am
thinking about USRP or BladeRF, but maybe there is a better
alternative. I am willing to spend more in order to get a more
future proof unit (for example: to have a unit which is capable of
doing EDGE if and when it is going to be supported).

Nobody to command you. Naturally we do the development on the sysmoBTS
and when you have a look at the osmo-pcu git repository you see which
entity is the most active one. ;)

cheers
holger

[Sipos Csaba]

Hi Holger,

Post by Holger Hans Peter Freyther
Nobody to command you. Naturally we do the development on the sysmoBTS
and when you have a look at the osmo-pcu git repository you see which
entity is the most active one. ;)

I want to be commanded :-) or at least guided towards the best
possible choice.

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.

So lets see if I get this correctly:

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?

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.

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?

Anyway, I thought that the GPRS support is part of the OpenBTS
development, and any hardware that can run OpenBTS is also capable of
doing GPRS, but it is clear, that there are differences in the level
of support, even between SDR like devices.

I still think that it would be nice, to clarify all this packet data
related stuff on the site.

BR,Csaba

[Alexander Chemeris]

Hi Sipos,

Post by Sipos Csaba
- 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?

Post by Sipos Csaba
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.

Post by Sipos Csaba
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.

[Matt Ettus]

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.

Post by Alexander Chemeris
- 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.

Post by Alexander Chemeris
- 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.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140124/8c57e226/attachment-0001.html>

[Alexander Chemeris]

Matt,

Post by Matt Ettus
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.

Post by Matt Ettus

Post by Alexander Chemeris
- 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.

Post by Alexander Chemeris
- 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.

[Holger Hans Peter Freyther]

Post by Sipos Csaba
Hi Holger,

Hi!

Post by Sipos Csaba
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.

Post by Sipos Csaba
Correct?
From what I see yes.
Anyway, I thought that the GPRS support is part of the OpenBTS
development, and any hardware that can run OpenBTS is also capable of
doing GPRS, but it is clear, that there are differences in the level
of support, even between SDR like devices.

The majority of the code of osmo-pcu has been contributed by or on
behalf of sysmocom. If you take a look at the development of the PCU
for the last 6 months you will clearly see that sysmocom is doing all
the work. Just like with OpenBSC a lot of others benefit from our work
though. ;)

Post by Sipos Csaba
I still think that it would be nice, to clarify all this packet data
related stuff on the site.

[Peter Stuge]

Post by Holger Hans Peter Freyther
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.


//Peter

[Holger Hans Peter Freyther]

Post by Peter Stuge

Post by Holger Hans Peter Freyther
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

[Hans Witvliet]

Post by Holger Hans Peter Freyther

Post by Peter Stuge

Post by Holger Hans Peter Freyther
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

So if you are able to "do edge" depends very much on the hardware you've
got: http://openbsc.osmocom.org/trac/wiki/nanoBTS/Models

And with the 139U you're out of luck, i'll guess...

[Peter Stuge]

Post by Holger Hans Peter Freyther

Post by Peter Stuge

Post by Holger Hans Peter Freyther
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

[Sipos Csaba]

Thanks again for the infos!

Now I have a sense about what unit we should get.

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 :-)

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

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?

Thanks,

Csaba

[Holger Hans Peter Freyther]

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

Hi again,

Post by Sipos Csaba
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.

Post by Sipos Csaba
Can someone enlighten me about the current limitations of the GPRS
stack?

Please have a look here[2].

Post by Sipos Csaba
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

[Sipos Csaba]

Hi Holger,

Post by Holger Hans Peter Freyther
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...

Is there a plan to change that one behavior (only one UL 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.

BR,
Csaba

[Holger Hans Peter Freyther]

Post by Sipos Csaba
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.

Post by Sipos Csaba
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

[Alexander Chemeris]

Hi Holger,

On Fri, Jan 24, 2014 at 4:29 PM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther
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.

This is a very broad statement.
AFAICT, UmTRX passes GSM specs as specified by the 3GPP is calibrated
properly. Could you point out which specs you mean and some proof that
_no_ SDR device can pass that spec?

Post by Holger Hans Peter Freyther
The majority of the code of osmo-pcu has been contributed by or on
behalf of sysmocom. If you take a look at the development of the PCU
for the last 6 months you will clearly see that sysmocom is doing all
the work. Just like with OpenBSC a lot of others benefit from our work
though. ;)

We all appreciate the effort Sysmocom and you personally has been
putting into the development of OsmoPCU for past 6 months and we all
love shameless commercials on this mailing list.

For the sake of completeness, I want to point out that the code was
originally written by Ivan Kluchnikov (Fairwaves employee) under my
mentorship. We left it in a stage of the proof of concept, since we
have never had any commercial customers for it. Then a few features
were added by Andreas Eversberg. And then Sysmocom took a turn to
restructure the code and make it closer to production.

That's what I like about open-source and cooperation in general -
everyone contributes a little bit and a project becomes better than if
everyone wrote the thing from scratch.

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
with paid feature requests and with buying more of our hardware. And
just by submitting more high-quality patches, i.e. by more
cooperation. :)

Happy hacking!

[Holger Hans Peter Freyther]

Post by Alexander Chemeris
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

[Alexander Chemeris]

Hi Holger,

On Mon, Jan 27, 2014 at 1:13 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther

Post by Alexander Chemeris
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?

Definitely.

You've seen some of hose patches at the mailing list. Unfortunately we
haven't had enough free time yet to merge them into master, as we've
been using jolly-branches. I hope that jolly-branches will be merged
into master soon, including the osmo-trx support, and we'll submit
those patches for merging to master as well.

As an example, we're experiencing issues with SMS delivery in a case
of spotty coverage and high network load. It's too early to share
anything, as we're still understanding the reasons and how to solve
this. We're looking into may be writing a unit test for the NITB's
SMSC, but it's not clear yet how to do this cleanly and without too
much effort.

Another issue with SMS is that validity period is not supported and
SMS stay in the DB forever, making to too slow after just a few days
of usage.

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.

Then, there is this whole big thing about using an SQLite DB for
everything, from HLR to SMSC to counters storage. This is fine for
testing, but has its limitations when you run the system 24/7 under a
heavy load. At this moments we're using workarounds like not storing
counters in the DB and cleaning up the DB with a script, but we're
looking into solving this in a proper way.

These all is quite a lot of work, unfortunately, and it distracts us
from working more on shiny new features like GPRS and EDGE.

PS If there is any interest, I can talk at OsmoDevCon about our
experience in running OsmoNITB in production and what we see as the
challenges moving forward.

[Ralph A. Schmid, dk5ras]

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?

From my point of view slowly increasing TX power is OK for booting a new cell into

operation, but during normal operation?!

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru

Ralph.

[Alexander Chemeris]

Ralph,

On Mon, Jan 27, 2014 at 7:07 PM, Ralph A. Schmid, dk5ras

Post by Ralph A. Schmid, dk5ras

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?
From my point of view slowly increasing TX power is OK for booting a new cell into
operation, but during normal operation?!

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,

[Ralph A. Schmid, dk5ras]

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.

[David A. Burgess]

Ralph -

Post by Ralph A. Schmid, dk5ras
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.

There is a hold-off timer sent in the immediate assignment reject message, but it is still possible for the RACH to be so congested that only a small fraction of bursts are decodable. And it is possible for the AGCH to be so congested that it is impossible to respond to any significant fraction of the requests anyway. Once this happens, you get a kind of live-lock on the air interface. If you are the only BTS in the area, this locked condition can persist for hours. You can either turn down the power and reduce the number of phones in the coverage area and serve that reduced population, or stay in the live-lock condition and not serve anyone.

Yes, you ramp up power on startup. We just automated that process. And unless the BTS falls into this kind of live-lock condition, because of the sudden failure of a neighbor cell or some other overlapping network, this mechanism does not take any action.

Post by Ralph A. Schmid, dk5ras
Or am I totally wrong?

From my point of view slowly increasing TX power is OK for booting a new cell into

operation, but during normal operation?!

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.

Post by Ralph A. Schmid, dk5ras

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru

Ralph.

[Ralph A. Schmid, dk5ras]

Post by David A. Burgess
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.

[David A. Burgess]

You start seeing this with several thousand phones.

Post by Ralph A. Schmid, dk5ras

Post by David A. Burgess
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.

[Tom Tsou]

On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther
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

[Holger Hans Peter Freyther]

Post by Tom Tsou
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther
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?

Post by Tom Tsou
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.

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

[Tom Tsou]

On Mon, Jan 27, 2014 at 7:49 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther

Post by Tom Tsou
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther
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.

Post by Holger Hans Peter Freyther
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

[Ralph A. Schmid, dk5ras]

Hi,

Post by Tom Tsou

Post by Holger Hans Peter Freyther
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?

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.

Post by Tom Tsou
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.


Ralph.

[Tom Tsou]

On Tue, Jan 28, 2014 at 3:49 AM, Ralph A. Schmid, dk5ras

Post by Ralph A. Schmid, dk5ras

Post by Tom Tsou
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.

Post by Ralph A. Schmid, dk5ras

Post by Tom Tsou
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

[Ralph A. Schmid, dk5ras]

Hi,

Post by Tom Tsou
Note that the USRP1-WBX combination does not support LO offset or IQ
imbalance compensation; those factors will be your largest source of

overall

Post by Tom Tsou
signal distortion. In regards to the harmonic distortion, it seems that

the

Post by Tom Tsou
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.

Yes, sure, this is normal behavior.

Post by Tom Tsou
I will certainly not deny that spurious signals exist in USRP-type boards

or that

Post by Tom Tsou
passband filters are used in commercial products. My only issue is the

claim

Post by Tom Tsou
that a narrow tuning range limited by front end filters is a mandatory
requirement for suitable spectrum compliance. A huge number of frequency

I see more problems in the receiver stages, and there parameters are also
mandatory during compliance tests.

Post by Tom Tsou
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.

Post by Tom Tsou
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

Post by Tom Tsou
think should be ignored.

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.

Post by Tom Tsou
-TT

Ralph.

[Tom Tsou]

On Wed, Jan 29, 2014 at 2:23 AM, Ralph A. Schmid, dk5ras

Post by Ralph A. Schmid, dk5ras
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

[Alexander Chemeris]

Hi Holger,

On Mon, Jan 27, 2014 at 4:49 PM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther

Post by Tom Tsou
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther

Post by Holger Hans Peter Freyther
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?

Do you mean carrier harmonics?

Post by Holger Hans Peter Freyther
From what we know, to follow general regulation, no noise (including

those harmonics) must be above:
-30 dBm @ 30 kHz span above 1 GHz
-36 dBm @ 30 kHz span below 1 GHz

In case of UmTRX without an amplifier it's enough to use a ceramic or
SAW duplexer to bring harmonics below those levels.

For those buying UmTRX's as a lab package of universal UmDESKs, we
offer to buy an external ceramic duplexers. These improves coverage
and solves the out of band noise issues.

For those buying band-specific UmDESK's, we use SAW duplexers, which
are even more efficient in reducing out of band noise.

Post by Holger Hans Peter Freyther

Post by Tom Tsou
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.

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

You're obviously more proficient in European norms. Could you point me
to a link where we could find these differences between the ETSI
published GSM Standard and European harmonized norms?

It would be a very good addition to the OpenBSC wiki's "Standards" page.