OpenBSC -> only BTS+RNC+MSC+HLR without BSC possible?

historical

Hi Ellen,

On Mon, Jun 25, 2012 at 09:50:22AM +0200, Ellen Apolinar wrote:
> > There are no BTS in UMTS.  There is no BSC in UMTS.  There's only NodeB,
> > RNC.  As the Iub interface is completely unlike Abis, and UMTS (except
> > call control and sms) is completely unlike GSM, I really don't
> > understand what a BTS and a BSC would have to do with UMTS.
> 
> We want to use it for GSM and UMTS. I know that UMTS is completely
> different
> and what I meant was BTS for GSM and NodeB for UMTS. 

> UMTS is more important than GSM for our project and I have to analyse
> if it is possible to realise it also for UMTS. One of our programmers
> will work for a half year at the projekt to realise it.

If you have some resources to get external help/input with this, I
suggest you talk to Dieter Spaar.  He has been wokring on a prototype
implementation of a RNC for use with NSN and Ericsson NodeB's at some
point in the past.

If you don't need real NodeBs with Iub interface, femtocells might be an
alternative.  Their Iuh or UMA/GAN interface is much less low-level, as
they basically include most of the "RNC" part internally.

> > If you are talking about a classic GSM BTS that speaks a dialect of
> > A-bis RSL (08.58), adding support for them to OpenBSC shouldn be hard.
> > Can you give us a list of BTS models that you're looking to support?
> 
> We want to support following BTS/NodeB - models:
> 
> Nokia: Citytalk, Ultrasite, Flexitalk
> Siemes: BS60/61/21, BS240/241/40/41/82

At least for Nokia and Siemens, it is definitely 08.58.  As we already
support other Siemens and Nokia BTS, it is expected to be relatively
easy to add support for the models you have indicated.

> Alcatel: G9100 Evolium, 63/64

I have no information on their back-haul interface, so I cannot comment
on the size of the effort.

> Also Nortel GSM BTS. We got the traces from the Nokia Ultrasite and
> Flexitalk, also from the Nortel18000. We have a T1/E1 Protocol Analyser:
> 
> http://www.gl.com/laptopt1.html

The protocol analyzer is only of help if it supports the decoding of the
various BTS specific RSL and OML protocol dialects.  From my experience,
Tektronix K15 is good in this area, but also is far short of decoding
all information elements in any of the formats.

Also, there's no need for tapping communicatoin between OpenBSC and the
BTS.  That's what we have PCAP support for.

What's most useful is if you will actually be able to take traces
between the real BSC and the BTS.  Those traces then are the basis for
adding OpenBSC support.  Without traces, I see only a very dim chance to
add a BTS driver to OpenBSC.

> Yes, this is known here and I think it should be quite natural that we
> release the code with our modifications if it works and share our
> ideas with you.

Ok.  We've had some bad experience about this in the past, so it's good
to have this statement from you.  Please note that it would be good
practise not to wait until everything works and then dump the code, but
to actually develop it in an open git repository, where people can watch
+ provide feedback for every commit as you go.  The latter of course is
not a legal requirement under AGPLv3, but it would be beneficial for you
and for us.

> > Based on past experience, I would say adding support for a new Abis
> > variant is an effort somewhere between one and three man-weeks for a
> > developer already familiar with OpenBSC internals and APIs.
> 
> The project I work for is from a company so the purpose is that one of
> the programmers works with us at the project and becomes familiar with
> OpenBSC for making modifications so we could realise the connection
> with our BTS and perhaps for UMTS.

For the GSM BTS I see no problem. For UMTS, I would really see it as a
completely separate/independent project, with probably at least 20 times
the effort of your GSM project.  Also, the type of work is vastly
different.  On the GSM side all the complex part is implemented and it
is just putting in some BTS specific bits, as opposed to the UMTS side
where you need to do everything from design/architecture/...

> But we have to know if it is achievable and if it is worth it. If it
> is to unstable

I'm not worried about it being unstable, but about the size of the
effort.

We are currently doing some work in separating the core network part
from the BSC part (having one program for MSC/HLR/AUC/SMSC and one for
BSC, communicating via A-over-IP..  At that point, it might become
fasible to re-use the MSC/HLR/AUC/SMSC part together with a
to-be-written from scratch RNC.

My suggestion would be to focus on GSM.

Last, but not least, it would be interesting to know the purpose of your
implementation / application.

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)