 So, for the next talk for this evening, this is a talk that is personally interesting to me, and I hope to you as well, I'm very much looking forward to it. Our next two speakers will be talking to us about how we can deploy GSM base stations over software-defined radio hardware, so very interesting things that we'll hear from them. So, please welcome Vadim Yanitsky and Piotr Kryshik, a big round of applause to them. Introduction. So, hi everyone, this is our first talk ever at the congress, so thanks for having us here. Let's start. My name is Vadim Yanitsky, I'm a researcher from Positive Technologies Company at the telecommunication department. At the same time, I'm a SMACOM contributor, I had some background in web development but this time is gone, and now I'm in telecommunications. Now I prefer to use C in Python, and this is Piotr. Hello everyone, I'm Piotr Kryshik, I'm working at Warsaw University of Technology. I'm generally a person that thinks that free software, using free software is a good idea and writing is even better, so I created some small pieces of free software myself and one of them is GRGSM, I will introduce it later. Another one is multi-RTL, it's software for synchronizing RTL-SDR devices in order to make from them multi-channel receivers. Okay, so we are going to introduce our work we have been doing for some long time and in a few words we will show you how to run a GRGSM mobile phone on software defined radio. And as you probably already know, our project is mostly based on the SMACOM BB project, so we will introduce it in a few words and we will tell you what's wrong with the currently supported hardware and why our work makes sense and finally we will show you some demonstration. So let me ask how many people here used to play with SMACOM BB? Raise your hands please, and not so much, but anyway, thanks. And so from my experience when people hear about SMACOM BB, they basically imagine and all of Motorola phones, we always hang in firmware, so what is it? It's not a secret for everyone that your phone actually has a separate baseband processor that takes care about the network operation. No matter which operating system do you prefer to use, when you're sending a short message or calling to your friend, your operating system kindly asks the second baseband processor to do that. So a baseband processor is typically running some proprietary firmware and as many other people we don't trust this firmware. So the main idea of SMACOM BB project is to provide the open source implementation of phone side stack of JSM. And the higher levels of this stack are typically represented by software running on your host side, PC, and the lower layer is layer one is firmware which is running on some Calypso-based phone. And the implementation is more or less complete so you can make some voice call and receive SMS messages and so on. But at the same time this project is not actively maintained at the moment. So you may ask me why do I need this project, for what for is it? And well it depends on who you are. If you are a student or JSM beginner, it may became your best friend in practical learning of JSM stack. If you are some kind of security researcher or doing something related in JSM networks, you probably already know about this project and I don't need to explain you. And of course it mostly helps to debug existing COSMACOM projects so yeah. And a few years ago there were a few weeks leaks of TI Calypso source code and documentation and these allowed SMACOM researchers to reverse engineer the firmware of some old Motorola phones. And yeah so the primary hardware for SMACOM BB is mostly Motorola Calypso-based phones, mostly Motorola C1 something like that. And such phones run custom firmware which represents layer one of JSM stack and this firmware interacts with the whole software via serial link. And mostly the problem is that this firmware doesn't do much of things. It mostly drives a proprietary DSP. And what is the problem is that such hardware is not manufactured anymore mostly. And the DSP which is digital signering processor is not fully researched. So you still rely on the black box running open source software. And finally this is not full open source implementation. And the hardware limits you in some ways. For example you cannot operate in GPS mode despite the hardware is capable to do that. So what happened if we try to replace a Calypso-based phone with something else? For example what about software-defined radio? And what is software-defined radio? It is a general purpose radio hardware. It's not limited to any particular technology or software stack. And so this means that it could be used for different technologies and protocols like LTE, Bluetooth, GSM and of course GSM. So the good news here is that this is open source friendly. Many open source projects do support SDR and many SDR vendors do support open source actually. And of course software-defined radio is popular in scope of mobile communication. So you can run your own LTE network for example or run your own GSM network. You can even run LTE mobile site pro stack. But what about GSM? Can we run a mobile phone on GSM actually? And oops yeah this is actually when our work comes to play. So do remember this is general purpose hardware so there is no screen, there is no keyboard, there's no SIM reader or audio subsystem. But in general we are not going to create another open source user targeted phone. So then you ask me what is it for? And mostly this inherits some IMS from Osmocon BB project and as mentioned before it's mostly for education, research and development. And this allows you to implement absolutely open source layer when implementation. This allows you to get another hardware platform for Osmocon BB. And yeah this let's turn back time and imagine that we are developing software-defined radio platform for Osmocon BB from scratch. And from what did we start is here on the top of this picture you can see the Osmocon application which was previously used to connect the higher level applications and lower layer represented by firmware together. And the higher applications used to communicate via serial link. But in our case we don't have firmware anymore, we don't have phone and we need to communicate with software-defined radio somehow. So yeah after a quick look at the source code of Osmocon BB we found that it do use LiarOneControl protocol which is custom but pretty simple protocol. And good news is that this protocol is already implemented in software of higher levels and in firmware too. And the problem is that Osmocon BB host applications do understand layer two frames but not layer one bursts. So you need to implement some kind of burst encoding from yeah. And another problem is that host applications don't care about time division multiple access. And this is one of some basic technology in GSM. So we need to implement some kind of TDMA scheduler here. And OsmobTS became our source of inspiration because both things already implemented here. So we separated the common part of OsmobTS which is actually Osmocon base station project. And we created a separate shared library called Libosmocoding. Clean up and cleaned up and documented some parts of code and extended with accelerated VTRB decoder. And also we took some basic GSM structures like multi-frame structure or clock synchronization routines from OsmobTS as is. And finally now we have TurexCon application and now we can communicate with higher level applications but still we cannot communicate with software defined radio. We can receive birds transcode and perform encoding and decoding for them but we cannot directly communicate with software defined radio. And there is Turex protocol which was first introduced in open BTS project and it's still used by OsmobTS to communicate with transceiver and basically it assumes three UDP sockets one for resource management and other for frame clock indications and other for actually for birds. And so okay we implemented these two in TurexCon applications and now both Osmocon BB and OsmobTS projects do support Turex interface so maybe connect them together for early development and testing without actual hardware and yes of course we can do that and so welcome fake Turex toolkit. This is a set of tools written in Python and mostly used for debugging Turex interface and the most interesting application here is fake Turex. It works, it allows you to connect TurexCon directly to OsmobTS application. It acts like a proxy on the level one so you don't need any hardware to interact with your open source network from open source stack mobile site stack. And what is the purpose of these tools? For example you can learn whole JSM stack without hardware. You can perform simulation and stress testing without hardware and of course you can test and debug other projects. And yeah so we need the last part which should directly communicate with transceiver and what these applications should do is to perform downlink burst detection and demodulation. It should be able to perform uplink burst modulation and yeah it should follow TDMA time system of JSM. And of course finally it should talk via Turex interface which is currently supported by TurexCon application. So yeah there are two programs which may fit our requirements and one of them is Osmo Turex and it's still used in OsmoCon project. Basically it's designed to act as a BTS and it could be used but the source code is heavy mix of C and C++ and you need to understand the whole infrastructure to make some little modifications here and probably we will take care about Osmo Turex in the future. So also there is GRJSM and this is a new radio out of three model to play with JSM so it's modular, easy to modify everything you need so why not to try these two? And yeah this is why I contacted my friend Piotr to continue work on that direction together. So yeah yeah the part of my work was implementing the burst transceiver for the GSM and it is based as Vadim said on GRJSM which is relying on the radio. The whole GRJSM project was started from a part of April project that years ago in 2009 I added to April project it was called GSM receiver but it is now much more from just a software from for passive receiving burst. It also does the multiplexing, the correcting burst. It has no radio blocks for decoding different logical channels for filtering burst and there are also out-of-box applications demonstrating how to compose these blocks into working applications. There is application for live monitoring, the GSM broadcast channel decoding different logical channels and analyzing them in wireshark and also for searching BTSS active in the area. So what was the initial project status? It was that we had the whole receiver but what was missing was of course whole transceiver chain and what was to do was to implement GSM burst modulator then figure out how to synchronize the transmitted signal coming out from this modulator with signal received from the base station and then we actually had some constant time offset that needed to be corrected and in the end we had to verify if the signal transmitted the radio output is the right one so we don't interfere with anyone's license bands. So very short introduction of GSM signal at the U.M. interface, the radio interface of GSM. It uses time division multiple access with frames containing eight time slots each time slot carries one GSM burst it's kind of GSM packet and these packets are usually modulated with Gaussian minimum shift kink modulation and today position of each burst is precisely defined by the frame number and time slot number in which they should be transmitted. So the first task was to implement the modulator and it was actually quite simple because all of the building blocks were actually already in the GNU radio so I just had to figure out how to connect them together to make a working GSM modulator. There is already GMSK modulator in the GNU radio and then some with some blocks we're talking some blocks together you can perform differential encoding connect them together and hope that it will work and it should work actually and the other task was to synchronize the transmitted and received signal and this wasn't as easy but in the end the implementation isn't very large for this so we have following tasks we have burst coming from the upper layer they have frame number and time slot number and then we have to somehow transmit them in precisely defined moment in the whole TDMA structure. So for this very helpful is hardware clock that is in the inside of the software defined radio that we use this is usrp it allows for transmitting at precisely defined moment and the received signal is also tagged with the current time so you have time attached to a sample and then the receiver based on this metadata can track current time and if it receives a signal coming from from base station it can synchronize with this signal and associate reception time to frame and time slot number so this pair of information is then used for for performing conversion of frame numbers and time slot numbers into transmit time tags that are added to the burst that are for the for the transmitting and based on this information after the modulator the bursts are transmitted by usrp at precisely different moments so after this finishing this task we still had some unknown but constant delay caused mainly by signal processing algorithms like for example low pass filtering and also by sdr hardware so we needed to take it into account and how we did this is here so we have a signal coming from the base station to the usrp the output of receive chain we have burst these bursts we connect back to the transmit chain but we've adding some known delay of some known number of frames and then we retransmit this signal at some frequency close to the received signal frequency we then record both signals the received signal which contains both signals channelize channelize the received and delayed signal remove no number of frames of delay from the delayed signal and what is left is the unknown but constant delay between the both signals the received and transmitted by us and this we can measure with a use of cross correlation it should appear here yet we can measure it with use of cross correlation and it will give us the shift from the zero and this shift of the peak of the correlation from the zero position is actually our delay that we have to put into our take into account in producing the transmit attacks so then we had to verify the transmitted signal amplitude and normally programs like osmo bts or osmo tx are transmitting constant stream of samples but for mobilization it will be kind of lame to do that because we would have to transmit constant stream of samples when mobilization has to transmit something only from time to time so we actually used usrp's burst interface to transmit burst for each for each gsm burst and it has many advantages like you transmit when we need and it's easier to re-synchronize the the transmission in kinds of transmission problems but there are some drawbacks and here is the how it signal amplitude should look like for the gsm there are some guard periods when the signal amplitude goes down but then it's kind of constant but this is what we got and where the hell 300 microseconds of our bursts were gone so after some looking for the answer it's appeared that this problem appears only on usrp's b210 and it can be limited into this that only it appears only when we are transmitting and receiving on the same side of the device and it also appears only when there is no connection between active pin of the transmit port and the signal grant so if we avoid this we can have much better much better signal amplitude but then what is the thing in front of my burst so what is this after some looking it appeared that this is the end of the previous burst that appears at the beginning of the next burst and it is probably the result of growth delay of the usrp's fpga processing chain and yeah and it can be avoided by just adding zeros at the end so if i would know at the beginning i would just do that and not lose some time on this and in the end what had to be done was verifying transmitted signal spectrum with spectrum analyzer and when you are connecting antenna to the sdr device you should take into account always the fact that it might not produce the ideal signal and for example here for usrp b210 it there is a signal with amplitude of minus 13 db from from the main signal on the third harmonic so you should always put an analog close filter especially in case you are using wideband antenna so after applying the filter you get something like this so in at this moment my part was was working i think but to to check that we had to wait for the demo done by Vadim yeah thank you so when we finished more or less work in implementation of that transceiver we get something like that so finally we can now communicate with software-defined radio through the application called gRJ SMturex so we can not only communicate with our open source tech represented by osmo turex and osmo bts but also these different base stations so yeah let's try to show some demo but we have some limited time and i need to put it here yeah so first thing we need to run is actually our transceiver yeah it will start and then we need to run our turex cone which actually like a bridge between transceiver and osmocone bb applications and finally we need to run some osmocone bb application for example mobile application yeah and what's happening now that it started to it just synchronized to its base station of this local network and now we can try to register here for example yeah this is classical things we need to put our virtual SIM card because at the moment we don't have any direct SIM card interface so yeah let's try and what's happening now we just performing location update request in gsm network and let's see yes and we just got we just registered on that network and what we can do here is to perform some basic operations like we can request for our number it was it's simple so yeah the implementation is not so stable so feel free to contribute our project and yes this is our virtual extension so we can try to send sms message to ourselves it's shoot back and we should receive it back for for example this way so yeah we got a channel and oops let's try one more time okay yeah and we got it back thank you and finally let's try to call somewhere because we have some basic integration and I hope it shouldn't yeah let's try this to call some testing number actually finally so we need to switch back to our presentation and yeah the current project status is here and it's not so perfect as I would like to see so what we what have we achieved is now we have a full open source gsm layer one implementation and so you don't need to hunt for ellipse of fonts anymore you feel free to use software defined radio you can use any frequency you want for example you can run your network in wi-fi band and call in this network we are close to the future gprs implementation and for example we can do some things like try to integrate non-gsm audio codecs like speaks or opus here and of course this is the window of change for us macomb bb this is a new hardware platform for that project so yeah thanks for your attention and feel free to ask your questions so thank you very much Vadim and Piotr unfortunately we're out of time so we don't have time do a q&a hopefully you can stick around and people can maybe approach you if they have any questions so again a big round of applause to Vadim and Piotr for a great talk thank you very much