From laforge at gnumonks.org  Tue Feb 15 11:20:55 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Feb 2011 12:20:55 +0100
Subject: Proposed OpenBSC application interface
In-Reply-To: <20100414214822.GE7381@prithivi.gnumonks.org>
References: <20100414214822.GE7381@prithivi.gnumonks.org>
Message-ID: <20110215112055.GC24290@prithivi.gnumonks.org>

Some more thoughts on that old topic:

A custom protocol seems to make more and more sense.  Neither original
RSL nor 08.08 seem to be a close match.

Some more specification of the original protocol idea:

On Wed, Apr 14, 2010 at 11:48:22PM +0200, Harald Welte wrote:

> * ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
Parameters:
	* mobile identity (tmsi/imsi) (can re-use 04.08 mobile identity IE)
	* channel type (sdcch/tch) (can reuse RSL information element)
	* which parts of the protocol shall openbsc handle (RR/MM/CC)
	* unique reference identifying this 'call/radio channel'

> * ESTABLISH CONFIRM -- network confirms a channel has been established
	(confirmation that the radio channel has been established)
Parameters:
	* unique reference identifying this call/radio channel
	* exact arfcn/timeslot/sub-slot that was established
		(can be RSL or 04.08 channel description)

> * ESTABLISH INDICATION -- network tells app connection was made by MS
	(confirmation that a LAPDm connection was established)
Parameters:
	* unique reference identifying this call/radio channel
	* SAPI (RSL Link ID)

> * [UNIT] DATA REQUEST -- app requests data to be sent to MS
> * [UNIT] DATA INDICATION -- network indicates data was received from MS
Parameters:
	* unique reference identifying this call/radio channel
	* SAPI (RSL Link ID)

> * ERROR INDICATION -- network tells app something went wrong
Parameters:
	* unique reference identifying this call/radio channel
	* error code / reason

> * RELEASE REQUEST -- app asks network to release channel
Parameters:
	* unique reference identifying this call/radio channel
> * RELEASE CONFIRM -- net tells app that channel was released (as rqd)
Parameters:
	* unique reference identifying this call/radio channel
> * RELEASE INDICATION -- net tells app that channel was released (by MS)
Parameters:
	* unique reference identifying this call/radio channel

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Tue Feb 15 11:55:52 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 15 Feb 2011 12:55:52 +0100
Subject: Proposed OpenBSC application interface
In-Reply-To: <20110215112055.GC24290@prithivi.gnumonks.org>
References: <20100414214822.GE7381@prithivi.gnumonks.org>
	<20110215112055.GC24290@prithivi.gnumonks.org>
Message-ID: <4D5A69C8.6040206@freyther.de>

On 02/15/2011 12:20 PM, Harald Welte wrote:
> Some more thoughts on that old topic:
> 
> A custom protocol seems to make more and more sense.  Neither original
> RSL nor 08.08 seem to be a close match.

The question is still what we want to fuzz. The strong point of GSM 08.08 is
that it is 'connection' based. We do have a connection (maybe over multiple
lchan's) to a MS and GSM 08.08 is quite good at sending messages to the MS.

On the other hand if we have something closer to RSL we are on the assembler
level, this way we either need to have something else in the system to bring
the MS into the state where someone wants to start fuzzing (which i think will
complicate the test setup), or one is using the assembler commands to get the
system into the state.

But then again it all depends on what one wants to test and how complicated it
is to get the MS into this mode. So I might be missing the point. :)

regards
	holger



From laforge at gnumonks.org  Tue Feb 15 14:04:35 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Feb 2011 15:04:35 +0100
Subject: Proposed OpenBSC application interface
In-Reply-To: <4D5A69C8.6040206@freyther.de>
References: <20100414214822.GE7381@prithivi.gnumonks.org>
	<20110215112055.GC24290@prithivi.gnumonks.org>
	<4D5A69C8.6040206@freyther.de>
Message-ID: <20110215140435.GJ24290@prithivi.gnumonks.org>

Hi Holger,

On Tue, Feb 15, 2011 at 12:55:52PM +0100, Holger Hans Peter Freyther wrote:

> The question is still what we want to fuzz. The strong point of GSM 08.08 is
> that it is 'connection' based. We do have a connection (maybe over multiple
> lchan's) to a MS and GSM 08.08 is quite good at sending messages to the MS.

But we only have 08.08 support if you run osmo-bsc, at which point you loose
all the MM common procedures,etc.  The requirement seems to be flexibility,
i.e. being able to use any or all of the bsc_hack features and configure
flexibly what you want.

Tobias and I have now discussed an alternative approach: Filtering.  Something
similar to NF_QUEUE, where all incoming/outgoing RSL(RLL) messages are routed
through an external application first.  The app can then simply allow them to
pass, filter them, modify or replace them with something completely different.

This has the advantage that you can benefit from the existing MM and CC state
machines in OpenBSC, but can simply modify individual messages or IEs inside
messages, without having to care about much else.

It would then be a per-subscriber property if messages from/to him are to
be relayed through that external filter app or not.  The per-subscriber
property then propagates down into a per-lchan property.

Regards,
	Harald.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Tue Feb 15 14:12:45 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 15 Feb 2011 15:12:45 +0100
Subject: Proposed OpenBSC application interface
In-Reply-To: <20110215140435.GJ24290@prithivi.gnumonks.org>
References: <20100414214822.GE7381@prithivi.gnumonks.org>	<20110215112055.GC24290@prithivi.gnumonks.org>	<4D5A69C8.6040206@freyther.de>
	<20110215140435.GJ24290@prithivi.gnumonks.org>
Message-ID: <4D5A89DD.2050909@freyther.de>

On 02/15/2011 03:04 PM, Harald Welte wrote:
> Hi Holger,
> 

> But we only have 08.08 support if you run osmo-bsc, at which point you loose
> all the MM common procedures,etc.  The requirement seems to be flexibility,
> i.e. being able to use any or all of the bsc_hack features and configure
> flexibly what you want.

The adaption to make bsc_hack connect to osmo-bsc would be small and actually
osmo-bsc is (almost) able to handle a connection locally and then move it to
the external interface.


> 
> Tobias and I have now discussed an alternative approach: Filtering.  Something
> similar to NF_QUEUE, where all incoming/outgoing RSL(RLL) messages are routed
> through an external application first.  The app can then simply allow them to
> pass, filter them, modify or replace them with something completely different.

Again, I don't know all the usecases and just have the approach I would take
in mind. One (the only) issue I see is timers. E.g. we have timers for CC,
SMS, etc. We want to stop, release the resources without releasing the
connection. I assume leaking is a an allowed option for the fuzzing.



From holger at freyther.de  Mon Feb 21 11:21:33 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 21 Feb 2011 12:21:33 +0100
Subject: New utility for drawing protocol ladder diagrams
In-Reply-To: <20100709075543.GM22836@prithivi.gnumonks.org>
References: <20100709075543.GM22836@prithivi.gnumonks.org>
Message-ID: <4D624ABD.4000605@freyther.de>

On 07/09/2010 09:55 AM, Harald Welte wrote:
> Hi!

> The bent/curved arrows are a result of graphviz trying to indicate
> that the message is between e.g. MS and MSC and 'bypasses' BTS and BSC.
> I'm still waiting for somebody with more graphviz skills to make this an
> option.

I think the reason is more that the edges that make up the verical line are
not equally sized. E.g. this can be seen when removing the rank=same.

holger




From omar.atia at its.ws  Wed Feb 16 09:31:35 2011
From: omar.atia at its.ws (Omar Atia)
Date: Wed, 16 Feb 2011 11:31:35 +0200
Subject: How to download firmware and configure NanoBTS the first time...
In-Reply-To: <4D36B94B.6080806@fokus.fraunhofer.de>
References: <AANLkTi=oFywVrzPK1ysp5NxZ=boQH+-DPJ4byRD=MzeP@mail.gmail.com>
	<4D36B94B.6080806@fokus.fraunhofer.de>
Message-ID: <008601cbcdbc$52496ac0$f6dc4040$%atia@its.ws>

Dear Peter and All,

Do you have any idea or example of the ipaccess-config usage to how to
download the firmware from BTS into your debian system .

Does the firmware comes from ipaccess already installed into NanoBTS or we
install it ?


From laforge at gnumonks.org  Wed Feb 16 21:52:33 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Feb 2011 22:52:33 +0100
Subject: How to download firmware and configure NanoBTS the first time...
In-Reply-To: <008601cbcdbc$52496ac0$f6dc4040$%atia@its.ws>
References: <AANLkTi=oFywVrzPK1ysp5NxZ=boQH+-DPJ4byRD=MzeP@mail.gmail.com>
	<4D36B94B.6080806@fokus.fraunhofer.de>
	<008601cbcdbc$52496ac0$f6dc4040$%atia@its.ws>
Message-ID: <20110216215233.GO25856@prithivi.gnumonks.org>

Omar,

how should we know in what you get your particular nanoBTS units delivered?

You have to talk to your supplier about that.

For all I know, it is customary for the nanoBTS to ship with pre-installed
firmware.  Based on your support contract with ip.access you may receive
firmware updates from time to time, which you can then apply either using
tools from ip.access or using our ipaccess-config.   Our tool is of course
not officially recognized/authorized/recommended/endorsed for this purpose.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From ravi.varun00 at gmail.com  Wed Feb 23 11:43:48 2011
From: ravi.varun00 at gmail.com (Ravi Shankar)
Date: Wed, 23 Feb 2011 17:13:48 +0530
Subject: How to download firmware and configure NanoBTS the first time...
Message-ID: <AANLkTik1dmpxjbV66wenfLhxZPdtVbhu8pt9QbT2j8sS@mail.gmail.com>

Nothing required actually.
The firmware is preloaded.Just configure the Nanobts using the installation
CD given.
Some jar file is there for configuring part.



> https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>        openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>        openbsc-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
>   1. Re: How to download firmware and configure NanoBTS the first
>      time... (Harald Welte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 16 Feb 2011 22:52:33 +0100
> From: Harald Welte <laforge at gnumonks.org>
> Subject: Re: How to download firmware and configure NanoBTS the first
>        time...
> To: Omar Atia <omar.atia at its.ws>
> Cc: 'Peter Hasse' <peter.hasse at fokus.fraunhofer.de>,
>        openbsc at lists.osmocom.org
> Message-ID: <20110216215233.GO25856 at prithivi.gnumonks.org>
> Content-Type: text/plain; charset=us-ascii
>
> Omar,
>
> how should we know in what you get your particular nanoBTS units delivered?
>
> You have to talk to your supplier about that.
>
> For all I know, it is customary for the nanoBTS to ship with pre-installed
> firmware.  Based on your support contract with ip.access you may receive
> firmware updates from time to time, which you can then apply either using
> tools from ip.access or using our ipaccess-config.   Our tool is of course
> not officially recognized/authorized/recommended/endorsed for this purpose.
>
> Regards,
>        Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 26, Issue 15
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110223/3e5b578f/attachment.htm>

From openbsc at ngolde.de  Tue Feb  1 20:15:13 2011
From: openbsc at ngolde.de (Nico Golde)
Date: Tue, 1 Feb 2011 21:15:13 +0100
Subject: GPRS - local and foreign TLLIs
In-Reply-To: <20110123180155.GH5499@prithivi.gnumonks.org>
References: <20110121064403.18fa0913@c7h5n3o6.sofago.net>
	<20110123180155.GH5499@prithivi.gnumonks.org>
Message-ID: <20110201201513.GA10654@pool.math.tu-berlin.de>

Hi,
* Harald Welte <laforge at gnumonks.org> [2011-01-25 14:59]:
> On Fri, Jan 21, 2011 at 06:44:03AM +0100, Luca Melette wrote:
> 
> > after setting up a nanoBTS with OpenBSC/SGSN/GGSN,
> > I had some troubles trying to connect my smartphone
> > to the GPRS cell.
> > 
> > Investigating the BTS-to-SGSN traffic, I saw that the
> > frames sent by the SGSN were all marked with the same
> > N(U) value (at LLC layer), the value was 0.
> > 
> > With some debug, I found that the there was a mismatch
> > in the TLLI storage, used to keep the status of attached
> > terminals.
> 
> This is probably related to some recent changes like
> f6bd340df6bcac716da78da8e35f379a7b853027 where I tried to fix the TLLI lookup
> in case a MS moves from one RA to another.  It seems instead of fixing it,
> I have made things worse.  Try to revert that patch...

I'm not completely sure if my problem is from the same 
origin (I just started to look into using openbsc with 
gprs). However this patch did not resolve my problem. What I 
see in osmo-sgsn is:
<0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA
<0017> gprs_llc.c:428 LLC SAPI=1 C   FCS=0x797ccfCMD=UI DATA
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA
<0017> gprs_llc.c:428 LLC SAPI=1 C   FCS=0xcd35c4CMD=UI DATA
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA
<0017> gprs_llc.c:428 LLC SAPI=1 C   FCS=0x804229CMD=UI DATA
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly
<0002> gprs_gmm.c:213 Starting MM timer 3370 while old timer 3370 pending
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:342 LLC TX: unknown TLLI 0xa2d141c3, creating LLME on the fly
<0016> gprs_bssgp.c:346 BSSGP TLLI=0xa2d141c3 UPLINK-UNITDATA
<0017> gprs_llc.c:428 LLC SAPI=1 C   FCS=0xfcdd5aCMD=UI DATA
<0017> gprs_llc.c:117 TLLI 0xa2d141c3 is foreign, converting to local TLLI 0xe2d141c3
<0017> gprs_llc.c:700 LLC RX: unknown TLLI 0x08x, creating LLME on the fly
<0002> gprs_gmm.c:213 Starting MM timer 3370 while old timer 3370 pending

openbsc before:
<0005> abis_nm.c:537 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) 

Which will repeat over and over again as long as the MS tries to connect.
There is only one RA in this scenario.

As mentioned I just started looking into gprs so any pointer 
on how to debug this further or add missing information are 
welcome. Apologies for hijacking this thread if this is a 
different problem.

Cheers
Nico



From luca at srlabs.de  Tue Feb  1 20:47:42 2011
From: luca at srlabs.de (Luca Melette)
Date: Tue, 1 Feb 2011 21:47:42 +0100
Subject: GPRS - local and foreign TLLIs
In-Reply-To: <20110201201513.GA10654@pool.math.tu-berlin.de>
References: <20110121064403.18fa0913@c7h5n3o6.sofago.net>
	<20110123180155.GH5499@prithivi.gnumonks.org>
	<20110201201513.GA10654@pool.math.tu-berlin.de>
Message-ID: <20110201214742.39edff06@c7h5n3o6.sofago.net>

On Tue, 1 Feb 2011 21:15:13 +0100
Nico Golde <openbsc at ngolde.de> wrote:

Hi Nico,

> I'm not completely sure if my problem is from the same 
> origin (I just started to look into using openbsc with 
> gprs). However this patch did not resolve my problem.

This is what I've done.

diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 7991f4c..969c224 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -126,7 +126,7 @@ static struct gprs_llc_lle
*lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi) {
        struct gprs_llc_llme *llme;

-       tlli = tlli_foreign2local(tlli);
+       //tlli = tlli_foreign2local(tlli);

        llist_for_each_entry(llme, &gprs_llc_llmes, list) {
                if (llme->tlli == tlli || llme->old_tlli == tlli)

Let me know if it works for you.

Cheers,

LM



From openbsc at ngolde.de  Thu Feb  3 11:12:21 2011
From: openbsc at ngolde.de (Nico Golde)
Date: Thu, 3 Feb 2011 12:12:21 +0100
Subject: GPRS - local and foreign TLLIs
In-Reply-To: <20110201214742.39edff06@c7h5n3o6.sofago.net>
References: <20110121064403.18fa0913@c7h5n3o6.sofago.net>
	<20110123180155.GH5499@prithivi.gnumonks.org>
	<20110201201513.GA10654@pool.math.tu-berlin.de>
	<20110201214742.39edff06@c7h5n3o6.sofago.net>
Message-ID: <20110203111221.GA25515@pool.math.tu-berlin.de>

Hi,
* Luca Melette <luca at srlabs.de> [2011-02-03 11:34]:
> On Tue, 1 Feb 2011 21:15:13 +0100 Nico Golde <openbsc at ngolde.de> wrote:
> > I'm not completely sure if my problem is from the same 
> > origin (I just started to look into using openbsc with 
> > gprs). However this patch did not resolve my problem.
> 
> This is what I've done.
[...] 
> Let me know if it works for you.

Indeed, this improved things. Thanks a lot!

Cheers
Nico



From laforge at gnumonks.org  Tue Feb  1 08:35:41 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 01 Feb 2011 11:35:41 +0300
Subject: How to obtain one of these HSL 2.75G Femtocells?
In-Reply-To: <AANLkTimiYORvnUv7eXx-sQfJvqCxhEFKFAGXKSw7eZiX@mail.gmail.com>
References: <AANLkTimiYORvnUv7eXx-sQfJvqCxhEFKFAGXKSw7eZiX@mail.gmail.com>
Message-ID: <ee0dbd13-e6c8-4e00-8a23-88d723fac24b@email.android.com>

Hi ste7an and others,

It seems HSL does not want in any way be associated with OpenBSC and actually think it is a bad thing that we have made our software interoperable with their product :(

So it seems we have to continue to look for (and/or work on) other alternatives. I have some ideas but it is too eatly to talk about it.

I do not know of anyone so far using/deploying their cell.
--
Sent from a mobile device, excuse my short response



From piyush.bhardwaj at wipro.com  Tue Feb  1 11:52:55 2011
From: piyush.bhardwaj at wipro.com (piyush.bhardwaj at wipro.com)
Date: Tue, 1 Feb 2011 17:22:55 +0530
Subject: An Enquiry
Message-ID: <BA2CAF453A0A044198A163DA6583CAB40E5968@BLR-EC-MBX01.wipro.com>


Hi, 
Can You please help me how to setup a session - packet or CS call session and capture trace messages - protocol traces , Alarms, Performance Management Counters and CDR? 

It will be very kind of you if you help me in this issue.

Regards,
Piyush


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110201/dc3c482f/attachment.htm>

From holger at freyther.de  Wed Feb  2 11:40:13 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 02 Feb 2011 12:40:13 +0100
Subject: An Enquiry
In-Reply-To: <BA2CAF453A0A044198A163DA6583CAB40E5968@BLR-EC-MBX01.wipro.com>
References: <BA2CAF453A0A044198A163DA6583CAB40E5968@BLR-EC-MBX01.wipro.com>
Message-ID: <4D49429D.3070600@freyther.de>

On 02/01/2011 12:52 PM, piyush.bhardwaj at wipro.com wrote:
> 
> Hi,
> Can You please help me how to setup a session - packet or CS call session and
> capture trace messages - protocol traces , Alarms, Performance Management
> Counters and CDR?


OpenBSC does not support data calls. You could start implementing it though,
we should have all the enum values and structs that you need to send the right
messages to the MS.




From spaar at mirider.augusta.de  Wed Feb  2 12:54:03 2011
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 02 Feb 2011 12:54:03 
Subject: An Enquiry
Message-ID: <4d4953ec.mirider@mirider.augusta.de>

Hello Holger,

On Wed, 02 Feb 2011 12:40:13 +0100, "Holger Hans Peter Freyther" <holger at freyther.de> wrote:
> 
> OpenBSC does not support data calls. You could start implementing it though,
> we should have all the enum values and structs that you need to send the right
> messages to the MS.

You mean CSD ? Then its most certainly also necessary to implement RLP
(Radio Link Protocol) which is the protocol used for non-transparent
CSD. At least I did not manage yet to get a reliable CSD connection
between two phones by just connecting the data traffic between them
(I tried transparent and non-transparent modes).

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From holger at freyther.de  Wed Feb  2 19:05:29 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 02 Feb 2011 20:05:29 +0100
Subject: An Enquiry
In-Reply-To: <4d4953ec.mirider@mirider.augusta.de>
References: <4d4953ec.mirider@mirider.augusta.de>
Message-ID: <4D49AAF9.6090105@freyther.de>

On 02/02/2011 12:54 PM, Dieter Spaar wrote:
> Hello Holger,
> 
> On Wed, 02 Feb 2011 12:40:13 +0100, "Holger Hans Peter Freyther" <holger at freyther.de> wrote:
>>
>> OpenBSC does not support data calls. You could start implementing it though,
>> we should have all the enum values and structs that you need to send the right
>> messages to the MS.
> 
> You mean CSD ? Then its most certainly also necessary to implement RLP
> (Radio Link Protocol) which is the protocol used for non-transparent
> CSD. At least I did not manage yet to get a reliable CSD connection
> between two phones by just connecting the data traffic between them
> (I tried transparent and non-transparent modes).

I had CSD in mind. The words 'packet' and 'call' triggered the enum we have
for Chan Modify and Assignment commands for Abis. I have never tried playing
with it though.



From kobayashi_maru at onlinehome.de  Wed Feb  2 18:52:27 2011
From: kobayashi_maru at onlinehome.de (Thomas Ansorg)
Date: Wed, 02 Feb 2011 19:52:27 +0100
Subject: isdnsync question
Message-ID: <1296672747.8553.7.camel@r-9djhc747gf8b40ha>

hi list,
have to sync one of my bs-11. got the hfc-s card and soldered the 2
wires. 
is any driver needed for the hfc-s? 
or is the clock always on c4io and f0io once the card is plugged in? 
the hfcmulti driver loads the e1 card, i have a bmask and a dmask
parameter in modprobe.conf. should i remove them or just hang on the
"type=0x00800"?
i have only one try, so i want to clear all possible problems before

T.
-- 
Wer Rechtschreibfehler findet, darf sie behalten!




From openbsc at ngolde.de  Thu Feb  3 12:57:42 2011
From: openbsc at ngolde.de (Nico Golde)
Date: Thu, 3 Feb 2011 13:57:42 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending process
	for specific subscribers only
Message-ID: <20110203125742.GA24978@pool.math.tu-berlin.de>

Hi,
I'm not sure how useful this patch is for others, I found it 
quite useful during my sms testing. See attached patch file.

Cheers
Nico

From nico at ngolde.de  Thu Feb  3 12:51:01 2011
From: nico at ngolde.de (Nico Golde)
Date: Thu, 3 Feb 2011 13:51:01 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending process for specific subscribers only
 misc: remove unused rc variable in subscriber_send_sms_cmd
Message-ID: <mailman.26.1641744168.42898.openbsc@lists.osmocom.org>

---
 openbsc/src/vty_interface_layer3.c |   18 +++++++++++++++++-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c
index 526ae9e..b6ada71 100644
--- a/openbsc/src/vty_interface_layer3.c
+++ b/openbsc/src/vty_interface_layer3.c
@@ -206,6 +206,22 @@ DEFUN(show_subscr,
 	return CMD_SUCCESS;
 }
 
+DEFUN(subscriber_send_pending_sms,
+      subscriber_send_pending_sms_cmd,
+      "subscriber " SUBSCR_TYPES " ID sms pending send",
+	SUBSCR_HELP "SMS Operations\n" "Send pending SMS\n")
+{
+	struct gsm_network *gsmnet = gsmnet_from_vty(vty);
+	struct gsm_subscriber *subscr = get_subscr_by_argv(gsmnet, argv[0], argv[1]);
+	struct gsm_sms *sms;
+
+	sms = db_sms_get_unsent_by_subscr(gsmnet, subscr->id, UINT_MAX);
+	if(sms)
+		gsm411_send_sms_subscr(sms->receiver, sms);
+
+	return CMD_SUCCESS;
+}
+
 DEFUN(subscriber_send_sms,
       subscriber_send_sms_cmd,
       "subscriber " SUBSCR_TYPES " ID sms send .LINE",
@@ -340,7 +356,6 @@ DEFUN(subscriber_ussd_notify,
 	struct gsm_subscriber_connection *conn;
 	struct gsm_network *gsmnet = gsmnet_from_vty(vty);
 	struct gsm_subscriber *subscr = get_subscr_by_argv(gsmnet, argv[0], argv[1]);
-	int rc;
 	int level;
 
 	if (!subscr) {
@@ -767,6 +782,7 @@ int bsc_vty_init_extra(void)
 	install_element(ENABLE_NODE, &smsqueue_max_cmd);
 	install_element(ENABLE_NODE, &smsqueue_clear_cmd);
 	install_element(ENABLE_NODE, &smsqueue_fail_cmd);
+	install_element(ENABLE_NODE, &subscriber_send_pending_sms_cmd);
 
 	return 0;
 }
-- 
1.7.2.3


--0OAP2g/MAC+5xKAE--



From holger at freyther.de  Tue Feb 15 11:49:25 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 15 Feb 2011 12:49:25 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending process
	for specific subscribers only
In-Reply-To: <20110203125742.GA24978@pool.math.tu-berlin.de>
References: <20110203125742.GA24978@pool.math.tu-berlin.de>
Message-ID: <4D5A6845.2040906@freyther.de>

On 02/03/2011 01:57 PM, Nico Golde wrote:
> Hi,
> I'm not sure how useful this patch is for others, I found it 
> quite useful during my sms testing. See attached patch file.

I think you want to call subscr_put and test for the subscriber. Would you
mind updating the patch and testing?

thanks
	holger



From openbsc at ngolde.de  Tue Feb 22 16:55:41 2011
From: openbsc at ngolde.de (Nico Golde)
Date: Tue, 22 Feb 2011 17:55:41 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending
	process for specific subscribers only
In-Reply-To: <4D5A6845.2040906@freyther.de>
References: <20110203125742.GA24978@pool.math.tu-berlin.de>
	<4D5A6845.2040906@freyther.de>
Message-ID: <20110222165541.GA25270@pool.math.tu-berlin.de>

Hi,
* Holger Hans Peter Freyther <holger at freyther.de> [2011-02-15 13:15]:
> On 02/03/2011 01:57 PM, Nico Golde wrote:
> > I'm not sure how useful this patch is for others, I found it 
> > quite useful during my sms testing. See attached patch file.
> 
> I think you want to call subscr_put and test for the subscriber. Would you
> mind updating the patch and testing?

Sorry had no time until now. Updated patch is attached.

Cheers
Nico

From nico at ngolde.de  Tue Feb 22 16:54:47 2011
From: nico at ngolde.de (Nico Golde)
Date: Tue, 22 Feb 2011 17:54:47 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending process for specific subscribers only
Message-ID: <mailman.27.1641744168.42898.openbsc@lists.osmocom.org>

---
 openbsc/src/vty_interface_layer3.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c
index a575274..6cb9cbf 100644
--- a/openbsc/src/vty_interface_layer3.c
+++ b/openbsc/src/vty_interface_layer3.c
@@ -206,6 +206,24 @@ DEFUN(show_subscr,
 	return CMD_SUCCESS;
 }
 
+DEFUN(subscriber_send_pending_sms,
+      subscriber_send_pending_sms_cmd,
+      "subscriber " SUBSCR_TYPES " ID sms pending send",
+	SUBSCR_HELP "SMS Operations\n" "Send pending SMS\n")
+{
+	struct gsm_network *gsmnet = gsmnet_from_vty(vty);
+	struct gsm_subscriber *subscr = get_subscr_by_argv(gsmnet, argv[0], argv[1]);
+	struct gsm_sms *sms;
+
+	sms = db_sms_get_unsent_by_subscr(gsmnet, subscr->id, UINT_MAX);
+	if(sms)
+		gsm411_send_sms_subscr(sms->receiver, sms);
+
+	subscr_put(subscr);
+
+	return CMD_SUCCESS;
+}
+
 DEFUN(subscriber_send_sms,
       subscriber_send_sms_cmd,
       "subscriber " SUBSCR_TYPES " ID sms send .LINE",
@@ -766,6 +784,7 @@ int bsc_vty_init_extra(void)
 	install_element(ENABLE_NODE, &smsqueue_max_cmd);
 	install_element(ENABLE_NODE, &smsqueue_clear_cmd);
 	install_element(ENABLE_NODE, &smsqueue_fail_cmd);
+	install_element(ENABLE_NODE, &subscriber_send_pending_sms_cmd);
 
 	return 0;
 }
-- 
1.7.4.1


--fdj2RfSjLxBAspz7--



From holger at freyther.de  Thu Feb 24 13:51:53 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 24 Feb 2011 14:51:53 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending	process
	for specific subscribers only
In-Reply-To: <20110222165541.GA25270@pool.math.tu-berlin.de>
References: <20110203125742.GA24978@pool.math.tu-berlin.de>	<4D5A6845.2040906@freyther.de>
	<20110222165541.GA25270@pool.math.tu-berlin.de>
Message-ID: <4D666279.5060905@freyther.de>

On 02/22/2011 05:55 PM, Nico Golde wrote:
> Hi,

> Sorry had no time until now. Updated patch is attached.

I included it for now. How big is your diff needed for your work? E.g. I think
we could include signals for RF Failures that would allow you to figure out if
the phone crashed.

holger



From openbsc at ngolde.de  Thu Feb 24 14:09:13 2011
From: openbsc at ngolde.de (Nico Golde)
Date: Thu, 24 Feb 2011 15:09:13 +0100
Subject: [PATCH] sms: introduce new command to trigger the sending
	process for specific subscribers only
In-Reply-To: <4D666279.5060905@freyther.de>
References: <20110203125742.GA24978@pool.math.tu-berlin.de>
	<4D5A6845.2040906@freyther.de>
	<20110222165541.GA25270@pool.math.tu-berlin.de>
	<4D666279.5060905@freyther.de>
Message-ID: <20110224140913.GA15816@pool.math.tu-berlin.de>

Hi,
* Holger Hans Peter Freyther <holger at freyther.de> [2011-02-24 15:07]:
> On 02/22/2011 05:55 PM, Nico Golde wrote:
> > Sorry had no time until now. Updated patch is attached.
> 
> I included it for now. How big is your diff needed for your work? E.g. I think
> we could include signals for RF Failures that would allow you to figure out if
> the phone crashed.

It was my plan to give something of that code back to you, 
it's not that much but it's quite a crude hack so far. Need 
to do some cleaning of this first.

Kind regards
Nico



From jens.david at jens-david-consulting.com  Fri Feb  4 12:15:21 2011
From: jens.david at jens-david-consulting.com (Jens David)
Date: Fri, 4 Feb 2011 13:15:21 +0100
Subject: [semi-OT] iPhone SIM access via AT+CSIM
Message-ID: <4A929DC7-0D06-4139-90E5-92E7BE5D9F03@jens-david-consulting.com>

Hello all,

I am trying to implement a bluetooth RSAP daemon for the iPhone platform.
I read your description on http://openbsc.osmocom.org/trac/wiki/A5_GSM_AT_tricks .
Unfortunately it does not seem to work on my phone.
It always returns error code 0x6E00 for class 0xA0 (GSM application) commands:

> AT+CSIM=14,"A0A40000023F00"
> +CSIM: 4,"6E00"

Which iPhone version and "baseband" firmware was used when doing these
experiments? Any further tips?

By the way, it is better to use one of the virtual serial lines,
e.g. /dev/dlci.spi-baseband.extra_13 to access the X-Gold 608 when doing normal
stuff rather than using the real UART interfaces (/dev/tty.debug etc.) because
one does not need to unload CommCenter to have a reliable connection.

   --j

--
Jens David, DG1KJD
jens.david at jens-david-consulting.com
http://www.jens-david-consulting.com






From 246tnt at gmail.com  Sat Feb  5 08:43:34 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 5 Feb 2011 09:43:34 +0100
Subject: [semi-OT] iPhone SIM access via AT+CSIM
In-Reply-To: <4A929DC7-0D06-4139-90E5-92E7BE5D9F03@jens-david-consulting.com>
References: <4A929DC7-0D06-4139-90E5-92E7BE5D9F03@jens-david-consulting.com>
Message-ID: <AANLkTikf6c7+h=8UGJdvGuV4iB2kD3q=0dF7P3xaT-O6@mail.gmail.com>

Hi,

> It always returns error code 0x6E00 for class 0xA0 (GSM application) commands:
>
>> AT+CSIM=14,"A0A40000023F00"
>> +CSIM: 4,"6E00"
>
> Which iPhone version and "baseband" firmware was used when doing these
> experiments? Any further tips?

It was on an iPhone 1 and with whatever firmware was the latest 18
month ago. (with a both jailbroken and unlocked iphone)

Cheers,

    Sylvain



From jens.david at jens-david-consulting.com  Sat Feb  5 12:43:43 2011
From: jens.david at jens-david-consulting.com (Jens David)
Date: Sat, 5 Feb 2011 13:43:43 +0100
Subject: [semi-OT] iPhone SIM access via AT+CSIM
In-Reply-To: <AANLkTikf6c7+h=8UGJdvGuV4iB2kD3q=0dF7P3xaT-O6@mail.gmail.com>
References: <4A929DC7-0D06-4139-90E5-92E7BE5D9F03@jens-david-consulting.com>
	<AANLkTikf6c7+h=8UGJdvGuV4iB2kD3q=0dF7P3xaT-O6@mail.gmail.com>
Message-ID: <CC70F416-C761-4E1D-BEF5-23F8936E09C7@jens-david-consulting.com>

Thank you, Sylvain.

Meanwhile I did some more experimenting and found that the symptoms are also SIM card related.
It seems that the 0x6E00 problem only occurs with USIMs (UMTS) that also (instead?) support the
0x00 class. Maybe the observed effects are part of some intended locking mechanism that takes place
either on the SIM card or within the "baseband" firmware. I did my tests with 3GS FWs 05.13.04 and
05.11.07 by the way.

  --j


Am 05.02.2011 um 09:43 schrieb Sylvain Munaut:

> Hi,
> 
>> It always returns error code 0x6E00 for class 0xA0 (GSM application) commands:
>> 
>>> AT+CSIM=14,"A0A40000023F00"
>>> +CSIM: 4,"6E00"
>> 
>> Which iPhone version and "baseband" firmware was used when doing these
>> experiments? Any further tips?
> 
> It was on an iPhone 1 and with whatever firmware was the latest 18
> month ago. (with a both jailbroken and unlocked iphone)
> 
> Cheers,
> 
>    Sylvain
> 

--
Jens David, DG1KJD
jens.david at jens-david-consulting.com
http://www.jens-david-consulting.com






From laforge at gnumonks.org  Sat Feb  5 15:05:40 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 5 Feb 2011 16:05:40 +0100
Subject: [ANN] Config file change with mISDN / BS-11
Message-ID: <20110205150540.GG21929@prithivi.gnumonks.org>

Notice to all OpenBSC users with mISDN / BS-11:

I've had to introduce some new config file statements in order for the
upcoming DAHDI support.

This means if you update beyond git revision
3016d9f299ea4cfc8961376d20862b9418cfb059, openbsc will not start with
an old 'openbsc.cfg' file.

You will have to add the following two lines to make it work again
(like shonw in the new openbsc.cfg.1-1):

==============
e1_input
 e1_line 0 driver misdn
==============

Sorry for that inconvenience.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sat Feb  5 19:35:37 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 5 Feb 2011 20:35:37 +0100
Subject: OpenBSC DAHDI support now in master
Message-ID: <20110205193537.GI21929@prithivi.gnumonks.org>

Hi!

Today I've been working on improving + cleaning up the DAHDI work that
had been done last year by Xavier Carcelle and Matthew Fredrickson, which in
turn uses some simplistic LAPD implementation by Oystein Homelien.

It now seems to be working fine, at least for my TE110P card and a BS-11
in 2-TRX configuration.  Haven't tried multi-drop yet.

All you need to do is to
 * make sure your dahdi/user.h is found in the include path
 * build openbsc
 * configure your /etc/dahdi/system.conf according to your T1/E1 physical
   setup
 * check that dahdi_tool shows no Alarms for the physical line
 * use e.g. openbsc.cfg.1-1 as sample and change 'e1_line 0 driver misdn' to
   'e1_line 0 driver dahdi'

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From matt at fredricknet.net  Sat Feb  5 21:28:31 2011
From: matt at fredricknet.net (Matthew Fredrickson)
Date: Sat, 5 Feb 2011 15:28:31 -0600
Subject: OpenBSC DAHDI support now in master
In-Reply-To: <20110205193537.GI21929@prithivi.gnumonks.org>
References: <20110205193537.GI21929@prithivi.gnumonks.org>
Message-ID: <AANLkTinV-NU_E8Uz4DTU2_jjrWDDDZV+FDD6EfqUjjg-@mail.gmail.com>

Thanks so much for doing this!  Sorry about not merging it myself, I
never ended up purchasing equipment for myself to test with and so I
have not had as much time and opportunity as I had hoped I would to do
this.

If there are any questions I can answer to assist, I would be glad to
do so.  Thanks for taking up my orphaned branch and merging it back
in.

Hope all is well with you.

Matthew Fredrickson

On Sat, Feb 5, 2011 at 1:35 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi!
>
> Today I've been working on improving + cleaning up the DAHDI work that
> had been done last year by Xavier Carcelle and Matthew Fredrickson, which in
> turn uses some simplistic LAPD implementation by Oystein Homelien.
>
> It now seems to be working fine, at least for my TE110P card and a BS-11
> in 2-TRX configuration. ?Haven't tried multi-drop yet.
>
> All you need to do is to
> ?* make sure your dahdi/user.h is found in the include path
> ?* build openbsc
> ?* configure your /etc/dahdi/system.conf according to your T1/E1 physical
> ? setup
> ?* check that dahdi_tool shows no Alarms for the physical line
> ?* use e.g. openbsc.cfg.1-1 as sample and change 'e1_line 0 driver misdn' to
> ? 'e1_line 0 driver dahdi'
>
> Regards,
> ? ? ? ?Harald
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>
>



From gus at bourg.net  Mon Feb  7 19:17:50 2011
From: gus at bourg.net (Gus Bourg)
Date: Mon, 7 Feb 2011 19:17:50 +0000 (UTC)
Subject: Question about Dahdi system.conf
Message-ID: <Pine.LNX.4.64.1102071913530.5001@carrera>

Hi,

I've been playing with Dahdi and OpenBSC (I have an old T100P card) and 
something I'm a little confused about is what is the proper configuration 
for system.conf?

Does dahdi itself take care of the hdlc/lapd signalling (in which case I'd 
expect the signalling channel to be set as dchan in 
/etc/dahdi/system.conf) or is openbsc taking care of the hdlc/lapd 
signalling (in which case I'd expect the signalling channel to be set as 
clear)?


Thanks,
Gus Bourg



From matt at fredricknet.net  Mon Feb  7 20:45:44 2011
From: matt at fredricknet.net (Matthew Fredrickson)
Date: Mon, 7 Feb 2011 14:45:44 -0600
Subject: Question about Dahdi system.conf
In-Reply-To: <Pine.LNX.4.64.1102071913530.5001@carrera>
References: <Pine.LNX.4.64.1102071913530.5001@carrera>
Message-ID: <AANLkTikMqZAxbL=CyRKhrOEt5MyL-e4zN8DBatrhkff8@mail.gmail.com>

Dahdi takes care of the signalling, in a manner of speaking.

For OpenBSC, the signalling channel should be a "dchan".

Matthew Fredrickson
Digium, Inc.

On Mon, Feb 7, 2011 at 1:17 PM, Gus Bourg <gus at bourg.net> wrote:
> Hi,
>
> I've been playing with Dahdi and OpenBSC (I have an old T100P card) and
> something I'm a little confused about is what is the proper configuration
> for system.conf?
>
> Does dahdi itself take care of the hdlc/lapd signalling (in which case I'd
> expect the signalling channel to be set as dchan in /etc/dahdi/system.conf)
> or is openbsc taking care of the hdlc/lapd signalling (in which case I'd
> expect the signalling channel to be set as clear)?
>
>
> Thanks,
> Gus Bourg
>
>



From laforge at gnumonks.org  Tue Feb  8 18:25:21 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 8 Feb 2011 19:25:21 +0100
Subject: Question about Dahdi system.conf
In-Reply-To: <Pine.LNX.4.64.1102071913530.5001@carrera>
References: <Pine.LNX.4.64.1102071913530.5001@carrera>
Message-ID: <20110208182521.GM4847@prithivi.gnumonks.org>

Hi!

On Mon, Feb 07, 2011 at 07:17:50PM +0000, Gus Bourg wrote:

> Does dahdi itself take care of the hdlc/lapd signalling (in which
> case I'd expect the signalling channel to be set as dchan in
> /etc/dahdi/system.conf) or is openbsc taking care of the hdlc/lapd
> signalling (in which case I'd expect the signalling channel to be
> set as clear)?

Normally you'd do HDLC inside DAHDI and do LAPD inside OpenBSC.

This is what happens if you do 'dchan=1'.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Tue Feb  8 18:02:46 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 8 Feb 2011 19:02:46 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
Message-ID: <20110208180246.GL4847@prithivi.gnumonks.org>

Hi all,

Some people have been working together in order to finally start with
support of the Ericsson RBS2308 (and similar models) in OpenBSC.

The biggest issue so far is bringing up the actualy LAPD on the E1/T1 link.
It seems Ericsson is using some dynamic timeslot configuration between BSC
and BTS, so unlike e.g. Siemens, you cannot explicitly configure the OML E1
timeslot on the BTS using local configuration tools.

The current working assumption is: Somehow the BSC produces bit-patterns on the
E1 link and uses them to let the BTS know where to start LAPD for OML.

One contributor was friendly enough to do raw bit-traces of a Racal 6113
connected to the Ericsson RBS, and they look like this:

Racal to BTS 

Initialization

openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
*
00092e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa 55aa
00092f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0009600 ffff ffff ffff ffff ffff ffff ffff 7e7e
0009610 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
00096b0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e
00096c0 3e5f 49ce cfef cfcf cfcf cfcf cfcf cfcf
00096d0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*


I've written a small C program to do soft-hdlc decode.

* a pattern of alternating bits (0xaa)
* a pattern of all-1 bits(0xff)
* a sequence of FLAG symbols (01111110)
* a HDLC message FA 7D 7F 4E F2, which is a TEI=62/SAPI=62 SABME
  (SAPI 62 / TEI62 is configured for OML on the BTS)

The interesting part is:

1) this is a SABME from BSC to BTS, whereas GSM 08.56
   specifically says the BTS is the TE and the BSC the NT
2) we have not seen any TEI manager related messages(L2ML)


Keep alives afterwards, about every 8 seconds

001d5e0 cfcf cfcf cfcf ebcb 04e4 a805 f323 f3f3
001d5f0 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0031630 f3f3 f2f3 f9fa 0101 086a fcfc fcfc fcfc
0031640 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
0045680 fcfc fcfc fcfc fcfc fcfc fcfc bebe 4040
0045690 825a 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
00456a0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
*
00596e0 3f3f 2f3f 90af 1610 8fa0 cfcf cfcf cfcf
00596f0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
006d730 cfcf cfcf cfcf cfcf cbcf e4eb 0504 23a8
006d740 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0081790 faf2 01f9 6a01 fc08 fcfc fcfc fcfc fcfc
00817a0 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
00957e0 fcfc fcfc fcfc befc 40be 5a40 3f82 3f3f
00957f0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f

If you decode this, you get

FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 21 AC (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)


If we look at the BTS to Racal 6113 side:

Initialization

openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
000fe00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e5e7 f3f5
000fe10 1039 f971 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
000fe20 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*


Keep Alives, every 8 seconds


0023e40 f9f9 f9f9 f9f9 f9f9 f9f9 7c7d 8080 04b5
0023e50 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0037ea0 5f5f 2020 412d 9f1f 9f9f 9f9f 9f9f 9f9f
0037eb0 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
004bef0 9f9f 9f9f 9f9f 9f9f 979f c8d7 0b08 4750
004bf00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
005ff40 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 f5e5
005ff50 02f2 d402 f911 f9f9 f9f9 f9f9 f9f9 f9f9
005ff60 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
0073fa0 f9f9 f9f9 f9f9 7c7d 8080 04b5 7e7e 7e7e
0073fb0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0087ff0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e 205f
0088000 2d20 1f41 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
0088010 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
009c050 9f9f 9f9f 979f c8d7 0b08 4750 e7e7 e7e7
009c060 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*

Decoded, we get:

FA 7D 73 60 3A (LAPD UA)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 25 25 AD 20 (LAPD unknown??)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)

So as a summary, it seems that 

1) the BSC applies some magic pattern (0xaa / 0xff)
2) the BSC establishes the LAPD session for OML TEI/SAPI
3) there is no L2ML, contrary to lots of Ericsson Abis documentation
   that you can find online.

We'll continue our attempts and see if we can get the OML up...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Tue Feb  8 23:19:12 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Feb 2011 00:19:12 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110208180246.GL4847@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
Message-ID: <20110208231912.GU4847@prithivi.gnumonks.org>

Hi all,

I've connected my 6113 to a DAHDI card in raw mode and sampled the
data, it can be found (together with some tools) in osmo-rbs.git
on git.osmocom.org

To me, it seems as if it simply sending a continuous sequence of SABM
commands for TEI=62/SAPI=62 on timeslot 1, interspaced with idle pattern
of FLAG bytes.

However, if I attempt to send this sequence (using dslot=1, i.e. the HDLC
support within DAHDI) and the rbs_sabm.c program on /dev/dahdi/1), there is no
response from the RBS.

On all other timeslots, the 6113 will just produce a default pattern of
alternating 0 and 1 bits (0xAAAAAAA).

We still must be doing something wrong here...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From matt at fredricknet.net  Tue Feb  8 23:54:09 2011
From: matt at fredricknet.net (Matthew Fredrickson)
Date: Tue, 8 Feb 2011 17:54:09 -0600
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110208231912.GU4847@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<20110208231912.GU4847@prithivi.gnumonks.org>
Message-ID: <AANLkTikS-1Df+afpbzpSrMUCpyCRTYNze87brHq4YEgS@mail.gmail.com>

One thing I noticed in your sample program is the size of the frame
you're sending to DAHDI.  Try adding 2 to the size parameter when you
write() on the device (assuming you're still using dahdi HDLC).

Also, you must append 2 empty bytes to the frame you write down to the
DAHDI dchan as a placeholder for the CRC.

So change:

-const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F };

to:

+const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F, 0x00, 0x00 };

And that should take care of both things I mentioned above.

Be warned though, a DAHDI channel set to be a "dchan" will send HDLC
idle bit patterns when no data is sent (0x7e) on it.  This means that
if you need to send 0xff or 0xaa or some pattern like you posted
above, you will need to use custom HDLC code, or modify the DAHDI hdlc
code to send your required idle pattern.

Matthew Fredrickson

On Tue, Feb 8, 2011 at 5:19 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi all,
>
> I've connected my 6113 to a DAHDI card in raw mode and sampled the
> data, it can be found (together with some tools) in osmo-rbs.git
> on git.osmocom.org
>
> To me, it seems as if it simply sending a continuous sequence of SABM
> commands for TEI=62/SAPI=62 on timeslot 1, interspaced with idle pattern
> of FLAG bytes.
>
> However, if I attempt to send this sequence (using dslot=1, i.e. the HDLC
> support within DAHDI) and the rbs_sabm.c program on /dev/dahdi/1), there is no
> response from the RBS.
>
> On all other timeslots, the 6113 will just produce a default pattern of
> alternating 0 and 1 bits (0xAAAAAAA).
>
> We still must be doing something wrong here...
>
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>
>



From laforge at gnumonks.org  Wed Feb  9 20:25:10 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Feb 2011 21:25:10 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <AANLkTikS-1Df+afpbzpSrMUCpyCRTYNze87brHq4YEgS@mail.gmail.com>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<20110208231912.GU4847@prithivi.gnumonks.org>
	<AANLkTikS-1Df+afpbzpSrMUCpyCRTYNze87brHq4YEgS@mail.gmail.com>
Message-ID: <20110209202510.GS5246@prithivi.gnumonks.org>

Hi again,

On Tue, Feb 08, 2011 at 05:54:09PM -0600, Matthew Fredrickson wrote:
> One thing I noticed in your sample program is the size of the frame
> you're sending to DAHDI.  Try adding 2 to the size parameter when you
> write() on the device (assuming you're still using dahdi HDLC).
> 
> Also, you must append 2 empty bytes to the frame you write down to the
> DAHDI dchan as a placeholder for the CRC.

ok, thanks a lot.  I've modified the program accordingly.  However, still
no success in getting any response from the RBS2308.

On the other hand, on a RBS2401 this works.  As soon as you send something
like one SABME per second on timeslot 1, after a couple of seconds the RBS
will start answering using UA and later I-frames.

Now the only mystery remains about the RBS2308.

And somebody (*hint to the list*) will still have to write a OM2000 BSC-side
implementation, basically what we have with abis_nm is for TS 12.21, but for
the proprietary Ericsson OM2000 protocol (details see my wireshark dissector).

But at least for the 2401 we should have all required information now.

Regards,
	Harrald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From matt at fredricknet.net  Tue Feb  8 23:54:56 2011
From: matt at fredricknet.net (Matthew Fredrickson)
Date: Tue, 8 Feb 2011 17:54:56 -0600
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110208180246.GL4847@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
Message-ID: <AANLkTin-NgKsqFMUe-L_N=gXTUZYh3rijovfwx73bKTK@mail.gmail.com>

Is the data dump output from /dev/dahdi/1 the output of a single
timeslot (bchan=1), or this in clear channel mode with all timeslots
bonded together in DAHDI (clear=1-31)?

Matthew Fredrickson

On Tue, Feb 8, 2011 at 12:02 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi all,
>
> Some people have been working together in order to finally start with
> support of the Ericsson RBS2308 (and similar models) in OpenBSC.
>
> The biggest issue so far is bringing up the actualy LAPD on the E1/T1 link.
> It seems Ericsson is using some dynamic timeslot configuration between BSC
> and BTS, so unlike e.g. Siemens, you cannot explicitly configure the OML E1
> timeslot on the BTS using local configuration tools.
>
> The current working assumption is: Somehow the BSC produces bit-patterns on the
> E1 link and uses them to let the BTS know where to start LAPD for OML.
>
> One contributor was friendly enough to do raw bit-traces of a Racal 6113
> connected to the Ericsson RBS, and they look like this:
>
> Racal to BTS
>
> Initialization
>
> openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
> 0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
> *
> 00092e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa 55aa
> 00092f0 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0009600 ffff ffff ffff ffff ffff ffff ffff 7e7e
> 0009610 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
> *
> 00096b0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e
> 00096c0 3e5f 49ce cfef cfcf cfcf cfcf cfcf cfcf
> 00096d0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
> *
>
>
> I've written a small C program to do soft-hdlc decode.
>
> * a pattern of alternating bits (0xaa)
> * a pattern of all-1 bits(0xff)
> * a sequence of FLAG symbols (01111110)
> * a HDLC message FA 7D 7F 4E F2, which is a TEI=62/SAPI=62 SABME
> ?(SAPI 62 / TEI62 is configured for OML on the BTS)
>
> The interesting part is:
>
> 1) this is a SABME from BSC to BTS, whereas GSM 08.56
> ? specifically says the BTS is the TE and the BSC the NT
> 2) we have not seen any TEI manager related messages(L2ML)
>
>
> Keep alives afterwards, about every 8 seconds
>
> 001d5e0 cfcf cfcf cfcf ebcb 04e4 a805 f323 f3f3
> 001d5f0 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
> *
> 0031630 f3f3 f2f3 f9fa 0101 086a fcfc fcfc fcfc
> 0031640 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
> *
> 0045680 fcfc fcfc fcfc fcfc fcfc fcfc bebe 4040
> 0045690 825a 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
> 00456a0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
> *
> 00596e0 3f3f 2f3f 90af 1610 8fa0 cfcf cfcf cfcf
> 00596f0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
> *
> 006d730 cfcf cfcf cfcf cfcf cbcf e4eb 0504 23a8
> 006d740 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
> *
> 0081790 faf2 01f9 6a01 fc08 fcfc fcfc fcfc fcfc
> 00817a0 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
> *
> 00957e0 fcfc fcfc fcfc befc 40be 5a40 3f82 3f3f
> 00957f0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
>
> If you decode this, you get
>
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 21 AC (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
>
>
> If we look at the BTS to Racal 6113 side:
>
> Initialization
>
> openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
> 0000000 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
> *
> 000fe00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e5e7 f3f5
> 000fe10 1039 f971 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
> 000fe20 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
> *
>
>
> Keep Alives, every 8 seconds
>
>
> 0023e40 f9f9 f9f9 f9f9 f9f9 f9f9 7c7d 8080 04b5
> 0023e50 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
> *
> 0037ea0 5f5f 2020 412d 9f1f 9f9f 9f9f 9f9f 9f9f
> 0037eb0 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
> *
> 004bef0 9f9f 9f9f 9f9f 9f9f 979f c8d7 0b08 4750
> 004bf00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
> *
> 005ff40 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 f5e5
> 005ff50 02f2 d402 f911 f9f9 f9f9 f9f9 f9f9 f9f9
> 005ff60 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
> *
> 0073fa0 f9f9 f9f9 f9f9 7c7d 8080 04b5 7e7e 7e7e
> 0073fb0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
> *
> 0087ff0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e 205f
> 0088000 2d20 1f41 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
> 0088010 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
> *
> 009c050 9f9f 9f9f 979f c8d7 0b08 4750 e7e7 e7e7
> 009c060 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
> *
>
> Decoded, we get:
>
> FA 7D 73 60 3A (LAPD UA)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 25 25 AD 20 (LAPD unknown??)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
> FA 7D 01 01 AD 20 (LAPD RR)
>
> So as a summary, it seems that
>
> 1) the BSC applies some magic pattern (0xaa / 0xff)
> 2) the BSC establishes the LAPD session for OML TEI/SAPI
> 3) there is no L2ML, contrary to lots of Ericsson Abis documentation
> ? that you can find online.
>
> We'll continue our attempts and see if we can get the OML up...
>
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>
>



From laforge at gnumonks.org  Wed Feb  9 09:54:24 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Feb 2011 10:54:24 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <AANLkTin-NgKsqFMUe-L_N=gXTUZYh3rijovfwx73bKTK@mail.gmail.com>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<AANLkTin-NgKsqFMUe-L_N=gXTUZYh3rijovfwx73bKTK@mail.gmail.com>
Message-ID: <20110209095424.GV4847@prithivi.gnumonks.org>

On Tue, Feb 08, 2011 at 05:54:56PM -0600, Matthew Fredrickson wrote:
> Is the data dump output from /dev/dahdi/1 the output of a single
> timeslot (bchan=1), or this in clear channel mode with all timeslots
> bonded together in DAHDI (clear=1-31)?

this is bchan=1 output of the single timeslot
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Wed Feb  9 15:29:06 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Feb 2011 16:29:06 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110208180246.GL4847@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
Message-ID: <20110209152906.GI5246@prithivi.gnumonks.org>

Hi all,

based on some more traces taken from a different Racal 6113 in RBS2000 mode,
there is a consistent observation:

> 1) the BSC applies some magic pattern (0xaa / 0xff)
> 2) the BSC establishes the LAPD session for OML TEI/SAPI
> 3) there is no L2ML, contrary to lots of Ericsson Abis documentation
>    that you can find online.

The 0xAA /0xFF pattern is only applied once at the very start-up of the
6113.  After that, the 6113 loops in sending SABM (SAPI=62/TEI=62)
messages in a lot of 0x7E LAPD idle pattern.

So my assumption is that the initial 0xAA / 0xFF is more like an artefact
of the 6113 starting up or initializing its A-bis timeslots, whereas the
repeated SABM messages are what the BTS/RBS locks onto.

However, using a small demo program (rbs_sabm.c) sending the exact same
SABM messages (utilizing the in-kernel DAHDI HDLC in dslot=1) does not
trigger any response from the RBS.  The RBS just simply continues to send
its 0x7F pattern on all timeslots.

The physical connection is definitely fine, i.e. if we enable TNOM on TS 24
of the RBS, we can clearly see valid HDLC traffic on TS24 - but of course
only for this TNOM and not for OML.

Also, if the RBS boots, the 0x7F pattern disappears for some time.

I'm right now really out of ideas.  Applying the 0xAA / 0xFF pattern at the
very beginning is difficult using any standard DAHDI/mISDN HDLC implementation,
as you can either switch the line into raw mode and then transmit that pattern,
or switch into d-channel mode where the driver will do the HDLC framing but
generate the default 0x7E idle pattern only.  And as indicated, I really don't
believe it will make any difference, as it only happens on 6113 start, but
not during the lopp while it waits for the RBS connection to establish.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sun Feb 13 09:16:49 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Feb 2011 10:16:49 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110209152906.GI5246@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<20110209152906.GI5246@prithivi.gnumonks.org>
Message-ID: <20110213091649.GY5246@prithivi.gnumonks.org>

Hi all,

meanwhile some things have happened, so here some update:

1) activating the OML link to the IXU/DXU in the Ericsson BTS works
   much more reliably from a Racal 6113 than from our own code sending
   a flood of SABME on TS0.  This might be DAHDI related.

2) after the BTS has seen SABME for TEI=62/SAPI=62, it will memorize this
   and we can switch the cable from the 6113 to our DAHDI+OpenBSC setup

3) The current laforge/rbs2000 branch will establish the primary OML Link
   and will start to initialize the CF (central function).  After that, you
   will have to manually use the telnet interface with a sequence of commands
   like this:

	enable
	bts 0 om2000 class is 0 255 0
	connect-command
	is-cof-req
	enable-request

   At this point the TRX0 should be connected to the same signalling slot
   and based on the protocol traces I've done between the 6113 and the BTS,
   we should now establish a _second_ OML connection, but this time to TEI=0
   (SAPI still 62).  No code for this exists yet in the laforge/rbs2000 branch.

For some reason the last operation (SABME to SAPI=62/TEI=0) does not work on my
BTS, neither with the Racal 6113 nor from custom code.  So I believe something
is wrong with the actual hardware setup...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sun Feb 13 09:34:51 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Feb 2011 10:34:51 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110213091649.GY5246@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<20110209152906.GI5246@prithivi.gnumonks.org>
	<20110213091649.GY5246@prithivi.gnumonks.org>
Message-ID: <20110213093451.GZ5246@prithivi.gnumonks.org>

On Sun, Feb 13, 2011 at 10:16:49AM +0100, Harald Welte wrote:
> Hi all,
> 
> meanwhile some things have happened, so here some update:
> 
> 1) activating the OML link to the IXU/DXU in the Ericsson BTS works
>    much more reliably from a Racal 6113 than from our own code sending
>    a flood of SABME on TS0.  This might be DAHDI related.

I have just checked my logs from the MA-10 protocol analyzer. It sends SABME
frames at intervals of 0.3 seconds.  If I use the same timing from our
rbs_init.c, I can initialize the A-bis path to the RBS 2308.

Quite strange that apparently 1 second delay is not sufficient, and 50
milliseconds is too often...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Sun Feb 13 14:55:02 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Feb 2011 15:55:02 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110213093451.GZ5246@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
	<20110209152906.GI5246@prithivi.gnumonks.org>
	<20110213091649.GY5246@prithivi.gnumonks.org>
	<20110213093451.GZ5246@prithivi.gnumonks.org>
Message-ID: <20110213145502.GA5246@prithivi.gnumonks.org>

Ok guys,

I'm giving up for now, definitely have to take care of more important work
right now :(

The status is as follows:
* You need 'dchan=1,4' in your /etc/dahdi/system.conf

* laforge/rbs2000 has been merged master as it doesn't touch common code

* OpenBSC happily 'initializes' the A-bis link now (IXU OML LAPD+TEI 62)

* The IS MO can (must) be configured manually via the VTY (see last mail)

* SABM on TEI=0/SAPI=62 (TS0) as well as TSI=1/SAPI=62 (TS4) for TRX0
  and TRX1 fail. OpenBSC now tries to establish those SAPIs according
  to the TRX you configure in openbsc.cfg

* If I configure the IS to route (524,16,4), i.e. connect ICP 524..527 to
  ICP 16..19, I get a valid HDLC idle pattern (0x7e) on TS 4, which confirms
  the assumption that the ICP assignments are as follows:
	ICP  0..3  : E1 Port A TS 1
	ICP  4..7  : E1 Port A TS 2
	ICP  8..11 : E1 Port A TS 3
	ICP 12..15 : E1 Port A TS 4
	...
	ICP 512..515 : TRX 0 Signalling
	ICP 516..519 : TRX 0 Um TS 0..3
	ICP 520..523 : TRX 0 Um TS 4..7
	ICP 524..527 : TRX 1 Signalling
	ICP 528..531 : TRX 1 Um TS 0..3
	ICP 532..535 : TRX 1 Um TS 4..7
	...

* The DCP numbers referenced in some documents are DCP = ICP / 4

* Further observations:
  * Unused traffic slots seem to generate raw bit pattern 0x5555
  * Unallocated slots (no assignment in IS) generate raw bit pattern 0x5454

If anyone wants to play with it, feel free to do so.  I would definitely
want to know if anyone else gets the SAPI 62 to TRX0 or TRX1 up.  As in my
setup not even the Racal 6113 can get that SAPI up, I think I may be facing
soem malfunction/misconfiguration in my RBS.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Mon Feb 14 16:21:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 14 Feb 2011 17:21:56 +0100
Subject: Ericsson RBS2308 support / Status on LAPD
In-Reply-To: <20110208180246.GL4847@prithivi.gnumonks.org>
References: <20110208180246.GL4847@prithivi.gnumonks.org>
Message-ID: <20110214162156.GM5246@prithivi.gnumonks.org>

Finally,

all problems regarding LAPD and (IS) Interface Switch seem to have been
solved.

Using current openbsc 'master' branch and the openbsc.cfg.rbs2308-4trx
in it, I am able to initialize all 9 LAPD links (1x IXU-OML, 4x TRX-OML,
4x TRX-RSL) to the RBS 2308.

The IS configuration can now be done as part of the BTS configuration in
the OpenBSC VTY.  The config file example configures like follows:

E1/T1 TS  1: IXU-OML, TRX0 (OML+RSL)
E1/T1 TS  2: TRX0 TS0..3
E1/T1 TS  3: TRX0 TS4..7
E1/T1 TS  4: TRX1 (OML+RSL)
E1/T1 TS  5: TRX1 TS0..3
E1/T1 TS  6: TRX1 TS4..7
E1/T1 TS  7: TRX2 (OML+RSL)
E1/T1 TS  8: TRX2 TS0..3
E1/T1 TS  9: TRX2 TS4..7
E1/T1 TS 10: TRX3 (OML+RSL)
E1/T1 TS 11: TRX3 TS0..3
E1/T1 TS 12: TRX3 TS4..7

If you want to aggregate the OML+RSL links onto one E1 timeslot, the CON
unit has to be used.  While you can already enter CON configuration on the
VTY, it is not yet sent to the BTS.

What's missing now is the OML bring-up of the TRX + TS (TRXC,RX,TX,TS Managed
Objects).  After that, it should be ready to go for regular RSL messages.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From kobayashi_maru at onlinehome.de  Tue Feb  8 21:39:47 2011
From: kobayashi_maru at onlinehome.de (Thomas Ansorg)
Date: Tue, 08 Feb 2011 22:39:47 +0100
Subject: CCCH on C0?
Message-ID: <1297201187.9578.3.camel@r-9djhc747gf8b40ha>

hi list,
i came over line 523 in gsm_data.h: 
	/* CCCH is on C0 */
	struct gsm_bts_trx *c0;

could this be the reason why a bs-11 without aktivated trx0 dont work /
isnt seen by handy?

T.
-- 
Wer Rechtschreibfehler findet, darf sie behalten!




From laforge at gnumonks.org  Wed Feb  9 09:55:23 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 9 Feb 2011 10:55:23 +0100
Subject: CCCH on C0?
In-Reply-To: <1297201187.9578.3.camel@r-9djhc747gf8b40ha>
References: <1297201187.9578.3.camel@r-9djhc747gf8b40ha>
Message-ID: <20110209095523.GW4847@prithivi.gnumonks.org>

No BTS will ever be seen without a C0, and the GSM spec defines that TRX
will always carry the CCCH.  I would be surprised if a BTS actually supports
BCCH/CCCH on a different TRX.

On Tue, Feb 08, 2011 at 10:39:47PM +0100, Thomas Ansorg wrote:
> hi list,
> i came over line 523 in gsm_data.h: 
> 	/* CCCH is on C0 */
> 	struct gsm_bts_trx *c0;
> 
> could this be the reason why a bs-11 without aktivated trx0 dont work /
> isnt seen by handy?
> 
> T.
> -- 
> Wer Rechtschreibfehler findet, darf sie behalten!
> 
> 

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From hwit at a-domani.nl  Fri Feb 11 07:34:04 2011
From: hwit at a-domani.nl (Hans Witvliet)
Date: Fri, 11 Feb 2011 08:34:04 +0100
Subject: data
Message-ID: <1297409644.15872.5.camel@t43.lan0.a-domani.nl>

This is probably completely off-topic, but can thoses nano-bts also be
used for data, instead of voice?

I don't mean sms, but access to email and so-on.
It is not about performance, but being able to test gsm-dongles for
wireless internet. (not wifi)

Hans



From holger at freyther.de  Sat Feb 12 07:50:00 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sat, 12 Feb 2011 08:50:00 +0100
Subject: data
In-Reply-To: <1297409644.15872.5.camel@t43.lan0.a-domani.nl>
References: <1297409644.15872.5.camel@t43.lan0.a-domani.nl>
Message-ID: <4D563BA8.50502@freyther.de>

On 02/11/2011 08:34 AM, Hans Witvliet wrote:
> This is probably completely off-topic, but can thoses nano-bts also be
> used for data, instead of voice?
> 
> I don't mean sms, but access to email and so-on.
> It is not about performance, but being able to test gsm-dongles for
> wireless internet. (not wifi)

data as in GPRS or CSD? The GPRS/EDGE support is working in the lab
environment, you will find information in the wiki and searching the
mailing-list archives.

regards
	z.



From kobayashi_maru at onlinehome.de  Fri Feb 11 07:46:22 2011
From: kobayashi_maru at onlinehome.de (Thomas Ansorg)
Date: Fri, 11 Feb 2011 08:46:22 +0100
Subject: creating primary trx
Message-ID: <1297410382.5717.9.camel@r-9djhc747gf8b40ha>

hello
my 2nd bs-11(bts 1) has a defective trx0, so no c0 can be created. lets
have a look at gsm_bts_trx_alloc in gsm_data.c:
i changed
	trx->bts = bts;
	trx->nr = bts->num_trx++;
	trx->nm_state.administrative = NM_STATE_UNLOCKED;

to
	trx->bts = bts;
         if(bts->nr == 1) {trx->nr = 1;}
         else {trx->nr = bts->num_trx++;}
	trx->nm_state.administrative = NM_STATE_UNLOCKED;

in gsm_bts_alloc, the primary trx should be created then, in the case of
bts 1 starting at trx1, since trx0 dont exist

unfortunately, i get a general protection fault :-(

hints very velcome!

T.
-- 
Wer Rechtschreibfehler findet, darf sie behalten!




From cr3 at cr3.us  Mon Feb 14 19:13:35 2011
From: cr3 at cr3.us (Chris Rankine)
Date: Mon, 14 Feb 2011 14:13:35 -0500
Subject: "Dial up networking" config
Message-ID: <AANLkTinhk9ggOA6Wbjjcb+NgO9afASBx-ef51OMAjiTJ@mail.gmail.com>

For our ongoing experiment, we are hoping to tether some laptops onto the
EDGE connection, either through a USB style dongle or a USB cord into a
phone that allows it to be treated like a modem (And for some old school
phones, maybe even a Serial port connection).  These situations require a
number to be dialed, what I believe is a USSD code, and sometimes a username
and password to be entered.  I am not talking about newer smart phones where
the connection is sometimes shared using advanced drivers.  Has anyone been
able to do this with OpenBSC?

Chris Rankine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110214/d1766176/attachment.htm>

From laforge at gnumonks.org  Tue Feb 15 08:09:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Feb 2011 09:09:56 +0100
Subject: "Dial up networking" config
In-Reply-To: <AANLkTinhk9ggOA6Wbjjcb+NgO9afASBx-ef51OMAjiTJ@mail.gmail.com>
References: <AANLkTinhk9ggOA6Wbjjcb+NgO9afASBx-ef51OMAjiTJ@mail.gmail.com>
Message-ID: <20110215080956.GF10925@prithivi.gnumonks.org>

Hi Chris,

I think you are confusing a number of very different things: USSD, CSD/HSCSD
and GPRS/EDGE.  We do support GPRS+EDGE (marked as experimental).  We don't
do CSD/HSCSD, and there is no need for USSD in connection to all of this.

There is no problem using our GPRS/EDGE support in _small_ lab installations.
Don't put dozens or hundreds of phones at it.

The way you establish the GPRS connection from your phone depends on your
phone / dongle.  Normally it is oriented closely at the AT command set described
in TS 07.07, sometimes with a multiplexer according to TS 07.10.

> number to be dialed, what I believe is a USSD code, and sometimes a username
> and password to be entered.  I am not talking about newer smart phones where
> the connection is sometimes shared using advanced drivers.  Has anyone been
> able to do this with OpenBSC?

On the network side, there is no difference between those two cases.  So to
OpenBSC, OsmoSGSN and OpenGGSN it does not matter whether you use serial lines,
USB or a smartphone that locally terminates the IP and then does something like
USB/WiFi tethering. It's all the same.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From jayrworthington at gmail.com  Thu Feb 17 12:42:36 2011
From: jayrworthington at gmail.com (Jay R. Worthington)
Date: Thu, 17 Feb 2011 13:42:36 +0100
Subject: Legal usage without a carrier-licence?
Message-ID: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>

Hi,

as probably for most of us an official (testing) licence is out of reach, is
there a "workaround" for this problem?

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

- Are there any "standard" gsm handsets that could be modified (preferably
in software) to work at 2,4GHz?

- 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.

I realize the first two options would not exactly make it legal, but i'd
prefer the wrath of my neighbors over the suicide-squad from a carrier or
regulatory agency ;).

Any comments?

Regards,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110217/573da64e/attachment.htm>

From bjastles at gmail.com  Thu Feb 17 14:42:37 2011
From: bjastles at gmail.com (Barnaby Astles)
Date: Thu, 17 Feb 2011 09:42:37 -0500
Subject: Legal usage without a carrier-licence?
In-Reply-To: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
References: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
Message-ID: <AANLkTi=Y-R=Ov10N2X+iOvWDqiQ1SqWn0DF0VT-C=b3Y@mail.gmail.com>

That is the same question I have been asking my self.

Maybe we could take a 2.4GHz (or 5.8) soft radio and turn it into a
debugging/development tool
I.E. create our own handset/base station combo

It would not be perfect and maybe not feasible.

Barnaby J Astles

On Thu, Feb 17, 2011 at 07:42, Jay R. Worthington <jayrworthington at gmail.com
> wrote:

> Hi,
>
> as probably for most of us an official (testing) licence is out of reach,
> is there a "workaround" for this problem?
>
> - 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...)
>
> - Are there any "standard" gsm handsets that could be modified (preferably
> in software) to work at 2,4GHz?
>
> - 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.
>
> I realize the first two options would not exactly make it legal, but i'd
> prefer the wrath of my neighbors over the suicide-squad from a carrier or
> regulatory agency ;).
>
> Any comments?
>
> Regards,
>
> Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110217/f09c107f/attachment.htm>

From laforge at gnumonks.org  Thu Feb 17 17:15:15 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 17 Feb 2011 18:15:15 +0100
Subject: Legal usage without a carrier-licence?
In-Reply-To: <AANLkTi=Y-R=Ov10N2X+iOvWDqiQ1SqWn0DF0VT-C=b3Y@mail.gmail.com>
References: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
	<AANLkTi=Y-R=Ov10N2X+iOvWDqiQ1SqWn0DF0VT-C=b3Y@mail.gmail.com>
Message-ID: <20110217171515.GJ1002@prithivi.gnumonks.org>

Hi Barnaby,

On Thu, Feb 17, 2011 at 09:42:37AM -0500, Barnaby Astles wrote:
> That is the same question I have been asking my self.
> 
> Maybe we could take a 2.4GHz (or 5.8) soft radio and turn it into a
> debugging/development tool I.E. create our own handset/base station combo

while that is possible (implementing the radio modem for the MS and e.g.
running OsmocomBB on top) - what is the purpose?

If you want simulation with custom implementations for both sides, you can
skip the radio link altogether and simply tunnel Um over UDP between a virtual
BTS and a virtual MS.

The point of running a real Um interface on the air is to use existing
telephones 'as-is'.  And then you have to operate in the bands they support.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Thu Feb 17 17:13:21 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 17 Feb 2011 18:13:21 +0100
Subject: Legal usage without a carrier-licence?
In-Reply-To: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
References: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
Message-ID: <20110217171321.GI1002@prithivi.gnumonks.org>

Hi Jay,

On Thu, Feb 17, 2011 at 01:42:36PM +0100, Jay R. Worthington wrote:
 
> as probably for most of us an official (testing) licence is out of reach, is
> there a "workaround" for this problem?

why do you think that?  'experimental license' != 'carrier license'.  

We've obtained this in Germany, Austria, Switzerland and the Netherlands.  So
at least in the EU it seems generally no problem

The fees we had to pay for those experimental/test licenses are typically < 300
EUR, so much cheaper than the equipment that you need to run the network
anyway.


From kerney at cryptikware.com  Thu Feb 17 19:08:11 2011
From: kerney at cryptikware.com (kerney at cryptikware.com)
Date: Thu, 17 Feb 2011 12:08:11 -0700
Subject: Legal usage without a carrier-licence?
In-Reply-To: <20110217171321.GI1002@prithivi.gnumonks.org>
References: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
	<20110217171321.GI1002@prithivi.gnumonks.org>
Message-ID: <27D16822-CC41-48ED-9847-40C2A4CF424F@cryptikware.com>

I don't remember the complete process, bit you can apply to the FCC for an experimental lic from their website.  You have to pay a fee (I think it was 50 or 100 USD) and as long as you are power limited, I think they pretty much approve it for one year.

I can post the website link once I get back to the office.

*Sent from my iPhone 4

On Feb 17, 2011, at 12:25 PM, "Harald Welte" <laforge at gnumonks.org> wrote:

> Hi Jay,
> 
> On Thu, Feb 17, 2011 at 01:42:36PM +0100, Jay R. Worthington wrote:
> 
>> as probably for most of us an official (testing) licence is out of reach, is
>> there a "workaround" for this problem?
> 
> why do you think that?  'experimental license' != 'carrier license'.  
> 
> We've obtained this in Germany, Austria, Switzerland and the Netherlands.  So
> at least in the EU it seems generally no problem
> 
> The fees we had to pay for those experimental/test licenses are typically < 300
> EUR, so much cheaper than the equipment that you need to run the network
> anyway.
> 
> From what I've heard about the US with regard to experimental licenses, they
> 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 at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
> 



From dburgess at jcis.net  Thu Feb 17 19:50:16 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Thu, 17 Feb 2011 11:50:16 -0800
Subject: Legal usage without a carrier-licence?
In-Reply-To: <27D16822-CC41-48ED-9847-40C2A4CF424F@cryptikware.com>
References: <AANLkTi=yXtQvNjtvZ+PbV-QT+89QU2PnRmVCxQmzNUSk@mail.gmail.com>
	<20110217171321.GI1002@prithivi.gnumonks.org>
	<27D16822-CC41-48ED-9847-40C2A4CF424F@cryptikware.com>
Message-ID: <EDFA456E-9D0E-480E-933E-4E1B7BCA7A7B@jcis.net>


The US FCC process pretty painless.  Three weeks.  US$60.  Mostly done on the web, although you might get a telephone call.  But if you want a high-power license, you must also "coordinate" with any licensed carriers in the spectrum, which is considerably harder than dealing with the FCC.

Be aware that frequencies just above the ISM900 band are used for aircraft landing beacons in the US.  Screw with that on a foggy day and you are looking at some serious liability.  We had a much more difficult time getting a high-power experimental license in ISM900 (down the road from an Air Force base) than we did in GSM850 (out in the desert).

I also also heard that a group at UC Berkeley recently got an experimental license to operate in the GSM1800 band, but I do not know the details.

On Feb 17, 2011, at 11:08 AM, kerney at cryptikware.com wrote:

> I don't remember the complete process, bit you can apply to the FCC for an experimental lic from their website.  You have to pay a fee (I think it was 50 or 100 USD) and as long as you are power limited, I think they pretty much approve it for one year.
> 
> I can post the website link once I get back to the office.




From daniel at totalueberwachung.de  Fri Feb 18 23:07:28 2011
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Sat, 19 Feb 2011 00:07:28 +0100
Subject: Possible error in libosmocore
Message-ID: <20110219000728.1e5a648d@adrastea.totalueberwachung.de>

Hello,

I just stumbled over the following change in libosmocore

diff --git a/src/vty/Makefile.am b/src/vty/Makefile.am
index 7353ab8..8d730c3 100644
--- a/src/vty/Makefile.am
+++ b/src/vty/Makefile.am
@@ -10,5 +10,5 @@ lib_LTLIBRARIES = libosmovty.la
 
 libosmovty_la_SOURCES = buffer.c command.c vty.c vector.c utils.c \
                        telnet_interface.c logging_vty.c
-libosmovty_la_LIBADD = $(top_builddir)/src/libosmocore.la
+libosmovty_la_LIBADD = -losmocore $(top_builddir)/src/libosmocore.la
 endif

from commit 2822296d
The -losmocore seems wrong as it is the library we're building here and
it's not necessarily already installed.
If I remove that part libosmocore builds for me again.


Regards,
Daniel Willmann



From laforge at gnumonks.org  Sat Feb 19 14:40:31 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 19 Feb 2011 15:40:31 +0100
Subject: Possible error in libosmocore
In-Reply-To: <20110219000728.1e5a648d@adrastea.totalueberwachung.de>
References: <20110219000728.1e5a648d@adrastea.totalueberwachung.de>
Message-ID: <fcb004ab-767f-4ce5-a435-2ac93f047529@email.android.com>

Daniel, 

the idea was to link libosmovty against libosmocore. But I'm fine with reverting this change.

-- 
Sent from my mobile phone. Please excuse my brevity.



From 246tnt at gmail.com  Sun Feb 20 11:49:11 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 20 Feb 2011 12:49:11 +0100
Subject: Possible error in libosmocore
In-Reply-To: <fcb004ab-767f-4ce5-a435-2ac93f047529@email.android.com>
References: <20110219000728.1e5a648d@adrastea.totalueberwachung.de>
	<fcb004ab-767f-4ce5-a435-2ac93f047529@email.android.com>
Message-ID: <AANLkTi=sP9oKrfqLfe0+2M+pRT4gR_ZD8-2ZhoPLC9zt@mail.gmail.com>

Hi,

> the idea was to link libosmovty against libosmocore. But I'm fine with reverting this change.

I think it would be best to just add libosmocore to the LDFLAGS of
libosmovty in the pkg-config file.

   Sylvain



From Andreas.Eversberg at versatel.de  Mon Feb 21 08:46:31 2011
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 21 Feb 2011 09:46:31 +0100
Subject: fix of chan_lcr / new socket interface for openbsc
Message-ID: <B16317F2B1592B4492FC414114171CE60510DED2@FLBVEXCH01.versatel.local>

hi,
 
the broken chan_lcr is now fixed in the "develop" branch of lcr git. i
have tested it with asterisk 1.8.1. the locking seems to be improved in
this asterisk version. i could not run it in a deadlock, as i could with
asterisk 1.6. i would suggest to try this out, but please keep your
current asterisk and lcr sources. if all works fine, i would like to
merge the "develop" branch into the "master" branch soon.
 
for the gsm users: the second change in the "develop" branch is the
socket interface between openbsc and lcr. thanks to harald welte for
providing this patch. instead of linking openbsc to lcr, openbsc runs
it's own process. (using bsc_hack as usual) lcr connects to a socket of
openbsc. with it, the gsm.conf became obsolte and has been removed from
lcr. in order to run lcr with openbsc ("master" branch of openbsc) :

bsc_hack -P -m -l <sqlite-database> -c <openbsc-config>
 
-P is required to enable rtp proxy for use with ipaccess bts.
-m is required to allow call control via socket interface
 
 
to get lcr from "develop" branch, do:
 
git-clone git://git.misdn.org/git/lcr.git/
cd lcr
sh checkout-branch.sh develop

regards,

andreas




From laforge at gnumonks.org  Tue Feb 22 12:21:32 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Feb 2011 07:21:32 -0500
Subject: fix of chan_lcr / new socket interface for openbsc
In-Reply-To: <B16317F2B1592B4492FC414114171CE60510DED2@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE60510DED2@FLBVEXCH01.versatel.local>
Message-ID: <4D63AA4C.2010005@gnumonks.org>

Andreas,

thanks for integrating the mncc socket patch into lcr.

I would personally like to see the following improvements:
* add some (preferrable automatically computed) version to the mncc,
to make sure you cannot run lcr + bsc_hack built from a different mncc.h
file.  We could do something like a md5sum over the header at compilation
time, stored in both openbsc and lcr.  Once they connect the mncc socket,
they request the remote side md5-value and compare it with the local-side
value.  If they don't match, print an error message and exit the program.

* make the socket path configurable, which is required for running multiple
instances of openbsc+lcr on the same machine.

If you (or anyone else on this list) happens to have some time to work on
that, it would be greatly appreciated.

Regards,
   Harald



From Andreas.Eversberg at versatel.de  Tue Feb 22 12:46:26 2011
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 22 Feb 2011 13:46:26 +0100
Subject: AW: fix of chan_lcr / new socket interface for openbsc
Message-ID: <B16317F2B1592B4492FC414114171CE60510E6BF@FLBVEXCH01.versatel.local>

hi harald,

i would also suggest to combine mncc.h of openbsc and osmocom-bb first, and move it to libosmocore. this way the LCR (or other mncc_socket client) does not depend on any files of openbsc and osmocom-bb, just on libosmocore.

because i like to use the same socket interface for osmocom-bb, i would suggest to to put mncc_sock.c into libosmocore too, so it must not be implemented twice.

then i would make lcr to be able to connect to both osmocom-bb and openbsc sockets. finally there is no more polling of file descriptor required at lcr. 

if you agree, can you move the code to libosmocore? i will work on the socket configuration and see what i can do with the versioning.


andreas


-----Urspr?ngliche Nachricht-----
Von: Harald Welte [mailto:laforge at gnumonks.org] 
Gesendet: Dienstag, 22. Februar 2011 13:22
An: Andreas.Eversberg
Cc: openbsc at lists.gnumonks.org
Betreff: Re: fix of chan_lcr / new socket interface for openbsc

Andreas,

thanks for integrating the mncc socket patch into lcr.

I would personally like to see the following improvements:
* add some (preferrable automatically computed) version to the mncc,
to make sure you cannot run lcr + bsc_hack built from a different mncc.h
file.  We could do something like a md5sum over the header at compilation
time, stored in both openbsc and lcr.  Once they connect the mncc socket,
they request the remote side md5-value and compare it with the local-side
value.  If they don't match, print an error message and exit the program.

* make the socket path configurable, which is required for running multiple
instances of openbsc+lcr on the same machine.

If you (or anyone else on this list) happens to have some time to work on
that, it would be greatly appreciated.

Regards,
   Harald



From laforge at gnumonks.org  Tue Feb 22 12:53:09 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Feb 2011 07:53:09 -0500
Subject: AW: fix of chan_lcr / new socket interface for openbsc
In-Reply-To: <B16317F2B1592B4492FC414114171CE60510E6BF@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE60510E6BF@FLBVEXCH01.versatel.local>
Message-ID: <4D63B1B5.7010702@gnumonks.org>

Hi Andreas,

On 02/22/2011 07:46 AM, Andreas.Eversberg wrote:
> if you agree, can you move the code to libosmocore? i will work on the socket configuration and see what i can do with the versioning.
>
>    
Sure, move it to libosmocore.


At some point we will have to split libosmocore into seperate 
functional  blocks though.  Right now it is just a conglomeration of 
various different things, some of them generally usefule, others GSM 
specific, yet again others specific to OpenBSC or OsmocomBB.

But this is an entirely separate discussion.  I'm just saying, sooner or 
later I want to split libosmocore in 2-3 separate libraries, where the 
*core library really only contains stuff like the select/timer/... 
stuff, and another one (maybe libosmogsm) then contains the stuff 
related to GSM.

Cheers,
     Harald



From bouchtaoui at gmail.com  Tue Feb 22 15:08:56 2011
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 22 Feb 2011 16:08:56 +0100
Subject: Timing Advance
Message-ID: <4D63D188.5030004@gmail.com>

  Hello guys,

I haven't been busy with openbsc for a while, however, I was following 
the mailing-list.
I have the following question, is timing advance also implemented for 
the nanoBTS? Cause I don't really know where to look in the sources, 
thank you.




From laforge at gnumonks.org  Wed Feb 23 18:24:01 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 23 Feb 2011 19:24:01 +0100
Subject: Timing Advance
In-Reply-To: <4D63D188.5030004@gmail.com>
References: <4D63D188.5030004@gmail.com>
Message-ID: <20110223182401.GA32171@prithivi.gnumonks.org>

On Tue, Feb 22, 2011 at 04:08:56PM +0100, Nordin wrote:
 
> I haven't been busy with openbsc for a while, however, I was
> following the mailing-list.
> I have the following question, is timing advance also implemented
> for the nanoBTS? Cause I don't really know where to look in the
> sources, thank you.

Timing advance handling is in RSL and thus independent of the BTS you use.
OpenBSC does it for all the BTS it supports.

However, I am not sure the ip.access nanoBTS hardware/firmware actually
implements it on the radio layer, considering it is intended as a
pico/microcell.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From andaluz.coder at gmail.com  Wed Feb 23 20:36:59 2011
From: andaluz.coder at gmail.com (Maradona Mossiba)
Date: Wed, 23 Feb 2011 21:36:59 +0100
Subject: Timing Advance
In-Reply-To: <20110223182401.GA32171@prithivi.gnumonks.org>
References: <4D63D188.5030004@gmail.com>
	<20110223182401.GA32171@prithivi.gnumonks.org>
Message-ID: <AANLkTi=e2OVDeBPGjKE-5U9uSzjtebBdXDL-BiKq8RaN@mail.gmail.com>

Timing advance handling is in RSL and thus independent of the BTS you use.
> OpenBSC does it for all the BTS it supports.
>
However, I am not sure the ip.access nanoBTS hardware/firmware actually
> implements it on the radio layer, considering it is intended as a
> pico/microcell.
>

Thank you for your answer Harald. It's clear to me.


> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110223/93b3f211/attachment.htm>

From stuart at bluewave.im  Wed Feb 23 18:50:53 2011
From: stuart at bluewave.im (Stuart Baggs)
Date: Wed, 23 Feb 2011 18:50:53 +0000
Subject: Timing Advance
In-Reply-To: <4D63D188.5030004@gmail.com>
References: <4D63D188.5030004@gmail.com>
Message-ID: <64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>

Hi Guys,

The ip.access nanoBTS (at least model 139) do implement timing advance. We have used them in a macro network coupled with 24 AMPS for nearly a year now and they work quite effectively. They work right up to the 25 KM timing advance limit.

Kind Regards

Stuart Baggs

BlueWave Communications Ltd - Suppliers of IP pico/femto cells.

On 22 Feb 2011, at 15:08, Nordin wrote:

> Hello guys,
> 
> I haven't been busy with openbsc for a while, however, I was following the mailing-list.
> I have the following question, is timing advance also implemented for the nanoBTS? Cause I don't really know where to look in the sources, thank you.
> 
> 




From andaluz.coder at gmail.com  Wed Feb 23 20:41:14 2011
From: andaluz.coder at gmail.com (Maradona Mossiba)
Date: Wed, 23 Feb 2011 21:41:14 +0100
Subject: Timing Advance
In-Reply-To: <64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>
References: <4D63D188.5030004@gmail.com>
	<64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>
Message-ID: <AANLkTikxrhfSjDjs2CqtiTdiHkV3MywtC=saS3fG4Jbf@mail.gmail.com>

Ok cool, thnx Stuart.
Is this info based on technical specs of the 139 model?

On Wed, Feb 23, 2011 at 7:50 PM, Stuart Baggs <stuart at bluewave.im> wrote:

> Hi Guys,
>
> The ip.access nanoBTS (at least model 139) do implement timing advance. We
> have used them in a macro network coupled with 24 AMPS for nearly a year now
> and they work quite effectively. They work right up to the 25 KM timing
> advance limit.
>
> Kind Regards
>
> Stuart Baggs
>
> BlueWave Communications Ltd - Suppliers of IP pico/femto cells.
>
> On 22 Feb 2011, at 15:08, Nordin wrote:
>
> > Hello guys,
> >
> > I haven't been busy with openbsc for a while, however, I was following
> the mailing-list.
> > I have the following question, is timing advance also implemented for the
> nanoBTS? Cause I don't really know where to look in the sources, thank you.
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110223/6f6524fb/attachment.htm>

From omar.atia at its.ws  Thu Feb 24 07:54:31 2011
From: omar.atia at its.ws (Omar Atia)
Date: Thu, 24 Feb 2011 09:54:31 +0200
Subject: Timing Advance
In-Reply-To: <AANLkTikxrhfSjDjs2CqtiTdiHkV3MywtC=saS3fG4Jbf@mail.gmail.com>
References: <4D63D188.5030004@gmail.com>
	<64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>
	<AANLkTikxrhfSjDjs2CqtiTdiHkV3MywtC=saS3fG4Jbf@mail.gmail.com>
Message-ID: <005701cbd3f8$13dea6a0$3b9bf3e0$%atia@its.ws>

Dears,,

 

In addition to the below question , first what do you mean by 24 AMPS ?, 2nd
Does ipaccess covers up to 25 KM or it needs amplifiers or one ipaccess
antenna can cover that distance can you explain?

 

Thanks,

Omar Atia

 

From: openbsc-bounces at lists.osmocom.org
[mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Maradona Mossiba
Sent: Wednesday, February 23, 2011 10:41 PM
To: Stuart Baggs
Cc: OpenBSC list; Nordin
Subject: Re: Timing Advance

 

Ok cool, thnx Stuart.
Is this info based on technical specs of the 139 model?

On Wed, Feb 23, 2011 at 7:50 PM, Stuart Baggs <stuart at bluewave.im> wrote:

Hi Guys,

The ip.access nanoBTS (at least model 139) do implement timing advance. We
have used them in a macro network coupled with 24 AMPS for nearly a year now
and they work quite effectively. They work right up to the 25 KM timing
advance limit.

Kind Regards

Stuart Baggs

BlueWave Communications Ltd - Suppliers of IP pico/femto cells.


On 22 Feb 2011, at 15:08, Nordin wrote:

> Hello guys,
>
> I haven't been busy with openbsc for a while, however, I was following the
mailing-list.
> I have the following question, is timing advance also implemented for the
nanoBTS? Cause I don't really know where to look in the sources, thank you.
>
>



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110224/1de373c0/attachment.htm>

From bouchtaoui at gmail.com  Thu Feb 24 08:37:18 2011
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 24 Feb 2011 09:37:18 +0100
Subject: Timing Advance
In-Reply-To: <005701cbd3f8$13dea6a0$3b9bf3e0$%atia@its.ws>
References: <4D63D188.5030004@gmail.com>
	<64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>
	<AANLkTikxrhfSjDjs2CqtiTdiHkV3MywtC=saS3fG4Jbf@mail.gmail.com>
	<005701cbd3f8$13dea6a0$3b9bf3e0$%atia@its.ws>
Message-ID: <4D6618BE.5000708@gmail.com>

  On 24-2-2011 8:54, Omar Atia wrote:
> Dears,,
>
>
>
> In addition to the below question , first what do you mean by 24 AMPS ?, 2nd
> Does ipaccess covers up to 25 KM or it needs amplifiers or one ipaccess
> antenna can cover that distance can you explain?

For such a distance you need special amplifiers and antennas. It works 
as Stuart said, he told that from his experience.

>
>
> Thanks,
>
> Omar Atia
>
>
>
> From: openbsc-bounces at lists.osmocom.org
> [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Maradona Mossiba
> Sent: Wednesday, February 23, 2011 10:41 PM
> To: Stuart Baggs
> Cc: OpenBSC list; Nordin
> Subject: Re: Timing Advance
>
>
>
> Ok cool, thnx Stuart.
> Is this info based on technical specs of the 139 model?
>
> On Wed, Feb 23, 2011 at 7:50 PM, Stuart Baggs<stuart at bluewave.im>  wrote:
>
> Hi Guys,
>
> The ip.access nanoBTS (at least model 139) do implement timing advance. We
> have used them in a macro network coupled with 24 AMPS for nearly a year now
> and they work quite effectively. They work right up to the 25 KM timing
> advance limit.
>
> Kind Regards
>
> Stuart Baggs
>
> BlueWave Communications Ltd - Suppliers of IP pico/femto cells.
>
>
> On 22 Feb 2011, at 15:08, Nordin wrote:
>
>> Hello guys,
>>
>> I haven't been busy with openbsc for a while, however, I was following the
> mailing-list.
>> I have the following question, is timing advance also implemented for the
> nanoBTS? Cause I don't really know where to look in the sources, thank you.
>>
>
>
>
>
>




From pauldart at gmail.com  Thu Feb 24 09:39:05 2011
From: pauldart at gmail.com (Paul Dart)
Date: Thu, 24 Feb 2011 09:39:05 +0000
Subject: Timing Advance
In-Reply-To: <4D6618BE.5000708@gmail.com>
References: <4D63D188.5030004@gmail.com>
	<64DCE9F4-48E6-48C9-9EED-DD35EE080697@bluewave.im>
	<AANLkTikxrhfSjDjs2CqtiTdiHkV3MywtC=saS3fG4Jbf@mail.gmail.com>
	<005701cbd3f8$13dea6a0$3b9bf3e0$%atia@its.ws>
	<4D6618BE.5000708@gmail.com>
Message-ID: <AANLkTi=_xsN5DO4TXS-YjcFEWo8j0ryX+FzGTfqzFdPR@mail.gmail.com>

On 24 February 2011 08:37, Nordin <bouchtaoui at gmail.com> wrote:

>  On 24-2-2011 8:54, Omar Atia wrote:
>
>> In addition to the below question , first what do you mean by 24 AMPS ?,
>> 2nd
>> Does ipaccess covers up to 25 KM or it needs amplifiers or one ipaccess
>> antenna can cover that distance can you explain?
>>
>
> For such a distance you need special amplifiers and antennas. It works as
> Stuart said, he told that from his experience.


Surely not 24 amplifiers off one BTS though.
I would have thought the noise floor would have gone through the roof and
ruined performance.
Rough, finger in the air guessing, I would say more than a few amps per
cell/sector would be enough.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110224/89d054e0/attachment.htm>

From joe at monkey.org  Mon Feb 28 22:13:59 2011
From: joe at monkey.org (Joe Eggleston)
Date: Mon, 28 Feb 2011 17:13:59 -0500
Subject: spec download
Message-ID: <AANLkTim9=raE=Gmhg29KB-HKfi6_uVOmiaODrpRqNY1E@mail.gmail.com>

Hi all,
Maybe I'm missing something, but I haven't found an easy way to
download pdf versions of all the 3gpp specs. Why would you want to do
that? Well, dealing with MS-Word format is a pain. And, there's no
online full-text search of all the specs.
So, I threw together a quick web scraper to pull down the latest
version of all the 3GPP specs from the ETSI web site in pdf format.
Thought it might be useful to others -
http://monkey.org/~joe/files/fetch_3gpp.py
Feel free to contact me if you have any trouble using it.

-Joe