9.1Introduction

This chapter is mostly dealing with Wi-Fi, and secondly with Bluetooth. Before diving into these, we will look at the overall picture. You can structure the huge selection of wireless networks in many ways. In approximate descending order of link-distance:

Table 9.1 is a rough comparison of a broad selection of networks. The values stated must be taken with a grain of salt. A parameter such as the “Free Range” is typically exaggerated, and if it is possible to communicate anything at this range it will typically be at a very low rate.

Table 9.1: A selection of wireless networks.

*via 6WLoPan

**It really is mW

9.2Wi-Fi basics

There are many wireless technologies. Of these, some are WLAN, and of these, most are IEEE 802.11 based. The Wi-Fi Alliance has registered “Wi-Fi” as a trademark for IEEE 802.11-based products. This chapter is about Wi-Fi.

Many of the Wireshark captures in Chapter 7 were actually done on a PC connected to a Wi-Fi SOHO router. This is transparent when using Wireshark alone. However, if you buy the device “AirPcap” from Riverbed, you can get a lot more insight.

A normal setup is running in infrastructure mode, where a wireless router is known as the AP (access point). All iPads, phones, PCs, and IoT devices on Wi-Fi, are known as STAs (stations). They all transmit on the same shared channel which means that only one AP or STA at a time can transmit. The whole interworking setup is a basic service set and similar systems nearby, that can interfere, are known as overlapping basic service sets.

The BSSID identifies the AP, and is the MAC address of the radio. The SSID (service set ID) identifies the WLAN and may be present on many APs. When an AP handles several SSIDs, each has a BSSID. Thus an AP is assigned as many MAC addresses as the number of SSIDs it can serve. All these terms are collected in Table 9.2.

Table 9.2: Parameters on application layer protocols.

In the 2.4 GHz band, there are 11 channels (more in some countries), but they overlap. If interference is to be avoided, you can have separate basic service sets on channels 1, 6, and 11 at the same time. Wi-Fi is defined by IEEE 802.11, with the postfixed letters being very important. The first really used standard was 802.11b, then for some years 802.11g, and currently 802.11n and 802.11ac are where the action is, both including the 5 GHz band. If you have 802.11b equipment, you should get rid of it. It monopolizes the airtime as we shall see.

9.3The access point as a repeater

The most common use of an access point is access to the internet; hence the name. SOHO (small office/home office) routers have a single wired connection to the internet, often marked WAN (wide area network), while offering local connection via Wi-Fi to a number of devices. Typically, these routers also have a small number of wired Ethernet ports, working like a switch connected to a 2-port router. This was shown earlier in Figure 7.2.

The users of iPads, phones, or PCs rarely see a need to interconnect these devices, they just need access to the internet. However, in a home or office you often need to connect to a printer or a NAS disk with movies or backups, and music systems like Sonos. The optimal way to connect these devices is via the wired Ethernet ports in the router, but this is not always possible. There is also a growing need to connect STAs like an iPad to wireless IoT devices like air quality measurement, heating, lights, etc. Such devices are also STAs. Thus STAs need to communicate with each other.

In the following, we will study the scenario where the AP (router) helps the STAs (devices) to communicate with each other. This gives a good background for understanding the possibilities and limitations in the Wi-Fi technology. The connection from a single wireless STA to the internet is basically a subset of this scenario.

When we have an access point, we operate in infrastructure mode—the normal way to use Wi-Fi. On a wired network, nodes can communicate directly or through a switch—using unicasts, multicasts, or broadcasts. In a standard Wi-Fi infrastructure system, however, all communication must use the access point as a stepping stone. You may think: access point or switch—what’s the difference? There are two major differences:

We will now look at the multicast scenario, using Wireshark with “AirCap,” a device that catches wireless traffic and gives information about the 802.11 frames as we shall see.

A STA “wants” to send a multicast frame to all other STAs in the basic service set. It does this by sending a message to the AP, which the AP then multicasts to all STAs; see Figure 9.1.

When one STA is sending anything, it is by definition to the AP, and the other STAs go into sleep mode, for the duration of the transmission, to save power. To help with this, there is generally information in all frames about the expected duration—we will see more of this in Section 9.9. Frame 2419 in Figure 9.1 is from the STA to the AP, while frame 2421 is the same data from the AP to all STAs. When setting up AirPcap, PPI (per-packet-information) was chosen which we see in the dissections of the two frames in Figures 9.2 and 9.3.

Analyzing the two dissected frames tells us the following:

Whereas a wired Ethernet frame only has a source and destination MAC address, the wireless Ethernet has room for four MAC addresses and “to DS” and “from DS” bits. Luckily, Wireshark interprets this for us—see Table 9.3.

In other words, Wireshark helps us keep the original “source” and “destination” terms, and is using “receiver” and “transmitter” for the participants on the radio level.

Table 9.3: Wireshark terms for Wi-Fi nodes.

9.4How is speed calculated?

In Section 9.3, we saw different speeds listed by Wireshark. But how are these obtained? This is a very advanced subject—we will focus on the main parameters:

If we have an MCS index of 7, a long guard interval and a 20 MHz channel, the data rate can be calculated as in Table 9.4.

Table 9.4: Wi-Fi data rate calculation.

A short guard will cut of 0.4 μs of the 4 μs, increasing the speed by 11 %. You can find tables of MCS indexes at Wikipedia and other places. These are built into Wireshark.

This speed is the maximum theoretical speed without retransmissions and without time-sharing the channel with other devices.

9.5Case: Wi-Fi data transmission

Figure 9.4 shows a scenario with a data-producing device,44 wired to a small Asus router.

Via this, data is transmitted to a “pre-Air” iPad. The recording is made with AirPcap, using the PPI header from the 802.11 layer. A fantastic feature in Wireshark is that when you “open up” the dissector, you can right-click on an interesting value and select “Show as Column.” In Figure 9.4, this has been done with all the columns shown between “protocol” and “info”: Data Rate, Duration (μs), MCS Index, RSSI, and RTT.

Let’s walk through the case:

Figure 9.5 shows another tool applied—Chanalyzer with Wi-Spy from MetaGeek. We are measuring on channel 6, on the SSID called BK3660A-100039.

The information about the Wi-Fi SSIDs in the bottom table comes from the PCs wireless NIC. Based on this info, the tool draws a “profile” of a given network, the dotted line, over the actual measurement.

Apart from looking very fancy, this is actually a nice tool. We can see a lot of stuff on Wireshark, but it is all above the physical layer. You may have problems with connections that only show in Wireshark as retransmissions. Noise on the physical level from, for example, a microwave oven, a wireless mouse, or an infrared movement detector, may interfere. This can be seen with a tool such as Wi-Spy. The tool includes “standard signatures” of known noise sources. This may help find the culprit.

9.6Case: beacons

We are not completely done with the transmission in the previous section. It is interesting to know why we ended up with MCS index 7, and why only 20 MHz Bandwidth, as the Asus AP should be able to support channel bonding where two 20 MHz channels are joined into one 40 MHz channel. Even in 20 MHz mode we should be able to get 72 Mbps according to Figure 9.5.

Access points are periodically (typically every 100 ms) emitting so-called beacons. These are broadcasts sent on a slow and robust data rate. This ensures that they are seen by all STAs in the vicinity, even older types. An important part of this broadcast is the SSID. This allows you to choose between networks. The AP also transmits a lot of information on its capabilities. Figure 9.6 shows the beacon from the Asus AP.

The “HT Capabilities Info” is the relevant section here; “HT” for “high throughput,” which is related to the 802.11n standard. The figure shows that the Asus AP says that it only supports 20 MHz operation, but why does it then claim support for “Short Guard” on 40 Mhz? It turns out that it actually can do the 40 MHz operation, but in this session this feature was disabled in its setup.

STAs may do probe requests where they advertise their capabilities. Not a single probe request was caught in this recording. A STA may run in passive mode where it does not emit probe requests, but simply connect to the AP with a common denominator of the two parties capabilities.

The iPad used at the time did not support neither 40 MHz channels or “short guard,” so the resulting traffic ends with a single 20 MHz channel and long guard, giving us an MCS index of 7 and from this the 65 Mbps speed. AirPcap does not support the short guard interval either. If both devices had supported the short guard interval, we would not have been able to follow the transmissions. In order to debug anyway, we would simply disable short guard on one of the devices. Figure 9.7 shows the probe request from a similar unconnected iPad. Beacons and probes are also used when deciding which encryption to use; see Section 10.15.

9.7Case: a strange lagging

The setup we have studied for some time, was working fine. On the GUI, there were “moving curves” and no loss of data. However, once in a while there was a short “hesitation.” Timing it, it appeared to be every 5 minutes. Picking “Statistics” in Wireshark, then “I/O-graph” on a longer capture, Figure 9.8 was created.

The top jagged line at almost 20M bit/s (y-axis is on the right of this, not easy to read) is data in the direction where data flows. The more steady line just below, is the segment length in bytes, which is not so relevant in this discussion (y-axis to the left). It is clear that something does happen almost exactly 5 minutes after starting the traffic and the Wireshark caption, as the hard-to-read neighboring main grid lines are at 280 s and 320 s. The area of the “dive” matches the area of the peak shortly after, meaning that the transmission catches up, and no data is lost. However, the dive verifies the “hesitation” experienced in the application. Making the similar graph on RTT (round-trip time) in Figure 9.9 verified the lagging.

Here, the RTT goes from less than 60 ms to 360 ms for a short duration. The x-axis here is hard to read, but the closest main grid line says 700,000,000 Bytes. With a steady traffic at just below 20 Mbps, this grid line, shortly before the peak, is at a little more than (700,000,000 Bytes ∗ 8 bits/Byte)/20 Mbps = 280 s.

Browsing the standards, it became clear that according to 802.11n all STAs are required to scan all Wi-Fi channels every 300 seconds, and report their findings back to the AP. The AP collects this information and spreads it to all STAs so that they can update their “Navigation Vector.” This assists in the handling of hidden terminals. Knowing what to look for now, Figure 9.10 was produced.

The figure shows a Wireshark display filter on the “power management” bit (showing up as “P” in the info field) and the relevant BSSID (the MAC address of the AP). Every 300 seconds the iPad takes 13 small “power naps.” Technically, the 2.4 GHz band has 14 channels (not all legal everywhere), and when the iPad is listening to one of these it needs to scan the 13 others every 300 s.

These power naps can effect any application. In this scenario, where data is continuously streamed, we see it clearly on the screen as a hesitation. Had we used a higher data rate we would have lost data. In more normal scenarios, it means that the maximum latency is longer than what a simple measurement suggests.

9.8Aggregated frames

As smarter types of coding were developed, it became clear that the outstanding problem was the overhead involved with each frame. The usual solution when you have a lot of overhead per something, is to bundle and share the overhead. This is exactly what is done. This is called aggregation and in Section 9.5 we saw “aggregated frames.”

The thing that is aggregated is PDU (protocol data units). A PDU is loosely stated the “packet” at any level. As stated earlier the correct term for a PDU in Ethernet is a “Frame,” while in IP it is a “Packet” and in TCP the PDU is a “Segment.” At the application level, the PDU is a “Message” or simply “data.” An MPDU is a MAC PDU, in other words the packet as seen going in and out of the MAC. Confusingly, there are two different types:

We will focus here on the first which we saw used in Section 9.5. In a later test with similar hardware as before, but this time using OpenWRT firmware loaded into the same type of Asus router, a capture was done—see Figure 9.11—which is the case for this and the next section. OpenWRT is described in Section 6.10.

Figure 9.11 shows the following:

9.9Channel assessment

We have seen the use of request-to-send and clear-to-send several times. The terms are ancient, dating back to at least RS-232, but the technology behind RTS/CTS in modern Wi-Fi is much more sophisticated. 802.11n does not need these if it is alone in the world (greenfield), but the modern variant has proven very robust; see Figure 9.12.

The RTS is sent by the STA transmitter-to-be, to the AP after a period of silence in the air called DIFS (distributed interframe space). Should this collide with a similar transmission from another STA, or the AP, it will abort and retry a semi-random delay later. This is just like classic Ethernet coax, where we also had a shared medium.

The RTS contains the expected transmission time, and the address of the receiver. This allows third parties to adjust their NAV (network allocation vector) and sleep until the expected end of the final ACK. The CTS serves a similar purpose, but as it is sent from the AP it may reach other third parties (hidden terminal problem). Once we have a designated transmitter-receiver pair, the “dead-time” between frames can be shorter—resulting in higher transmission speed. This shorter dead-time is called SIFS (short interframe space).

A STA or AP may use a “CTS-to-self” to protect against neighbors that do not understand the 802.11n protocol.

9.10Bluetooth low energy

Some years ago a war was fought between Wi-Fi and Bluetooth about being the preferred wireless connection. One of the main reasons why Wi-Fi won the war, is that 802.11 (Wi-Fi) is built on top of the existing Ethernet protocols. This gives the connectivity needed. With the assistance of a cheap Wi-Fi router connected to an existing network, the PCs, and later the phones and tablets, could connect to any server in the world.

Since then, Wi-Fi has been all about performance, getting more and more bytes across. Naturally, power savings has also been interesting as Wi-Fi is heavily used on laptops, but when, for example, using a device like Chromecast, there is typically power at the AP as well as at the Chromecast. And here you want your high-resolution Netflix without glitches.

Meanwhile, Bluetooth found an increasing niche in the “small-device-to-phone” market. This is where you don’t really need to route to the internet, you just want the headphones or whatever, to connect to your phone. In the “small device” end of the market, Bluetooth is thus very well known, and the main focus has been on battery savings.

Now everybody is gearing up for IoT, and the war is sort of restarting. Wi-Fi is weaker than Bluetooth on the power side. This is suddenly very relevant, since IoT devices may not be connected to power as often as laptops and phones. Bluetooth Classic still really hasn’t got the connectivity, and is way behind on performance. On the other hand, Bluetooth Low Energy does have the connectivity. It is not created for long lasting peer-to-peer connections like Bluetooth Classic. It connects fast and tears down fast, much like UDP.

Table 9.5 is a comparison of Bluetooth Classic and BLE (Bluetooth Low Energy) a.k.a. Bluetooth Smart.

Table 9.5: Bluetooth Classic versus BLE.

The data rates in Bluetooth Low Energy are governed by which mode is chosen. The first version of BLE had very short frames—39 Bytes—but in the extended version in the 4.2 standard, frames can be up to 257 bytes. This explains why the theoretical max rate is given as two numbers in Table 9.5. The broadcast concept is new with BLE. Apple has an iBeacon concept which only broadcasts, and never does anything else. This is to be used in, for example, a department store, or a museum, where you walk around with your iPhone and catch different offers, anecdotes, or news.

Bluetooth 5 was announced very late in 2016, without the expected mesh technology, which came a little later. It boasts double speed or range (sometimes even more) due to new PHYs with more advanced coding of the symbols. It appears that the double speed can be obtained without using more energy than 4.2. Thus Bluetooth 5 may save energy.

The war between Wi-Fi and Bluetooth may be on again, but the rules have changed. The wireless IoT devices we hear about now, are supposed to run very long on batteries, only transmitting or receiving a small blurb once a minute or even less frequently. A good guess is that the Bluetooth guys have decided to avoid a direct war, and instead bet on their strongest virtue – the lower power consumption. This is why they invented Bluetooth Low Energy (BLE). BLE is enhancing what they are already good at. But what about the connectivity? IoT devices do not just want to connect to your personal phone, they want to connect to the cloud. For this reason, BLE in Bluetooth 4.2 has some added means of connectivity; see Table 9.6.

Table 9.6: Bluetooth Smart connectivity.

None of these can connect the device directly to the cloud, they all need gateway functionality, which may be in a phone or a more static, dedicated device. The GATT (see Table 9.6) solution is for BLE devices, mounted or located in a home or working place, where they are within reach of a “BLE gateway,” with a built-in HTTP server, statically connected, for example, via Wi-Fi, to the internet gateway. This allows the owner/employee to pick up his phone anywhere in the world and call up the HTTP server in the gateway. Via this, the device may check temperature, turn on heating, call up bath-weight measurements from the last month, etc. This is an existing solution.

The second solution is where a client inside the device needs to call something in the cloud. To do this, it requires a “proxy,” this time with an HTTP client, which could be the same gateway as before or a mobile phone. Surely the latter makes it more intermittent.

6LoWPAN is like a generally connected IPv6 device. Here, the device is again near a gateway. Via this it connects more transparently to the cloud, where it offloads data and gets new stored instructions. The gateway could be an application on a phone, or a static gateway. This solution is not tied up to HTTP—it could be anything using IP. If the IP address is that of the phone, then the connection is local, like Bluetooth Classic. The connectivity, once configured, is thus better than the other solutions, 6LoWPAN needs the GATT part for the original discovery and setup phase. At the time of this writing, iPhone does not support 6LoWPAN.

It is probably due to the new connectivity addendum that BLE is now being marketed as Bluetooth SMART. It sort-of turns Bluetooth Classic into Bluetooth DUMB, but it is already out there. There is still plenty of room for Bluetooth Classic, as it delivers a much higher bandwidth than the SMART does.

9.11Certification

The 2.4 GHz band is used all over the world for unlicensed radio traffic such as Wi-Fi and Bluetooth. The fact that this band is unlicensed, does not mean that it is unregulated. If a device is to be used in a given country, it must be certified for this country. With a single certification from the FCC45 the US is open, along with a number of smaller countries that accept an FCC certification. There is a similar certification allowing usage in the EU countries. In the US and EU, a “DoC” (document of compliance) can be filled out by the manufacturer and submitted to the authorities. In this document, the manufacturer states the compliance of the product to the relevant standards, backed up by documentation. China, Brazil, and a few other countries demand an “in-country” certification—meaning that the measurement has to be performed by government appointed test-facilities inside the country.

Since June 13, 2017, the “Radio Equipment Directive”—(RED)—is enforced in the EU. All equipment marketed after this date must abide to the RED. The major new thing in RED, compared to the old rules, is that not only transmitters, but also receivers are regulated. As we have seen in this chapter: if a transmitter experiences too many transmission errors, it will select a more robust modulation type and lower the transmission speed. This means that a badly designed receiver will occupy the radio for a longer time.

The RED requires efficiency on both parties in order to get the overall best utilization of our shared medium. In an effort to make life simpler, the RED not only regulates the wireless performance but also takes the place of the EMC directive and the low-voltage directive, whenever there is a radio involved.46 As other directives, RED only speaks in plain language about requirements, and defers all the technical stuff to a “Harmonised Standard” called “ETSI 300 328.” This standard specifies the actual conformance tests (and results) needed to obtain a certificate. It has two main parts, one for frequency hopping (Bluetooth), and one for static channels (Wi-Fi and, e. g., Zigbee). The actual EU certification is a question of filling out the Document of Compliance, submitted together with documentation for the various measurements. In theory, you can perform these measurements yourself, if you have the lab, but most companies will use a commercial lab for these measurements.

In the US, the major sections are FCC § 15.247 for 2.4 GHz and FCC § 15.407 for 5 GHz. The latter contains some rules on DFS (dynamic frequency selection) in order to avoid interference with weather radar. The FCC rules do not yet mention receiver efficiency. In the EU as well as the US, a so-called “SAR” testing is needed if the device is hand-held, or otherwise in close contact with human bodies.

If the device is based on a “precertified” wireless module, life becomes a lot easier. This module has been tested and documented on all digital and protocol related parameters such as, for example, SIFS and DIFS described in Section 9.9. Building the module into a box and adding an antenna does not change these specs. However, it is necessary to measure emission and input sensitivity.

Modern Wi-Fi also uses 5 GHz, and this is where things get complicated. Some countries, for example, China, does not allow for the use of 5 GHz. The European RED refers to “ETSI 301 893” for 5 GHz equipment.

9.12Further reading