GRC 3.6 / 802.11 a/g test signal

GNU Radio
1

Greetings engi’s!

I’m currently working on my masters (802.11 wlan receiver with
MATLAB/USRPN210). After creating all the important stuff ie:

-symbol finder
-time synchronization
-coarse and fine frequency compensation
-symbol demodulator
-deinterleaver
-Viterbi decoder
-descrambler etc.
-MAC layer decoding

i’m looking for any tested 802.11 a/g IQ signal for further research
becouse live samples captured by USRP seem to have incorrect result’s
(wrong frame type MAC field, random MAC adress, CRC, parity bits etc).

And here comes my 1st question.

Is there any place where i can get some real, tested IQ wlan signal i
a/g standard and full description (rate, coded data, adresses, included
MAC fields)? Tried with Agilent Signal Studio but files are saved in
.wfm encrypted format :frowning:

I also found GRC beacon frames transmitter, written in GRC

http://rrsg.ee.uct.ac.za/members/jwamicha/gr-wlan.tar.gz

but due to having GRC 3.7 (where ‘gnuradio-core’ was repleaced with
‘gnurdaio-runtime’) i can’t simply compile this file becouse of an
error:

checking for GNURADIO_CORE… configure: error: Package requirements
(gnuradio-core >= 3) were not met:

No package ‘gnuradio-core’ found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables
GNURADIO_CORE_CFLAGS
and GNURADIO_CORE_LIBS to avoid the need to call pkg-config.

It seems that those binaries arent compatible with my GRC version :frowning:

Any helpful guy to install this library and send me IQ signal of this
beacon frame? (in any MATLAB readable format - simple file sink in GRC).

Looking forward for any reply.

Thanks

2

Hi,

you can use gr-ieee802-11 [1] to generate WiFi frames. Just start the TX
flow graph and pipe the output to a file.
I uploaded a frame (IQ data, no noise) [2] for you that you can use to
get started.

I dont use Matlab, so i dont know how to import the data, but you can
display the IQ samples with

od -fw8 frame.bin

There is also a GNU Radio script [3] that might be helpful.

Hope it helps,
Bastian

[1] GitHub - bastibl/gr-ieee802-11: IEEE 802.11 a/g/p Transceiver
[2] Home | Bastian Bloessl
[3]
gnuradio/gr-utils/octave/read_complex_binary.m at master · gnuradio/gnuradio · GitHub

On 02 Oct 2014, at 17:25, Ernest S. [email protected]
wrote:

-Viterbi decoder
a/g standard and full description (rate, coded data, adresses, included

Alternatively, you may set the environment variables

Thanks

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Dipl.-Inform. Bastian B.
Distributed Embedded Systems Group
University of Paderborn, Germany

3

Greetings,

Ok, got this. After some test’s i think that the problem is with my
descrambler (de-interleaver and Viterbi seems to be ok). Currently, im
using
Matlab’s one provided by comm. toolbox.

Is it correct to use 127-bit length pre-defined scrambling/descrambling
seq?
(i found it in 802.11 standard). Or it sould be only implemented as a
shift
register with poly 1+x4+x7?

And last one question:

In any of frames generated by your grc script, there sould be 16x"0" in
SERVICE field (as it a part of PLCP Header) - becouse a typical wlan
card is
able to decode it, it is following the 802.11 standard - am I right?

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50614.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

On 10/05/2014 01:37 PM, Ernest S. wrote:

Greetings,

Ok, got this. After some test’s i think that the problem is with my
descrambler (de-interleaver and Viterbi seems to be ok). Currently, im using
Matlab’s one provided by comm. toolbox.

Is it correct to use 127-bit length pre-defined scrambling/descrambling seq?

No, this is an example output if you initialize the scrambler with
0b1111111.

(i found it in 802.11 standard). Or it sould be only implemented as a shift
register with poly 1+x4+x7?

yes.

And last one question:

In any of frames generated by your grc script, there sould be 16x"0" in
SERVICE field (as it a part of PLCP Header)

yes.

  • becouse a typical wlan card is
    able to decode it, it is following the 802.11 standard - am I right?

No. It’s following the standard and, thus, a normal card can decode it
:slight_smile:

Best,
Bastian

5

Hi,

On 06 Oct 2014, at 10:33, Ernest S. [email protected]
wrote:

Could you please check my methodology??

  • OFDM demodulation (to get 48 complex data points)
  • BPSK demodulation (to get 48 coded bits)
  • de-interleaving (1st and 2nd permutation)
  • Viterbi decoding ([133 171 poly] to get 24 uncoded bits)
  • descrambling

and if its correct way, i should get 24 bits of data (16x0 and 8 bits
depending on FRAME CONTROL paylaod) right?

The payload is scrambled (as opposed to the signal field). So maybe your
scrambler has a bug. Did you try to generate the example sequence from
the standard?

Do not try to decode the next OFDM symbol on its own, but the rest of
the frame. The decoder is not reset with a zero sequence as with the
signal tail bits. So it might not work with the same decoding function
that you used for the first symbol.

Best,
Bastian

6

Ok, so i decoded all of the payload (123 data symbols, de-interleaving
every
one in receiver’s loop). After Viterbi and descrambling it gives some
strange results:

7 of SERVICE bits are random - OK (i read in standard that those 7 bits
are
0’s at the transmitter, and will set receivers descrambler to correct
initial state).
9x0’s in RESERVED field - OK.

and now:

FRAME CONTROL - !incorrect!

TAIL bit’s looks fine (11x0’s - 6 zeros from TAIL field and probably 5
PAD
bits).

I also checked autocorelation function of received data bits. It
indicates
that there is some cyclicness in payload (every 96 bits function shows a
simple peak). Assuming that your frame consist of text:Hello world! -
its 12
characters, 8 bits each - together 96 bits repeating sequence, but cant
find
Hello world text.

Its rather imposible, that those results are correct.

You have mentioned that i should try with some test sequence (dont have
any
one). If i will try to generate it on my own, i wouldnt be sure that its
following the standard :frowning:

PS.

I was also searching for 48x"1" bit broadcast adress. Found only 43x"1"
in
row. Close but not the same :smiley:

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50639.html
Sent from the GnuRadio mailing list archive at Nabble.com.

7

Hi, much appreciate for your reply Bastian.

I have succefully found your frame.bin signal, forwarded by my USRP
(generated in MATLAB, received with Windows Network Monitor and wlan
card).

You were right. It is Data frame, 232323:232323 Source MAC and
FFFFFF:FFFFFF
Destination MAC.

Still dunno what’s wrong.

Could you please check my methodology??

1st OFDM symbol is carrying a SIGNAL field - it is decoded correctly (i
checked all rates with your grc wlan script) - no problem here.

2nd OFDM symbol is carrying Data. Assuming BPSK 1/2, it should carry 16
bit
SERVICE field, and 8 bits from FRAME CONTROL field (together - 24
uncoded
bits).

And my algorythm goes as follows (for 2nd OFDM symbol):

  • OFDM demodulation (to get 48 complex data points)
  • BPSK demodulation (to get 48 coded bits)
  • de-interleaving (1st and 2nd permutation)
  • Viterbi decoding ([133 171 poly] to get 24 uncoded bits)
  • descrambling

and if its correct way, i should get 24 bits of data (16x0 and 8 bits
depending on FRAME CONTROL paylaod) right?

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50621.html
Sent from the GnuRadio mailing list archive at Nabble.com.

8

Hi,

I cant help you much without the code, but did you see the example frame
in Annex L of the standard?

Maybe it helps you to debug your scripts.

Bastian

9

On 10/07/2014 04:57 PM, Ernest S. wrote:

Nope,

Any way to get it? Is it downloadable?

Should be helpfull indeed.

As far as I know it is not downloadable. You would have to extract (copy

  • paste) the data from the pdf.

Bastian

10

Nope,

Any way to get it? Is it downloadable?

Should be helpfull indeed.

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50661.html
Sent from the GnuRadio mailing list archive at Nabble.com.

11

On 10/08/2014 11:54 AM, Ernest S. wrote:

Ok. After couple of days trying to decode your frame i decided to check my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0’s in correct positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work out
your frames? Such amount of correct data couldnt be a coincidence :frowning:

As I already mentioned, it is very hard to help you without the code…

That test frame from Annex L is fully coded (scrambled, interleaved and conv
coded)?

Yes, it is. And it’s clearly stated. But for your convenience I can copy
paste from the standard.

The encoding illustration goes through the following stages:
a) Generating the short training sequence section of the preamble;
b) Generating the long preamble sequence section of the preamble;
c) Generating the SIGNAL field bits;
d) Coding and interleaving the SIGNAL field bits;
e) Mapping the SIGNAL field into frequency domain;
f) Pilot insertion;
g) Transforming into time domain;
h) Delineating the data octet stream into a bit stream;
i) Prepending the SERVICE field and adding the pad bits, thus forming
the DATA;
j) Scrambling and zeroing the tail bits;
k) Encoding the DATA with a convolutional encoder and puncturing;
l) Mapping into complex 16-QAM symbols;
m) Pilot insertion;
n) Transforming from frequency to time and adding a circular prefix;
o) Concatenating the OFDM symbols into a single, time-domain signal.

Bastian

12

Ok. After couple of days trying to decode your frame i decided to check
my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0’s in correct
positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work
out
your frames? Such amount of correct data couldnt be a coincidence :frowning:

That test frame from Annex L is fully coded (scrambled, interleaved and
conv
coded)?

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50672.html
Sent from the GnuRadio mailing list archive at Nabble.com.

13

Got the pilot sequence but ill check it once more. I also got Annex L so
not
neccesary to post it but thanks. Ill check everything once more,
according
to L.

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50678.html
Sent from the GnuRadio mailing list archive at Nabble.com.

14

On 10/08/2014 11:54 AM, Ernest S. wrote:

Ok. After couple of days trying to decode your frame i decided to check my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0’s in correct positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work out
your frames? Such amount of correct data couldnt be a coincidence :frowning:
One last idea: If groups of bits are correct, then most likely you
forgot to invert the pilot patter according to the sequence given in
Equation 18-25 of the standard.

Bastian

15

So… After going deep into Annex L i found that my scrambler fails.
Also
MATLAB built-in scrambler gives wrong results. Could you pls check this
code
fragment?

Asumme that we have 20 data bits to scramble. Initial scrambler state is
[1
0 1 1 1 0 1] (bit nr 7 left side).

scrambler_register=[1 0 1 1 1 0 1]; %
scrambler seed
data_bits=randi([0 1],1,20);
%
data to be scrambled

for i=1:20
temp=xor(scrambler_register(1),scrambler_register(4)); % x7 and x4
xor
operation
data_scrambled(i)=xor(data_bits(i),temp); %
output
bit
register=circshift(scrambler_register’,-1,1)'; %
shift
left register
register(7)=data_scrambled(i);
%
insert data to register
end

To clarify, left side of register has index (1), right side has index
(7).

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50685.html
Sent from the GnuRadio mailing list archive at Nabble.com.

16

On 08 Oct 2014, at 14:23, Ernest S. [email protected]
wrote:

data to be scrambled

for i=1:20
temp=xor(scrambler_register(1),scrambler_register(4)); % x7 and x4 xor
operation
data_scrambled(i)=xor(data_bits(i),temp); % output
bit
register=circshift(scrambler_register’,-1,1)'; % shift
left register
register(7)=data_scrambled(i);

the scrambler is independent from the data. you want to feedback temp
and not data_scrambled.

Maybe you want to have a look at Figure 1 in

http://www.ccs-labs.org/bib/bloessl2015scrambler/

Bastian

View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50685.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Dipl.-Inform. Bastian B.
Distributed Embedded Systems Group
University of Paderborn, Germany

17

Greetings,

finnaly got it working :smiley: Problem was with descrambler. Now it gives
results
as follows:

                        Service: 'ok'
                      Duration: '0000'
     Source_MAC_Adress: '232323232323'

Destination_MAC_Adress: ‘FFFFFFFFFFFF’
Protocol_version: ‘Supported’
Type: ‘Data’
Subtype: ‘Data’
To_DS: ‘False’
From_DS: ‘False’
More_fragments: ‘No’
Power_menagement: ‘Active’
More_data: ‘No’
Protected: ‘No’
Order: ‘Random’

But I still dunno how to estimate initial descrambler state (checked all
and
found correct one this time).
Descrambler graph sould be the same as the scrambler from you paper
right?

Best,
Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50709.html
Sent from the GnuRadio mailing list archive at Nabble.com.

18

Ok fixed. Now giving correct results :slight_smile: Ill try with your frame once
more and
hit you up later.

Thanks for your amazing feedback Bastian.

Best,

Ernest

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50690.html
Sent from the GnuRadio mailing list archive at Nabble.com.

19

Ok. All working fine :smiley:

–
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50731.html
Sent from the GnuRadio mailing list archive at Nabble.com.

20

On 10/09/2014 10:40 AM, Ernest S. wrote:

                             Type: 'Data'
                        Subtype: 'Data'
                           To_DS: 'False'
                       From_DS: 'False'
             More_fragments: 'No'
       Power_menagement: 'Active'
                     More_data: 'No'
                      Protected: 'No'
                            Order: 'Random'

Great

But I still dunno how to estimate initial descrambler state (checked all and
found correct one this time).
Descrambler graph sould be the same as the scrambler from you paper right?
On the receiving side, take the first 7 bits, put them in the scrambler
register, and use the very same algorithm on as on TX side. (Since the
output of the scrambler is fed back the first seven bits are also the
internal state of the scrambler).

Bastian