Channel Selection and Time Slot based Data Transmission using USRP

[Amir2]

Hi all,

I would like to prototype an algorithm using USRP-2943R (120MHz) and LabVIEW or LabVIEW communication. I will try to explain this simple algorithm to you in the most understandable manner possible:

First of all, the algorithm applies to the communication systems that are frequency division and time slot based.

Assume that there are 10 channels in the wireless medium obtained through dividing the available frequency bandwidth. Also, each time slot duration is T = T_s + T_t.

Where, T_s  and T_t are the sensing time and the data transmission time, respectively.

Channel selection and transmission algorithm:

In the beginning of the time slot the transmitter chooses one of the channels uniformly at random. Then, it starts to sense the channel for some times T_s (sensing time). If the transmitter finds that the channel is idle, then it transmits the data for some times T_t. Otherwise, if at the end of the sensing time the transmitter finds the channel busy, then it doesn’t transmit and stays silent until the end of the current time slot. This strategy is repeated for channel selection, sensing and data transmission. I have attached a photo that represents the time slot structure.

So, for implementing this algorithm, it seems to me that answering to the following questions is required:

1- How we can divide the whole available bandwidth into 10 channels?

2- How we can implement the time slot based data transmission?

3- How we can select the channel in the beginning of the each time slot uniformly at random?

4- How we can sense the channel and make the decision that the channel is idle or busy?

Could you please share with all your thought and suggestions?

I hope this discussion would be helpful for other members as well.

Thank you for your time.

[lucaso3]

Hello Amir2,

Thank you very much for posting your questions into our forum. Even though it is a broad question that might be solved in different ways, I believe we can discuss a possible approach.

If I understood correctly, you would like to be switching the center frequency and in each verifying if there is already a transmission on the line. In order to be able to do this, I would use a loop that will be obtaining values out from an array with already specified center frequencies and insert each one on the Carrier Frequency Property Node. Once the center frequency is set, we can fetch data and based on the decibels obtained we can decide on whether or not the band is being used. If it is, then we don’t transmit anything, but if we only fetch the noise floor, then we can make a transmission.

It will depend on the amount of power that you are expecting, so you should be able to determine that threshold. Also, we will need to take into account that we need to have a defined span. To divide the span and insert the values to an array, you can either use the full range allowed by the USRP, or select one and make the division on the amount of channels you require. Again, something you need to take into account is the span.

Does this approach seem similar to something you might want to have?

Regards,

Luis Calderon

Applications Engineer

[Amir2]

Hello lucaso3,

Thank you for your reply. Your guide was informative for me. 

Regarding changing the Carrier Frequency using the Property Node, I see how you approach to it. So I can get the answer to the first question that I've asked in the first post. 

Regarding sensing the channel and deciding to transmit or not, I should say: Yes, I need to define a power threshold for detecting whether the channel is already busy or not.

Is there any VI examples on sensing and deciding what to do based the sensed power or energy? 

Regarding the span and dividing the span, you are suggesting that I can consider a span let's say 60second. Then, I can divide it into 600 time slot with each time slot range equals to 100ms (assume 20ms for sensing and 80ms for transmission or being silent if the channel is already busy). Is that what you mean? Can you remember any time slot based transmission VI examples?

Also, according to the algorithm, in the beginning of the each time slot the transmitter should select another channel and transmit if the selected channel is idle. If the channel is busy, the transmitter should wait until time slot ends. And this policy is repeated. In other words, at each time slot the transmitter will be on a different channel. By knowing that, what do you mean by "you can either use the full range allowed by the USRP, or select one and make the division on the amount of channels you require." ?

I think at this point my question is that:

How we can implement that time slot based data transmission policy? 

Thank you Luis.

[lucaso3 · Accepted solution]

Hello Amir2,

You are welcome. My intention is trying to help you reaching a state of confidence to start building your application. With that said, I believe we need to align ourselves with some terminology in order to fully capture the intention of each other.

When I mentioned the span, I meant the frequency range of the computed spectrum, in hertz. In other words, if we select a span of 100 MHz with a center frequency of 1GHz, we will have a spectrum from 950MHz-1050MHz. In other words, if we have a span of 100MHz, we will compute a spectrum 50MHz below and 50MHz over the center frequency. The span is not a time based analysis.

Related to the previous, what I meant by selecting an operations range is deciding what will be your initial and final frequency to analyze. For example, we can say that we want to start analyzing from 1GHz to 10GHz. So, we choose a specific span and we start to use center frequencies that allows us to analyze the specified range of frequencies. To make it a little more explanatory, we can set a span of 100MHZ, then we can use the center frequencies 1050MHz, 1150MHz, and so on. Or, we can start with a center frequency of 1GHz, 1100MHz, and on.

Now, regarding the power sensing, I am not fully aware of an example that shows it as is. What I would recommend is using the niUSRP EX Spectral Monitoring (History).vi example shipped with the driver to help you get an idea on how to transform from the IQ data to a spectrum form. Also, we can use SMT (Spectral Measurement Toolkit) to obtain the spectrum and by using the Spectrum Peak Search function we can determine if the channel is not idle. SMT has an example that we can use as a base, it is called SMT Basic Zoom Power Spectrum (simulated).vi.

For the time that you mention, we will need to set the configuration of the transmission in order to send data for a fixed amount of time. This will need to be accomplished by setting the IQ rate and number of samples properly. If we do not perform any transmission, we can use a wait time that will wait for the desired amount of time.

I hope that this comment might clarify a little more the intention with the initial one.

Regards,

Luis Calderon

Applications Engineer

[Amir2]

Hello lucaso3,

Thank you for your reply and helpful discussion. 

Sorry about misunderstanding of "span" meaning! I understood what you mean! Thank you for clarification. 

I have NI USRP-2943R (1.2GHz - 6GHz,  120 MHz BW). I would like to have 10 channels with defined span of 100 MHz which is supported by the USRP that I have. So, I would like to start from 2050MHz to 2950MHz.  So I use the following central frequencies:

2050MHz   2150MHz   2250MHz   2350MHz   2450MHz   2550MHz   2650MHz  2750MHz  2850MHz  2950MHz

So, as you suggested before, I will go head and assign the central frequencies to the USRP by using the niUSRP Property Node. SO this part is clear to me now. Thank you! 

Regarding implementing the time slot based transmission, how we can transmit for a specific amount of time by setting the IQ rate and number of samples properly? Could you please provide a numerical example on that?

From your explanation my understanding is that whenever the transmitter decides to not transmit, it just needs to not to write. Is that what you mean? If that is the case, I can kept the transmission session open for all the time and control to transmit or not transmit just by deciding to write or not to write. Is that what you mean? 

Thank you.

[lucaso3 · Accepted solution]

Hello Amir2,

Exactly, my suggestion is to avoid writing when the line is not idle. Now, when it is, then we can just write the data. Assuming the data will always be the same, we can use the niUSRP EX Tx Continuous Async Recording on the Fly.vi as reference to start building our own application.

My train of thought would be to monitor if there is a considerable peak, as we mentioned previously. If there is, then we will have a case structure with the case just waiting for the fixed amount of time. If we do not detect any peak, then I would have a for loop with a defined amount of runs depending on the time the repeated signal takes to send. For example, if our signal takes 1ms and we need to transmit for 10ms, then we need to set the for loop to run 10 times. Does this make sense? Do you think this approach might fit your requirements?

Regards,

Luis Calderon

Applications Engineer

[Amir2]

Hello lucaso3,

Thank you for the clarification. I understand what you mean. Thank you. 

Yes, for my requirements, it is fine if we assume that the data will always be the same. So, as you suggest I can start from niUSRP EX Tx Continuous Async Recording on the Fly.vi as reference.

Consider the front panel of USRP-2943, in the RF0 section, I want to use TX1 for transmitting the signal and RX2 for monitoring the spectrum. Let's assume that each time slot duration is 100ms. I want to allocate 20ms of this for monitoring (sensing) the selected channel and, the rest (80ms) for transmitting (if the channel is idle) or waiting (if the channel is busy).

Now, regarding the signal length, I should say, YES, that makes sense. For my requirements, I thinks, we can assume that our signal takes 1ms and set the for loop to run 80 times or we may assume that our signal takes 20ms and set the for loop to run 4 times.   

My understanding is that, in the transmitter part, we may need to have three cases for the case structure. When the receiver is monitoring the selected channel since the transmission session is open, the first case should be waiting a fixed amount of time (for our example 20ms) until the sensing ends. The second case needs to be transmitting if the channel is idle and the third case needs to again be waiting for the fixed amount of time (for our example 80ms) if the channel is busy. Does that work?

In addition, since the final decision for transmitting or waiting comes from the sensing results, I can imagine that, I need to have the receiver (RX2 in RF 0) graphical programming in the same VI as the transmitter. Is that right?

And, I need to construct another case structure for the sensing part as well. I need to consider two cases for that. One of them sensing just for a specific amount of time (for our example 20ms) and the other one just waiting (not to fetch) for the reset of the time (for our example 80ms). Is that true?

In the monitoring part how we can say to the receiver that just sense the channel for a specific amount of time? 

I appreciate your help.

[lucaso3 · Accepted solution]

Hello Amir2,

Yes, you can have the transmission and fetching on the same VI. The way I imagined it is by just having the sensing part before the transmission, so you will be just fetching data, converting it to a power spectrum and analyzing if the peak is enough to assume the channel is idle or not. Based on that decision, we just need a case structure for the transmission with two cases. One to wait (because we find a high peak) and the other to transmit (because we only saw noise floor).  

Regards,

Luis Calderon

[Amir2]

Thank you Luis!

I will try to implement the algorithm and let you know if I had a question. 

Thanks!

Amir

[figther92]

 share with me a VI with Implementing 2x1 MISO system with LabVIEW and NI USRP 2921?? I need problem with the estimation channel in the receptor, i used the alamouti code with 2 antennas trnasmitter and one antenna receiver.