Picocell from HAY SYSTEMS

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Sep 20 15:42:14 UTC 2010


Hi Konrad,

On Mon, Sep 20, 2010 at 04:29:36PM +0200, Konrad Meier wrote:
 
> Searching the web I found the following BTS:
> http://www.haysystems.com/mobile-networks/hsl-picocell/
> 
> The System seams to be very similar to the ip.access nanoBTS.
> POE and Abis over IP.

Yes, on a high level it seems like it.  Several of my customers have tried
to buy the femtocell starter kit of the HSL femtocell throughout the last 12
months, but last time they checked (August 2010) it was still not shipping to
customers.

The picocell is an even later product, so I would be surprised if that has
started shipping before the femtocell.

> Can someone roughly estimate the time needed to integrate this BTS
> into openBSC? The developer I have in mind already has some
> experience in OpenBSC.

It's hard to make an estimate without knowing the details.  Adding basic
signalling and voice call support for the nanoBTS to OpenBSC (at a time it only
supported the BS-11) was done in < 1 week full time, using only a sample
nanoBTS unit and packet traces between a proprietary BSC and the nanoBTS.

Factors that relate to the amount of time are largely dependent on
* is there any documentation that can be used to write Open Source (NDA, ...)?
* how close do they follow A-bis OML and RSL?
* how is the adaption between A-bis RSL/OML and IP done?
* how are the actual TCH data (voice streams) transported over IP?
* do you only need GSM signalling + voice or also GPRS/EDGE data?

I would guess somewhere between 2-4 weeks, to be on the safe side.

> What exactly is needed to complete this task?

Ideally there would be written documentation from the vendor on the exact
protocol they use on their Abis/IP backhaul.  Specifically, it is interesting
to understand the questions I'm raising above.

If no documentation is available, doing packet captures between the BSC
and BTS, followed by reverse engineering the protocol will be needed.  My
personal approach would be to simply look at the packets, try to find data
that looks like TS 12.21 or TS 08.58, and then write a wireshark dissector
plugin to hand-off the 12.21/08.58 data to the existing OML or RSL dissectors.

From that point on, you can write OpenBSC code to bring up the BTS by simply
playing back the same messages that you have seen from the proprietary BSC.

-- 
- 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100920/e6eec2ba/attachment.bin>


More information about the OpenBSC mailing list