20 Mar
2012
20 Mar
'12
2:51 a.m.
On Mon, Mar 19, 2012 at 5:46 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Okay that would be great! Of course you should definitely review my
code first, as I am still a learning student :)
Thanks for the great clarification. I had a slight idea about the
random access bursts, but this outlines the process perfectly.
Thanks for the encouragement, and any feedback would be terrific!
Hopefully my inexperience doesn't show and it isn't too hackish or
anything.
Also take your time, I know you're a busy guy.
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 :(
It's okay, I'm sure you have a lot of other projects you need to work
on; I'm glad to be able to help a little. Your skeleton framework and
layer separation were actually very helpful for getting me started
since I hadn't had much experience developing OpenBTS or Osmocom. And
reading code is a lot easier for me than reading lengthy specs to find
a starting point.
On Mon, Mar 19, 2012 at 02:27:28PM -0400, Thomas Cooper wrote:
Haha sounds good, although I'm perfectly fine with leaving it named
openbts-osmo. I just wasn't sure if any of my code would ever make it
into your repo (since you were working on it already and I just needed
to finish mine quickly).
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)