libLTE
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/32563 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2014168 / 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
State of matterMultiplication signProjective planeRight angleNatural languageSoftware frameworkSummierbarkeitLipschitz-StetigkeitLibrary (computing)Open sourceModule (mathematics)
00:58
Musical ensembleAreaCASE <Informatik>Data structureProjective planeCross-correlationRight angleImage resolutionParameter (computer programming)Block (periodic table)Level (video gaming)Sign (mathematics)Category of beingThermal radiationMereologyInteractive televisionComputerSequenceComputer programmingMultiplication signSynchronizationEndliche ModelltheorieoutputLibrary (computing)1 (number)Inequality (mathematics)Data miningState of matterSocial classLatent heatHydraulic motorPhysical systemOrbitInferenceSemiconductor memoryCartesian coordinate systemElectric generatorFunctional (mathematics)Domain nameSpring (hydrology)Software frameworkLengthForm (programming)Mathematical analysisRule of inferenceDistanceLoop (music)Wave packetTheoryOrder (biology)Sampling (statistics)Event horizonConvolutionInstance (computer science)Open sourceRing (mathematics)StatisticsComputer configurationRow (database)Computer fileWorkstation <Musikinstrument>Food energyCodeStability theoryNoise (electronics)Real-time operating systemCharge carrierPortable communications deviceObject (grammar)GradientFrequencyWebsiteEstimatorMoment (mathematics)NumberStatement (computer science)OracleAlgorithmImplementationMedical imagingStandard deviationVideo gameSelectivity (electronic)Bounded variationTheory of relativityCollaborationismSpeech synthesisPlug-in (computing)DatabaseBitEscape characterSet (mathematics)Web crawlerSimilarity (geometry)Condition numberGreen computingModal logicContext awarenessPower (physics)Density functional theoryInterface (computing)Mixed realityMathematicsFunction (mathematics)Resampling (statistics)Computer hardwareCellular automatonTime domainWaveformComputing platformRadical (chemistry)Software-defined radioAngleFraction (mathematics)Computing platformScripting languageBroadcasting (networking)PhysicalismRun time (program lifecycle phase)FeedbackOscillationGreatest elementSoftwareProgrammer (hardware)Module (mathematics)Directory serviceTransmissionskoeffizientDiagramTurbo-CodeLecture/Conference
Transcript: English(auto-generated)
00:07
We should give away. We should have a picture of him giving away. It's a die and do it free. He's free to bag apples. He's like, you know you can talk to people, but don't give away all the information.
00:26
May I? Ismail, please. My name is Ismail. Nice to see you here. I come from the CTBR Research Center.
00:43
I'm going to present this LIP LTE. It's a modular open source library for LTE. There's other people involved in this project. Paul Sutton from the CTBR, too. And Book, who is with Virginia Tech. And Tony, who is from UPC in Barcelona.
01:03
LIP LTE is a very new project. We just started this in January. It's a library for LTE. With a library, we mean that it's not an application. We don't want to make eNodeB a base station or a user terminal.
01:23
We just want to provide a collection of modules that then you can use to implement your base station. But, of course, we will provide a reference implementation of a base station and a mobile terminal.
01:41
It's a modular library. With modular, what we mean is that we want to be able to, if you're only interested in one of the modules of the library, to be able to pick it and use it in your application. For those of you who usually use libraries, you have found probably that sometimes it's very difficult.
02:03
Maybe you're interested in only a piece of the library and it's very difficult to get it and use it in your own software. Also, we want it to be computationally efficient. That means that we don't want to just implement the standard in a naive way.
02:22
We want to be clever. For instance, if you have to make a convolution, you can use the FFT convolution, these kinds of things. Also, one of the objectives is to avoid dependencies with other libraries or frameworks. To facilitate the portability to embedded systems, for instance.
02:43
What is true, and we have seen it today, is that Ginyu Radio, for instance, has a huge number of users. If you want your application to be used by other people, you have to provide some way for these Ginyu Radio users to use it.
03:05
Also, we have other SDR frameworks. We have seen Iris here, but we also have Aloy, I will talk a little bit after, and SCA, which is a military framework for software radio.
03:24
We want somehow to enable these framework users to use this library. In this table, I summarize the related projects on LTE. The first one is the MariSoft software.
03:42
It's probably the best software on LTE that we have today, but unfortunately, it's proprietary. It is able to run in a quad-core in real-time with two antennas, 20 mAh bandwidth, and they implemented the eNodeB as well as the MME.
04:04
Also, it works on the end-to-end user, but unfortunately, it's proprietary. We also have the OpenLT. As far as you know, it's also quite complete. It implements the PHY and MAC layer and partially the RC layer, but unfortunately, it's not modular.
04:26
If you are only interested in some of the DSP blocks, it's very difficult to isolate because there are many dependencies between models. We also have the GLT, but also as far as you know, it only implements the synchronization and decoding of broadcast signals.
04:48
PVCH is the physical broadcast channel in LTE, and it also uses Boost library. We also have this LTE cell scanner, which doesn't use a framework,
05:03
but also only implements the synchronization and decoding of the broadcast channels. And it uses IT++. IT++ is a very good library, but when you move to an embedded system, it's very difficult that it can run it. And finally, there's also SLD, which is a project I was involved in.
05:25
This was also an LTE downlink application for this alloy framework, but this framework was very focused on distributed real-time processing, and so it wasn't easy to use for the people.
05:44
So, yes, why do we want another LTE library? The first thing is that we want, as I said, to enable the reuse of models. We want to enable portability. C++ or Boost are difficult to find in some embedded platforms.
06:07
And we would like to avoid the necessity to use a framework. If you want to use it, you can use it, but sometimes it's too much overhead, and also it's very hard to move one model from one framework to another.
06:25
And finally, efficiency. As I said, it's not only implementing the standard. So we have this objective, modularity, we want to be able to generate code for frameworks, and we want efficiency.
06:43
And the design that we approach is a two-layer interface for the models. At the low level API, we don't impose any rule to the designer. The designer can implement the DSP block as he wants.
07:04
And then we define a high-level API where we do specify some rules. Finally, the idea is not using all the well-known libraries like FFTW or bulk, but if they are available in the system, use them.
07:29
This is an example of how the low-level API is defined. As you see, there is no rule. The programmer defines his initialization and function to allocate the memory.
07:46
You can set options, you can get options. Typical interface without any restriction. But then you have this high-level interface where we do specify these three functions, for instance, that you typically see in all the frameworks.
08:09
All the frameworks start with an initialize function, and then they have a work function, which is called periodically to perform the DSP, and then a stop function.
08:20
The idea is that the DSP designer has to implement these functions, calling the low-level API functions. Also, we define this structure, which needs to be followed, where you can see that the designer specifies the parameters that configure the model at the beginning.
08:48
And then some runtime input or output parameters that this model accepts or produces. All this is defined in a .h file.
09:03
And from this, using the Python C library, we parse this header, and using a Python script, we convert this model specification to a general XML file. Then from this XML file, you can implement using another script, you can generate automatically the C or C++ files that your framework needs.
09:31
For instance, now we only have this Python script that generates the model for this framework.
09:41
But it shouldn't be difficult for someone to implement this Python script to convert the XML file to a GNU Radeon model. So the idea is that with the same library of models, we can generate code for very different frameworks.
10:02
How do we work? Typically, here I try to describe how we are working with this library. You start with a MATLAB model, and we use a reference base station, which happens to be the Microsoft, because it's much cheaper than a professional signal generator.
10:25
And then we implement our receiver code of a specific functionality. Then we move to a live base station, a live signal that we capture from the base station, and we check that our receiver code is working properly.
10:44
And finally, we make the transmitter, we check against the receiver that we know is working with the standard, and we verify that the signal generated by the transmitter is the same than the others.
11:00
This diagram shows a little about the model structure of the library. At the bottom you have small modules, each implementing a DSP block. For instance, the binary, the scrambling, the ring matching, or the CRC. These modules have minimal inter-module dependencies.
11:23
So if you are only interested in the pre-coding of the LTE, you can take this file and move it to your application. On the other hand, as you move up in the layers, obviously you start finding more dependencies.
11:43
For instance, the synchronization algorithm uses this set of files for decoding the primary synchronization signal to estimate the channel. So if you aren't tested on the synchronization, then obviously you find some dependencies.
12:04
Well, this is the directory structure of the library. We organize the blocks in categories, and there is a single .h file that the programs using this library need to include.
12:27
What we've done so far, we implemented a real-time self-search program. It scans an LTE band and looks for basic stations and synchronizes with them.
12:45
Later, if we are lucky, we will try to find some LTE basic stations. I don't know if we will find some. The LTE synchronization uses two signals which are sent by the basic station.
13:05
The primary and the secondary signal, which are transmitted every five milliseconds. So the receiver needs to perform a correlation with three possible PSS sequences every five milliseconds.
13:20
This is very complex, so you need to try to be clever on how to implement this. Otherwise, you will consume all the resources only for synchronization. You also have to do carrier frequency offset estimation and, in most of the cases, sampling frequency offset estimation.
13:42
The CFO, you can estimate it from the cyclic prefix or from the PSS. What we do is to use the PSS because it's more accurate. To estimate the sampling frequency offset, what you do is you observe the variation in the times that the PSS has been sent.
14:06
Finally, this is what the self-search program does. It scans an entire band. First, we look at the receiver signal strength. For those bands where we observe that the signal power is high enough, we try to correlate the PSS.
14:23
If you find the PSS, then we track the signal for end frames and we estimate the CFO and SFO and the cell ID. To implement LT, LT is a very complex waveform.
14:41
If you want to be able to run it in real time in a laptop, it's very hard. To start with, the sampling frequency is a problem because not all hardware has the 3.84 clock. For instance, the M210 doesn't have it, so you need to resample.
15:00
Resampling is very expensive. But as Tom pointed out before, the FFTW has a very good performance even if the length of the DFT is not a power of two. So maybe one of the solutions is not sampling and the clock that you should sample, but then not changing the length of the DFT.
15:25
Another problem is the synchronization. The synchronization is transmitted in a sample at almost 2 MHz, 1.92, but the signal only uses 1 MHz. So you could sample at 1 MHz, exactly 945.
15:47
Also, using a time domain correlation is very expensive. You should use a DFT-based correlation. And then once you find the peak, narrow your search only to where this signal is supposed to be.
16:05
The coding is also very expensive, especially a turbo-coder, and it needs a very high throughput. So this is something that should be done, probably, to use SIMD instructions.
16:21
Bulk, for instance, exactly. But implementing a turbo-coder with bulk probably is not easy. And also, multi-user detection is also a problem at the base station, especially synchronization and detection. This is a little bit the roadmap of this project.
16:45
We started with the downlink. In most of the physical channels of this downlink, we already have some code from this OSD project that it was involved in before. And this code can be reused.
17:01
For the uplink, also, most of the parts are the same in the downlink. It can be reused. But there are still many things to do, like the SIMD decoder, the MIMO, and integrating all the pieces.
17:21
To summarize, liblt is a library. We aim at modularity. We want to be able to use this library, only parts of this library or all the library in embedded platforms. With no framework dependencies or third-party libraries.
17:43
And I take the opportunity to call for contributions, either in MATLAB models or C implementations are welcome. If any of you is working on LTE or something related, any kind of implementation is welcome. And that's it. Thank you very much.
18:09
Any questions? How do you correct the sampling frequency offset? Actually, now we don't correct it. Because for the synchronization, the correlation is robust against the sampling frequency offset.
18:24
We are able to detect it. And we will show in the demonstration later that we are able to detect it. But correcting is very complex. Especially if the offset is very small. But yes, this is a problem.
18:42
Are you planning to do this or just resynchronize every frame? Yeah, exactly. If the offset is small enough, you can resynchronize every framework. You just lose some SNR.
19:02
Any other questions? Can you repeat the question for the audio?
19:23
I think he asked if we estimate the CTO and if it's related to the offset of your oscillator. Was that the question? Is there a lead by the reference oscillator in the receiver instead?
19:41
If the feature hardware platform already does it, you use a VCPCXO instead of a normal oscillator, so you could control the frequency a little bit. And then you could solve both of these problems at the same time. You could just tune the reference clock of your receiver. First of all, you cannot do that with all the receivers.
20:07
And the second thing is that in LTE, correcting the carrier frequency offset is very easy. Estimating it is very easy, very simple computationally speaking.
20:21
But correcting it is also very easy. The sampling frequency offset is a little harder. But as we said, if it's small enough, it's only synchronizing every five milliseconds and you solve the problem.
20:44
To estimate the CFO, correcting it is very easy. You multiply by a phase. And to estimate, you have two ways. You can use the cyclic prefix. And what you do is you look at the angle of the output of your correlation.
21:07
Because you are transmitting the same sequence, so you look at the phase here. And if you have already synchronized with the primary signal, this PSS sequence, which is transmitted by the base station,
21:23
you know how this sequence looks like. There are only three possible sequences. And once you have correlated and you are synchronized in the time domain, at the output of the correlator, you also look at the phase shift that you have at the output of your correlator.
21:43
And this gives you the CFO. It is a standard approach. It is used by most synchronization techniques.
22:06
If you look at that paper. For the SFO, you look at the variation. When you synchronize, you know the time offset.
22:20
So if you look at the time offset every frame, you get an estimation of the SFO. If it is very small? If it is very small, you need more time. And then you go out of sync? No. If it is small, you don't go out of sync. Exactly. If it is small enough, you only synchronize every five milliseconds.
22:42
But you don't need to estimate it. If you want it, you could do it. But then you don't have to resynchronize and just estimate in, let's say, 100 frames, which is the offset. But if it is that small, correcting it will be very complex.
23:04
And it is a huge fraction of the sample. Then you probably don't need it, because your noise will spread it so far that it doesn't matter anymore. And you still have the phase noise of those small drifts you have.
23:21
You will not see it. There is not working with that. That is what you are talking about. You estimate for one frame the frequency offset, and you think it is in sync for the frame. No. I mean, you can do it, but your estimation is not very good, because it is subject to variation.
23:42
We were talking about sampling frequency offset, not carrier frequency offset. Ah, I knew I was to do this. There were two different questions. No, but for the carrier frequency offset, that is also true. You have to average over, I don't know, 100 or 50 frames.
24:02
Each frame is 5 milliseconds. And the more accurate you want your CFO estimation, the higher the delay on synchronizing with the network. But there is no feedback. It is only open. Yeah, there is no feedback. OK.
24:20
I will move the other questions to the open session. I would like to thank Ismael again.