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/.
Thomas Cooper tacooper at vt.eduOn Mon, Mar 19, 2012 at 5:46 PM, Harald Welte <laforge at gnumonks.org> wrote: > 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: >> 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 ;) 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). > >> 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. Okay that would be great! Of course you should definitely review my code first, as I am still a learning student :) > >> 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. Thanks for the great clarification. I had a slight idea about the random access bursts, but this outlines the process perfectly. > >> 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. 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. > > 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)