 Yeah, this is the presentation about the Osmo-com BTS hardware support, which is a presentation I am doing together with Alexander, who is, ah, I was looking at you, where you were sitting before, it's like, oh, the chair is empty, where is he going, he's right here, yeah. So I'm going to do the introductory part and talk about mostly the more classic BTSs and then Alexander is taking over for the Osmo Tier X related BTSs, because that's really his, if he has way more information or way more understanding than I have. So I have tried to draw a slide or a graph using my favorite slide drawing tool called Dotty, and I tried to show all the different supported BTS models. So actually, it's too wide to really put, even with this writing on a single slide, but this is basically all the different BTSs that we support, try to fit that on one slide. This is also already in the wiki, I already put it in the Osmo-com wiki, so they can review it in more detail. So in general, we have two classes of BTSs that we support. We have the classic E1T1-based BTSs that are illustrated there, and we have the IP-based BTSs on the left-hand side. Most people are these days, of course, focusing on IP-based BTSs, but still I'd like to include those E1-based, because there might actually still be some use, because you can get quite professional grade E1-based BTSs second-hand very inexpensively these days. And that's also where we started, so we started with E1T1-based BTSs, and we have support for basically three different vendors or dialects of the AVIS interface. I'm not claiming we can support all the Siemens or all the Ericsson-based stations, or all the Nokia ones, but these are sort of the models that we have successful testing with, and particularly in the Ericsson case, I'm quite convinced that almost all of the RBS 2000 BTSs should work, because they all have the same protocol architecture. And in terms of advantages or disadvantages, if we look at this, right, on the pro side for these old E1T1-based devices, well, you get them very inexpensively from decommissioned sites, and that doesn't mean, I mean, you have to chase individual people who de-install or decommissioned BTSs, but there's an entire market and there are suppliers such as Shields-E or PowerStorm or however they're called, basically companies that do nothing else but sell refurbished or second-hand telecom-grade equipment, and they have huge databases and catalogs, what they have currently in stock and so on. So, and you can get like really large capacity, so up to 12 TRX, which I think no IP-based BTS that I know supports, whether open-source or not, you can get really high RF output power built into the devices themselves. As said, you can get like 40 or even more watts, a rugged mechanical build, mean time to failure. Of course, they're also used and they might not always be an advantage, because well, they've been running for quite some time. Anyway, yeah, on the con side, well, it's a bit antiquated. Not many people are familiar with the technology even to, let's say, install E1T1 lines and to debug them and to analyze issues, and it's not so nice. Also, in terms of interfaces, you just don't have an E1 port on your laptop. And even in a lot of embedded devices, if you think of very popular embedded Linux devices, nothing has anything where you have an E1 port. So, you end up having to have a device that has PCI Express slots and have to have PCIe cards for the E1 interface. So, it's not that nice. Power consumption also tends to be really high, of course, because it's old equipment where efficiency was not such a key aspect and also the technology was not as advanced to have that efficiency. And then also the very old models, like the Siemens PS11, for example, they don't have EGPS, so there's no 8PSK support or no AMR codec because the design of these devices predates adaptive multirate. So, how does this actually look like? I have to bring this up. A lot of people will know it already, but this is actually two Siemens PS11 base stations at the Hacking at Random Camp 2009. And this is the professional antenna installation. No red tape here. No pun intended. And so, well, that's basically was the first deployment of OpenVSC at the Hacking at Random Camp 2009. And here you can see all the cabling coming down from the antennas. So, we had an E1 backhaul over Cat5 cable to OpenVSC running in a tent. I'm not showing the tent. So, we have some other devices that we support over time. There's the RBS-2308, for example, as many other RBS-2000 models, also RBS-2111. And this is actually a picture like you can find it on eBay right now today for, I think, like, $300, $500 or so. And it has 40RX already inside, you know. It's a pretty good price point. That's of course the IPS NanoPCS. This is an old one. There's more modern ones. And that's already getting into the IP-based world. So, yes, they're PoE-enabled and so on. You can deploy them. You can get them in GPRS only or EGPRS-enabled models, band specific and so on and so on. But of course, like all the previous ones I described, the BTS and or people, in this case, the PCU is also inside is proprietary. And not everybody has been quite happy with that for all kinds of reasons. And the number one reason even is that lots of crashes and no way to fix it. So, yeah, but it is one supported option. Also, there's no fully dynamic channels, which we support in the Osmo BTS-based devices these days. So some features. Then you have lots of system of BTS devices. I don't want to talk too much about them. It's like the different devices we have and the capabilities, which as we have described before, use Osmo BTS and Osmo PCU. There's something from a company called Neuran, Neuran Light Cell 1.5, which is a Tenwa 2 TRX outdoor BTS, which has a specific port of Osmo BTS. It's called the Osmo BTS Light Cell 15, because we don't want dots in the executable names, which interfaces with the proprietary physical layer using a shared memory queue. And we have Osmo PCU, which pretty much does the same in that device. And this is in master mainline of the repositories. So this is not some fork of the code, but it is on gitosmo.com.org. There is Octasic boards. This basically, it's various different, basically SDR boards with proprietary physical layer running in an Octasic-specific DSP. We actually have a port of Osmo BTS that can run on that. That's the Osmo BTS OctFi, if you've ever seen that somewhere, by compiling or configuring the code. It talks over Unix domain, socket to the Osmo PCU for GPS support. And there's a series of different boards, which have different number of DSPs, number of radio interfaces and so on. You can check the manufacturer if that's something that you're interested in. As far as I know, maybe I'm wrong. And please correct me if I'm wrong. EGPRS is not working yet due to some issues with the integration on the PCU side. Is that correct, Philip? Yeah, yeah, okay. That's still the case. Also, I think not all voice codecs are supported. The GSM supports at the moment, but otherwise it is like any other Osmo BTS supported device. And that's where I'm coming to my end of file and handing over to Alexander for the Osmo TRX and Osmo BTS TRX supported devices. Okay, yeah, so now let's talk about software-defined radio or more DIY way of playing with Osmo COM and all the way to production. So for those who don't know what software-defined radio is, so software-defined radio is the easiest way to describe that it's a sound card for radio waves. So the same way a sound card takes digital signal on your computer, produces sound waves. Software-defined radio takes digital signals on your computer and it produces radio waves. That's the basic way how it works. So the way it interfaces with the Osmo COM stack is that, so you have this hardware, which is software-defined radio, right? And it is talking to the radio part of the system. And on the other hand, it is taking the digital signal into computer and talking to all of this software on the computer where UHD is a driver basically, which is working with the multiple versions of software-defined radios and then providing a single API to a software called Osmo TRX. And Osmo TRX is implementing what's called layer zero or lower layer one, which is basically doing modulation, demodulation and producing bursts of soft beats. Then they are going to Osmo BTS, which is implementing layer one, layer two. And after Osmo BTS, it's the same familiar Osmo COM stack as with every other architecture. So a small overview of SDR hardware available currently for Osmo TRX. So two most popular by my personal assessment are looking at the like mailing list and talking to people. So is our young TRX, which was designed specifically for GSM. And by the way, a laboratory version of this is open source hardware with all the sources published. So it's open source hardware device. And the second one is a USRP B200, which is just a very popular software-defined radio in general. That's why many people are using it with Osmo COM just because they already have it. And there is a bunch of others like USRP one was the very first one ever used for GSM, now no longer manufactured and sold. And then there is like USRP and 200, which are more expensive, we usually use in laboratories embedded devices, recently LIME SDR was supported, which is a new USB based low cost SDR. So X-Tricks, which is a new generation of SDR, we are developing currently, it's will be available soon. So an answering to two popular questions. So Blade-RF and HAC-RF are not supported currently for different reasons, HAC-RF is half-duplex, so it's not possible to support it because base station must be full-duplex. Blade-RF technically should work, but there was no work done to actually implement the NOS material. So patches are welcome, if there are Blade-RF funds, welcome to submit patches for this. So if you're looking to get a new SDR for you, so there are several parameters you should be looking for and should understand to make sure you are, you're getting what you're expecting. So the most important part and the biggest issues you will be facing is clock accuracy. So according to the standard, clock accuracy of GSM cells must be 50 ppb or 0.00 ppm, which is parts per million for macro cells or 0.1 for small cells and for Pico cells. So that's quite accurate clock, let's put it this way. So this is required if you want to build network with Handover, for example. So in practice, if you're doing lab testing with a single base station, 200 ppbs or 400 ppbs, apart from a billion, that should be okay, as long as you don't do Handover. Most phones will work. For the death, there is no guarantee. Some phones will work, some phones will not work. Some phones will kind of work and then fail. It's like no guarantee space. The problem is that most commercially available SDRs out there has accuracy of 1.2 ppm, which is like an order of magnitude worse. So what this means is that this is basically heat and mist for you. If you are working in the laboratory at fixed temperature because clock drifts a lot due to temperature, if it's fixed temperature and you calibrated it, may work for a while, may stop working next day. If you're getting on a street, it will stop working again, so it's heat and mist. And you will also depend on, okay, so this unit works, this unit doesn't work because they have different crystals with different initial accuracy due to manufacturing differences. So, and this applies to all users of SLIME SDRs, Blade or F, so pretty much to all of them. So what to do in this case, you have basically two options or like three options. So first of all, you can use external clock. So if you have another stable clock, maybe from your signal generator and laboratory or just a static clock, you can use this as a clock source to look on it. Or you can get GPS DO, for example, ATOS is selling GPS DO specifically for their users, and then you have to put in 10 and get look to GPS signal to synchronize. Or you have to regularly calibrate towards using some other external clock source. And this problem was actually the reason why we started YUMTRAX project back in 2008, I think, or 2009, because we were completely stuck with this issue. We created our own clock, then we started creating our own SDR. And so YUMTRAX is again, the only popular SDR I know of, which has a clock, which is 0.1 ppm stability by itself plus GPS. So you can get even lower to 50 ppb with GPS lock, which means that you won't have this problem at all. So next thing is clock rate. So GSM symbol clock rate is 13 divided by 48 megahertz. And ideally, you want to avoid fractional resampling, makes signal slightly worse, adds a lot of CPU consumption. It's not the worst thing ever. For example, user, and even though it has a 50 megahertz clock, which requires fractional resampling still generates a good signal, many people are using it in their labs, better to have integer. So again, if you are choosing something for your experimentation, better to have something like YUMTRAX or B200, which has a flexible clock rate, so it adjusts to your requirements. In other two points, first of all is interface. So there are three interfaces for different software defined radios, first is USB, which is like user pb200 and LIME-SDR, other is Ethernet, it's YUMTRAX, and the different versions of USURBS and PCI Express, again, for upcoming DixTrick. So USB is very handy when you are doing development and specifically if you are using your laptop and you're moving, so you just plug in and it works very nice. On the other hand, there's a lot of issues with USB if you try to run it in production for month of runtime, various issues with USB. So that's why, again, Ethernet is much more handy if you are doing something long-run related. I'll put the refpower, now there are popular questions, so people are buying SDRs and they're like, oh, my SDR is not covering more than a couple meters, so what do I do, right? So first of all, a thing to note is that there are very low power SDRs, then DBM is basically 10 milliwatts and some of them even go lower, so B200, E300, LIME-SDR are all in this wallpark, and there are SDRs which have higher power, so again, Euntricks, user pn200 have higher power, so with low power, you'll get like a few meters, less than 10 meters, definitely. With these guys, you can get like 100 meters, 200 meters depending on configuration antenna or whatever, so. Radio front end, another thing to keep in mind when talking about radius is like the coverage is what is your radio front end, because again, this is just 100 milliwatts out of here, so and even if you have 100 milliwatts in some cases you don't need duplexer, in some cases you don't need duplexer, so what is duplexer? So duplexer is device which actually combines transmitter and sieve signals and separates them, so to make sure that your transmit signal is not blinding your receive signal because if you have too strong transmit signal your receiver will listen all this noise and will not be actually able to receive low power signal from phones, so if you are adding any power amplifier, duplexer is basically a must for you and another thing, and the LNA is low noise amplifier, the same on the receive side, so this ties back to what Harold was talking about the path loss calculations and how it's called, the sensitive CVT and all the stuff, so this is what affects it, right? So and this is how it looks like, for example in our base station, so this is our base station like inside, so this is the SDR, this is the PC and this are two power amplifiers because it's a dual channel base station, so the power amplifiers and this block is low noise amplifier plus duplexer, so you can see that, so this cable is going into like from the SDR into power amplifier, so here it gets out of power amplifier, amplified goes into here and then goes into duplexer inside and this is antenna, so from TX it goes to antenna here, then on the other way it gets from antenna inside, goes to here, this which is receive port and then go through like low noise amplifier here and then into the SDR, so that's how it looks like. Yeah, the same picture like layered, so another reason why you do care about duplexers when you're putting amplifiers is that you should filter out all the noise you will be producing in the spectrum and I request that if you put an amplifier, don't put it into operation unless you have good equipment to check that you actually filtered out all the noise, because this is a signal which we, for example, transmit at what's that, 826 megahertz, which is I think in 850 band for North American GSM band and as you can see, this signal also has the second spore at 2.4 gig, which will basically completely interfere with your Wi-Fi, Bluetooth, whatever you're running in 2.4. So unless you filter this out, this will be in the spectrum and it will be high-powered, the difference between one and two is only 2.4 gig, only 10 dB. So if you are putting like 10 watt amplifier, you will be like one watt at this, which is like a lot. So please don't do that. Okay, so now to the actual configuration. Well, actually you can read all of this in the documentation, but basically there are very few parameters of receive gain, transmit attenuation. Again, we are transmitting attenuation, not the power. A max delay is basically the radius of the cell. Everything else is not so important. These are the parts which you have to really care of and a mass power loop also make sure you're doing this right. So Osmoeterics has no VTI, no file configuration, only command line options, but in most cases, you just need to, you can just run it with no parameters or when you mean all parameters, minus G just enables GPSDO lock for user P. Otherwise, it's very straightforward to run initially. If you want more channels, specify minus M, with B210, there's no M because it's already dual channel. And that's basically it for now. Again, slides will be published if you want to read them in more details, you are welcome to do so. Okay, thanks. Slightly, do we have questions? Again, we are slightly behind schedule, so but still one or two questions I think we can take. Okay, so just about the Blade RF, does it, I believe that works with Yate BTS, right? Which I, is that I? That's my understanding as well. So, yeah, so basically Yate, so initially Osmoeterics is a fork of code from OpenBTS, so OpenBTS transceiver was forked and we created Osmoeterics and added much more features, optimizations and whatnot. So Yate BTS has another fork, but I guess the code base is kind of compatible. So again, if there is anyone interested in Blade RF support, you can take a look at Yate BTS code and try to adapt it to the existing Osmoeterics code base should be reasonably doable. Hi, just a small question. This is regarding, I think, a 2G. Is some project or some plan to do compatible the Osmo UMTS project with SDR boards? Well, so there is OpenBTS UMTS, which is outside of OsmoCom project, which is a completely separate open source project. It supports SDRs, like our UMTS is supported, the user PISA supported. I mean, you can try it. It's not very stable, it's definitely far behind stability in terms of, compared to OsmoCom projects. So Thomas wanted to ask something or comment something. So Thomas is actually the maintainer of OsmoTRX, so. So regarding the OpenBTS UMTS, my understanding is most of the development on that now is no longer in the public open. Range Networks is still operating a business there, but they have a commercial version that's internal and we don't know what the status of that is. So for anyone interested, you would have to contact them for that information. And also speaking from the other research side, I'm not aware of anyone working or in progress on doing anything in terms of UMTS layer one, so to the best of my knowledge. Yeah, like my personal understanding is that UMTS is going to die way before 2G and LT will just take over. So there's a lot of going activities in 4LTs, there's a lot of activities for GSM. UMTS is kind of just declining. Thanks for the welcome. Haha, yeah.