Networking: Focus on Wi-Fi
This lesson / web-page is extension work – all you need to know about Wi-Fi to pass your GCSE in Computer Science is more than covered in Lesson 4 of Networking.
This is a “deep dive” into Wi-Fi to enrich your STEM education, give you some context and a look at the wider world of this topic, and maybe even pique your interest enough to take this topic further through studying Engineering at college and university.
Revision & recap: In Term 5, specifically lesson 4, we looked at different transmission media, one of which being Wi-Fi / IEEE802.11 – if you can’t remember it, go back and refresh your memory. There’s a BBC Bitesize page specifically for our (OCR) syllabus on Wi-Fi too.
Believe it or not, there was a time before we had the Internet, let alone broadband and Wi-Fi. Some people are even old enough to remember those dark times…
An important thing to remember with Wi-Fi is that it does not just mean “the Internet”. Wi-Fi is just a replacement for an Ethernet cable: it connects you to a LAN. You only get to the Internet and the WWW is because of all the other equipment in the network (routers etc.), just like with a wired desktop PC.
This extended lesson is in two parts: a whistle-stop tour of how Wi-Fi works in general (albeit from a Medium Access Control, MAC, perspective), then a history lesson of the development of Wi-Fi.
How Wi-Fi Works
Quick Task: What do you think are the different parts of a Wi-Fi system? What things would you need to buy if you were setting one up from scratch? Once you’ve had a think about it, compare what you came up with with the information in the next section.
Main Parts of a Wi-Fi System
In the diagram above, on the right, are what Wi-Fi calls “stations” (STA for short) – that’s just a general term for any client device (laptop, PC, tablet, phone). In the middle of the diagram is the Wi-Fi Access Point (AP) – that (usually white) box on the wall or ceiling, sometimes with antennas sticking out of it.
The AP is just like a STA as far as the radio functionality goes, but then also has Ethernet ports to connect to your LAN, and usually some router functionality and so on. Wi-Fi only cares about the blue area in the diagram above – getting data from AP to STA and from STA to AP over radio waves. That data could be your web-page that your browser has just requested, the email you just sent, the Snapchat picture you just posted, anything – and Wi-Fi doesn’t care, it’s all just 1s and 0s that it has to send across “the air” via radio waves.
By the way, the AP transmits an ID code that stations can see as well as a “name”, so that you know which Wi-Fi you are connecting to… and you see those names every time you search for Wi-Fi networks:
Transmitting Data with no Wires Attached
With a wired LAN (e.g. Ethernet), there is, as the name suggests, a wire. So it’s just like an electrical circuit in Science – you can apply a voltage with a power supply (transmit a signal) and measure a voltage with a voltmeter (receive a signal) at the same time, no problem.
This means that wired technologies (e.g. Ethernet) can listen while they transmit – if you can hear your signal nice and clearly, then so can everyone else in your network, and you can be pretty confident that the message got to where it was supposed to get to intact. If you hear garbled noise, then there was probably a collision – two stations transmitted at the same time. Just like when two people try to talk at once in a conversation, what you need to do is stop, and have some way of working out who is going to speak first, then you’re OK to carry on.
Wi-Fi, though, uses radio. Radio waves, and all waves, propagate (travel) according to an inverse square law (depending on environment). That just means that as a radio wave moves away from the source, it spreads out over a larger and larger area (like the rubber of a balloon getting stretched thinner and a thinner as you blow it up).
The “inverse square” bit specifically means that if you take how far you’ve moved away and square it (multiply it by itself), that’s how much weaker the signal now is. That is, if you double the distance, the radio wave is a quarter of the strength. Five times the distance and it is 1/25 (4%) of the strength; ten times the distance it is 1/100 (1%). So if you are 10m away from the Wi-Fi Access Point, the signal you are receiving is one hundred times weaker than what you would receive just 1m away from it. That’s why Wi-Fi coverage gets weaker and weaker as you move away.
Quick task: I move four (4) times further away from the AP. How much weaker is my radio signal now?
What does this mean for us? It means that a radio device needs to transmit at high power (to give the signal the best chance to get where it’s going), and also need to listen carefully for some potentially very faint signals. That is, it SHOUTS REALLY LOUDLY and has really sensitive ears. If you try to listen while you are transmitting, you will deafen yourself (overload your receiver): at best you won’t be able to understand because it’s all so shockingly loud (saturation), worst case you could damage your hearing permanently (overload and damage the delicate circuits).
So, with Wi-Fi, we can’t transmit and listen at the same time. We have to do something else to work out if our message got through, and to try to avoid collisions.
To do our best to avoid collisions, we have to have some rules so that we can compete (contend) fairly for our turn on the radio channel.
Quick Task: can you think of some rules that you could use to make sure that everyone in a meeting or a lesson gets a fair chance to say what they want to say?
How could you make sure that the most important things get said? How can you stop one person waffling on and on and wasting everyone’s time? What happens if it’s a big room and not everyone can hear everyone else?
The Rules for Transmitting
The rules* that IEEE 802.11 uses if you have some data to transmit are:
- Check that no-one else is currently transmitting – “listen before talk” (if someone is talking, then go back to sleep for a bit and try again later);
- Wait a short, fixed period of time (called “DIFS”);
- Wait an extra, random, bit of time (called the “Contention Window”);
- Check it’s all still quiet;
- GO GO GO! You can transmit your data, get talking.
* specifically, these are the Distributed Coordination Function, DCF, rules. That’s why “DIFS” starts with the letter D – it’s the DCF Inter Frame Space.
We’ll call those “The Contention Rules” so we can refer back to them later.
Hang on – why are there two waits (steps 2 and 3)?
Well, the first wait (“DIFS”) is so that everyone waits the same, polite amount of time (it wouldn’t be fair if someone waited for a shorter period, they’d always win). There’s another reason for this fixed wait period, which we’ll come to later…
The second wait (“Contention Window”) is just in case you were not the only one waiting and listening – if there were two or more of you, then as soon as that first wait period (DIFS) was up, you’d all go piling in and start transmitting – big collision, uh-oh!
Instead, everyone waits for slightly different (randomly chosen) period of time with each attempt. Maybe this time your random number was big, so someone else sneaked in; but next time, you might get the shortest random number, so you’ll win. It all evens out in the end.
Quick Task: Draw a flow chart for the The Contention Rules, using the standard flow chart syntax that we’ve used since the beginning of KS3.
Did You Hear Me?
We still need to know that our data arrived OK. There could have been another problem – someone may have started microwaving their dinner, trashing our lovely data packet; or maybe the other station’s software crashed, or it got turned off, or moved too far away and never got it all.
So, the station that received the data has to say “yes, I got it” – a short acknowledgement (ACK) message. If we don’t receive that ACK straight away, then something has gone wrong, and we need to try again.
(Extension task: The receiver station could also be expected to send a “nope, didn’t get that, come again?” message, called a “negative acknowledgement“, NAK. Why would this be of little use here? Hint: think about the different reasons why a STA would want to send a NAK and, indeed, know it even had to…)
These ACKs, therefore, are really important. If the little ACK doesn’t arrive, then we’ll assume our (big) data packet got lost, and we’ll try sending it again later, which is a waste of everyone’s time (our’s, the receiver’s, and everyone else on the Wi-Fi who can’t transmit while we’re needlessly re-sending our duplicate) – and doubly bad, because the data packet could be quite big so it takes up a lot of air-time and energy.
So, these little ACKs are high priority. If you’ve just received a data packet, then you’re now the most important person on the network – everyone else must get out of the way and let you send that ACK! But how…?
Giving Everyone a Fair Chance
In standard (DCF) Wi-Fi, there’s no boss, traffic policeman or conductor telling each STA when it’s their turn to transmit, it just works (and works pretty well!) even though every STA is making the decision to transmit or not to transmit on its own, just by listening and waiting as described above.
This works because everyone follows the same rules – even the AP, who you might think would be given some special priority seeing as it’s the device that all the traffic is going to flow through. We met some of the rules above – “The Contention Rules“.
The whole protocol (set of rules) needs to do some other things as well though – we need to make sure each ACK gets sent before anyone else sends any more data, for a start.
This is why there’s that fixed “DIFS” wait period in the second step of The Contention Rules. If we say that a station who needs to send back an ACK straight away only has to wait for a shorter period of time (lets call it the Short Inter-Frame Space, “SIFS”), then it’ll be able to jump in straight away, and when everyone else comes back to listen for the second time (step 4), they’ll see that the channel is busy and back off. That way, a STA with an ACK to send should always be able to do so, and everyone else will excuse themselves, back off politely and let it do it.
Extension: There are some other rules as well – including the brilliantly named “Truncated Binary Exponential Back Off“, which is the increasing amount of panic stations experience when they keep experiencing collisions. If an ACK doesn’t arrive when we were expecting it, then something’s going wrong on the channel – so it’s probably not the greatest idea to go diving back in head-first and start transmitting again straight away. So wait (back off) a bit (pick a random number out of, say, 32 possibilities).
(Note that we’re using random numbers again, just in case two stations end up synchronised, doing exactly the same thing each time and just keep bumping into each other!)
Then try again – if you get another collision then “whoah!” – back off for twice as long (pick another random number but from a bigger pool – say, 64 possibilities). Try again.
Another disaster? Back off twice as long again (from 128 possibilities now). And so on – 256 next.
That’s why it’s named “binary” – we’re doubling each time (like with binary search where we halve the list each time – binary can just mean there’s a factor of 2 in there) – and “exponential” because the back offs are getting much much further apart each time.
It’s “truncated” (chopped off) because eventually, after a long period of time, the algorithm does actually stop doubling before it gets too silly and just sticks with that upper value (in the original version of the algorithm, it starts at 32 and tops-out at 1024).
The reason for all of this is that, remember, there’s no boss or manager of the network, so if everything’s going pear-shaped and we can’t see why, the safest thing to do is step back and wait a bit to see if it all sorts itself out – and if everyone does that, it should all calm down quite quickly. Quick extension task: how many collisions will there have to be to get up to a back-off window of 1024?
Packets and Overheads
Imagine that you want to send a simple text message over WhatsApp or Instagram or whatever cool app you use now that I am far too old to have even heard of. The words and characters that you typed in are converted to binary (remember ASCII from Year 7 & Year 8?). If you’re sending an image, it might be encoded as a bitmap (Year 7 and Year 8 again!), which is another series of bits. Whatever your data is, it all gets passed over to the Wi-Fi software on your phone.
That Wi-Fi software is quite complex, so it’s been decomposed down into smaller modules that have different jobs, such as the the Medium Access Control (MAC) layer and the Physical (PHY) layer.
Remember that Wi-Fi is only about this one wireless hop – the first step on the journey of going all the way across the Internet to the person you are sending you data to. So, first of all, we need to translate the network address of the person you’re sending the data to, to the MAC address that we need to get to on this first hop (it’ll be the MAC address of the AP). Next we need to process the actual data.
Wi-Fi (the original version at least) has a maximum data payload of 2304 bytes. So if your data is text (remember that each character is represented by one byte / 8-bits if it’s ASCII – 16 or even 32-bits for Unicode), that’s 2304 characters including spaces and punctuation, which is about one-side of A4 of plain text (no formatting).
Pictures and (gasp!) video are much worse – that picture of a balloon up the page a bit is 74 kilobytes… that’s 32x bigger than a single Wi-Fi packet can carry. So one job that we need to do is to chop that data up, label each chunk (so that we know what order we need to put them back together in) and then send it a chunk at a time.
What else do we need to send across?
- Every station on this Wi-Fi channel / network will hear the packet that we send, so we need to make sure everyone knows who it is for. So we’ll need to include the destination MAC address (probably the AP).
- The receiver will need to know who to ACK to, so we need to include our own, source, MAC address.
- There could well be multiple Wi-Fi networks overlapping too on the same, or adjacent, radio channels (think of all of those networks listed when you scan for what Wi-Fi is available!) – so we’ll include a third address, called the BSSID, which is another MAC address specific to our network (so, to use the same network names above, anyone on “LuminiferousAether-Lounge” network can immediately ignore anything from “TheWeeFee” or “Phlogiston” networks).
- We’ll need to remember that sequence number (so that we know what order to stick the chopped-up chunks of data back together in).
- We’ll need a few more bits here and there – such as what type of packet this is (DATA, ACK, etc. – there are lots more we haven’t covered!), and duration – how long the packet will go on for (because then stations that are waiting will know how long to go to sleep for before trying to send their data), and a few more bits to help work out if this packet got damaged in transit or not (error detection).
- Oh, and don’t forget the actual data 🙂
So, before our data even gets down to the PHY layer to be converted into digital modulations of amplitude or phase constellations on the electrical currents being passed through the power amplifiers and onto the antenna (trust me, that sounds like techno-babble to me too, I’m a MAC guy…) we’ve added a load of extra bits in addition to our actual “payload”, the lump of data that we want to carry. All these extra fields (everything that isn’t blue in that diagram above) is an overhead – some extra, but very necessary, bits and bytes that we need to send as well for this all to work, but which have nothing to do with the actual data payload.
- If I buy a Wi-Fi access point in PC World, turn it on and connect my laptop to it, I will be able to access the Internet for free forever – true or false?
- What does AP stand for, and what is STA short for?
- What is the difference between an AP and a STA?
- What does a STA need to do before it can transmit on the radio channel?
- How does a STA know that a packet has been received OK by the destination? How does it know if it hasn’t been?
- What does a STA do if it realises its packet has been lost in transit?
- What is bigger – DIFS or SIFS? Why?
- Draw a diagram of an IEEE 802.11 MAC frame.
- What is an overhead in the context of Wi-Fi? Could we get rid of the overhead?
Extension: if you really want to go down this rabbit hole, I recommend Matthew Gast‘s “802.11 Wireless Networks – The Definitive Guide”, of which there is now a second edition (other bookshops are available).
The History and Development of Wi-Fi Standards
The reason that you can buy Wi-Fi equipment from lots of different manufacturers and it all works nicely together is because of standards. A standard is something that defines clearly how things work together. There are standards all around you – if you see the BSI kitemark on something, or the European CE mark, then that means that that product has been built so that it meets one or more standards. The standards could be safety ones (e.g. on children’s toys: nothing sharp can poke out, it shouldn’t catch fire, there shouldn’t be a choking hazard, etc.), or something to do with how the thing works. A simple example is the 3-pin mains plug on electrical appliances – everyone has to make them to the same standard. If they didn’t, some plugs wouldn’t fit in some sockets, some might be dangerous, and so on.
Telecommunications devices are no different: all mobile (cell) phones have to follow standards, as do broadband modems, Ethernet NICs and cables, and Wi-Fi. And there are a lot of standards!
“Wi-Fi” itself is a trademark of The Wi-Fi Alliance, a group that tests and certifies that equipment works with all other manufacturers’ equipment. The word “Wi-Fi” was coined to be a bit like “Hi-Fi” (High Fidelity stereo sound equipment), and has been retconned to be short for “Wireless Fidelity.”
The standards that the Wi-Fi Alliance are testing against are published by the IEEE (the Institute of Electrical and Electronics Engineers, an American-based professional body, like the IET, BCS or IoP in the UK). The standards are developed by hundreds of interested companies and thousands of engineers (of which I was one for several years), coming together to present technologies, suggestions and ideas in vast public meetings (anyone can go, for the price of a registration fee – feel free to go if you’ve got several hundred pounds to spare and some air miles to burn). The idea is that the best solutions are chosen and voted for, carefully and clearly defined in standards documents, and then published by the IEEE.
The IEEE’s standards arm has thousands of standards, both active and under development. It’s organised into many different “Working Groups”, all concerned with different subjects (e.g. healthcare, nuclear power, transport), and one of which is the IEEE 802.11 Wireless Local Area Network Working Group – and at any given time, there are dozens of parallel projects running within IEEE 802.11. Each project is developing a new sub-standard or “amendment”, e.g. project 802.11ad focused on millimetre wave technologies, and eventually produced the 802.11ad standard. This page is going to pick out some of the “landmark” amendments: there were dozens more.
And all of this so you can connect to the Internet from your sofa and watch funny cat videos.
The very first version, published in 1997, had three PHY (Physical) layers to choose from: two radio technologies that both worked in the 2.4GHz ISM band (alongside baby monitors, Bluetooth and microwave ovens), and an infra-red light-based version. The fastest data rate you could get was 2Mbps.
Engineers soon developed a faster PHY, using clever mathematical codes to squeeze the data through faster, but still able to work with the older standard (“backwards compatibility”) – this got the data rate up to 11Mbps, and was published as IEEE 802.11b in 1999. If you want to learn more about the coding used, you’ll have to wait until you go to university and do a course on communications.
11a: The Search for more Bandwidth
One of the problems with that unlicensed ISM band at 2.4GHz is just that: it is unlicensed and unregulated. There are loads of different technologies all working in that band, interfering with each other and getting in each other’s way, and there’s not much space (just 79MHz wide) in the first place. Microwave ovens are really bad from a radio point of view – they’re designed to heat food and not transmit precise communications packets, so they drift around the band, trampling all over any communications packets. You may notice that if you try to stream video over Wi-Fi or listen to music over Bluetooth headphones when stood next to the microwave oven warming your dinner up.
IEEE802.11a was built to work up in the 5GHz frequency band (a higher frequency than 2.4GHz, but still a lot lower than visible light, that’s up at 400,000 – 800,000 GHz), where there is less competition and more space, which allowed 802.11a to offer up to 54Mbps. There is a disadvantage to going up in frequency though – higher frequencies have shorter range. Most devices nowadays are “dual band” – they can operate in both the 2.4GHz and 5GHz bands.
11e: Some Traffic is More Equal than Others
When Wi-Fi was first developed, the only applications were things like email and the WWW, i.e. moving blocks of text from one place to another. As you well know, we use the Internet for a lot more than that now: music and video streaming, video calls, games, and so on. What you don’t want is for your video to freeze, or your game to stop responding, as a result of a load of emails getting transferred – those emails could have waited a few more seconds and no-one would have noticed, or cared. What we need is to be able to prioritise different types of traffic – get the urgent stuff through first, for example.
This is done in wired as well as wireless telecommunications as well (e.g. across the Internet – that’s one reason that Netflix can stream OK most of the time), and is usually referred to as “Quality of Service” (QoS) and traffic classes.
2005’s IEEE802.11e introduced four separate queues for data (ranging from “really important and urgent video traffic” to “meh, background data transfer“) that allowed the time-critical data to get to the head of the queue of packets wanting to be transmitted at a particular STA. These four queues not only meant that packets with Speedy Boarding got sent first, they also got prioritised access to the radio channel – rather than always using a fixed DIFS wait-period for all packets (see “The Rules for Transmitting” above), 11e introduced a separate Inter-Frame Space (called AIFS, Arbitration Inter-Frame Space) for each traffic queue, with the most important, urgent traffic getting the shortest value, down to the background data queue getting the longest.
NB: Even the shortest AIFS is still much longer than SIFS – the ACKs must get through!
11e also extended the idea of a “super-frame” (which had actually been lurking in the standard since 1997, part of the Point Coordination Function), where part of the time, Wi-Fi would work more like cellular (with a controller telling devices when to transmit), but this was really complicated (many, many inventions were patented and published to try to make it work optimally) and needed people to buy more hardware (the controller), so the super-frame part never really took off in products – we get by just fine without it. Those traffic queues and AIFS are still around though.
11n: More Antennas, More Throughput
802.11a (and subsequently 802.11ac) and 802.11b, and other projects within 802.11, had used more and more clever coding schemes to make the data rate (the number of bits we can send each second) faster and faster.
But, there was a problem… that only applied to the DATA bit of the frame:
The other parts of the frame (all those pink/red/orange/etc. blocks) couldn’t go faster, otherwise older stations that were built before these newer standards came out wouldn’t understand what was going on anymore. An older AP, say, might not be able to understand the address fields if it was sent in some new speedy way that it didn’t know about, any more than you can persuade a turntable to play a CD or stream Spotify. So the overheads were getting proportionally bigger and bigger – we were spending most of the air-time sending the stuff we didn’t really want to be sending (but had to).
The 11n project attacked this in a couple of ways. One was to increase the amount of useful throughput – and it managed this by “frame aggregation”, which was effectively a way of making that DATA block much, much bigger, so reducing the relative overhead. (It was actually cleverer than that – it allowed a series or salvo of packets to be sent in convoy, all piggy-backing on one leader – like an Australian road train or cycling peloton.)
The other big change introduced was at the PHY layer, introducing more than one antenna with a technique called MIMO – that’s why APs often look like hedgehogs now with antennas poking out all over the place. Basically, with multiple antennas at source and destination, and some maths, it’s as if you’ve not just got one radio channel, but now lots. If you have 2 antennas at each end, you get (2×2=) 4 independent channels – (nearly) four times the throughput, woo-hoo!
This is a great example of why you should pay attention in your Maths lessons – all those times when you’ve said “I’ll never use that in real life!“… well you’d be surprised. MIMO all works, fundamentally, because of complex matrix manipulation. If you’re doing matrices in maths, it’s how your Wi-Fi works.
Because of all of this, with 11n, we jumped from 54Mbps (11a) to up to 600Mbps!
One of the earliest pre-802.11n systems (using a MIMO antenna array) was demonstrated in Geneva at the ITU-T World Fair in 2003 by an intrepid band of brilliant research engineers based here in Bristol (ahem)…
11ax and Beyond: Now and The Future
The “current” version, soon to be published as a standard and only just coming out in early products now, is 802.11ax (the last amendment I worked on directly), being marketed as “Wi-Fi 6”, which took those MIMO ideas of 11n even further, considerably raised the data rates of even 11ac and 11n (hitting a theoretical maximum of over 1Gbps, that’s 1000Mbps – remember that the original 802.11 offered just 2Mbps), brought in new ideas such as channel bonding (merging different radio channels together and treating them like one bigger channel), is able to work in any frequency band between 1-6GHz (not quite DC-to-daylight but getting there), and added multiple ways to reduce latency (delays) which is key for gaming and other time-sensitive applications.
Wi-Fi is also moving into different frequency bands – 11ad & 11ay work in the 60GHz millimetre band; 11af works in the space left by old or unused TV channels; 11bb (currently in progress, due to publish in 2021) uses visible light, ironically going almost full circle back to the original 1997 802.11 with the infra-red PHY option.
IEEE802.11 is still rolling on, with projects starting, running and publishing every year – the 802.11be project is already looking at what comes after 11ax, for example. So long as we keep coming up with new ways to use it (e.g. smart homes, wireless gaming, Netflix, virtual reality…) the engineers working on the communications technologies will keep on inventing and innovating to give us the connectivity we want.
- What year was the first IEEE802.11 standard released?
- How many PHYs did it have?
- Which frequency band does 802.11a work in?
- Why was 802.11e introduced?
- What have matrices got to do with Wi-Fi?
- What’s the maximum data rate achievable with 802.11ax?
- What’s special about 802.11bb?