23 Jan
2014
23 Jan
'14
1:33 p.m.
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
23 Jan
23 Jan
7:04 p.m.
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.
24 Jan
24 Jan
10:32 a.m.
On Thu, Jan 23, 2014 at 12:33:55PM +0100, Sipos Csaba wrote:
Hi Guys,
Hi,
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.
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
11:59 a.m.
New subject: Re[2]: GPRS, EDGE support
Hi Holger,
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
2:29 p.m.
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?
10:29 p.m.
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.
//Peter
25 Jan
25 Jan
noon
On Fri, Jan 24, 2014 at 09:29:21PM +0100, Peter Stuge wrote:
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
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. 
1:01 p.m.
On Sat, 2014-01-25 at 11:00 +0100, Holger Hans Peter Freyther wrote:
On Fri, Jan 24, 2014 at 09:29:21PM +0100, Peter Stuge
wrote:
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...
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.
26 Jan
26 Jan
12:26 a.m.
Holger Hans Peter Freyther wrote:
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
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.
25 Jan
25 Jan
1:39 p.m.
New subject: Re[2]: GPRS, EDGE support
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
11:47 p.m.
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
26 Jan
26 Jan
12:20 p.m.
New subject: Re[2]: GPRS, EDGE support
Hi Holger,
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
8:51 p.m.
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
10:55 p.m.
Hi Holger,
On Fri, Jan 24, 2014 at 4:29 PM, Holger Hans Peter Freyther
<holger(a)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.
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?
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!
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
11:13 p.m.
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
27 Jan
27 Jan
10:26 a.m.
Hi Holger,
On Mon, Jan 27, 2014 at 1:13 AM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
On Mon, Jan 27, 2014 at 12:55:31AM +0400, Alexander
Chemeris wrote:
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.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
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? 
5:07 p.m.
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?
9:56 p.m.
Ralph,
On Mon, Jan 27, 2014 at 7:07 PM, Ralph A. Schmid, dk5ras
<ralph(a)schmid.xxx> wrote:
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,
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
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?!
28 Jan
28 Jan
10:29 a.m.
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.
1:11 p.m.
Ralph -
On Jan 27, 2014, at 17:07, Ralph A. Schmid, dk5ras <ralph(a)schmid.xxx> wrote:
Hi,
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.
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?
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.
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.
1:29 p.m.
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.
5:30 p.m.
You start seeing this with several thousand phones.
On Jan 28, 2014, at 13:29, Ralph A. Schmid, dk5ras <ralph(a)schmid.xxx> wrote:
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.
27 Jan
27 Jan
1:29 a.m.
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans Peter Freyther
<holger(a)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
2:49 p.m.
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(a)freyther.de> wrote:
Ah cool. Can you point me to papers/text showing how the n-th harmonic
is being removed from the spectrum?
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.
The policy of FCC vs. European Union is quite different. There are more
norms that apply in Europe.
9:48 p.m.
On Mon, Jan 27, 2014 at 7:49 AM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
On Sun, Jan 26, 2014 at 06:29:00PM -0500, Tom Tsou
wrote:
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.
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans
Peter Freyther
<holger(a)freyther.de> wrote:
Ah cool. Can you point me to papers/text showing how the n-th harmonic
is being removed from the spectrum? 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. 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
28 Jan
28 Jan
10:49 a.m.
Hi,
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.
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? 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.
6:10 p.m.
On Tue, Jan 28, 2014 at 3:49 AM, Ralph A. Schmid, dk5ras
<ralph(a)schmid.xxx> wrote:
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.
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
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. 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.
29 Jan
29 Jan
9:23 a.m.
Hi,
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.
Yes, sure, this is normal behavior.
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
I see more problems in the receiver stages, and there parameters are also
mandatory during compliance tests.
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.
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.
-TT
Ralph.
10:20 a.m.
On Wed, Jan 29, 2014 at 2:23 AM, Ralph A. Schmid, dk5ras
<ralph(a)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
28 Jan
28 Jan
8:12 p.m.
Hi Holger,
On Mon, Jan 27, 2014 at 4:49 PM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
On Sun, Jan 26, 2014 at 06:29:00PM -0500, Tom Tsou
wrote:
Do you mean carrier harmonics?
On Fri, Jan 24, 2014 at 7:29 AM, Holger Hans
Peter Freyther
<holger(a)freyther.de> wrote:
Ah cool. Can you point me to papers/text showing how the n-th harmonic
is being removed from the spectrum? 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.
24 Jan
24 Jan
4:52 p.m.
New subject: Re[2]: GPRS, EDGE support
Hi Sipos,
On Fri, Jan 24, 2014 at 1:59 PM, Sipos Csaba <dchardware(a)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
7:15 p.m.
New subject: Re[2]: GPRS, EDGE support
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.
- 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.
Matt
26 Jan
26 Jan
10:35 p.m.
New subject: Re[2]: GPRS, EDGE support
Matt,
On Fri, Jan 24, 2014 at 9:15 PM, Matt Ettus <matt(a)ettus.com> wrote:
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
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.
3780
days inactive
3783
days old
32 comments
10 participants
participants (10)
-
Alexander Chemeris -
David A. Burgess -
Don Fanning -
Hans Witvliet -
Holger Hans Peter Freyther -
Matt Ettus -
Peter Stuge -
Ralph A. Schmid, dk5ras -
Sipos Csaba -
Tom Tsou