Towards an Open Source IEEE 802.11p Stack
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32644 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Electric generatorCartesian coordinate systemConstraint (mathematics)AnalogyMultiplication signSign (mathematics)Machine visionSoftwareMultimediaDifferent (Kate Ryan album)TheoryBasis <Mathematik>PhysicalismStreaming mediaoutputCommunications protocolProjective planeWaveOperating systemLink (knot theory)TelecommunicationMereologyStandard deviationSharewareRadiusLimit (category theory)CASE <Informatik>Software frameworkQuality of servicePlastikkarteReal numberProcess (computing)Computer hardwareFrame problemOrder of magnitudeMessage passingCharge carrierTheory of relativityField (computer science)Computing platformSampling (statistics)Data transmissionPortable communications deviceMechanism designMathematicsNormal (geometry)Point (geometry)Identity managementGroup actionWireless LANBitDevice driverResultantBand matrixLaptopIntegrated development environmentPublic domainFrequencyFirmwareService (economics)Computer sciencePlanningComputer simulationSpectrum (functional analysis)Error messageRandomizationInformation privacyDebuggerSoftware testingEndliche ModelltheorieForm (programming)ImplementationPhysical systemSoftware-defined radioLine (geometry)Exclusive orGraph (mathematics)Fuzzy logicDataflowPerspective (visual)State of matterMehrfachzugriffTraffic reportingModule (mathematics)Computer programInsertion lossBefehlsprozessorBlock (periodic table)Signal processingInterface (computing)Address spaceNoise (electronics)Information securityString (computer science)Open sourceInformationLevel (video gaming)Latent heatProcedural programmingCommunications systemPower (physics)Bounded variationComputer architectureIdentifiabilityHeegaard splittingPattern languageCollisionVideo gameBuildingRoutingInstance (computer science)GodCrash (computing)Wage labourSingle-precision floating-point formatComputer fileUniverse (mathematics)Kernel (computing)HypermediaRight angleCodecNetwork socketBit rateExtension (kinesiology)Particle systemMetreFreewareView (database)WordMeasurementData managementFinite-state machineNeuroinformatik3 (number)Physical quantityStack (abstract data type)CodeOffice suiteTime domainSymbol tableBuffer overflowTrailGreatest elementPrototypeSummierbarkeitINTEGRALCharacteristic polynomialSoftware developerExecution unitSocial classSpacetimeLetterpress printingFingerprintFigurate numberStudent's t-testSubsetDependent and independent variablesMaxima and minimaDistribution (mathematics)Computer animation
Transcript: English(auto-generated)
00:00
We've got the 11P stack, and this 11P is a very slight adoption to a normal Wi-Fi to operate in vehicular environments. So when the Wi-Fi card is not equipped to your laptop or smartphone, but when it's equipped to your car. This whole stuff is a bit embedded in a broader project, which I call Wime,
00:25
which is for building some communication devices to experiment with wireless networks in general, so for example also with sensor networks and stuff. And as a PhD student, I had to invent the problem, so this is basically my project now where I'm working on. But today I want to talk to you about a subset, which is this 11P transceiver,
00:44
which I want to tell you what I already can. And finally, I want to talk about some applications. So what can you do with this thing? And maybe you'll find some more applications. But to start, I want to make one step back.
01:02
I don't work in software-defined radio for too long, but in the last years there were some really fast developments. So now there are very cool hardware platforms out there. We've just seen the B210 from Airtools, and also the M210. There's a hot-pack RF and blade RF, so that means there's now really affordable, cheap hardware.
01:23
Which is really powerful also with MIMO and stuff like that. And then on the other side, we have this software part, which I labeled GNU Radio because I use GNU Radio for all my stuff. And there today we already heard, for example, about Folk, which is using SIMT instructions and really speeds up the whole computation process by these vectorized instructions.
01:43
And then another thing, Martin just showed us these asynchronous messages where you can really switch back and forth between stream-based and packet-based processes. So that means that you can easily implement a real communication system as opposed to just hacking in some physical layer.
02:02
And of course we have this OFDM reference design that Martin implemented, which is not just some blocks, but also extended the whole framework from GNU Radio. You heard about these text stream blocks, for example. And if we add this together, also all this, then we now have the tools at hand to implement some state-of-the-art communication standards.
02:21
And I picked some where I know that there are some active projects for GNU Radio, which are DVBT, which is really active today, then LTE, and I am working on this Wi-Fi part. So since you have the ability to implement some state-of-the-art communication standards, and since you can really build a whole communication system,
02:41
I think that software-defined radios are also now interesting, not only for these physical layer guys that are typically interested in signal processing and receiver design, but also as a computer scientist or some guy who is working on the upper layers who might be interested in implementing some protocol on top of these standards,
03:00
or who might look for input data for simulations, or who is concerned about security and privacy issues of these networks. So I think that with all these improvements, that you can somehow connect these both domains with software-defined radios quite well. And today I want to show how I think you could do it for the example of vehicular networks that I talked to in the beginning.
03:25
Okay, but first, just to give you a very quick idea about what vehicular networks are about, so there's this vision that cars are equipped with some radio module, and let's say that if the guy in the front car just realizes that there is a traffic jam ahead,
03:41
then he has the possibility to communicate this to all the other cars around him, and the guys on the other lane could, for example, pick up this information and bring it to someone in the very back. So that means that you could make driving more safe, because he's already alarmed that there is a jam and that you could maybe avoid rear-end crashes,
04:02
or on the other hand you could make it more efficient by proposing an alternate route, if you have the possibility to pick one, because he has not. And maybe you also want to include, let's say, road signs into this whole thing. And yeah, a lot of people came up with ideas what you could use these networks for,
04:20
so they started to work on that and came up with a standard in 2011. And also they reserved some spectrum for exclusive use for ITS applications, so Intelligent Traffic Systems. So this spectrum is in the 5.9 GHz band, so people are actually interested in that because it's really, spectrum is scarce, you know,
04:45
so to have some dedicated part of that is really valuable. And what they did is the following. They took Wi-Fi, normal Wi-Fi 11A or G, which most of your laptops are currently operating, and just made some very slight adoptions.
05:02
So what they did is they doubled all the timings. That means that your frame is stretched in time domain, but gets more narrow in frequency domain. So as opposed to 20 MHz bandwidth where your normal Wi-Fi card will operate, it has a 10 MHz bandwidth. From an economics point of view, this is pretty cool,
05:22
because you can just reuse your old Wi-Fi chip and divide the clock by two, so that everything rises slow in that case. And also from a software-defined radio point of view, that's also pretty cool, because this change in timing just means you change the sample rate. And yeah, but there are some obvious problems arise with this,
05:44
because Wi-Fi was actually intended to operate in indoor environments, like here for example. And now if you put Wi-Fi cards in your car when driving around on the freeway, with in Germany maybe 400 km per hour relative speed or something like that, then you don't really know what happens.
06:03
And actually we tried to find that out, and we bought some utterly expensive hardware prototypes, and then we also took some normal Wi-Fi cards and changed a bit around in the kernel, and some card support to change the clock rate, so we could come up with some experimental devices, so these two.
06:21
I have also one of those with me today. And yeah, we were driving on the freeway, and we're interested what happens when there's a truck in between these two cars, in the case for example, and stuff like that. But all these kinds of prototypes, they have the limitation that, I mean, you just get very basic data out of them,
06:41
so you can send a frame, and the receiver either picks it up or not, but if it did not work, you don't know what happens, so if you're back in the lab and try to make some sense out of the data, you might easily run into problems. So our idea was to use soft and defined radius for that, and now maybe the interesting part is I started to work on one
07:02
and implement this 11P transceiver, and currently it looks like that, so I tried to build it and design it very layered, because computer scientists are pretty used to this layered communication stack, you may even know the ESO OC stack,
07:20
and I mean, you have the hardware at the very bottom, the physical layer, then some Mac stuff, which is, for example, adding the Mac address and all that, and then you have an interface where you can connect to such an activity, insert data into the flow graph. We already talked about hierarchical blocks today, and I also make use of them, so the whole OFDM stuff is hidden, for example, in the physical layer block,
07:44
so there's an OFDM transceiver in there, and I developed this when Martin was working on his OFDM implementation, and now I obviously also want to kind of integrate this, and I already did it for the transmit side, so the transmit side is now completely using Martin's design,
08:04
but the receive side not yet, and I also have it here, and we can have a look at this if you are interested. So, since you already are familiar with Martin's, it's obviously always an advantage for me if it has the very same design, so then if you open the flow graph,
08:22
then you might easily see what's going on, if you are already familiar with the new radio reference design. And I created some modules to connect to that to make live a bit easier, and this is, for example, a Wireshark module, so where you can attach Wireshark and you see live what's going on,
08:41
you get the frames and you can even annotate it with bandwidth channel and stuff like that if you want, and it runs also completely in software, so it doesn't make use of the FPGA. So, at the very top you have this application, so where you can feed something into the flow graph to actually transmit it, for example, and I have an example for that, how easy that is.
09:04
So, with only six lines of Python code, you can inject a packet, for example, and send some packets out there that you can receive with your Wi-Fi card. So, in that example, I used Wave Short Message Protocol, which is a protocol standardized by IEEE,
09:22
and maybe this way, traffic information or also safety messages might be distributed in vehicular networks, and you can generate those frames and maybe distribute your own traffic information, I don't know, whatever, really, really easily, with just writing to the socket, it can already pick that up and send out the frame.
09:42
And, yeah, we tried this with quite some hardware, so with all the hardware prototypes we had for 11p and also we tried it with some Wi-Fi cards to ensure that this works. Okay, but then I also want to talk about the limitations of that, because people ask very often,
10:03
and, I mean, we have the advantage of doing everything on the CPU, so it's really easy to hack, and you can play around with that pretty easy, but the disadvantage is that you add some delay, and, as I said, you can connect this thing to the Linux TCP IP stack, for example,
10:21
and then the easiest thing to do is you can just ping the other device, so you connect, you just use the ping command and send some frame back and forth between the user p and there's some normal Wi-Fi card, and here we added 100 milliseconds delay artificially, but actually, I know it's not a very exact way to measure delay,
10:44
but the point I want to make here is about the orders of magnitude. So, with this system, we are in the low millisecond scale about the delay, so around that, but if you want to meet the timings of normal Wi-Fi signals, then you have to get to the microsecond scale,
11:02
so that means with this approach, you will not be able to support request to send and clear to send. This is a mechanism where you reserve the channel prior to the actual transmission or you will not be able to send an acknowledgment in time because there you would have to have the short inter-frame space,
11:22
which is around 32 microseconds in that case, and then there's also a duration field that specifies a certain amount of time that you should visually block the channel even though the actual frame is physically already gone. So, this is something that I think will, at least with this architecture,
11:44
not work and there will not be standards compliant. But another thing that is currently still missing and that I think we can get working is carrier sensing and channel access. And there I talked with Andre in Miami last year
12:02
and he already mentioned it today that they have an FPGA implementation for channel sensing. And he shared that with me and we were working on that. And what we are currently doing is you can pre-load your Wi-Fi frame on the FPGA of the USRP
12:20
and then the USRP is doing channel sensing for you, it has an easy state machine, you can annotate for example slot times and all of that and then you really can come down to the microsecond scale. In that example I plotted here, it's just the power levels and then we had one USRP that was generating noise
12:41
then we switched it off and another USRP which was sensing the channel then added some very small gap that you would not be able to manage on the CPU and then sent out the actual OFDM frame and we also received this frame with another Wi-Fi card. So that works basically but I still have some issues
13:01
mainly because I'm really bad in FPGA programming and I'm currently trying to get used to it so it's not working 100% now so having really standard compliant channel access but I think we're on a good way and I hope we will manage that. Okay, so the last part I want to talk about some applications
13:21
and some applications from a perspective of a computer science guy because obviously since we now have an SDR implementation you have all the advantages like everything about your signal and when it got wrong and what happened and stuff like that but there are also some cool things I guess you can do on the Apple IS and one of those is for example fuzzing
13:45
and this is a form of penetration testing that means you send as some kind of random cluttered simple frame or whatever and then you see what happens to the device driver actually I did not plan to do that but when I was working on the transmitter
14:01
then at some point I realized that it was constantly breaking the driver of my Wi-Fi card and I had to reboot all the time and I was pretty annoyed about that and did not make a git commit because it was obviously not working and then some month ago I thought this was actually very cool to have this as a result
14:21
but now I'm trying to reproduce it but it turns out not to be that easy yeah, but I think this is something you could do with a driver usually a sign is a problem and then another thing also some other guys in my group are working on is privacy and fingerprinting techniques
14:42
so that means that you're basically want to identify a sender want to maybe track him or disclose his identity or stuff like that and there are approaches from this physical layer guys they often look at channel features or some characteristics of maybe the analog front end of your device
15:00
you know, there are some variations and stuff like that and the computer science guys are more on the higher layers and look at traffic patterns and when did you communicate with what target what was the packet size or maybe look at MAC addresses and identifiers and I think with an STR you can get somewhere in between and try out something new because maybe you can learn about
15:23
some timings of the chip or the firmware or maybe also the driver because not everything let's think of the CSMA procedure is defined really, really exact in the standard so there are always some something that are implementation specific and maybe you could use this
15:43
at least as additional information to learn something new or to easily identify a source more robust let's say like that and the last thing that we are currently working on and where I think software defined radios would be cool is to enable more realistic simulations
16:02
which have absolutely nothing to do with software defined radios but we in our group we also have a network simulator which is able to simulate large scale vehicular networks and then you need some input for the simulator like let's say some packet error curves for example and on the other side
16:22
there are some physical layer guys that were driving around with some channel sounders and have real precise measurements and learn how the channel behaves and looks so you have some maybe tap delay line models or they have some coherence time, bandwidth, whatever but you cannot plug this results directly into your simulator
16:43
you need to step in between and I think maybe with new radio and software defined radio you can do that let's say new radio has also incorporated some channel models you could parametrize these channel models with some data that you already know that you learn from the guys who were driving around with a channel sounder you maybe can plug this data in
17:02
and then do some simulations in new radio and come up with some more realistic error curves that you can then use in your simulator so maybe these are some applications that are more high layer okay so that's it from my side and I quickly want to wrap this up so we have this OFDM Transceiver implemented and I hope that it's easy to use
17:22
and it's modular and extensible and I showed you some possible applications about that maybe you can come up with something more okay finally I have some other projects I'm currently working on this is RDS which is decoding radio data service
17:40
and also some syncify I also contributed there and for these three projects I also have some demo stuff with me so if you are interested you can just talk to me or we can have a look at that if you want okay so thanks for your attention
18:07
probably you are aware of the Wave DSRC project yeah it's good that they finally standardized the physical layer but is there some standard coming out of the link layer as well
18:22
so there's this Etsy, ITSG5 and then there is this DSRC Wave and they both use 11p as the physical and Mac layer on top of that and both give recommendations on how to use this physical and Mac layer so it's no definite answer to that
18:40
I mean for example they're not using TCP at all exactly yeah so I mean you can also run TCP in theory on top of that but for these traffic applications you have a different stack for that and there you have quality of service for different traffic for let's say safety or more multimedia streams and stuff like that
19:00
so they build up on 11p as the basis yes do you think that the next generation you could meet the WiFi specs with pure software in it no not with this approach because I think yeah if you really want to meet all these timing constraints
19:22
you have to move everything a lot of stuff to the FPGA and then that basically means changing the whole architecture even the operating system no even if you're using the PCI Express you can't meet the timing requirements there's a paper called the split Mac by George Nytjes that explains why and how he solved the problem
19:41
it's a hack where he actually the FPGA sends out a pre-calculated hack and then it processes the real packet based on the SNR it's a clever little hack but he basically shows you how you can't even do it with PCI Express there's not exactly a question