We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Wireless Networks In-the-Loop

00:00

Formale Metadaten

Titel
Wireless Networks In-the-Loop
Untertitel
gr-winelo - A GNU Radio Network Emulator
Serientitel
Anzahl der Teile
199
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
This talk introduces gr-winelo, an in-the-loop simulation framework for communication networks which are based on the GNU Radio software radio toolkit. gr-winelo mimics the behavior of common RF frontends such as the USRP, but instead of sending the signal over the air, a central server plays the role of the wireless communication channel. Arbitrary channel models can be simulated, by passing their respective GNU Radio processing block to the server. Since this whole setup is completely transparent to GNU Radio applications, it is at any moment possible to switch between simulations and real-world tests. For the Demo a frequency hopping network will be simulated and analyzed using gr-winelo.
65
Vorschaubild
1:05:10
77
Vorschaubild
22:24
78
Vorschaubild
26:32
90
115
Vorschaubild
41:20
139
Vorschaubild
25:17
147
150
Vorschaubild
26:18
154
158
161
Vorschaubild
51:47
164
Vorschaubild
17:38
168
Vorschaubild
24:34
176
194
Vorschaubild
32:39
195
Vorschaubild
34:28
PolarkoordinatenSoftwaretestEinfache GenauigkeitSoftwareentwicklerNotebook-ComputerSoftwareComputersimulationDrahtloses lokales NetzHardwareMultiplikationsoperatorTeilbarkeitImplementierungTaskp-BlockGrenzschichtablösungAbsoluter RaumServerPublic-domain-SoftwareVerschlingungReelle ZahlSimulationEinflussgrößeKonfiguration <Informatik>SkalierbarkeitIterationCodeKartesische KoordinatenSoftware RadioNummernsystemt-TestDifferenteStatistische HypotheseEinsProjektive EbeneRauschenStichprobenumfangSoftware Development KitPunktGraphiktablettProgrammierumgebungOrdnung <Mathematik>InternetworkingWeb logDebuggingDatenstrukturSenderVollständiger VerbandUltraviolett-PhotoelektronenspektroskopieGamecontrollerSpezielle unitäre GruppeStandardabweichungRechenwerkKomplex <Algebra>RelativitätstheorieBildschirmmaskeElement <Gruppentheorie>GefrierenSystemaufrufCASE <Informatik>ComputerspielSigniertes MaßGruppenoperationEchtzeitsystemVorlesung/Konferenz
SimulationRauschenMultiplikationsoperatorFehlermeldungGraphiktablettEin-AusgabeKartesische KoordinatenMixed RealityComputersimulationDifferenteCharakteristisches PolynomStichprobenumfangTaskService providerStreaming <Kommunikationstechnik>InformationZahlenbereichBenchmarkMereologieDigitalisierungQuaderCodeOpen SourceEinflussgrößep-BlockParametersystemStatistische HypothesePhysikalisches SystemStandardabweichungBenutzeroberflächeGüte der AnpassungKonfiguration <Informatik>MomentenproblemFrequenzZeitstempelFunktion <Mathematik>SharewareHardwareMathematikOvalInzidenzalgebraFunktionalWeb logGewicht <Ausgleichsrechnung>Versionsverwaltungt-TestMaßerweiterungInformationsverarbeitungRechenwerkInstantiierungSpezielle unitäre GruppeSoftwaretestAutomatische IndexierungSchreib-Lese-KopfEreignishorizontRelativitätstheorieComputerspielGradientRechenschieberSchlussregelSystem FSymboltabelleResultanteSchreiben <Datenverarbeitung>Vorlesung/Konferenz
p-BlockFrequenzKartesische KoordinatenAdressraumRechenwerkBilineare TransformationVererbungshierarchie
ServerKartesische KoordinatenGraphische BenutzeroberflächeEinfach zusammenhängender RaumSimulationZellularer AutomatDatenflussGraphGraphiktablettLokales MinimumProgramm/QuellcodeFlussdiagramm
Kartesische KoordinatenRelativitätstheorieVorlesung/Konferenz
FrequenzHook <Programmierung>TransmissionskoeffizientKorrelationsfunktionInformationstechnikGraphFolge <Mathematik>Kartesische KoordinatenComputersimulationMultiplikationsoperatorDruckverlaufAntwortfunktionZahlenbereichBitrateThumbnailEinflussgrößeBenutzeroberflächeMAPAnalytische FortsetzungMessage-PassingGefangenendilemmaEinfach zusammenhängender RaumDoppler-EffektBruchrechnungProgrammierumgebungStichprobenumfangDifferenteSenderp-BlockSchlussregelFramework <Informatik>Prozess <Informatik>Drahtloses lokales NetzTelekommunikationWurzel <Mathematik>InformatikPhysikalisches SystemBitSummierbarkeitBildgebendes VerfahrenBereichsschätzungQuick-SortPropagatorVektorraumHydrostatischer AntriebDifferenzkernVirtuelle MaschineMereologieGeradeBildschirmmaskeMathematikSchwingungProjektive EbeneSymboltabelleFreier LadungsträgerDatenflussURLArithmetische FolgeRandverteilungLesen <Datenverarbeitung>PhasenumwandlungRechenwerkWort <Informatik>PunktGruppenoperationKlasse <Mathematik>Ordnung <Mathematik>Gebäude <Mathematik>CASE <Informatik>SystemaufrufOrtsoperatorRankingLogischer SchlussDatenstrukturRelativitätstheorieFunktionalEnergiedichteVerschiebungsoperatorGeschwindigkeitAuszeichnungsspracheKomponente <Software>ResultanteEreignishorizontKategorie <Mathematik>Zellularer AutomatRadiusObjekt <Kategorie>SpeicherabzugStreuungWasserdampftafelGraphische BenutzeroberflächeServerHardwareLokales MinimumRauschenSynchronisierungStellenringCodeDoppelspaltErwartungswertSpiegelung <Mathematik>SoftwarePuls <Technik>SimulationSharewareTropfenAutokorrelationsfunktionVorzeichen <Mathematik>SoftwareentwicklerWald <Graphentheorie>TaskGeometrische QuantisierungZweiKeller <Informatik>Leistung <Physik>Profil <Aerodynamik>MittelwertNotebook-ComputerVorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
I'm a PhD student at KIT and we will present you wireless networks in the loop. So that's basically the idea comes from Martin. So from a time when he was my advisor at the lab and so we should implement it.
I'm Gerald, I was also a student and Martin was my advisor when I did my master thesis. So that's why I also worked on this project. So first about the idea about wireless networks in the loop. So SDS simplifies radio development.
Well, I think you all know it's not true for everything so there come new problems with it and so on. But the great thing about this is that we can apply our workflow which we know from software development for the workflow of radio development.
So there are debugging tools, automated tests and test room development. And the idea or the question to answer is why just use them for a single block or a single node. We could use them for the entire network.
So to simulate the entire network with all nodes and the channel in between them. This would be great if we could allow a similar switching so that we can work with the same code base for our real application which we run on the user piece or other SDR hardware as well as for our simulation.
So that we could improve in every single iteration where we can switch from testing or real world measurements to simulation. So the main idea is to stay in the software domain as long as possible and to go back into the software domain as soon as possible if we have to do real world measurements.
The benefits of this approach are for sure flexibility and scalability. If you want to test really big networks like 20 or 30 nodes and you want to get a feeling about how the network will behave in this case, for most labs or for most people it will not be possible in the real world with real hardware.
The other benefit is that we have only one code base. So you don't need a MATLAB simulation code or you don't need to run NS3 simulations right before you could.
It's depending on how complex your network will be but you don't need to. So a great benefit, I think the greatest benefit of it is the easy debugging. So the possibility to set breakpoints on the air link is really nice if you develop complex networks and also the controllable realism.
So you can turn on and off impairments. So everyone knows that it's easy to run a simulation on the PC without something hardware or real world impairments or something like that. And here you have the option to turn on the hardware impairments but not so the channel impairments.
And this all leads to a reduced development time and an increased failure factor. So I come to the basic principles and implementation. So we've chosen a client-server structure so that you could run
a really computationally expensive task like the channel simulation on a powerful server. And you also could run several PCs as single nodes and connect them to the server as you would do with a hardware setup. So you have five laptops each with a USP equipped and the real channel is then simulated by our server and the samples go there over TCP IP.
So here are some points that we had to implement. So first of all is zero padding which I came through in a minute. And then all over the timing is a really problem when you want to simulate a channel.
So the easiest question is what do you do if the node stops sending, if your application stops sending? What would you do in a simulation? Because if one node stops transmitting, all of the other nodes still get noise in a real environment.
So you have to simulate it. And the big problem about this is that you have to get the exactly correct amount of samples which are noise samples. So we had to implement something like time commands or support for time commands which you would use
in a USP to enable it to transmit at several times or if you have a hopping scheme. We also have support for an absolute time. So it's the model of the GPSU or the support for GPS time.
Then clearly there are the hardware and the channel models. So we have different channel models and all of them are modular designed. So you can easily add new ones. And last but not least there is the simulation interface. Because to allow seamless switching you don't want to write different code for the simulation.
Because you want to use the same code as we would run in our real simulation to allow the switching between the measurement and the simulation. So let's come to the zero padding in detail. When you run slotted, if you run slotted applications with the USP, one possibility
is to use the start of burst, time stamp and end of burst feature. It's called stream text in uradio. Or it uses stream text from uradio. And the idea is that you could count the number of zeros you have to insert here. Because you know the start of burst and the time stamp, then you know how much samples go through your simulation.
Then you have an end of burst and with the next time stamp you can calculate this difference. And you know this amount of samples and then you can add this one. The problem is that you know this one, not at this moment.
So you don't know how much samples you have to add here. So we implemented a method that starts producing noise or zeros or anything and distributes them to all the receivers.
And until it gets the time stamp. Then it calculates how much it had produced already and how much it has to in the future. And if it produced too much it gives you a warning and an error and says stop here is the simulation error. So then you have to run the simulation a bit slower. So we have implemented three versions.
It's a simply accurate zero padding which I explained right now. And generic inaccurate zero padding. What this does is it simply waits and if there is nothing on the input of the work function it produces noise.
And there is also the initial zero padding. Which is important if you have transceiver systems which host output depends on the input. So there is a chicken egg problem at the beginning. When there is no input the transceiver produces no output at the end. So therefore we implemented an initial zero padding which produces noise at the start if the work function doesn't get an input.
So we followed overall a modular design to allow you to easily add general models, hardware models or change everything in between them.
And also the simulation interface could be changed. Right now we are using TCP UDP things in Clonradio because they are well known and they are working good. But you really easily could exchange them. So in the past we used twisted for the exchange of samples.
But that didn't perform well so we just use it for signaling now. And as you can see here the switching is really seamless. So the blocks have the same options because I copy pasted it from the UHD blocks. And add some of the simulation parameters to it.
So there is support for existing applications. So in my master thesis I wanted to show the performance of the overall system with some PER and BER curves. And therefore I used the standard TX benchmark RX which are part of the TR digital package.
And it worked out of the box. So I simply changed, I took out the UHD block and added the WinLOW source block and it worked out of the box. So another important task is to provide status information like the UHD does. So at which frequency are we now, at which sample rate are we.
And also give support for the application to change the frequency and such things. Therefore I have created a frequency hopping et-hoc application. Which has great possibilities for failures when you want to simulate it.
Because you have to model the mixing between the frequencies. And the overall et-hoc is really depends on, doesn't behave very well if you fail.
Or if you have failures in your overall or in your simulation or your channel model. So as you can see here the differences right now are you don't see the DC offset which would be very easily to implement. Or the RX filter characteristic which is implemented already.
And yes the data packet anti-interferrer at 340 MHz. It's also an opportunity to push interferrers into the whole simulation. So to test your network if in the presence of an interferrer or perhaps in the presence of secondary user, primary user when you think about cognitive radios.
So I want to show you a demo now. So what you can see here is the frequency hopping et-hoc application. So at the left there is one node which has addressed itself dynamically and also the second node.
So they have two addresses. This one has address 1 and this one address 2. And when I'm able to transmit packages from 1 to 2 like this or from 2 to 1 like this. And this is a real application which also runs on a USRP so I've tested it.
And what I've done here is I've taken out the UHD block and inserted the Winelo block. And we can have a look at it. So that's another feature we can easily connect new applications to the simulation server.
So now I connect a simple Qt GUI sync. So the server is running here on the left. You can see that it makes some new connections. And then we could maximize this. So now the overall flow graph stops and then it runs. Because we needed the initial zero padding here for the overall application and simulation to start.
So here you can see a beaten package. And so I could transmit some packages that you can see.
But it's really this application running here. So here are the packages. And that's one possible workflow. So it helped me a lot when I developed this frequency hopping at hook node. Because there are so many possibilities to make failures.
And it's easy to debug with a framework like this. So now Garret will continue. I'm going to talk a little bit about channel models here. So far we've talked about the whole setup, how the system is working with the server.
The sample server and the nodes that connect to the server and exchange IQ samples. But we've completely disregarded so far the channel models. And I think because most of you are computer science guys. So maybe I'll give just a rough and quick introduction. And what the problem is for an engineer who does wireless communication when he's trying to transmit data all year.
So the problem is that our wireless channel, which we are using to transmit data, behaves very differently. And it depends on various factors. Of course it depends on the frequency band. So whether you are transmitting at 100 MHz or at 2.4 GHz, it makes a lot of difference.
Or for example if you are outdoors or indoors, that's also a huge difference. How long does it take for your signal to get from the transmitter to the receiver? That's just one example.
It also depends on your movement speed. So if you are talking on your cell phone, if you are moving around on foot, or if you are driving in a car, you also have to take that into account. Other thing, it also depends for example on the data rate. If the symbols that you are transmitting are very short and therefore you can't transmit a lot of data. Or if they are long, it also makes a difference.
I explain it in more details later. And it also depends of course on the position of objects. Well, if you are surrounded by tall buildings or if you are just in a free space somewhere out in the forest or something. Okay, so here is a very simple scenario.
We've got our base station, we've got our cell phone, and then we've got of course a line of sight path. Correctly, but we also have multiple paths which are re-scattered by for example forest buildings or whatever. And all of those paths, they have different delays because they are differently long.
And then all of them also have a different phase. So they can either add up constructively or you can have interference depending on the phase. Which changes your signal level that you actually receive. Moving the receiver, it also, if you walk around for example with your cell, then you change, you also suffer from interference.
I don't know, probably all of you were in high school and you know the double slit experiment. So there you have this maxima and minima on your wall. And well, that's the same thing that you suffer with. You just suffer from if you have a cell phone. And moving also affects the perceived carrier frequency at your receiver.
You also suffer from a double slit. You also have to correct that. So that's just some of the tasks that you have to deal with. And now then, instead of a flat line for your received power, for example you get something like this with these drops in between and it's just called fading.
And well, it depends of course if you move around. And well, in the talk of Tom earlier you saw that, well he had this nice little example where he had the signal, the sign signal. And then he also added interference.
And if the interference gets too big, then you can't hear anything. It's probably much the same just the other way around. And your useful signal, the level drops and then you don't receive anything. You do not receive anything, just rubbish. And well, of course fading depends on the movement speed.
So how fast does it change, for example? Also of the precision from all the transmitters or the receivers. So if you're out on the street and then a large truck moves in front of you, then of course you're more or less covered. Maybe on your signal level drops. And then of course if you make a general model, you have to take your environment in which you are communicating has to take that into effect.
So one thing about channels that is described by the channel impulse response. Well that's just one way to describe them. And it's very simple. Imagine we have a transmitter and we are transmitting a short pulse. And then the receiver, depending on how many paths we have, you'll get probably maybe something like this one.
So this is our first path that we receive and then a little bit later, a little bit to the other path. Okay. So, and this is what we actually call the channel impulse response and that you can, you have to keep that in mind if you want to design your system.
Okay. So just as an example why the channel impulse response is so important. Well in both cases we have the same channel impulse response with these short pulses over here. And now imagine we are transmitting with a very low rate channel, with a low data rate.
So this example would be our transmitted signal, our symbol. So let's say just one bit. And of course we receive it on all paths. But we can see they all add up. Because they are very short. They are very long in time. Now we are transmitting with a load and with a higher data rate.
So our pulses are of course shorter, our symbols are shorter. And the first symbol is the red one, the green one, the blue one and the magenta one. We can see we are now transmitting the magenta one. We also get interference from the other paths but with other symbols.
Here we just received the blue one, there we get the red one. So in this phenomenon is called inter-symbol interference. And that's the reason why we actually need equalizers in our system which is what Martin already mentioned. So as you can see, well this is the same channel.
But just because we are using a different system, we also have to adapt the channel model. And I have to adapt our system. So this is why channel models are so important. And now what we wanted to do is, we wanted to not just create channel models, which you can do analytically and make some reflections about the environment that you are expecting.
But you can also sound the channel. Which means measuring the channel impulse response which describes the channel. This is called channel sounding. And this is where you transmit the short pass and then you detect all the echoes that you are receiving and then you pretty much get the channel impulse.
Problem is you are just transmitting very shortly, most of the time nothing. So that's not very efficient because your signal to noise ratio is very low. It's smarter to transmit all the time. So the idea is the correlation channel sounder and it transmits a sequence repeatedly
and then these sequences have now very nice properties. So if you use the autocorrelation function on them, then they have got this large peak when they are perfectly aligned. But if they are shifted a little bit, then they are close to zero. So and this is when we now transmit our sequence at the receiver at the transmitter,
then we can use this correlation to detect the different peaks on the trans... Ah crap. And then we can detect the different peaks at the receiver. Okay. So and then I can just show a couple of pictures.
So what we did, we made some measurements over here. So we placed the transmitter and thanks to the buildings we'll get multiple... Yeah, we'll get this multi-path environment so we'll get different... We can actually detect different paths. And just maybe this is of interest to you, this was our setup.
So we had the transmitter, we had the receiver and we just hooked them up to two laptops which actually ran the processing radio. We also had GPS disciplined oscillators which you need to measure the Doppler shifts of the multi-path components.
You have to speed up a little. So this is for example the results that you get. So if you're moving around, this is actually your received power. And as you can see, it fluctuates quite a lot. And here we've got the power delay profile which is kind of the time average of the channel impulse response.
And as you can see, here we've got the line of sight peaks at the beginning and then those are the paths that we received from the buildings. And then over there we got nothing that's just nice over here. Okay, and then from these measurements then we can also make a channel model.
I think I skipped the demo due to the time. But now the question is, well, what kind of models can we use in radio? So you can make some very simple analytical models like the WAGN sub-channels
where it's just a noise or radio fading channel. We also implemented cost 207 channel models which were used for designing GSM. But the design of wireless networks in the loop, you can, on the server, it's basically running a new radio flow graph which simulates the channel.
And so you can plug in pretty much any new radio block as a channel model. And as of 3.7, there's a project called GR Channels from Timo Shih. And he implemented a couple of channel models which you can also use. So Timo's channels are now part of the radio? 3.7, yeah.
I think I mentioned it. You probably did, I misunderstood. Okay, and as a kind of experimental feature, you can also create channel models from channel sounder measurements. So if you don't want to think too hard about the environment and you don't have an analytical model, you can just use a channel model sounder measurement
and then take from that one, yeah, create a channel model. But this is still very basic. And I think I leave the last two minutes for, well, what Outlook or what we want to do in future. Well, there have been a lot of new features lately,
so we have to clear our code base. And we want to release it at some point in 2014 to the public, so then you can get it. And Niko is going to be working on powerline communications, so he also wants to add some new channel models for powerline communications. And he's also working on this graphical user interface
for managing the whole application. So, yeah, this is what we are currently working on. And now we've got time for questions. Or if there are none, we can, okay, no, yes. Are there models useful for HF? HF, of these models, honestly, I don't know.
I've never worked with HF. I think that's 30 megahertz or something. That's ionospheric, it's all different kind of application. No, because, well, you have to take into account
the ionosphere and troposphere. Those models are not designed this way. No, where? So AWGN just adds noise and really it's just basically when you've got completely surrounded by scatterers, which is not the case in HF.
So we tried to provide a framework or to build up a framework, so there are really simple models up to now. But as I heard before, so Bastian had the same or similar idea, so I think we have to push it as soon as possible to work together on the whole thing and not to have five different radio simulation tools
or channel sounding tools. You said that you use a GPSDO for synchronization of different paths. Do you auto-simulate the drift of the local clocks of receiver and sender? Basically the function of the GPSDO is that you don't have any,
well, frequency offset at the channel sound. You mean, but you are trying, if you are simulating the same aspect in our hardware model? No, I mean, if you simulate it, do you have also taken into account that the oscillators of the receiver drift apart
without running the same frequency that they start the stream? Yeah, yeah. It depends on the hardware model. You can pretty much plug in any hardware model, but since we are in the infancy of the project yet, we just add a little bit of noise. But there is a radio channel block that does the drifting, I'm pretty sure about that.
Yeah, you can add the drift. So the idea with the hardware is that they would re-sync, usually there's a pulse per second input, so you're constantly re-syncing to the GPS in the phone. I mean, just run by the oscillator, plus or minus reality, you're within pretty good stack. The two are going to be pretty much locked together based on that.
And then you have your other hardware, your channel models that you add your own frequency to. We now have where it's dynamic, or your timing offset, which can be dynamic now as well. And then we also have the hardware impairments model, which we used to simulate like IIP3, IIP2, phase noise, quantization noise,
as well as the hardware. Yeah, just an example. This is for example now. Actually, we plugged in the channel model, and now we're sounding the channel model. And this is how the channel impulse response is changing.
But it can happen from the Doppler frequency, but you can also say, well, it's happening. So we saw that the oscillators are drifting apart. That's the reason why in the channels on the reuse deals, GPS deals, we wanted to measure the Doppler shift, but you have to know, well, do you have to shift based on the Doppler, or because the oscillators are drifting apart.
Okay, so you use that as a reference oscillator, so you have the same frequency? Yeah. Okay. If you want to simulate bad hardware, that is possible. Can I simulate with hardware? Yeah, one more. Yeah.
Sorry. So you're asking about the cost of 127 channel models.
Okay, basically there are four propagation environments, I think. There's one for topical urban, then bad urban, hilly terrain, and rural areas. So you have those four channel models, and then depending on what kind of simulation you want to run, then you can plug in one of these. And you can select inside, I want the environment.
Yeah, yeah, exactly. Okay, then... Perhaps you can come together, so after the presentation, so to get some ideas from you, who are developers for software different videos, what one could need or what we could implement with this tool. Thanks. Thank you very much.