"Osmo-USRP": combining OpenBTS and Osmocom

historical

Hi Thomas,

thanks a lot for your very encoraging post.

I should have been working on OpenBTS / osmo-bts integration for a long
time now, and to my big embarrassment I still haven't gotten anywhere
close to completion, for a variety of reasons :(

On Mon, Mar 19, 2012 at 02:27:28PM -0400, Thomas Cooper wrote:
> I've been working on connecting OpenBTS and osmo-bts ever since Harald
> formed the openbts-osmo repo
> (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice
> muxer framework and L1-L2 separation. I've named it Osmo-USRP but you
> can call it openbts-osmo or TrueBTS or whatever; it's not a big deal.

Yes, I agree, naming is not our most important task right now.  We can
have a vote on it ;)

> Unfortunately I'm running short on time for completing my MS research,
> so testing is nowhere near complete but I figured I'd let the public
> users help me out a bit here if they want to try it out. Many thanks
> to Tom Tsou for helping me weed out bugs and test too.

I'd really appreciate that and would love to give you write access to
the openbts-osmo.git repository in an effort to avoid too many different
branches in too many repositories.

> I've only scratched the surface of testing it with USRP1, USRP2,
> single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've
> been able to get a stable network of 1 and 2 BTSs across 2 PCs with
> multiple MSs camped, and voice calls and SMS working. 

cool.

> There seem to be a few fickle and unknown issues depending on which
> PC/Linux flavors/time of day I tested, and of course sometimes it will
> work for a certain MS but not another. Sometimes MSs won't location
> update to the network, or will hit errors when establishing a call; in
> the usual case, this won't even free the TCH so if resources run out
> the BTS must be rebooted. Just a few issues to name here, and I'm sure
> there are more out there.

All to be expected, I'm sure we will iron those out over time.

> The current focus of work (when I can find time) is implementing
> handover between cells. 

Great.

> I'm not even sure if osmo-bts and OpenBTS contain all the supporting
> functionality for handover (OpenBSC does though). 

OpenBSC indeed has complete hand-over support for both E1 as well as
Abis/IP based BTSs.

osmo-bts does not yet have it implemented.  I was about to work on it
yesterday, but then decided to work on encryption first.

The way it is supposed to happen:
* at the time your receive the RSL CHAN ACT REQ, you need to check
  if it is initial or HO related activation
* if it is HO related activation, you need to PH-ACTIVATE the RACH L1
  SAPI on the TCH
* The L1 will send a PH-RACH.ind on the TCH into osmo-bts
* Osmo-BTS will PH-DEACTIVATE the RACH and PH-ACTIVATE the FACCH/TCH/SACCH
* L2 establishment works normally after that.

> The MSs correctly send SACCH meas reports, the BSC detects
> and decides to handover, and the TCH is activated, but I think the
> Handover Command is getting lost in the BTS or the MS Handover Accept
> bursts are being processed.

The HO CMD is a standard L3 message, so I'm quite sure it is transmitted
correctly through all the layers like other messages.  It's likely that
it's simply the access bursts are neither handled in the OpenBTS part
nor the osmo-bts part..

> Also, multiple configuration files are needed because I have network
> parameters hard-coded (just for ease), which is elaborated some in the
> wiki. I ran into a segfault/bug trying to implement passing in config
> parameters from OpenBSC, and gave up to pursue more critical aspects
> of the project.

I agree, this is polishing that can be done at the end of the
implementation.

> If you'd like to help out by testing or even working on this project,
> it is much appreciated, even if only to help me grow my understanding
> of GSM networks through discussion.

I'll try to find time to review the code and give some feedback.  There
is going to be a delay as we just have OsmoDevCon coming up, and I'm
pretty busy until that is over :/

Keep up the great work, I really love seing all those pieces coming
together.

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)