Introduction to Ambient BackScatter, How it works?

In spite of many technological advances in wireless communications, whats the most annoying thing we face....battery drain, in fact more advanced technologies suck more battery !! For that reason for wireless devices like sensors, mobiles, swiping machines, all need a lot of maintenance...don't worry there is a way around ABS (ABC as they like to call it), Engineers from university of washington developed a prototype and demonstrated some applications.

BackScatter is an old technology used in RFID, but Ambient BackScatter differs from RFID in many ways (See below), main USP of ABS is, it Enables wireless devices with Power and Communications Medium without requiring batteries.....amazing isn't it..?? Its works on simple (Really!!) 2 principles 

1) It gets powered on using the ambient RF signals around
2) It transmits/receives signals by reflect/absorbing ambient RF signals around

The ambient RF signals discussed were TV Signals. 

It Uses 

• FM0 Coding (Data decoded by detecting change in transitions as 0 or 1)
• Carrier Sensing
• Own Network Stack (Similar Frame format as Ethernet)
• ACK based Protocol 

Now some more technical details from the official paper submitted

What is Backscattering?

At a high level, backscattering is achieved by changing the impedance of an antenna in the presence of an incident signal. Intuitively, when a wave encounters a boundary between two media that have different impedances/densities, the wave is reflected back 

 Energy Detection?

We show that one can perform energy detection by leveraging the property of the analog comparator, in the absence of a nearby backscattering transmitter, the comparator typically outputs either a constant sequence of ones or a constant sequence of zeros. A nearby transmission, on the other hand, results in changes that are greater than the comparator’s  threshold and therefore bit transitions at the comparator’s output. 

Since the transmitted bits have an equal number of ones and zeros (due to FM0 encoding), the comparator outputs the same number of ones and zeros. Thus comparing the number of ones and zeros allows the receiver to distinguish between the presence and absence of a backscatter transmission

How it is different from RFID?

Ambient backscatter differs from RFID-style backscatter in threekey respects.  

• Firstly, it takes advantage of existing RF signals so it does not require the deployment of a special-purpose power infrastructure—like an RFID reader—to transmit a high-power (1W) signal to nearby devices 

• Second, and related, it has a very small environmental footprint because no additional energy is consumed beyond that which is already in the air.

• Finally, ambient backscatter provides device-to-device communication. This is unlike traditional RFID systems in which tags must talk exclusively to an RFID reader and are unable to even sense the transmissions of other nearby tags

References: 

http://www.theengineer.co.uk/channels/design-engineering/news/ambient-backscatter-promises-battery-free-communications/1016925.article 

Why are some of the MCS combinations invalid in 11ac?

11ac boosts the WLAN rates tremendously in to the gigabit range, but it also introduces a slight problematic area which is not really focused in 11n (because its not much of a problem) "the no of BCC encoders."

In 802.11 there are 2 types of convolutional codes (FEC) defined,

 

• BCC (binary convolutional code)

• Encodes the data as per the coding rate, if multiple encoders are used demultiplexes the scrambled bits among NES (number of BCC encoders for the Data field) BCC encoders, in a round robin manner

• Punctures the Encoded output to achieve higher coding rate, by puncturing we mean we decrease the no of output bits (the denominator of the coding rate) there by resulting in an higher coding rate.

        

                   "Higher  rates are derived from it by employing 'puncturing.' Puncturing is a procedure for omitting some of the encoded bits in the transmitter (thus reducing the number of transmitted bits and increasing the coding rate) and inserting a dummy “zero” metric into the convolutional decoder on the receive side in place of the omitted bits. Decoding by the Viterbi algorithm is recommended."

• LDPC (low-density parity check code.)

• High performance error-correcting codes, lets us discuss these some other time.

Note: The same MCS table shall be used for both BCC and LDPC coded transmissions.

Lets take a look at both 11N and 11AC with regard to BCC encoding and MCS Rates Validity.

11N:

The rules of BCC encoder in 11N are:

1. A single BCC encoder can support up to 300 Mbps of data rate at most, after that for every 300 Mbps step we need to use an additional encoder.
2. NES values were chosen to yield an integer number of punctured blocks for each BCC encoder per OFDM symbol.
3. The number of BCC encoders is not limited

So if we observe the MCS's 21, 22, 23 they all use 2 BCC encoders as the Tx Rate is > 300 Mbps. When using multiple BCC encoders the encoder parser demultiplexes the scrambled bits among NES (number of BCC encoders for the Data field) BCC encoders, in a round robin manner. 

Process of Convolutional Coding: Multiple BCC Encoders

So the total number of bits must be multiple of no of encoders, else there will be some extra bits left at the end of the distribution.

For Eg: In case of 

optional 40 MHz, NSS = 3, EQM

MCS 21: 64QAM-2/3-1944-1296-2 Encoders

The total number of coded bits 1944 are split across   648 blocks of BCC encoders with 3 bit length, each block yields 2 bits resulting in 1296 Data bits/sub carrier.

11AC:

The rules for BCC encoder in 11AC are:

1. The maximum data rate per BCC encoder is 600Mbps
2. The number of BCC encoders for a particular combination of MCS, Nsts and BW is determined by the short GI data rate and the same number of encoders are used for the corresponding normal GI rate
3. The number of BCC encoders is not limited
4. NES values were chosen to yield an integer number of punctured blocks for each BCC encoder per OFDM symbol.

As shown in the 11N example, lets take the case of 

mandatory 20 MHz, NSS = 1, 

MCS-8: 256QAM-3/4-416-312

Here the total no of coded bits 416 should be split across 104 blocks BCC encoders with 4 bit length each block yielding 3 data bits resulting in 312 data bits/sub carrier.

MCS-9: 256QAM-5/6-416-??

Here the total no of coded bits 416 cannot be split across a interger number of encoders violating the above rule #4, hence this MCS combination is invalid.

mandatory 20 MHz, NSS = 3, 

MCS-9: 256QAM-5/6-1248-1040

1248/6 = 208 Blocks of 6 bits each yielding 5 bits output resulting in 1040 data bits, which is valid.

Similarly we can do for other MCS holes (Missing MCS rates which are thrown because they are considered invalid).

Conclusion:

So if we convert the above example in to a mathematical forumala...it sumps as below

The reminder of the division of Total no of coded bits/denominator of coding rate (the length of each convolutional code block) should be 0.

         "For BCC encoding, some of the MCS-N_SS combinations are excluded from the MCS table to avoid additional padding symbols. Allowed MCSs are selected such that the number of coded bits in each OFDM symbol contains an integer number of punctured blocks from all encoders, i.e., mathematically every allowed MCS-N_SS satisfies:"

Condition for a MCS to be valid: For definitions refer the IEEE spec

References:

1) IEEE 802.11ac-draft 5.0

2) IEEE 802.11-2012

3) 802.11ac: Survival Guide

4) IEEE Discussions-11ac spec

5) IEEE Discussion-11ac-MCS Holes

802.11 AC Primer: Whats all the fuzz about?

802.11ac is the upcoming big standard with tremendous increase in the data rates and throughput if properly utilized. Lets take a Brief/Raw look at the all the new features and how they help to achieve greater data rates and spectrum utilization.

PHY Features

• 256 QAM

• Very high order modulation scheme which increases the spectral efficiency only when used with beamforming technology, as high order modulation schemes are susceptible to noise and interference.

• Compared to 11n 64QAM, spectrum efficiency improves by 33% 

• Require about 30dB increase in SNR and coverage area is reduced (beam forming can solve this)

• Sub-carriers
• The maximum subcarriers that can be used with OFDM in WLAN is 64/20MHz, as of now 11ac uses this limit most efficiently, the next standard will run out the this limit, its time to increase it to 128/20MHz #IEEE :-)
• 11a/11g ==> 52
• 11n        ==> 57
• 11ac      ==> ~59
• 80 MHz

• 160MHz

• 80+80 MHz

• Single continuous 160MHz and 2 discrete 80MHz can also be combined as 160MHz channel, increases the throuhgput but not the spctral efficiency.

• 8 Spatial Streams

• Sounds high, yeah for a single user it doesn't make sense, but with Multi User MIMO we can exploit this to increase the overall spectrum efficiency.

• MU-MIMO

• Instead of using all the Antennae for a single user (Even though some of them are not really used for some MCSes) we can use each antenna for a single user (max up to 4) and serve all of them in parallel.  This poses few issues like how do we identify each STA? What about group frames? How can a STA for which the data is not destined can ignore the frames? 

• The answer to these questions is the additional features introduced in MAC as explained below. 

• AES-256

• GMAC and GCMP

• Present in 11n in most of the enterprise AP's, now its official along with few other extra algorithms.

MAC Features

PHY ID's (Included in the VHT SIG field) 

Basic motivation is determine if the packet is not destined for you at the earliest possible stage (PHY instead of MAC) and go to micro sleep. (Most likely the case when MU-MIMO is in use)

GroupID

"An AP determines the possible combinations of STAs that can be addressed by an MU PPDU by assigning
STAs to groups and to specific user positions within those groups. (through a new GroupID management Frame).
So after decoding the TXVECTOR the STA can decided whether the frame is for itself (or) not."

Note: Group ID 0 is reserved for transmissions to AP and Group ID 63 is reserved for downlink SU transmissions

Partial AID: The partial AID is a non-unique identifier of a STA and is 9 bits conveyed in the TXVECTOR To identify whther the transmissions are destined to a STA/not, used in conjunction with GroupID.

PHY Power-saving with PHY ID's

TXOP Sharing 

In the TXOP won for a particular AC, we can also send frames destined for others AC's to other STA's as well.

"This mode only applies to an AP that supports DL-MU-MIMO. 

The AC associated with the EDCAF that gains an EDCA TXOP becomes the primary AC. TXOP sharing is allowed when primary AC traffic is transmitted in a VHT MU PPDU and resources permit traffic from secondary ACs to be included, targeting up to four STAs."

TXOP power save

Sounds weird but is a good feature. Basically in a TXOP for MU-MIMO, if the frame is not destined for the STA it can doze off for that TXOP duration.

"If the AP allows non-AP VHT STAs to enter Doze state during a TXOP, then a non-AP VHT STA that is in VHT TXOP power save mode may enter the Doze state till the end of that TXOP when one of the following

conditions is met:

— On receipt of a VHT MU PPDU, the STA determines that it is not a member of the group indicated by the RXVECTOR parameter GROUP_ID. 

— On receipt of an SU PPDU, the STA determines that the RXVECTOR parameter PARTIAL_AID is neither equal to 0 nor does it match the STA’s partial AID. 

— The STA finds that the PARTIAL_AID in the RXVECTOR matches its partial AID but the RA in the MAC header of the corresponding frame that is received correctly does not match the MAC address of the STA."

 References:

1. IEEE Discussions: Spectrum Efficiency 
2. IEEE Discussion: PHY Powersave
3. 802.11ac-draft 5.0

Where is static variable used? A live Example

Till Date this was the question asked in many 'C' programming interviews asking for a live case of static variable, have come across a few cases but nothing was a solid one. Recently while going through spinlock code came across this function used in lockdep which has a solid example of static variable usage.

First, a little background on the context of lockdep and on below function. Lockdep is a lock monitoring utility in the kernel (an userspace version exists too) which keep tracks of all the locks allocated and order in which they are taken and throw necesary warnings if things are wrong.

Refer Introduction to LOCKDEP for details.

Now how do we track these numerous locks in the kernel, we wont. We only track the lock initialization per data structure, any number of the locks taken on the data structure doesnt matter unless we track one remaining show same behavior. With that we need to have a unique ID to identify a lock/data structure

a) If the lock is allocated statically (stack), then we use the address of the lock as the Unique ID (UID)

b) If the lock is allocated dynamically (heap), then we cant use the address as there will be too many addresses

So here's where the "static" comes in, in every lock init we use a "static" variable (its address a UID) so that across the initialization of the same structure the address remains the same.

       # define spin_lock_init(lock) \ 

       do { \ 

           static struct lockdep_type_key __key; \ 

           __spin_lock_init((lock), #lock, &__key); \ 

       } while (0)

Hmm, beauty isn't it. Finally a live use case for static variable, at least which i know :-)

Testing 802.11 Protected Management Frames(PMF or MFP or Robust Management) Feature: wlantest frame injection

Protected Management frames is an important security addition to wlan which can protect from different attacks such as connection termination by a 3rd party, management frame attacks.

PMF or MFP or robust management frames as its called came to popularity with recent addition to the latest 11n certification from WFA, this became a mandatory feature.

To test this feature thoroughly we need a management frame injector which can inject different kinds of frames protected, unprotected etc.
Lets take a look at the tool available as a part of the hostap.git wlantest which served this purpose, its a tricky tool and is less documented and used. Lets do some reverse engineering and find out the exact commands needed to inject packets. All text is taken from code as is.

Fetching and Compiling the Tool

1. git clone git://w1.fi/srv/git/hostap.git
2. cd wlantest
3. make

Starting the Tool:

wlantest -cq -i <interface> -p <passphrase>

c ==> control interface, needed for wlantest_cli

q ==> Decrease debug level

d ==> Increase debug level

i ==> Interface Must be in monitor mode to inject frame, this is done using the libpcap and radiotap header based on which the mac80211 handles the frame.

For normal operation we need wlan0, so to inject create another interface (use iw interface add) in monitor mode.

Leave the window as is or fork it background. This should be running throughout the test.

Note: The tool should be started before running any tests to capture the 4-way handshake to retrieve the transient keys.

 Form a connection: Connect the STA to the AP, this is crucial as the wlantest registers for EAPOL packets and extracts the security association from them given the passphrase, only then it can do the encryption.

Injection:

start the wlantest_cli, it will automatically connect to the wlantest is already running with control interface enabled.
Once we are in the prompt of wlantest_cli we can use the below commands to send different kinds of packets.

inject <frame> <prot> <sender> <BSSID> <STA/ff:ff:ff:ff:ff:ff>

frame: Frame Type

        { "auth", WLANTEST_FRAME_AUTH },
        { "assocreq", WLANTEST_FRAME_ASSOCREQ },
        { "reassocreq", WLANTEST_FRAME_REASSOCREQ },
        { "deauth", WLANTEST_FRAME_DEAUTH },
        { "disassoc", WLANTEST_FRAME_DISASSOC },
        { "saqueryreq", WLANTEST_FRAME_SAQUERYREQ }

As per the PMF WFA test plan we need to inject only disassoc, deauth, saqueryreq.

prot: Protection
         Normal ==> Depending on the security type the packet is sent as protected/unprotected.
         Protected ==> Send Encrypted
         Unprotected ==> Skip the Encryption.
         Incorrect ==> Packet sent with wrong key.

Sender: AP/STA (case insensitive)

BSSID: AP's MAC Address

STA/FF: In case of unicast frame injection use the STA address (or) when using broadcast frame injection (BIP) use the broadcast address.

Examples: 

inject disassoc incorrect AP BSSID STA

inject disassoc incorrect AP BSSID ff:ff:ff:ff:ff:ff

inject deauth unprotected AP BSSID STA

In case of any issues increase the logging level with multiple dd's.

Happy Injecting ;-)

Updated: Fix the meaning of "q" and "d" and some cleanup.

Roadmap of wifi: For coming years...

Is wifi saturated? whats coming up in wifi world?
Lately, i have been hearing this question a lot and decided to find an answer.

I believe that the field of wifi is very busy in the coming years, technology wise not so much change, the basic protocol remains same and so are the basic rules, but its more user-centric now and more real world scenario based. Lets take a look at the things coming up and soon in wifi

Lets divide the upcoming things in wifi in to technology based and user based.This time less text and more crisp no detailed technical analysis :-) , because most of these things have a roadmap of around 2015-2016, many of the TG's are in the nascent state.

Technology Centric: IEEE			User Centric: WFA
802.11 ac	PHY Changes	256 QAM, MU-MIMO, Beamforming, BW signalling,	Wifi Miracast	On top of P2P based Sharing ending Video and Audio over wifi, eg: project your video from laptop to TV
802.11aq	MAC Changes	Low Power Pre-association discovery	Neighbour aware networking	On top of P2P with Low power pre-association discovery and Information sharing, Get a pop up if the information matches then proceed through normal connection (P2P/AP)
802.11ah	PHY Changes	sub 1GHz < 1GHz (excluding TV) spectrum and 1,2,4,8,16 MHz bandwidths, over 1KM distances and 300 Kbps Low Power Large STA association Improvised legacy Powersave	Wifi Docking	P2P based Connecting Multiple peripheral using wifi
802.11ad	PHY Changes	Gigabit Wifi, 60 GHz Unlicensed	WNM Powersave	Max Idle Periods, Proxy ARP, WoW, Convert Multicast to Unicast (Direct/Flexible)
802.11af	PHY Changes	Wifi TV: SUB 1GHz TV band Optional AC for spectrum sense	Wifi Smart Grid	Smart Energy Profiles 2.0 compatible with non-wifi as well eg. Zigbee.
802.11ae	MAC Changes	Prioritization of Management frames
802.11ai	MAC Changes	Fast initial link setup: < 100ms data connection Lesser Management Frames

In short, we have got all the three tracks covered IEEE is working on huge

                     Major PHY changes : 

• Spectrum     : 3.7GHz, sub 1GHz, 60GHz
• Bandwidth   : 1, 2,4,8 and 16 MHz
• Low power   : Energey Efficient
• FSN OFDM : 64 subcarriers (Fixed Subcarrier Number)

                    Minor MAC changes 

• All advanced WFA programs are P2P based.
• Fast Discovery
• Fast Connection, 
• Efficient and Long powersave, 
• QoS for Management,

where as WFA is working on IOT and End-User scenarios and applications.

So for coming 5 years i would say wifi has lots of work to do. Especially the standard 802.11ah and ad are very popular among engineers and companies and are highest attended TG's.

Any more new ideas/use cases for wifi ? Please share your opinion.

802.11 WMM Priorities: UP/TID/802.1D Demystified.

WMM introduces the concept of priority in to wlan, but to implement the priority it uses a complex terminology like UP (User Priority), TID (Traffic ID)  and  802.1D priority. 

All seem to represent the same "priority" and convey the same information, but then why do we need the three different terms. This confuses many, especially in TSPEC/TCLAS we see TID and UP both in the same frame leading to more confusion. Lets take a quick glance at what they mean and when should we use each of them.

We know that priority in WLAN is tightly coupled with the priority set by the application in the upper layers, so first we need to understand the LLC and MAC interface i.e., MAC SAP.

MA-UNITDATA.request is the primitive used to send any MSDU's to MAC by LLC, in this request the params used are

• source address,
• destination address,
• routing information,
• data,
• priority,
• service class

Here Priority can be an integer from 0-15 (or) non-integer of "contention"/"contention-free".

TX SIDE:

Integer Priority: 

Values:
             0-7 for QOS STA's in an QOS IBSS
             0-15 for QOS STA's in an QOS BSS

The priority directly maps to TID field identify the particular traffic stream from LLC. TID is not priority, its just an ID through which the actual priority is derived....

if (0 <= TID <8)
       UP=TID
else if (8<= TID <=15)
     if (TSPEC defined)
              UP= TID from TSPEC/TCLAS
    else
             UP = 0

Non-Integer Priority:

• At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to MSDUs with TID 0
• and those with a priority of ContentionFree are delivered using the contention-free delivery if a point coordinator (PC) is present in the AP. 
• If a PC is not present, MSDUs with a priority of ContentionFree shall be delivered using an UP of 0

• At STAs associated in a non-QoS BSS, all MSDUs with an integer priority are considered equivalent to MSDUs with a priority of Contention.

RX SIDE:

If a STA is associated in a QoS BSS, the MSDUs it receives in QoS data frames are reported with the TID
value contained in the MAC header of that frame.

 The MSDUs such a STA receives in non-QoS data frames
are reported to LLC with a priority of Contention, if they are received during the CP, 

or ContentionFree, if they are received during the CFP.

Summary:

TID: 4 bits ID Used in

        QOS CTRL Header

               EDCA: same as UP (0-7)

               HCCA: TSID (8-15)

        TSPEC/TCLAS

UP: 3 bits Priority

        TSPEC/TCLAS

802.1D: 3 bits
          Used Internally similar to UP, taken from the bridging standard.

Decrypting 802.11 packets: Secured 802.11 Environment

While testing secured 802.11 networks we face with a common problem of analyzing the data of the WLAN frames  using a sniffer, as they are encrypted.  Especially if you want to debug some higher layer protocol issues (DHCP, ICMP, ARP etc). 

We have some options to overcome this issue, either using a sniffer (or) using a console (in case of Linux), lets take a quick look at them.

For an End-user/Production Environment:

Most of the wireless capturing tools have support for decryption of the WLAN packets taking the credentials from the user.

Omnipeek: 

In "Tools>Decrypt WLAN packets" we can enter the credentials for each type of security and omnipeek will try to decode all encrypted packets in the trace.

Omnipeek WLAN Decryption Procedure Screenshot

Wireshark:  

In the "Preferences>Protcols>IEEE 802.11" there is an option to enter the Decryption Keys and also to enabled the decryption.

For both the tools, We can enter WEP-Key/WPA-Passphrase/WPA-PSK in the below formats:

   "Key examples:

     01:02:03:04:05 (40/64-bit WEP)    010203040506070809101111213 (104/128-bit WEP)    WPA/WPA2-PSK: Use this calcualtor and paste the psk. 

Wireshark WLAN Decryption Procedure Screenshot

But these decryption techniques are not reliable (especially omnipeek :-) and we need to have that costly license as well)  and can only be useful for post-processing of the packets. Live capture any one??

For a Engineering/Development Environment:

Instead if we have access to the console of the device (of course which runs Linux :-)), we can make use of tcpdump. It should be there in all android phones (at least the ones i have tested have it).

tcpdump:

tcpdump is the back end of wireshark it provides almost all main features of the wireshark. Dont go by the name, it not only supports TCP capturing but all protocols captures supported by wireshark.  As we know that the 802.11 encryption "mostly" (Except if you are using software encryption for some testing/initial development purposes) happens in the HW and tcpdump collects the packet before that all the packets can be seen in plain text even though encryption is enabled. 

For a quick check its good to prefer this, its my favorite way to debug the connection issues/traffic issues/DHCP issues in a secured 802.11 environment.

Usage for an Android Phone/Any Linux Device would be:

tcpdump -i <interface> -s 0 -w <Location to save the capture file, make sure it is writable> 

See tcpdump-man page for details on options.

Eg: 

1. tcpdump -i wlan0 -s 0 -w /data/test.pcap
2. adb pull /data/test.pcap .
3. open the pulled pcap file using wireshark and analyze.*

Note: By default tcpdump captures only 96 bytes of every packet, "-s 0" will set the limit 64K (practically the whole packet)

* If you are an omnipeek maniac  and have a omnipeek Pro and want to analyze these tcpdump captures using omnipeek, there's a new plugin called "Remote TCPDump Adapter Enterprise" where in through SSH it captures the packets using tcpdump but displays in the omnipeek in windows.

Happy Sniffing and Debugging.

Revisions:

1) Thanks to sunil pamula for finding the improper command for PSK keys. Its updated now. 8/11/2013.