My init.d script does the following in short:
modprobe mISDN_dsp
modprobe mISDN_l1loop nchannel=30 interfaces=2
sleep 1
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.253.0/24 -o eth0 -j
MASQUERADE
screen -S bsc -d -m su gsm -c "osmo-nitb -d
DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg
-m -P"
screen -S lcr -d -m su gsm -c "/usr/sbin/lcr start"
I'm using mISDN_l1loop.ko from current mISDN git because it was not included
in my kernel. Small patch to make it compile:
--- a/drivers/isdn/mISDN/hwchannel.c
+++ b/drivers/isdn/mISDN/hwchannel.c
@@ -19,6 +19,8 @@
#include <linux/module.h>
#include <linux/mISDNhw.h>
+bool flush_work_sync (struct work_struct *);
+
static void
dchannel_bh(struct work_struct *ws)
{
-- Lennart
--00504502c5d4681bbb04a8fd3d31
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">2011/7/26 Konrad Meier <span dir=3D"ltr"><=
;<a href=3D"mailto:meierk@informatik.uni-freiburg.de">meierk(a)informatik.uni=
-freiburg.de</a>></span><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I could solve the above problem by a system restart. The mISDN_l1loop modul=
e was loaded but for some reason could not be used by LCR. The LCR error me=
ssage was:<br>
000000 ERROR loop port 1 failed to bind socket. (errno 93)<br>
<br>
<br>
By playing with the mISDN_l1loop module I discovered a strange problem. If =
I load the module with "modprobe mISDN_l1loop pri=3D1 nchannel=3D30&qu=
ot; all system memory is allocated by LCR after some seconds.<br>
<br>
If I load it with "nchannel=3D20" than everithing works fine.<br>
<br>
Can someone confirm this problem?<br>
<br>
Regards<br><font color=3D"#888888">
Konrad<br></font></blockquote><div><br>From my experience, no.<br>My init.d=
script does the following in short: <br><br>=A0=A0=A0=A0=A0=A0=A0 modprobe=
mISDN_dsp<br>=A0=A0=A0=A0=A0=A0=A0 modprobe mISDN_l1loop nchannel=3D30 int=
erfaces=3D2<br>=A0=A0=A0=A0=A0=A0=A0 sleep 1<br>
<br>=A0=A0=A0=A0=A0=A0=A0 echo 1 > /proc/sys/net/ipv4/ip_forward<br>=A0=
=A0=A0=A0=A0=A0=A0 iptables -t nat -A POSTROUTING -s <a href=3D"http://192.=
168.253.0/24">192.168.253.0/24</a> -o eth0 -j MASQUERADE<br><br>=A0=A0=A0=
=A0=A0=A0=A0 screen -S bsc -d -m su gsm -c "osmo-nitb -d DRLL:DCC:DMM:=
DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg -m -P"<=
br>
=A0=A0=A0=A0=A0=A0=A0 screen -S lcr -d -m su gsm -c "/usr/sbin/lcr sta=
rt"<br>=A0<br>I'm using mISDN_l1loop.ko from current mISDN git bec=
ause it was not included in my kernel. Small patch to make it compile:<br><=
br>--- a/drivers/isdn/mISDN/hwchannel.c<br>
+++ b/drivers/isdn/mISDN/hwchannel.c<br>@@ -19,6 +19,8 @@<br>=A0#include &l=
t;linux/module.h><br>=A0#include <linux/mISDNhw.h><br><br>+bool fl=
ush_work_sync (struct work_struct *);<br>+<br>=A0static void<br>=A0dchannel=
_bh(struct work_struct *ws)<br>
=A0{<br><br>-- Lennart<br></div></div>
--00504502c5d4681bbb04a8fd3d31--
systems from the same vendor, as it is assumed that these systems have
seen a priori more testing time and are thus more reliable than any
multi-vendor combination has seen/would be.
Should there be a problem, it is also a lot easier and faster to get
support from a vendor, when he can't first try and blame the other
vendors box, or the translator in between. Here, again, risk
management...
While the lock-in is indeed a bad thing, it is still considered the
lesser evil, compared to the effort needed to do q/a testing in mixed
systems on nation-size scale plus R&D for the translators plus
battling for support with N competing vendors, all blaming each other.
This is the oh-so-familiar argument on why many companies use
exclusively Microsoft, or everything Apple, etc...
Just my 0.05 chf on why translators did not happen... (yet?)
Cheers,
Thomas
--=20
Excercise 17:
If the human brain was simple enough for us to understand we'd be so
simple we couldn't understand.
Prove this by induction.
Sure, it would be a nice addition, but it's not something that I consider
extremely important. With regard to 'near future': I would say that in
something like six months the osmo-bts (BTS-side A-bis) code will have matured,
and is ready for an relaatively painless integration with OpenBTS.
I personally think the USRP hardware cost is still way too high, and I would
rather want to work on something that puts the financial entrance barrier to
private BTS ownership much lower.
Most of the people using OpenBSC today either use it commercially (and can
afford the nanoBTS units), or they use it private and either with a very
cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work
on supporting the RBS2308 that can be found for < 1000 USD goes into the
same direction.
I think whatever hardware will be affordable to hackers will see OpenBSC
support - just as well as any hardware where we have a commercial customer
will get OpenBSC support.
> > This is where I don't get you. All that needs to be removed is the L3-to-SIP
> > bridge. It doesn't make the vast majority of OpenBTS code disappear,
> > and it does not render that latter part useless. A full-blown GSM network with
> > all its components brings a lot of complexity. The stand-alone OpenBTS is
> > much more simple. And why would you want all the complexity if you don't
> > need to interoperate with legacy GSM?
>
> Well, because the the osmocom-integrated version will be, before or
> later, more full-featured than OpenBTS standalone.
>
> Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
> only jointly with Osmocom integration but not by the opensource OpenBTS
> standalone version.
If you use the USRP hardware (or any other SDR hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for
hand-over, you may be right, but I don't know the OpenBTS plans here.
Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
> Obviously the community will then use the OpenBTS/OpenBSC integration
> that would reach more features than just OpenBTS in the opensource edition.
well, but you loose the important 'simplicity' feature. Right now I doubt
there are that many people in our community who understand OpenBSC and the
GSM/GPRS network architecture enough to deploy a network (like the burning man
or CCC event networks) with it. We have close to zero documentation, and
unless you know GSM protocol details, you are lost. VoIP is much better
understood in the FOSS and Internet community!
> So the integrated code will grow while the "OpenBTS commercial code"
> will leave behind with less features and more buggy code (because less
> used).
you are making assumptions here. Do you have evidence or at least some
other indication that bug fixes are not being propagated from the commercial
to the free version?
> Osmocom and it's possible future changes to the market of GSM
> technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
I think this is a very bad comparison. We do not leak any proprietary/secret
information. We just break the ignorance of the Free Software community to
ever implement any of those openly-specified protocols. Not different from
Free Software entering any other area of technology.
And while we're doing that, we of course also like to challenge the ridiculous
claims of hundred-man-year efforts that allegedly went into some proprietary
GSM protocol stack implementations, which are often claimed by the existing
carrier equipment industry.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation
> for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a
> simplistic BTS), and I have started to split that code out into a separate
> repository at http://cgit.osmocom.org/cgit/osmo-bts/
>
> This code should eventually be used with the OpenBTS, and potentially other
> BTS types, too.
That's cool!!!!
>
>> With that approach the 'GSM-um' interface would be a very simplified
>> module of the overall system and osmocom would completely replace
>> OpenBTS all-in-one project.
>
> This is where I don't get you. All that needs to be removed is the L3-to-SIP
> bridge. It doesn't make the vast majority of OpenBTS code disappear,
> and it does not render that latter part useless. A full-blown GSM network with
> all its components brings a lot of complexity. The stand-alone OpenBTS is
> much more simple. And why would you want all the complexity if you don't
> need to interoperate with legacy GSM?
Well, because the the osmocom-integrated version will be, before or
later, more full-featured than OpenBTS standalone.
Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
only jointly with Osmocom integration but not by the opensource OpenBTS
standalone version.
Obviously the community will then use the OpenBTS/OpenBSC integration
that would reach more features than just OpenBTS in the opensource edition.
That means that in few times only the "integrated code" will works
better, because it will attract more user and will start getting used in
"production environment".
So the integrated code will grow while the "OpenBTS commercial code"
will leave behind with less features and more buggy code (because less
used).
That's why i just think that the destinity of OpenBTS is to integrate
(directly or just some piece) with OpenBSC, but doing that it will loose
several important value of the "OpenBTS commercial edition" and people
will start using what can be used for free instead of paying.
That's what usually happen within the opensource environment, before or
later.
It could reasonably happen also with that opensource gsm environment.
My comments was just consideration on this to stimulate the
considerations on this by the various project players.
I am just an opensource advocacy troll that like telephony stuff and
perceive very valuable the achievement of the hacking community in
opening a closed technology like GSM.
Osmocom and it's possible future changes to the market of GSM
technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
-naif
p.s. i have no commercial interests of any kind in that stuff
is not in the TLV table and this explains why we end up here. It might be a
good opportunity to see what else we are missing.
>
> BTW, the output of the patch is in git format, so I think that you can
> apply it with git am. It's the inner patch (which is contained inside
> this patch) that it's in svn format 8-).
Yes, I am talking about git am -3 for the inner part as this (wireshark svn)
is the place where having a three way merge is going to be the most useful
thing to do. :)
have a similar situation (see how OpenBTS folks managed to get licenses for
their burining man tests).
> - Is there some part of the official gsm bands that overlaps with local ISM
> or other not-so-tightly-regulated frequencies?
> (i.e, GSM1900 seems to have a small part that's not used by DECT...)
This is a rumour. Only one of the uplink/downlink bands is in there, so you
will still need a test license. Also, AFAIK the DECT band is not everywhere
unlicensed for any kind of application, but actually restricted to be used with
the DECT system.
> - Are there any "standard" gsm handsets that could be modified (preferably
> in software) to work at 2,4GHz?
no.
> - Is UMA/GAN (http://en.wikipedia.org/wiki/Generic_Access_Network) something
> that could be used with OpenBSC? As far as i understand the specification,
> UMA is GSM Layer 3 over an GPRS/IPSEC tunnel to the BSC, so all the
> GSM-Goodies should be there.
You would have to implemet a UMA gateway and somehow glue that to the layer3
inside OpenBSC. I don't think you can do it cleanly with the current code.
Later this year, once the new "real MSC" codebase emerges, this might be easier.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
understand that we only have to configure the Unit-id and Oml Address right
and I understand that the firmware is already installed .
I have tried the following :
ipaccess-config -f FIRMWARE -w
and sure it doesn't work :) .
And I also read the -w argument options that needs to be used to download
the firmware from BTS into debian system it should be used with -f .
Is it necessary to download it into our linux box or you need to configure
it only as it is already installed into BTS from ipaccess company .
Thanks,
Omar Atia
-----Original Message-----
From: openbsc-bounces(a)lists.osmocom.org
[mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Peter Hasse
Sent: Wednesday, January 19, 2011 12:14 PM
To: openbsc(a)lists.osmocom.org
Subject: Re: How to run openbsc on nanoBTS
On 19.01.2011 06:16, Ravi Shankar wrote:
> Dear sir
Hi Ravi
>
> I am new to openbsc.I have two NanoBTS(165cu).I'm facing some
> difficulty which I'm summarizing below
> I'm using Ubuntu10.04
> 1) Can we proceed with one nanobts.?
Yes, in fact i would recommend to start with one and if you get familar
with openbsc you can add more bts.
> 2)I've configured bts ip,unit id, oml ip of one bts.But not able to
> get the firmware.
Check out ipaccess-config util from the openbts source. You can download
the firmware out of the bts you have configured.
> How to get it and configure for NanoBTS??
nanoBTS is a different project and based on the USRP. checkout
openbts.org to get further informations.
>
> 3)how to run openbsc ??
http://openbsc.osmocom.org/trac/wiki/BscHack
>
> Please suggest the procedure to run the openbsc.
>
> Thanks
mfg derPeter
seems weird:
> but bts1 tells that:
>
> LMT LOGON: ACK
>
> PHASE: 3 Normal MBCCU0: No Load MBCCU1: Load
^^^^^
you have no software in TRX0!!
> PLL Set Value=1042, Work Value=1221
this is not good. your clock seems to be very far off, probably you have not
been running it in pll standalone mode at some point in the past. However,
this is unrelated to your E1 problems. The only consequence of this is that
phones might not see your BTS.
> SITE MANAGER ATTRIBUTES:
> E1 Channel: Port=1 Timeslot=17 (Full Slot)
> TEI: 25
This is the weird part. Why would the E1 channel of the site manager run on
Port=1? That is the not connected port of this BTS. It must run on Port=0.
> BS11 Power Amplifier 0 ATTRIBUTES:
> TRX Power: 2W (GSM)
I strongly recommend you do your testing with something like 30mW power limits,
unless you have a faraday cage and/or 2W-capable termiators.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Number of symbols in a burst =3D 156.25 symbols, and burst time 156.25 x<br=
>
3.69... =3D 576,92=ECs<br>
Number of symbols in TDMA frame is 8 x 156.25 =3D 1250 symbols,<br>
Number of symbols in Multiframe is 26 x 1250 symbols.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Jan 7, 2011 at 8:51 AM, Nataraju A B <<a href=3D"mailto:nataraju=
ab.tech(a)gmail.com">natarajuab.tech(a)gmail.com</a>> wrote:<br>
><br>
> Hi Andreas,<br>
> Thanks for the speedy reply.<br>
> The link which sent you is=A0definitely=A0useful. But the very basic q=
uestion I wanted to get a clarification was that, what is the drive behind =
selection of burst time to be 577us.<br>
> For example the audio frequency can range upto 4Khz. The sampling freq=
uency should be 8Khz. If each sample is of 8 bit accuracy. This lead to 64K=
bits of data. ...... =A0If we explore further on these lines we should be =
able to correlate to the time 577us for each burst.<br>
> I wanted some more info these lines. What was/were the drives behind s=
election of this burst time. Otherwise what are the other end requirements =
led to selection of this burst time and in turn TDMA frame hierarchy.<br>
> Thanks,<br>
> Nataraju A B<br>
> On Fri, Jan 7, 2011 at 7:01 PM, Andreas.Eversberg <<a href=3D"mailt=
o:Andreas.Eversberg@versatel.de">Andreas.Eversberg(a)versatel.de</a>> wrot=
e:<br>
>><br>
>> in addition:<br>
>><br>
>> Traffic Multiframe Structures - The 26 traffic multiframe structur=
e is<br>
>> used to send information on the traffic channel. The 26 traffic<br=
>
>> multiframe structure is used to combine user data (traffic), slow<=
br>
>> control signaling (SACCH), and idle time period. The idle time per=
iod<br>
>> allows a mobile device to perform other necessary operations such =
as<br>
>> monitoring the radio signal strength level of a beacon channel fro=
m<br>
>> other cells. The time interval of a 26 frame traffic multiframe is=
6<br>
>> blocks of speech coder data (120 msec).<br>
>> (<a href=3D"http://www.althos.com/tutorial/GSM-tutorial-frame-stru=
cture.html" target=3D"_blank">http://www.althos.com/tutorial/GSM-tutorial-f=
rame-structure.html</a>)<br>
>><br>
>> one encoded speech block lasts 20ms.<br>
>><br>
>><br>
>> =A0 =A0 =A0 =A0576,92307692307692307692307692308us per slot<br>
>> =A0 =A0 =A0 =A04615,3846153846153846153846153846 per 8 slots (1 fr=
ame)<br>
>> =A0 =A0 =A0 =A0120ms per 26 frames (6 speech blocks)<br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Thanks,<br>
> Nataraju A B<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Thanks,<div=
>Nataraju A B</div><br>
--00163641691bea689c04996d367c--
Number of symbols in a burst =3D 156.25 symbols, and burst time 156.25 x
3.69... =3D 576,92=ECs
Number of symbols in TDMA frame is 8 x 156.25 =3D 1250 symbols,
Number of symbols in Multiframe is 26 x 1250 symbols.
On Fri, Jan 7, 2011 at 8:51 AM, Nataraju A B <natarajuab.tech(a)gmail.com> wr=
ote:
>
> Hi Andreas,
> Thanks for the speedy reply.
> The link which sent you is=A0definitely=A0useful. But the very basic ques=
tion I wanted to get a clarification was that, what is the drive behind sel=
ection of burst time to be 577us.
> For example the audio frequency can range upto 4Khz. The sampling frequen=
cy should be 8Khz. If each sample is of 8 bit accuracy. This lead to 64K bi=
ts of data. ...... =A0If we explore further on these lines we should be abl=
e to correlate to the time 577us for each burst.
> I wanted some more info these lines. What was/were the drives behind sele=
ction of this burst time. Otherwise what are the other end requirements led=
to selection of this burst time and in turn TDMA frame hierarchy.
> Thanks,
> Nataraju A B
> On Fri, Jan 7, 2011 at 7:01 PM, Andreas.Eversberg <Andreas.Eversberg@vers=
atel.de> wrote:
>>
>> in addition:
>>
>> Traffic Multiframe Structures - The 26 traffic multiframe structure is
>> used to send information on the traffic channel. The 26 traffic
>> multiframe structure is used to combine user data (traffic), slow
>> control signaling (SACCH), and idle time period. The idle time period
>> allows a mobile device to perform other necessary operations such as
>> monitoring the radio signal strength level of a beacon channel from
>> other cells. The time interval of a 26 frame traffic multiframe is 6
>> blocks of speech coder data (120 msec).
>> (http://www.althos.com/tutorial/GSM-tutorial-frame-structure.html)
>>
>> one encoded speech block lasts 20ms.
>>
>>
>> =A0 =A0 =A0 =A0576,92307692307692307692307692308us per slot
>> =A0 =A0 =A0 =A04615,3846153846153846153846153846 per 8 slots (1 frame)
>> =A0 =A0 =A0 =A0120ms per 26 frames (6 speech blocks)
>>
>>
>>
>
>
>
> --
> Thanks,
> Nataraju A B
