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/.
Labs rp.labs at gmx.chOn 09-Jan-12 23:48, Peter Stuge wrote: > > I understand your reasoning. Some points come to mind: > > * An appliance is an integrated system and not only a software package > > OpenBSC can certainly be part of something larger, but it is "just" a > software package, even if a very comprehensive one. So far I don't > know about any open source appliances using OpenBSC. One thing that > might be interesting to make the very first testing easier would be a > preconfigure VM image that could be started to have an OpenBSC > running in seconds, for when the environment being used is not so > convenient for downloading and building the source, and configuring > network interfaces. > This is what I will do so I will be able to move the image in different labs but my main issue will be how I will connect an E1 transmission based BTS to a VM?! I also don't have an E1 PCI card to plug-in in a PC. I will check if I can use a Cisco router with an E1 port WIC or NM module and send the traffic via ethernet to VM. Did somebody try it? I will start a new topic for this one... > We had some tangential discussions at 28c3 in Berlin between X-mas > and NYE, where we last ran an OpenBSC test network. > So there are more people thinking like me? > > * The OpenBSC software may be integrated in many different ways > > OpenBSC does not neccessarily run only on Linux operating systems > (maybe this is actually a requirement now, but I don't think it needs > to be, and generally it is good to have software be portable across > many different operating systems) - this is significant because any > interface configuration is always highly system specific, and every > integration will have different processes here. Following the UNIX > principle, this is outside the scope of OpenBSC. Ie. interface > configuration is one step considered belonging to the base system, > while software configuration to use those interfaces is a separate > step which needs to match the system base configuration. > I am thinking that you always need to separate the traffic based on destination. That being said you will not use the same interface for management of the box and also for Abis or A interfaces. All of them should be separately defined. Management interface can be defined via normal OS way (or an OpenBSC GUI/startup menu?) but the rest of interfaces should be defined via OpenBSC config. I don't know how it works now, is there any "limitation" or you can have everything on one ethernet interface? > I actually don't think it is such a bad idea to also have OpenBSC be > involved in, or even take responsibility for, some interface > configuration, but this may well require some significant changes in > the source code, so it will not happen very quickly. > I know all of you dedicated a lot of time for this project but design should be done in advance so there will not be a complete re-write of the code in case of small/big? changes. Sorry if somebody feels hurt here. It is just my thinking about this, please no hard feelings. > If it happens I would argue that OpenBSC should configure only those > interfaces which are related to GSM, and that they be kept separate > from the "regular" interfaces used by the system. > Correct, agree. > Such a change will tie OpenBSC more strongly to the particular > operating systems it runs on, which is generally considered a bad > thing. However, I agree with you that there is a certain value to > indeed have all GSM-network-related configuration, including IP, in > the configuration file. > It is considered bad but you cannot just keep on testing different behaviors on all Linux flavors. I think most, probably 99%, are running the project on Debian. Regarding configuration, maybe it will change in time, who knows? > Also note that I'm not really a core developer, so even if I kindof > like the idea that does not have to mean very much. :) > It is an open source project so I guess we can have an open discussion on different ideas or design changes that's why I started this thread. >> I didn't install yet the OpenBSC but as I said in a previous email >> I will have it done by the end of next week and check all configs. > > You should be able to do it rather quickly, also without being a > programmer. The dependencies are not very many. > I know it will be fast just need some time to power on my VMware server. I shut it down last year... > GUI or CLI is a matter of (sometimes strong) taste. I think it's fine > to have different types of user interfaces, but this will possibly > require re-engineering of the existing CLI config interface a bit, > so that other types of interfaces can be integrated seamlessly. > > Of course it's also possible to build a GUI which in fact just uses > the CLI and has nice buttons to click on. All relevant information > must be available through CLI anyway. > I guess I put it in the wrong way in my first email. I work with CLI everyday but for some things I like the GUI. I am probably used with the commercial BSC CLI/GUI so... I prefer to have a GUI for checking fast some transmission line parameters (type/line code/BER results/IP address of BTS), check and reset different BTS boards that go crazy sometime... I am not sure what you can do now in regard to BTS components/modules and if the OML commands sent to BTS can do the above things. I am working on integration/operation of RAN so I need to combine both to be fast and fix the issues. >> I will/can write documentation based on my tests and real life >> experience. We need to discuss more on this topic. > > All contributions are valuable, and you absolutely don't have to be a > programmer to be able to contribute. Documentation contributions, in > particular from real life experience, are indeed very welcome! > I will definitely start to write some docs and update the wiki after I will install and get used with the project. > //Peter > R.