Building Link-Layer Protocols in a Lego-like Fashion
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| 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 | 10.5446/32495 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 2014116 / 199
2
3
10
11
12
13
14
17
18
19
23
24
25
27
29
45
46
47
48
49
50
51
52
55
56
57
58
65
67
68
70
72
74
75
76
77
78
79
81
82
84
86
87
89
90
93
94
100
101
102
103
104
106
107
109
110
111
112
113
114
115
119
122
123
124
126
127
128
129
137
139
141
143
145
147
150
154
155
158
161
163
164
165
166
168
171
174
175
176
179
182
183
185
188
190
191
192
194
195
196
00:00
VerschiebungsoperatorFramework <Informatik>Basis <Mathematik>Software RadioComputerarchitekturVisualisierungComputervirusNichtlinearer OperatorKonstruktor <Informatik>GamecontrollerSoftwareGebäude <Mathematik>BitIRIS-TXMLUMLVorlesung/Konferenz
01:07
Zellularer AutomatZusammenhängender GraphDifferenteSystemplattformLaufzeitfehlerIRIS-TProgrammbibliothekGrundraumLokales MinimumMaßerweiterungPhysikalisches SystemProjektive EbeneSpeicherabzugKonfigurationsraumParametersystemElektronische PublikationBitOpen SourceVorlesung/Konferenz
02:17
DatenverwaltungProjektive EbeneServerPhysikalisches SystemOpen SourceIRIS-TDynamisches SystemMathematikParametersystemPunktspektrumFokalpunktMultiplikationsoperatorFrequenzBandmatrixWellenformRegulärer GraphVorlesung/Konferenz
02:50
Bildgebendes VerfahrenInformationFrequenzSynchronisierungBildschirmmaskePhysikalisches SystemWellenformElektronische UnterschriftKorrelationsfunktionSchätzfunktionWeg <Topologie>TransmissionskoeffizientMultiplikationsoperatorFreier LadungsträgerMusterspracheBandmatrixBitPunktspektrumVorlesung/Konferenz
03:54
Dynamisches SystemSpieltheorieStörungstheorieProgrammierumgebungÜbertragungsfunktionProzess <Informatik>PunktspektrumTransmissionskoeffizientVerschlingungNichtlinearer OperatorFormation <Mathematik>
04:20
Bildgebendes VerfahrenSoftwareTypentheorieLeistung <Physik>ParametersystemSchnittmengeWorkstation <Musikinstrument>DifferenteWellenformElektronische UnterschriftEndliche ModelltheorieIRIS-TVorlesung/Konferenz
05:01
Dynamisches SystemGraphHardwareInformationComputerarchitekturFunktion <Mathematik>KomplexitätstheorieTypentheorieGebäude <Mathematik>SynchronisierungProgrammierumgebungBitGarbentheorieLokales MinimumMaßerweiterungMomentenproblemMultiplikationPhysikalisches SystemSpeicherabzugZahlenbereichVerschlingungDatenflussKonfigurationsraumParametersystemZusammenhängender GraphPunktspektrumSchnittmengeEin-AusgabeThreadMetadatenMultigraphWorkstation <Musikinstrument>Elektronische PublikationOpen SourceLaufzeitfehlerDifferenteAnaloge SignalverarbeitungIRIS-Tp-BlockTransmissionskoeffizientSoftware RadioKeller <Informatik>Interface <Schaltung>GamecontrollerDefaultMobiles InternetMechanismus-Design-TheorieMathematikMustererkennungIntegralGerichteter GraphMereologieTeilbarkeitComputervirusNichtlinearer OperatorBAYESVererbungshierarchieArithmetische FolgeZeitstempelTouchscreenMeta-TagFlussdiagramm
08:13
GraphInverser LimesDatenflussAbstraktionsebenep-BlockVorlesung/Konferenz
08:39
Dynamisches SystemGraphMathematikTaskEinfach zusammenhängender RaumFourier-EntwicklungKette <Mathematik>Physikalisches SystemRandverteilungWellenformVerschlingungDatenflussKonfigurationsraumTeilbarkeitParametersystemZusammenhängender GraphPunktspektrumComputersicherheitRichtungEreignishorizontAnaloge SignalverarbeitungElement <Gruppentheorie>MultiplikationsoperatorGamecontrollerMechanismus-Design-TheorieSoftwareTypentheorieRoutingParametrische ErregungThreadElektronische PublikationKeller <Informatik>Interface <Schaltung>Computeranimation
10:27
Physikalisches SystemZusammenhängender GraphGamecontrollerCodeDatenverwaltungComputerarchitekturKomplexes SystemProgrammbibliothekProjektive EbeneSpeicherabzugVirtuelle MaschineE-MailGüte der AnpassungComputervirusParametersystemPunktMailing-ListeEreignishorizontOpen SourceSichtenkonzeptLaufzeitfehlerDifferentep-BlockKurvenanpassungRechter WinkelInterface <Schaltung>OrtsoperatorDokumentenserverMultiplikationOffene MengeSpielkonsoleIRIS-TWeb logVorlesung/KonferenzDiagrammFlussdiagramm
12:17
GrundraumPhysikalismusVerschlingungPhysikalische SchichtSoftware RadioSoftwareentwicklerProtokoll <Datenverarbeitungssystem>Lesen <Datenverarbeitung>IRIS-TVorlesung/Konferenz
13:03
ComputerarchitekturPhysikalismusVerschlingungZusammenhängender GraphPunktspektrumEin-AusgabeProtokoll <Datenverarbeitungssystem>SoftwareBitWellenformOSI-ModellXML
13:41
Dynamisches SystemSoftwareTermÜbertragungsfunktionVerschlingungPunktspektrumSchlüsselverwaltungPartikelsystemWirkungsgradProgrammierumgebungInformationsverarbeitungZusammenhängender GraphPhysikalische SchichtProtokoll <Datenverarbeitungssystem>Kartesische KoordinatenUmwandlungsenthalpieVorlesung/Konferenz
14:34
DatenverwaltungMathematikFehlererkennungFunktionalMereologieVerschlingungDatenflussZusammenhängender GraphRadiusGamecontrollerDynamisches SystemInformationsverarbeitungPhysikalisches SystemPunktspektrumFehlermeldung
15:38
Dynamisches SystemInformationTelekommunikationStörungstheorieIntegralDimensionsanalyseFunktionalPhysikalisches SystemZahlenbereichZellularer AutomatVerschlingungSoftwarewartungExogene VariableCASE <Informatik>PunktspektrumKartesische KoordinatenUmwandlungsenthalpieMechanismus-Design-TheorieInstantiierungVorlesung/Konferenz
17:27
WirkungsgradFunktionalMaßerweiterungPhysikalisches SystemÜbertragungsfunktionVerschlingungZusammenhängender GraphInstantiierungPhysikalische SchichtProtokoll <Datenverarbeitungssystem>DatentransferGamecontrollerDatenverwaltungVerkehrsinformation
18:35
FunktionalSpeicherabzugZusammenhängender GraphEinfügungsdämpfungFramework <Informatik>ZustandsmaschineGeradeTermInstantiierungProtokoll <Datenverarbeitungssystem>RahmenproblemMobiles InternetVorlesung/Konferenz
19:36
DatenverwaltungHardwareComputerarchitekturIntegralFunktionalLeistung <Physik>MultiplikationResultanteSpeicherabzugVerschlingungFehlermeldungInstantiierungProtokoll <Datenverarbeitungssystem>Kartesische KoordinatenRahmenproblemKomponente <Software>GamecontrollerGrenzschichtablösungMereologieTeilbarkeitDruckverlaufBeobachtungsstudieInterface <Schaltung>SoftwareentwicklerXMLFlussdiagramm
21:36
DatenbankDynamisches SystemProgrammierungDreiFunktionalGruppenoperationSpeicherabzugVerschlingungZusammenhängender GraphPunktspektrumHeegaard-ZerlegungNummernsystemProgrammierparadigmaProtokoll <Datenverarbeitungssystem>Kartesische KoordinatenRahmenproblemEreignishorizontZustandsmaschinep-BlockARM <Computerarchitektur>PartikelsystemEinfache GenauigkeitGamecontrollerInteraktives FernsehenKomponente <Software>Vorlesung/Konferenz
23:24
ComputerarchitekturMereologieMultiplikationSpeicherabzugVerschlingungDatenflussOSI-ModellZusammenhängender GraphFehlermeldungDatenfeldInformationsspeicherungProtokoll <Datenverarbeitungssystem>Kartesische KoordinatenRahmenproblemDemoszene <Programmierung>GamecontrollerTDMAInterface <Schaltung>XMLFlussdiagramm
24:18
DatenverwaltungInformationVerschlingungZusammenhängender GraphInformationsspeicherungProtokoll <Datenverarbeitungssystem>Kartesische KoordinatenAdressraumGenerizitätInterface <Schaltung>GamecontrollerMobiles InternetUmwandlungsenthalpieSystem FPartikelsystemVorlesung/Konferenz
25:28
Dynamisches SystemOrdnung <Mathematik>FrequenzGruppenoperationLeistung <Physik>MereologieVerschlingungServerCASE <Informatik>Zusammenhängender GraphPunktspektrumNummernsystemPhysikalische SchichtProtokoll <Datenverarbeitungssystem>RahmenproblemWorkstation <Musikinstrument>DifferenteGenerizitätp-BlockGamecontrollerDoppler-EffektSoftwareMakrobefehlPhasenumwandlungAggregatzustandDatenflussComputervirusGewicht <Ausgleichsrechnung>InstantiierungInformationsspeicherungOrakel <Informatik>XMLUMLFlussdiagramm
27:38
ImplementierungTelekommunikationAggregatzustandKoordinatenSchedulingDatenflussVersionsverwaltungExogene VariableNichtlinearer OperatorCASE <Informatik>Zusammenhängender GraphSchnittmengeDatentransferKartesische KoordinatenInteraktives FernsehenSicherungskopieLaufzeitfehlerZustandsmaschineEindringerkennungMultiplikationsoperatorInterface <Schaltung>GamecontrollerMobiles InternetLeistung <Physik>InstantiierungEin-AusgabePartikelsystemMinkowski-MetrikEinsVorlesung/Konferenz
29:49
ImplementierungMathematische LogikBitGruppenoperationKonfigurationsraumLesen <Datenverarbeitung>Elektronische PublikationEreignishorizontEndliche ModelltheorieZustandsmaschineCodep-BlockXMLFlussdiagramm
30:23
Mathematische LogikAggregatzustandFunktionalGruppenoperationKartesische KoordinatenUmwandlungsenthalpieRahmenproblemElektronische PublikationGamecontrollerCodeProgrammbibliothekInstantiierungVorlesung/Konferenz
31:24
Dynamisches SystemPlotterInformationsverarbeitungMultiplikationGüte der AnpassungPunktspektrumZweiKomplexitätstheorieGruppenoperationMaßerweiterungAutomatische HandlungsplanungDatentransferMinkowski-MetrikUnternehmensarchitekturXML
32:28
DatenbankInformationPunktspektrumInstantiierungEndliche ModelltheorieMultiplikationsoperatorVorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
00:05
Hi everyone, I'm Paul Sutton, I'm not Andre. Andre very kindly has let me take a 10 or 15 minute slot at the start of the session just to tell you about IRIS, the software radio framework which is the basis for some of Andre's work. I'm from CTVR, the
00:21
Telecommunications Research Centre based in Dublin in Ireland. So just very quickly I'm going to give you an overview of IRIS, a quick look at the architecture and just talk a little bit about controllers, one of the features within IRIS. So what is IRIS? IRIS is a software radio architecture, so it's a framework to help you build software radios. So you can start from scratch
00:41
and write your own software radios, there's no problem doing that. Why use a framework? Because it gives you stuff that you don't have to write yourself. So it looks after your threading, it gives you IO blocks, it gives you some existing DSP blocks, it gives you instrumentation and it gives you visualisation tools. The main design goal of IRIS was to be
01:02
reconfigurable, so if you're going to build software radios you're doing that to get the flexibility. So from the start with IRIS we wanted to build in the reconfiguration and allow you to reconfigure your radio at runtime. It's mainly GPP based but we've run IRIS on FPGAs, on the cell BE, on various different platforms. It's component based, so similar to GNU radio, we take
01:25
a component based approach, components are written solely in C++ and then we use an XML configuration file to describe how these components get linked together and to specify initial parameter values for those components. It is written in C++, it's portable so we use the usual
01:45
libraries to help us get there, we use Boost, we use CMake as the build system, it's pretty straightforward. And it's extensible most of all, so any component based system is going to be extensible but we've tried to build this extensibility into the core as well with the concept of engines for
02:01
IRIS and I'll talk a little bit about that later. And most importantly it's open source and that might be obvious talking of FOSTA, IRIS was developed within a university so this is a big deal for us. When you're developing a project that starts within a university, start with the open source, don't develop the project and then try and open source as it's a real pain in the ass.
02:23
So what can I do with IRIS? Most importantly we tend to use IRIS to do demonstration systems which represent the conferences. So a lot of the focus has been on dynamic spectrum access systems and I'll give you a couple of examples here. We do a lot of work as I say with dynamic spectrum access systems, the challenge there is you're dynamically changing the fundamental
02:44
physical parameters in the waveform you're using. So you're changing bandwidth and frequency pretty regularly. One of the challenges in that scenario is you can do whatever you like with the transmitter but it's no good unless the receiver can keep up. So how does a receiver automatically figure out where its transmitter
03:02
is transmitting frequency, what waveform it's using, what's the bandwidth and so on and so forth. So one of the ideas we came up with was this idea of cyclostationary signatures and a fancy name for essentially a correlation pattern in the spectrum of the waveform. And it turns out this is a really nice tool, you can use it
03:21
and actually a little bit more about cyclostationary signatures. The nice thing about it is that you can detect this before you do any synchronization of your system. So it's one step above taking a spectrogram which means that you can use it to gain information about the waveform before you actually try to receive the waveform. So we've done a couple of demonstration systems
03:40
where you're using this for automatic carrier frequency tracking, automatic bandwidth estimation, automatically finding out more information about the transmitted waveform and syncing onto it at the receiver. A more recent demonstration was this idea of Spectrum Wars. The basic radio behind it is very, very simple but it's just a game for four players
04:05
using dynamic spectrum access. So the idea is you've got two teams each with a transmitter and a receiver and the idea is you have to create a link and you have to transfer as much data as possible. The catch is that you're operating this same spectrum band so you can interfere with your opposing team.
04:22
There are various tricks and tools you can use and you have a primary user that you have to avoid interfering with as well. And this is kind of a big demonstration that I hope to set up later and try and get playing with and we'll see how we get on. I'm not too sure what we're going to do for power in this room but we'll see. And then finally we've done some work on heterogeneous networks
04:42
and handover between heterogeneous networks. So this involved putting a usurp on a model railway and simulating handover between different types of heterogeneous networks. And again this used cyclostation signatures to determine the fundamental parameters of the waveform that was being used in each.
05:01
A good example of what you can do with IRIS was Jase Kibilda came to us on a two-week cost short-term scientific mission. He had no prior knowledge of IRIS and he very quickly put together quite a nice dynamic spectrum access demonstration system. So he had a base station, a couple of mobile stations and he quite simply was avoiding a primary user
05:21
using a control channel to manage the data channel. And there's more information about this at that link. So just to go through some of the basics. It's a GPP-based software radio architecture. A fundamental block is a component. The components are written in C++.
05:41
Your most basic configuration is a source to sync and some processing components in between like this. They get linked together by an XML file. This is an example XML file. So you have very quickly your software radio. You define an engine. I'll tell you a little bit more about that later. You've got a file reader, Oftia modulator, signal scaler and a USRP transmitter.
06:04
I'm sure you're all familiar with the USRP. Each of these can expose parameters which you can set and change at runtime. Obviously I'm not showing you a huge number of parameters here. If you run an XML file like this it's just going to use the default values.
06:21
Use the parameter tag to identify the parameter, set the value. You define ports, inputs and outputs and then you define links to link them together. That's how you create your flow graph and get it running. So that XML file will result in a simple flow graph for a OFDM transmitter.
06:42
So between the source and the sync you're passing these data sets. So data set contains data, timestamp, sample rate various types of metadata that you want to pass along with this. You can have a simple source to sync flow graphs but they support multiple inputs, multiple outputs and so on. So you can build up pretty complex flow graphs.
07:04
So I spoke a little bit earlier about engines and what is an engine? An engine basically is an environment within which one or more components runs and it defines its own data flow mechanism. It defines its own reconfiguration mechanisms. It runs one or more of its own threads and it just provides a clean interface to the Irish system
07:21
to allow the Irish system to set it up and run it. Basically what this means is that it executes a section of the flow graph but it's completely up to that engine how it does that as long as it provides this clean interface. So with this approach it means that you can build new engines for different types of flow graphs for different reconfiguration mechanisms
07:41
for different hardware if you so wish. So it's going back to that idea of extensibility and making sure that the core as well as the component base itself can be easily extended. At the moment we just have two engine types through the PHY engine and the STACK engine. The PHY engine is designed for maximum flexibility.
08:01
So we have one thread per engine. It's data-driven execution. You can have one or more components multiple component inputs and outputs data flow and no fixed relationship between inputs and outputs. So the idea is that it's as flexible as possible. How come you get the beer and I get the water? That's not beer.
08:21
Thought I was making an early start. And you've got these flexible block sizes. So the idea with the PHY engine is to make it as easy as possible. It abstracts the flow graph from the user. You don't have to care too much about the flow graph and what the limitations are because there aren't that many. So an example of a PHY layer engine is that this could be your USRP receiver
08:41
signal analysis of the MD modulator. And for example, a file writer. So this is the type of receive chain you might have for that dynamic spectrum access scenario where you're automatically figuring out parameters of the waveform before you're about demodulator. And then you're reconfiguring your demodulator according to what's going on. The STACK engine, components within the STACK engine
09:01
are layers within the STACK. Each one's its own thread. It supports bi-directional data flow. So for example, if you're going to implement a MAC layer this is where you do it. So we've got network interface. You could do security routing. We've got the MAC layers and so on. So if you're going to put together a transceiver design using multiple engines this might be how you decide to do it. You could have one PHY engine for your transmit chain
09:22
another for your receive chain and then you've got your STACK engine running your network stack. So far, I've spoken about how you create a radio how you can reconfigure it manually. So while the radio is running if you change the XML file tell the radio it's changed it'll read it then figure out what changed and implement that reconfiguration.
09:42
But how do we manage that dynamically? And this is where the idea of the controllers comes in. So we have parametric reconfiguration of parameters which are exposed by components. We have another mechanism for signaling events. So if something happens within your flow graph you're telling the system something needs to be done about this.
10:01
The controller is the element of the system that handles that flow. So sure, you can directly connect reconfigurations between components. The idea of controllers is to ensure that it remains component based the components are independent. So if you start creating direct control links between them there's a danger that you're going to get
10:21
these interdependencies between the components. So by using a controller, you remove that and you put that knowledge of the radio system and how the components interact into one separate module and it allows you to keep the components independent. So for example, with our transceiver you could add in a controller
10:41
and that controller can subscribe to events on any components running within that radio and it can reconfigure parameters within any component in that radio. This is just the view of the architecture. So Iris itself is written with a plain C interface. So when you run Iris you typically use a console launcher
11:01
but underneath the hood that's just a plain C interface into the library itself. You have the system, you have the engine manager. The engine manager has a repository of controllers that can load up at runtime. Each of the engines has their own component manager repository of components they can load up at runtime. So the Iris itself is split into the core
11:21
and the components are the core and the modules. So the core typically you'll only run one on your machine. The modules repository you could have multiple different modules repositories for various different reasons. So you can run the single core. You can tell it where 15 different module repositories are and then it can load up components from each of those module repositories as needed.
11:47
So why use Iris? It's a fairly quick learning curve. It's open source, very easy to contribute to. It's still quite a small project and it's very easy to quickly implement fairly complex systems. The code is on GitHub. We've got Redmine and mailing lists
12:01
and of course the blog. So feel free to check it out and let me know what you think. So I'll finish there and I'll hand over to Andre. Thanks very much.
12:21
Okay, hi everybody. My name is Andre and I'm from Ilmenauer University of Technology. So it's a small technical university in Germany in the center of Germany. And yeah, the reason Paul said so I've been using Iris for quite a while. So we just thought it makes sense
12:40
that Paul introduced it to the audience. So I was kind of relieved by this task. So are we going to talk about link layer protocols and how basically software radios can be used to implement higher layer protocols and not just physical or not just physical layer developments.
13:01
So it's basically going to give a quick introduction and talk a little bit about link layer protocol research. Then go into a component based link layer architecture that we came up with. Show some practical examples and then present an outlook and a summary. So basically what was the motivation behind this work?
13:21
So we have seen the talk by Tom and I think he presented the idea of the software defined radio. But most of the research or most of the work that we have been seeing there was mainly on physical layer aspects. So antennas, waveforms in general
13:41
or spectrum sensing as well. But from the high layers like link layer, network layer, transport layer or something like this, there hasn't been much so far. Basically trying to make use of this flexibility that we have in the physical layer.
14:04
Most of those work has been very application specific in which the protocols for let's say energy efficiency for sensor nodes or delay tolerant networking, cognitive radio as a general term for having a like environmental aware,
14:21
intelligent radio, dynamic spectrum access or Paul and Tom has also mentioned. And the key question we were basically asking can higher layer protocols or higher layer components benefit from this flexibility that I have underneath as well.
14:43
And when we are talking about cognitive radio link layer, so basically the question you have to ask what is new there, what remains and what changes there. And of course I guess you know link layer of radio is basically the layer sitting on top of the physical layer.
15:00
Basically trying to do the basic link layer functions like framing, error control, flow control, like multiplexing, demultiplexing, stuff like this. And of course a cognitive radio link layer or a flexible radio link layer needs to do those basic functions as well. But what is on top of this,
15:21
it has to basically try needs to manage the flexibility that is underneath it, trying to manage the high resource that it has. And when we are trying to build like cognitive radio systems or dynamic spectrum access systems or any other application like protocols,
15:44
you have some application specific responsibilities. Like for instance this link establishment that Tom mentioned earlier. So you have like eight channels and you know there is a jammer and you need to like instead of sending eight channels
16:00
and then having or the information like in parallel on eight channels, you basically could just send it on one channel and then hop. But you kind of need to know when there is a big number of channels like not just eight or 10 like hundreds or so. And it needs to be some mechanism to basically synchronize and to establish a link
16:23
prior to really communicate. And also in dynamic spectrum access system there is basically a use case called or that's basically the idea of dynamic spectrum access
16:45
that in licensed spectrum that you have something called a primary user which basically owns the spectrum or is the licensed owner of the spectrum. And when you use the spectrum you need to vacate it if the prime user comes back.
17:03
So you need to find out and it creates a mechanism to basically maintain your link to maintain your communication for seamless communication. That's an application, an example application for a specific link layer function for flexible radios or for reconfigurable radios.
17:24
But there could be many more. And the real challenge here is how can those heterogeneous system requirements be addressed in a link layer? So how can those data transfer functions which are basic functions of the link layer and of course also exist in the newer radios
17:46
basically how can I do those basic transfer functions and separate them from the more management-like functions? And how can I facilitate the reuse of those components that I have in each and every radio?
18:03
And when we're looking at the link layer protocols nowadays, so I think there has been a whole bunch of proposals from the research community specifically on medium access control protocols or link layer protocols. And most of them have been kind of standalone or extensions of medium access control protocols
18:25
basically trying to solve some energy efficiency issues for instance. And the general approach is to either extend an existing protocol and trying to like add some like for instance rendezvous function or mobility function into the core of the protocol
18:42
that you can see from the dashed lines there. But the problem here is that you tightly integrate this additional function into your core protocol and by that you make the core or you make it not really reusable. I mean the core is basically just there
19:02
for the purpose of, well, yeah. It's basically just the core and the digital functionality is bound to these and tightly integrated into the core. And there has been some flexible MEC kind of research on where component or where the component like term
19:24
was defined as kind of very fine-grained components where the components were state machine entities just like sending a packet or triggering a timer or receiving a frame or something like this. And this has been done mostly on for instance
19:42
add-on 2011 off-the-shelf hardware using a soft MEC approach or also an FPGA work. But the result is here that those protocols are quite complex to implement and also to maintain. So if you have to recompile FPGA for each and every step
20:07
of your protocol development, it becomes quite cumbersome. And also the flexibility or the reusability is quite limited due to this tight integration.
20:21
So the idea basically we came up with is kind of a component-based link layer architecture that basically separates those core functions from the additional user-specific applications. And the idea was to instead of tightly integrating
20:44
those additional applications into the medium access control protocol, we basically split it all up. We're having a core protocol which basically takes care of those essential functions like framing, error control, stuff like this. And we have multiple applications
21:05
like link layer applications that basically take over the management functionality and use the link layer or the core protocol as an application would use it using the same interface.
21:21
And we're having a controller which is capable of managing those five capabilities, trying to reconfigure a channel, trying to reconfigure the transmit power per frame or the modulation scheme or anything like this. And we're trying to basically model the dynamics
21:46
between the core protocol and those applications using a finite state machine which basically runs in the controller and interacts with the protocols. And you can use events similar to those we have in the radio itself.
22:04
But here the events could also come from an external application, not just only from a component internal to the radio like a sensing component or something like this, but also from an external application like a spectrum database or whatever you could think of, or a user application
22:22
that basically tries or signals the radio that this quality of experience is dictated and there should be an action. And you could basically program or code an handler for this event inside your controller
22:42
and basically reconfigure the radio. So this is basically the idea of instead of like having a single block with lots of functionality tightly integrated into it, having it kind of split up like following this component-based design paradigm,
23:03
but do this on the Mac layer or the link layer. Of course, when we want to have all these functionality, we need to have a few functions,
23:20
or we need to accommodate a few functions inside our generic or core Mac protocol. And there is basically a part of the link layer protocol which we call the core, which is basically a generic component which consists of one
23:44
or more error-on-flow control protocols for all the flows that you would like to handle, multiple applications, of course, which are all accessing a single interface. And of course, we need the frame multiplexer, demultiplexer.
24:00
And in the basic architecture, you have a media-dependent part here, which is basically the medium access control, either CSMA-based like add-on 2.11 or TDMA-based, accessing the physical layer, basically or userP or whatever you want to use.
24:21
Now, how do the applications we create here? So basically, the idea is now you have multiple components in your link layer, application-specific, for instance, the round-root protocol, which connects to the same application or just the same interface like user application would do,
24:41
signaling that it is a round-root protocol and it maybe has a higher priority to access the channel than the user application. You can configure this. Or a mobility protocol also uses the same interface just as a normal application would do.
25:01
And there's a new component with this controller having a generic data storage kind of thing where it can store information such as the address or the links it communicates to, the channels it has. There's a channel manager which kind of stores the information that the physical layer is capable of.
25:25
So the physical layer basically signals the link layer which capabilities it has, which channels it connects to, which modulation schemes it can use. And the controller is able to store per link, per flow,
25:42
for instance, the transit power it needs to configure the channel to in order to reach a certain station. And the whole idea is here that you basically, you have it decoupled from the media-dependent part, decoupled the generic part from the media-dependent part.
26:02
And you could, for instance, also use different MAC protocols here. For instance, TDMA-based MAC protocol or CSMA-based MAC protocol implemented either on FPGA or on your host computer, so that's kind of generic here. But still, you can use the generic part
26:22
on your host computer. So during the last couple of years, I'd say, we've implemented a few components. All of them were basically in the use case of this dynamic spectrum access,
26:41
that's why I was focusing on this a little bit. So we had various rendezvous components, which implement the state-of-the-art protocols there that you can use either for ad hoc networks, where the nodes basically don't know each other and don't know which frequency they are using
27:00
and don't have specific roles, or in like centralized networks, where you have dedicated base station, which is like a mobile station can connect to. You could use the coordinator-based protocol. And you have link layer protocols like simple block and wait,
27:21
like block acknowledgements, that has been basically done during the DARPA spectrum challenge for Iris, where you can basically send a bunch of frames. And instead of acknowledging a single frame, you can basically acknowledge a whole block of frames. And you have flows IDs with priority,
27:42
so you can have multiple applications which are all served according to their priority. You have medium access control protocols, lower, slotted lower. Then there's a soft FPGA, soft season A implementation, which basically tries to run a season A protocol in software, which of course has some drawbacks
28:02
to the latency that is involved with the communication. But there's also an FPGA version. And a simple TDMA version also there, which basically uses the time commands of the user P
28:22
in the UHD to like schedule transmissions. And there's also mobility protocols, which their responsibility is basically to coordinate between or among a few nodes,
28:41
a certain backup channel, for instance, that you could use in the case that a primary user occupies your primary operating channel, and that you can hand over. And there's also a few where central coordinator does the coordination, or there's a cluster base where a cluster had a selected during run time
29:03
and available channel sets are exchanged. And basically, the backup channel is negotiated within that cluster. I've talked about this controller
29:21
that implements a finite state machine to model the interactions among those components. And I just wanted to quickly show how this is working. Basically, what we've been using is a... Basically, there's a generic interface. You could basically use any state machine implementation
29:40
that you can think of. Either you code it in C++ or use Boost state chart. But there's another one called, which is based on StateBuilder, which uses an XML state machine model, which is extra from the actual Iris configuration that Paul mentioned, where your blocks are configured.
30:04
You basically define your state machine and the actions that are taken on the events in an XML file. And then you run in the build process. There's a code generator that creates a C++ implementation of this.
30:21
And you add some business logic to it, which is basically the actual work of the application specific clue code, basically, that you need. For instance, there's a function here called FindNextChannel, which you specify in the XML file, and which actually lives in the business logic here.
30:43
And that, with the base code, which takes care of basic functions like reconfiguring a channel, for instance, is linked together into a FFL control or into a controller library, which basically then runs your radio.
31:01
And you can basically use those XML files very intuitively to define transitions. Like if a frame received, you switch over to a connected state.
31:21
And when you enter a state, you basically find NextChannel and the transit, if the channel has been found, to reconfigure radio. This is basically just an example. And when you transit, you perform this action, reconfigure a channel. This is basically just an example of a radio that I mentioned in a few seconds.
31:47
Yeah, here we go. Okay, good. Let's come to some practical examples that we've been playing with. So this is basically just a demonstration overview
32:02
that we have been presenting at the conference last August in Ilma now, where we set up a dynamic spectrum access experiment with multiple cognitive radio nodes and a primary user trying to infer with the ongoing cognitive radio data transmission.
32:22
And you can see the waterfall plot and here's the primary user. The cool thing here was that instead of just hopping between the channels, we were using a database and an extra user p which was sensing the spectrum and was writing those information to a database.
32:42
And instead of just randomly selecting a channel, we basically showed that you can predictably model the primary user and use the channel that has been least used, for instance, over a certain amount of time and try to decrease.