Hey all, 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. 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'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. 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.
The current focus of work (when I can find time) is implementing handover between cells. I'm not even sure if osmo-bts and OpenBTS contain all the supporting functionality for handover (OpenBSC does though). 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 newly activated osmo-bts instance segfaults somewhere in LAPDm. I haven't had time lately to pinpoint the error, but just wanted to update on the current status of that.
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.
Github repo: https://github.com/tacooper (first release tag for Osmo-USRP = v0.1)
README/Guide: https://github.com/tacooper/Osmo-USRP/downloads (issues, configuration, and example setup for single/multi-BTS networks)
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.
Thanks! Tom Cooper
Thomas,
Congratulations for the release! Hopefully we'll see it stabilizing as more people start playing with it.
Am I correct, that you use Transceiver52M and the lower part of OpenBTS and the rest is from OsmoBTS? It would be great if the architecture were described somewhere in the docs.
On Mon, Mar 19, 2012 at 22:27, Thomas Cooper tacooper@vt.edu wrote:
Hey all, 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. 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'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. 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.
The current focus of work (when I can find time) is implementing handover between cells. I'm not even sure if osmo-bts and OpenBTS contain all the supporting functionality for handover (OpenBSC does though). 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 newly activated osmo-bts instance segfaults somewhere in LAPDm. I haven't had time lately to pinpoint the error, but just wanted to update on the current status of that.
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.
Github repo: https://github.com/tacooper (first release tag for Osmo-USRP = v0.1)
README/Guide: https://github.com/tacooper/Osmo-USRP/downloads (issues, configuration, and example setup for single/multi-BTS networks)
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.
Thanks! Tom Cooper
On Mon, Mar 19, 2012 at 3:15 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Thomas,
Congratulations for the release! Hopefully we'll see it stabilizing as more people start playing with it.
Thanks, I hope so too.
Am I correct, that you use Transceiver52M and the lower part of OpenBTS and the rest is from OsmoBTS? It would be great if the architecture were described somewhere in the docs.
That is correct, with a few minimal changes in OsmoBTS to get them to work together. Good idea, I have added another doc file to https://github.com/tacooper/Osmo-USRP/downloads with a basic description. I am just starting to write my thesis so more detailed descriptions will be available as I get to them.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
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
On Mon, Mar 19, 2012 at 5:46 PM, Harald Welte laforge@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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Alexander Chemeris -
Harald Welte -
Thomas Cooper