 All right, Andre is going to talk to us about LTE test beds. Wow, yeah, kind of. OK, so. Yeah, no, it's right. Thanks, Phil. So I'm Andre. I'm with software radio systems. And we do SRS-LTE, who you guys knows about SRS-LTE or has heard about it, who has actually used it. Not too bad. Cool, so hopefully you'll learn a little bit more about this today. So we are a relatively small company, headquartered in Cork Island with offices in Dublin as well. But most of our development takes place in Barcelona, Spain. And we are nine people, and we are growing. SRS fast in history, so it's been long, actually, since we started business, really. So first talk at FOSDEM about our software has been given by Ismail back then. LibLTE is an open source file library for doing signal analysis, or LTE signal analysis. Then 2015, there has been a talk given by Paul about an overview talk about available LTE, SDR software platforms. And there has been another talk three years ago by Ismail already looking at SRS-LTE, so the first UE implementation utilizing the base file library. And now 2017 and 2018, what have we done? Did we do anything at all? Did we just relax on the beach in Barcelona? No, we worked. And 2019, we're here again. So the SRS-LTE ecosystem, as you might know, so SRS-LTE is, first of all, a library, a file library, which we use for a variety of applications. And it basically implements the file as well as, and that's why it's a core LTE library, really, as well as common blocks that we share in upper layers as well. So from PHY, MAC, RSC, PDCP, RSC, you all have helpful functions that are shared among all then on top of the core library, such as SRS-U, as I said, SRS-E node B, which is fully functional LTE node B. And our most recent offspring, SRS-EPC, which is a lightweight core network implementation. And there's a bunch of other commercial products that also build upon SRS-LTE or the core library. So as a company, we're doing public projects as well as commercial projects. Why I'm bringing this project here specifically is because this has guided our development roadmap for the past two years, actually. It's a project called Open First, funded by NIST in the US. And they funded us, or still fund us, to build a fully end-to-end open source LTE network testbed with specific focus on public safety. So that's because they're most interested in. So we open sourced functions of particular interest to the public safety community, such as NBMS and D2D and other things. And we will have a look at this in a minute. So this slide just gives you a little bit of an overview about the releases of our software. So the left-hand side of the slide is basically the old version and scheme, which we started with just, yeah, normal 0.1 and so major-minor releases until version 2, which is, well, only one and a half years old. And we then switched to like that year month scheme that you probably know from Mubuntu, for instance. And with that, we also introduced, so in general, we're trying to release our software quarterly, so get out a new release every three months. And we are following kind of a TikTok model there, where in one release, we're trying to bring new features into the software. And in the second, residing in a smaller feature change list, first of all, trying to stabilize the software, but also to take the opportunity to refactor lots of stuff. So that's something that you usually don't see, and people don't really appreciate, but we have to do that constantly in order to be able to get all the features into the software and then to extend at the speed that we are doing that right now. And yeah, besides the 1712 release, I think we were like almost a month behind, so that was released in January or start of February 2018. I think the releases were all kind of in a week window after the version, or what the version number suggests. Yeah, and just recently, we released 1812, so that's our brand new release there in January. So I've collected what I call an important SRS-AT releases because they include quite some interesting features, just to give you an overview. So in SRS-AT2.0, we added or we made the SRS-EnoB public. And a big change for those of you who knew the project from before, we merged SRS-UE, which used to be a single repo into the SRS-AT2.0 code. So now from that point onwards, there was no longer the need for having a specific SRS-AT2.0 library, which back then only included the phi in the common code, and to have the matching UE or wise versa. So that went all into on a single repository, like the EnoB as well. Then in 1709, we added MIMO support for the filer and also the UE. So that gives us transitional three and four for those of you who know that. So you can actually do with a 20 megahertz LTE cell, you can do 150 megabits downlink in software running on your mid-range computer, I'd say. Then we added E-BMS. That's a broadcast services for LTE. So you could have a base station transmitting, for instance, a video stream and multiple UE's receiving it rather than each UE receiving the individual stream. I don't know if that is used in the public at all, but it's an LTE feature that was brought into release 10. Then we're for release 1712, we added MIMO to the EnoB, so you can also, previously, you could receive from another EnoB the downlink signal. Now you can also generate it with SRS-EnoB and serve commercial UE's with that. We added our first release of SRS-EPC, and from that moment on, you could really build an entire LTE end-to-end from handset base station core network just using open-source software. We also added handover and user plane encryption to the UE, so you can roam between cells. And then in 1806, after if you remember, after the E-BMS and the UE, we extended it to the EnoB and also the EPC. So all those changes require, like the E-BMS, for instance, require quite a amount of work in the core network, not only the radio access network. And those features generally just go to the UE first, the first fight in the UE, and then the core network as well. We had something that we called Hotsam Support, where you can use a commercial SIM card reader, plug your SIM card in, and then connect to a commercial EnoB and do the authentication with a real SIM card as well. And then last but not least, so our latest version, 18.12, in which we introduced the biggest change so far in terms of number of code being added and removed from the code base is a new ASN1 library for packing and unpacking RSC messages. So that's a big dilemma in all the open source radio projects. So you need to, in order to pack and unpack these messages, you need to understand ASN1. And we've previously relied on code from OpenLT, but the limitation there was simply that this is stuck to, yeah, the development code stuck at release 8, and we partially added higher releases, but it's very cumbersome to write that code manually, especially when you go upwards. And so release 15 RSC, that's thousands of messages, and you don't really want to write that manually. So we developed a code generator for this, and we know future proof of that. So we can actually generate our own packing and unpacking code there. As well, we added encryption to SRCPC and IPv6 support for the UV as well. So what's our roadmap for 2019? So as I said, so there will be four leases this year as well. A little bit, I don't want to make too high promises, but definitely what's going into the release is close to power control in the UE. Then depending on how the refactoring of our FICOs, like TDD support, so that's the mode for those of you who don't know, like in China, for instance, or also in the US, the carriers usually use TDD. And in Europe, it's FTD, so where uplink and downlink is on different frequencies. In FTD, in TDD, it's on the same frequency. And that's, for instance, a good example. We really required an overhaul of the file library, and that's currently on a merge. Then we add carrier aggregation to the UE. So we'll be able to run up to five carriers with one UE. And there will be user and developer documentation, a long-awaited thing. So later in 2019, I expect carrier aggregation to not be, and also a site link for the file. And probably, as I said, it's going to be integrated in the UE first. But we cannot commit on any particular release for those features, I'd say. Finally, packaging. So that's something that Marco said. So you're still not able to install new radio. And that's something that we also had problems with. So every now and then, people came and said, it's too cumbersome to install the binary or to install dependencies and build the software. And that's true. And that's what we added in 1806 Ubuntu packaging. So we maintain the PPA ourselves. And since then, we basically push releases there, no snapshots. But with that, you can install it pretty quickly. And then we've learned that there's also other people maintaining packages for SUSE or Open SUSE. I don't know what's the difference in the packaging there. Those are maintained by Martin Hauke. And there's Debian packages, which are maintained by Ruben. And they are going into Debian SIT, so unstable. And they are available. And both have actually, no, Debian's a lot updated to 18.12. But the SUSE packages are already at 18.12. And perhaps there are also other distributions that have packages that we don't know. But yeah. Supportive hardware. So we have support for ATIS research equipment. So basically the B200 series, the X series. We still get support questions for the N210. We don't have a resampler, so we don't support the N210. We support, natively, the BladeRF, the old and the new one, and Epic Solutions hardware. And through SOPE, those that we have tested, we have the SDR-TLSDR for receiving LIME. And also, LibIO, so analog devices on embedded platforms. And soon, we will also have a radio driver. It is actually not a hardware driver, but something called, that we called NoRF driver. So it's a serum-Q-based radio driver. So what's this all about? So first of all, most of our testing and development obviously runs with RF hardware. But there's adventures to not using hardware during development, also debugging and continuous integration. So something that we really want to do is to run the full software, but turn off the hardware. Run it with Fi, but not do any hardware. And have those ideal, like as Derek said, those ideal signals there, really. For instance, to be able to use tools like Walgrain or Atrocentetizer or GDB to really debug things without needing to get samples to the user or receive them. To run the code faster, so to simulate an hour of network traffic in half an hour to run it slower and also to pause code. As well as to model radio channels, for instance. So have a set of Bs, a set of UEs, and have a channel matrix between all those Bs and UEs. Also to plot signals and visualize them. But they are associated with that. So first of all, there's no B or UE changes allowed unless they make sense, obviously. But just for the purpose of putting that, we didn't want to introduce new changes there. And we only wanted to have the radio module as a, like really as if it is a real radio, just working over IP, for instance, or local transport. The problem here is that the way we typically use the RF hardware and the way we interface with the user through UHD is a little bit weird because we're not always transmitting, we're not always receiving. We are, for instance, in the UE, we are receiving, so subframes is basically the time unit in LTE. So we're receiving not always one subframe and transmitting one, but the UE, for instance, receives five subframes and then another five and then eventually transmits six subframes later, random access, for instance. So there's no continuous RXTX and no synchronous flow of IQ samples to and from the radio. And there's rate changes as well. So cell search, for instance, you do at a very low bandwidth and then you increase your rate if you find the cell to be 10 megabytes wide or 20 megabytes wide. So that's something we needed to cope with. And there's something that we, so there's still a few discussions going on as to where we put those functions. But in general, I think the idea is to have this no RF radio module, use your MQ for transporting IQ samples and use a request reply kind of model. I've applied it blocking receive and use different, after possibility, use different transports. Put a way of handling the timestamps that the UE generates and that the driver needs to understand and need to interpret into this driver. And then we obviously need to have some buffering and padding of IQ samples. Because of the way I just said, like a receiver expects input, but the UE does not always generate output. So we need to find a way how to deal with that there and the resampling issue. And I think it's going to look like that. There will be NUE, NENOTBs, and well, M, so it doesn't need to be the same actually. Number of UE's NOTBs and kind of a broker that manages the interaction and shows to this side, like as if the UE or the NOTB would actually be a synchronous RF device receiving and transmitting always with the same rate. So and we stitched together a quick prototype. So it's actually quite useful to show that it works. Using SRGNOTB as a transmitter there, using your F7Q radio as a transmitter, and using PSCHU, which is our light white signal, downlink signal sniffer, you could say. And using actually NURADIO as a broker, because with that approach, you can straight away use the CRMQ request reply blocks in NURADIO. From the NNOTB, adding them up, putting them through a failing model. There's a throttle block and a geophosphor plotter and the same signal is also sent to the UE. So you actually have the channel model on NURADIO and that's how this looks like. So you have a slider there where you can introduce some noise there and make the signal slower or faster so you can really observe every millisecond how the downlink is generated, how the noise is added and how the UE sees that all piped through NURADIO. That's pretty cool, I think. Okay, so yeah, a few of you might wonder what's the three clicks thing there in the title of the talk. So when I put that title there, I thought that, okay, we have a PPA, so I should be able to, doing a live demo there, I'll toss them in the software manager type SRGNOTB, click it and because it's installed as a service, it should actually be like three or four clicks, you should have to not be there, but it's not going to work, I found out later. So PPA packages are not in the software center and I don't know a way to install something that is in the PPA with just clicking mouse buttons, but I guess you appreciate that way as well. So it's adding the PPA SSI TE releases, doing update, install SSI TE, then there is a command here, so if you want to run the EPC and you want to have internet on your phone, for instance, or any other UE, you have to masquerade your device that gets access or provides internet access to the machine you're running on, so you have to call that script there and then run two commands and two different consoles and that should get us internet and we just give that a try here. I know there's people who hate live demos but we just give it a try. Okay, so, can you see the console, yeah? So that's SRS INO B and it's not installed, okay? So there's nothing. And I also get your disk screen here, so that's, can you see that phone? So that's a commercial, like, Android phone. That we used there, so install INO B SRS EPC, so we installed that there, okay? And then I do SRS EPC, so that's the call network, we need to launch that, I need sudo, and then there's sudo SRS INO B. Okay, so now I go to the phone, can you see the phone, yeah? I take that phone out of airplane mode and I see the phone connecting and I have this nice software radio systems ATE network there. No, I mean, it's, we're not transmitting at high power, so it's all good. It's will be okay. Yeah, I don't know, yeah, yeah. Yeah, okay, so you guys, you see that, we don't do the phone thing because I forgot to roam the, well anyway, so there's our 4G network. Okay, guys, that's it. No, all good. Claire, I made it on time.