 Okay. Our next talk, Andre is going to update us on SRS LTE. Thanks. So we should be running behind and that would mean that we are in 2020 in February, it's the second, it's two past two. And it's the only slot. Cool. So for those of you who don't know us, we're building open source end-to-end 3GPP protocol stacks. So with our software, you can build like fully and software run a entire LTE network. So you can have a UE, you have an E-Node B, which is the base station and a core network. You can run that entirely in software views herbs or RF front ends. You can use the E-Node B connect commercial handsets or your phone to the E-Node B or you can use the UE and connect to a commercial cell if you want so. And we do all sorts of crazy things with that. So we put the UE's in cars and in planes and like the satellites and stuff like this. Most of us know us obviously through the open source project and like we have a big or long history of researchers that use it for like security analysis. And that would be like a list of the GSMA, which is like a central entity that collects security vulnerabilities discovered in 3GP stacks. And out of this list, all of those have used SRS LTE. So it's pretty, so eight out of 11 of the recent CVDs have used that. And we have a list online on SRS-LTE.com and it lists currently over 165 research papers using our software for, but obviously there's other use cases, not just research or not just security research. So what I'll be talking about a little bit is the highlights of SRS-LTE from 2019. We're looking a little bit at 2020. Then I'll a little talk about a little bit about the platforms that we're talking because this has, we've extended this a little bit and briefly this touching, well, continuous integration, continuous delivery, test and quality assurance in general. So in 2019, we had three releases. So we've been following like a three month release cycle. And in early 2019, we added DTD support, so time division duplexing, something that is not used here, but in China. Carrier aggregation to the UE, we added a 3GPP channel simulator so you could basically emulate a channel when it is received from the UE or transmitted at the eNOTB. We added paging and user plane encryption to the eNOTB and the EPC. In 2006, we basically used those two releases, 1906 and 1909 to refactor a big portion of our protocol stack. So there hasn't been a lot of features added into this release and also the next one. So we focused on preparing it and making it scalable for all the developments that we were planning to do. So we did it in summer and in 1909, we started to open source the first 5G and R blocks, which were, yeah, I'm going to talk about this a little bit in detail, but there were kind of extensions to protocol layers, to data plane protocol layers that we had. We started to put MBIOT, which has previously been a closed source implementation. We started to put that open source through the community. We added circuit switch fallback so that you can actually use, have a network of 2G and 4G and have someone falling back to 2G for having calls. Yeah, thanks to Howard for who's unfortunately sick this day, so get better soon. So we get more additions from Howard there. Yeah, we also added conformance testing, like we started to add the conformance testing architecture there and in 1912, so just in December, we added for the protocol layers for 5G, we added support for RSE message packing, unpacking and also for interacting with 5G core, we started to add NGAP packing, as well as some cycling support, I will be talking about this later on. So for 2020, we are actually planning to change our release cycle a little bit. So those past two years, in which we've done a three month cycle, they've been quite stressful, not only because it takes a lot of time to prepare releases and fix. Everyone wants to get pull requests merged in and then you need to make sure that you do the quality assurance okay and that everything does not break and you don't introduce regressions. But especially the 06 and 012 release, they were quite hard because it was close to Christmas, everyone was on vacation. And then that's why we decided to go for that six month cycle from now on basically so that there won't be a 20 or three. So we will adopting kind of the Ubuntu cycle and releasing in 04 and in 010 because that better fits our development cycle. So basically after the start of the year, you have enough time to pair things and at least that's what is our intention. We'll see. And then for the autumn release after the summer, everyone comes back and you develop and test and then you have a good autumn release. So that's what we were looking at for 2020 at least. Let's see if we change that in 21, I don't know. Okay, so what are the upcoming features for 2020? So we will add more 5G and R stuff for sure and something that we are looking at is NSA, so non-send alone mode, which basically means that and all deployments that you're currently out there, they are non-send alone, which basically means that you always have a 4G, which kind of so as an anchor carrier and all the control, all the signaling is going over 4G always. And the NR is just to offload and to provide higher throughput essentially and and it only supports the data plane. So B can ask to enable a 5G bearer and then you have additional capacity and additional channel that goes over NR, but you always need 4G, so there's no way. As opposed to send alone where you really have on the right side like a 5G core, so a core network that exists and speaks the 5G language and can really run independently, well, send alone, as the name says. And as for most of our developments, we are focusing on the UE first, so this will be added in the beginning and then later on the eNOTB. What we have done so far is the user plane protocol layers, like all the extensions to MAC, RC, PDCP, they're pretty much done. The full control plane is there for non-send alone, so announcing that my phone is able to speak 5G and stuff like this that you need to do and that's all there. So what we're looking at now is to do the control plane. I mean not really control plane, but the part of the NR that is still needed for, let's say, on this side, so there's a little bit of control and signaling needed. Adding this and then we're extending the PHY, so we will be writing a x86 implementation of the NR PHY as well as an RFSOC, so an FPGA-based implementation that leverages some hardware effect on Siling's fabric and we will target in those. And the upper protocol layers, they're just run on the arms in this platform or on x86, so this is no problem. CV2x, so basically we've heard about car-to-car communication using 11p, so there's kind of two competing standards for car-to-car communication. One is based on Wi-Fi and the other one is the cellular way and that's why they put C there, so it's the cellular V2x. And so basically what it means if you're talking in cellular context is that usually like a phone is connected to a base station and there's uplink, downlink going through back and forth between a UI and a base station. And if there's, if you have two UI's that want to communicate, you always need to go through the base station, so essentially having a round-trip time or a round-trip between two UI's, it's like up to the base station, down to the UI, up to the base station and down to the UI again. And the idea is, I mean if they're close enough to each other, we could just have a site link, so SL, so let those two devices communicate directly with each other. That's essentially what site link brings, using LTE signals, more or less like modified versions of that, but more or less LTE-FI and 5G-FI in the future. And we have started to implement that and we are targeting like all four modes. We have a full file-layer implementation of Sidelink and we have joined a Etsy-sponsored interoperability testing in December in Malaga where we essentially tested interoperability with all like implementation from all vendors, like from test equipment manufacturers as well as all baseband chips and baseband, yeah, baseband chips that are then put into units, onboard units from various vendors and that's something that we will open-source as well in the next release. MBIT, I've been briefly mentioning that, so we've been developing this in private, but then later last year decided to open-source that and we will be adding a full file-layer for the UI and the EnotB into mainline SRS LTE and that's something that you can get then, in most countries, if you turn on GeoForce 4, you spot in the 800 megahertz band more or less like in some networks, you spot something like this, which is an MBIT carrier in-band in the LTE signal, sometimes also out of band here to not raise those resources and that's something that you can then sync on and decode. The reason for not putting the up-layers is only resources, so we do have them but we need to refactor them and then put them there, but the file will be there and that's something that you can then have like a critical user interface with constellation, sync and some message decoding of the broadcasting messages. Then CRMQ, that's something that we've been briefly talking about in the last FOSSTEM where we, basically the idea is to run LTE networks without needing, without requiring RF hardware, so basically to lower the entrance level a little bit, so you can run an LTE network but you always need at least two relatively expensive devices and a few computers and with this you can, you could do that basically without hardware and for us as developers that's pretty attractive, I mean we do have hardware but we want to use it for running wall grind and then address sanitizer and GDB-ing stuff that you cannot do if you're running over the air with a user, so you want to run stuff faster, slower, pause and stuff like this and maybe emulate more complex scenarios with multiple ENOBs that are very difficult to control and to orchestrate and so the idea was to basically use CRMQ and instead of sending those acute samples, I mean we're still running the full file to usurp, we are using CRMQ to send it over IPC or IP to a receiver and then we, yeah, we basically add a timestamp synchronization for that because LTE is like very much depends on time stamps and time synchronization, so we added support for that and then we've also removed all the dependencies from system timers in the UE and the ENOB this year so there's no, all the timings arrive from the samples that come from CRMQ in that case or from the user if you run it normally, that allows you to run a full end-to-end system like in the CMake like testing thing without requiring containers and other dependencies so it's very basic but it allows you to run those things with a make test basically and that's just a screenshot of how this looks like so it's three consoles, here you have the core network as there is EPC then the ENOB and then here you have a UE that attached to, you know it's a great channel, look at this, look at this constellation and yeah and you see like it just behaves as if you're running over the air, very good and it's all running on one machine and you can debug it, you can GDP it, you can single step through it, it's all good at least on the RAN side, okay. ASS and ENOB outlook so actually ASS ENOB is always a little bit like the step child of ours so we are like focusing on the UE so much but it's not, I mean we really don't mean that but the good news is that we will be focusing on ASS ENOB a lot more in the upcoming months so we not only add new features like handover for instance so this is needed if you have two cells and your UE moves so it's leaving basically the cell range of one base stage to the other one you need to do a handover so that will be added, there will also be support for carrier aggregation so a single UE cannot only have a primary carrier but you can add multiple carriers to it so and that's needed for increasing bandwidth obviously so yeah you can combine up to well five in release 10 and up to 32 in theory in I don't know release 30 I think so we see how much GSP we have to do that and we will focusing on performance and stability a lot so we're going to deploy this and this needs to be like rock solid target platforms so up until now we have really just I mean the priority has always been on x86 so the PHY is so computationally intense that it's not really viable to run a full ATE on anything else like the PHY on anything else on x86 just because all of the you know all of the like SIMD that is required and even ARM I mean it does have SIMD but it's even if you have a powerful like the snapdragon or Raspberry Pi 4 it's still hard I mean you can run like smaller bandwidth like six pure b is probably okay but a 20 megahertz or 20 megahertz LTE signal and there's no way you can run the entire PHY in ARM but it's getting better and yeah the idea is to basically widen that a little bit because of obviously it's getting better and up until now having focused on x86 only we will expand that so we do support ARM already but we will extend this to sync ultra scale so in fact we have a full PHY for downlink on an FPGA that basically offloads all the heavy stuff to an FPGA to sync ultra scale plus and only once the protocol layers L2, L3 so the up and non so not so these P critical things in ARM and that's something that we do with the same code base so we are this is not something different or different for us so so we are intending to maintain this and use the same code base that runs on all those platforms and we will see I mean maybe the ARM I haven't looked at the NVIDIA once perhaps a little bit more performant but maybe you can even run a bigger cell there with all these P in the ARM that would be would be cool so besides the wide range of RF hardware we're also tying a wide range of these P platforms here quality assurance so this is yeah like if you want to target like commercial crate I mean depending on what that means deployments and then things I mean you have to really look after of the quality and then after you know recreations that you do in your development and that you introduce and then that basically what you what you're you know putting there to a customer setting to a customer or putting on get up that actually satisfies your your needs and one of the building steps is obviously a continuous integration platform that we have and then we currently have around 600 not not exactly 600 it's a little bit less depending on what configuration you have a unit test that we are constantly running in Jenkins that is building for for x86 in ARM running atrocentrizer while grind limited in ARM and then basically executing those tests on a pull request basis and periodically in Jenkins as well so we also try to leverage from static code analysis tools that is available for open source projects like severity a tool from from synopsis as well as LGTM and that's something that we basically did in the in the last release so by looking at the initial analysis you kind of had a code quality batch of E which is like the like the worst you can get I mean it wasn't that bad actually and then and then we you know addressed a few of them some of them were yeah anyway so you you get now a and and and I hope we will get an A plus so that's that would be the best that's the second best but it also depends obviously on the ratio between code lines of code and errors that you have yes and then obviously unit test not enough so we are RF people so we have also an RF continuous integration that we call RFCI internally that we heavily use for yeah finding a regression box and and things like that that target or that are related to to RF things like like yeah these p and after related issues and we have been developing an in-house testbed where we used Jenkins that SSH into machines launch docker python scripts that you know post-process results and analyze logs and stuff like this create reports and that's also that we exit is also something that we execute on each pull request and periodically like long running handover test 24 hours 48 hours that we run you know weekly on a weekly basis something that yeah we'd like to announce here as well as that we've recently you know agreed with this become that we are more closely working together and basically adopting because this in-house testbed I mean it was a good thing for us and it worked for us but there's a tool called or yeah like a software called Osmo GZM tester which has a lot more features that that that we had and and it just made a lot of sense to kind of get SSLTE support into Osmo GZM tester so everyone else can use that it's already like open source is an Osmo Comp project so we will adding Osmo GZM SSLTE support to Osmo GZM tester and then basically we'll rebuild that entire framework with running tests and producing logs and reports and probably also trying to make those you know available for the outside world and also extend the RF infrastructure and that's a photograph that Harrod actually took so that's an installation in Osmo Comp where there's where Osmo Comp has built like a rack and a 19 inch 1U essentially housing that houses like various RF front ends and all connected cable together with variable antennae are all controlled remotely so this allows you to you know reproduce experiments to run those continuously and that's something that we are looking forward to and and extending also Osmo GZM tester for that. Another thing was conformance testing so I will briefly touch this so all the UEs that we have all the phones that we have they're they're running conformance tests so they need to obey like tests that 3GPP actually does and you usually do that you go to a testing entity you get a wrote on Schwartz one million you know a euro thing that you can test you with nobody can afford that and so what we did is to use Eclipse Titan it's a Eclipse project it's a TTCM3 compiler that is actually the language that the conformance tests are implemented in and basically wrote a system simulator that basically acts like this guy without phi fake phi and that's something that we can run on the Raspberry Pi it's all integrated in our conformance in our continuous integration and this is something that that like really helps to to make sure that you actually does what it is supposed to do and it complies with all the you know all the conformance requirements on the protocol side of things and we are running fully unmodified protocol stack there to test against the test and that's it thank you no I mean there's like we have a question yeah sorry so is the ROS here MQ transport LTE specific or not there is like timestamp synchronization and resampling and the resampling thing thing is something that you just you know put a base rate because how do you reconnect so base station depends on the bandwidth so it's first surges in the lower bandwidth and changes the bandwidth so you need to do a little bit of resampling there but I mean other than that no it's it's it's not LTE specific at all no thanks for that question yes the question was if we have been looking at the Pluto to implement LTE yes so two things the Pluto like at ease like really requires strict timing and so we need to know when we receive samples what the timestamp is and when we transmit them because the transmit is always you know aligned to the to the receive side and what we need to add there is timestamp support because the Pluto lipo doesn't have timestamp support very good are we looking forward to that so then the extension of of that would be yes you could perhaps run the mbaot on the Pluto itself definitely on the host but you still have your to a usb2 bandwidth limitation so you can definitely run the mbaot and probably is like a small LTE cell six pubes 15 pubes but definitely not the bigger ones because they're like 20 megahertz so you and then you're not getting that over the usb2 if you're going to Jenkins there are better alternatives okay thank you yeah I mean we just used Jenkins for continuous integration really so it's not you're already oh yeah yeah it's deploy yeah yeah yeah yeah yeah yeah of the serum q no I mean we don't so the question is if we if we have sms support so no no we don't do that I mean it's it's possible to send sms over nas signaling from the from the EPC and I know of like a few like users on the list who have looked into this but there is not it's not officially supported in our in the open sources okay yeah yeah it's it's yeah I mean yeah yeah yeah yeah yeah so I mean there's a few hemorrhaging users I know of and then they yeah obviously I mean it's the limitation is the rf that you're using and we are agnostic we are rf agnostic so we can yeah I mean like so there's a like we have a lookup table for all the 3 gbp like official channels and maybe you cannot directly use your channel of interest because it's not an official one but you can obviously add this if you want yeah I mean I don't see a problem here yeah