You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Before data can travel across a network, two devices must agree on the physical mechanics of how the bits actually move between them. This lesson covers the foundational layer of all networking: how individual bits are placed onto a communication channel, in which direction they may flow, and how the sender and receiver stay in step with one another. These ideas underpin everything that follows — the protocol stack, IP addressing and the application protocols all ultimately rely on a reliable bit-transport mechanism beneath them.
At A-Level you must be able to distinguish serial from parallel transmission, define simplex, half-duplex and full-duplex modes, contrast synchronous and asynchronous transmission (including the role of start and stop bits), and use the precise vocabulary of bit rate, baud rate and bandwidth correctly. Crucially, you must explain why a particular method is chosen in a given scenario — the examiner rewards reasoning, not just labels.
This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically the content on communication methods. The relevant material covers serial and parallel data transmission; simplex, half-duplex and full-duplex transmission modes; synchronous and asynchronous transmission and the purpose of start and stop bits; the distinction between bit rate and baud rate; bandwidth; and the meaning of the term protocol. It connects forward to the TCP/IP stack and the suite of network protocols studied later in the same area.
A protocol is a set of agreed rules that governs how data is exchanged between devices. Without protocols, two machines could send electrical signals at one another and neither would have any idea what the signals meant. A protocol defines things such as:
Both devices must implement the same protocol for communication to succeed — a sender using one set of rules and a receiver using another will fail just as surely as two people speaking different languages. Keep this definition crisp: examiners frequently award a mark for stating that a protocol is "a set of rules governing the transmission/exchange of data between devices."
A single conversation usually involves several protocols stacked together, each handling one concern — one protocol governs how bits are framed on the wire, another how they are routed, another what the message means to the application. This layering is why a web page can travel over Wi-Fi at home and fibre across the country without the browser ever knowing or caring: each layer's protocol does its job and hands the data to the next. You will study this stack of protocols in detail in the next lesson; here the key point is simply that the foundational layer — getting bits reliably across a physical link — is exactly what the communication methods in this lesson provide.
In serial transmission, data is sent one bit at a time over a single communication channel (a single wire or signal path).
flowchart LR
S["Sender"] -- "bit 0, bit 1, bit 2, bit 3<br/>(one bit at a time, single channel)" --> R["Receiver"]
| Feature | Detail |
|---|---|
| Bits per cycle | 1 |
| Number of channels | 1 |
| Cable cost | Low (fewer wires) |
| Distance | Suitable for long distances |
| Synchronisation | Simpler — no skew problems |
| Examples | USB, SATA, Ethernet, RS-232 |
In parallel transmission, multiple bits are sent simultaneously over multiple channels (several wires side by side, one per bit).
flowchart LR
S["Sender"] -- "bit 0" --> R["Receiver"]
S -- "bit 1" --> R
S -- "bit 2" --> R
S -- "bit 3" --> R
| Feature | Detail |
|---|---|
| Bits per cycle | Multiple (e.g. 8 or 32) |
| Number of channels | Multiple (one per bit) |
| Cable cost | Higher (more wires) |
| Distance | Short distances only |
| Synchronisation | Harder — data skew can occur at higher speeds or longer distances |
| Examples | Internal CPU buses, older printer cables (IEEE 1284), PCI (legacy) |
Intuitively, parallel sounds faster: if you send 8 bits at once, surely you finish 8 times sooner? For short, slow links this is true, which is why parallel buses are used inside a computer where wires are millimetres long. But over distance the picture inverts because of data skew (also called timing skew).
When bits travel in parallel over separate wires, tiny differences in wire length, electrical resistance, capacitance and interference mean the bits do not all arrive at exactly the same instant. The receiver clocks all the wires together expecting one neat column of bits, but bit 3 might lag bit 0 slightly. At low speeds this drift is negligible compared with the clock period. As you push the clock faster — or make the wires longer — the drift becomes a larger fraction of one clock tick, until eventually a bit from one cycle bleeds into the sampling window of the next and the data is corrupted. There is also crosstalk: adjacent wires carrying changing signals induce noise in one another.
Serial links sidestep all of this. With only one channel there is no skew between bits — each bit is sent and sampled in turn, so the only constraint is the clock speed the single channel can sustain. Modern serial standards drive that single channel at enormous frequencies (gigahertz), so they comfortably exceed the throughput of the older, slower parallel buses they replaced. This is exactly why USB replaced the parallel printer port, why SATA replaced the parallel ATA (PATA) ribbon cable, and why PCI Express (serial) replaced parallel PCI.
Exam Tip: A staple question is: "Explain why serial transmission is preferred over parallel for long-distance communication." Hit these points: (1) parallel suffers from data skew over distance — bits arrive at different times and cannot be reliably reassembled; (2) parallel also suffers from crosstalk between adjacent wires; (3) serial uses fewer wires, so cables are cheaper and thinner; (4) modern serial links run at very high clock speeds, achieving high overall throughput despite sending one bit at a time.
| Factor | Serial | Parallel |
|---|---|---|
| Bits transmitted per moment | One | Several (e.g. 8, 16, 32) |
| Number of data channels | One | One per bit |
| Susceptible to data skew? | No | Yes (worsens with distance/speed) |
| Susceptible to crosstalk? | Minimal | Yes |
| Cost of cabling | Lower | Higher |
| Best suited to | Long distance, high modern throughput | Very short distances (internal buses) |
The three transmission modes describe which way data may flow along a link.
Data flows in one direction only. The sender can only send; the receiver can only receive. There is no return path at all.
flowchart LR
S["Sender"] --> R["Receiver"]
Examples: television and radio broadcast, a keyboard sending keystrokes to a computer, a temperature sensor reporting to a control unit.
Data can flow in both directions, but only one direction at a time. The devices must take turns — while one transmits, the other must wait.
flowchart LR
A["Device A"] <-- "one direction at a time" --> B["Device B"]
Examples: walkie-talkies (you press to talk, release to listen), CB radio, and classic shared-medium Wi-Fi where only one device may occupy the channel at once.
Data can flow in both directions simultaneously. Both devices can send and receive at the same instant, typically by using separate channels (or pairs of wires) for each direction.
flowchart LR
A["Device A"] == "send" ==> B["Device B"]
B == "send simultaneously" ==> A
Examples: a telephone call (both people can speak and hear at once), modern switched Ethernet (separate transmit and receive pairs), and USB.
| Mode | Direction | Simultaneous? | Example |
|---|---|---|---|
| Simplex | One way | N/A — only ever one way | TV broadcast |
| Half-duplex | Both ways | No — take turns | Walkie-talkie |
| Full-duplex | Both ways | Yes — at the same time | Telephone call |
Exam Tip: Do not confuse half-duplex with simplex. Both differ from full-duplex, but half-duplex does allow two-way communication — just not simultaneously. A walkie-talkie is half-duplex (two-way, taking turns); a TV broadcast is simplex (genuinely one-way).
A subtle point worth grasping: full-duplex is usually achieved either by providing two separate physical channels (one for each direction — modern Ethernet uses different wire pairs for transmit and receive) or by frequency-division so the two directions occupy different frequency bands on one medium. Half-duplex, by contrast, shares a single channel and must coordinate whose "turn" it is to transmit, which is why early shared-medium networks needed media-access rules to prevent two devices talking at once and corrupting each other's signal. The historical move from half-duplex shared coax Ethernet to full-duplex switched Ethernet — giving every device its own dedicated, simultaneously bidirectional link — was a major reason network performance improved, because devices no longer had to wait for the channel to fall silent before transmitting.
This pair concerns how the receiver knows where each bit (or byte) begins and ends — the problem of keeping sender and receiver in step.
Data is sent as a continuous stream of bits synchronised to a shared clock signal. Sender and receiver agree precisely on the timing of every bit, either by a separate clock line or by a clock recovered from the data signal itself. Because the timing is continuous, there is no need to mark each individual byte — large blocks of data flow back-to-back with minimal overhead.
| Feature | Detail |
|---|---|
| Clock | Shared or embedded in the signal; sender and receiver locked together |
| Overhead | Low — no start/stop bits framing every byte |
| Speed | Higher throughput |
| Use | High-speed links: Ethernet, internal buses, SPI |
Data is sent in discrete chunks (typically one character/byte at a time). There is no continuously shared clock. Instead, each byte is wrapped with a start bit to tell the receiver "a byte begins now" and one or more stop bits to mark its end. Between bytes the line sits idle. The receiver re-synchronises afresh on every start bit, so the two devices only need to roughly agree on the bit rate — small timing drift is corrected at the start of each character.
The purpose of the start bit is therefore to signal the beginning of a character and trigger the receiver's sampling clock; the purpose of the stop bit(s) is to mark the end of the character and guarantee a known idle state before the next start bit. An optional parity bit may sit between the data bits and the stop bit for simple error detection.
| Feature | Detail |
|---|---|
| Clock | No shared clock — start/stop bits re-synchronise each byte |
| Overhead | Higher — extra start/stop (and possibly parity) bits per byte |
| Speed | Lower throughput (overhead per character) |
| Use | Slower, intermittent links: RS-232 serial, simple sensor/keyboard input |
Asynchronous byte frame layout (1 start bit, 8 data bits, 1 parity bit, 1 stop bit):
| Start bit | D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | Parity | Stop bit |
|---|
Notice the cost of asynchronous framing: to send 8 bits of actual data we transmit 11 bits on the wire. That is roughly a 27% overhead — fine for a keyboard, wasteful for a gigabit backbone, which is why high-speed links are synchronous.
These three terms are routinely confused; the examiner deliberately tests whether you can separate them.
The relationship between bit rate and baud rate is:
bit rate=baud rate×number of bits per symbol
If each signal change encodes exactly one bit, then bit rate equals baud rate. But if modulation is used so that each symbol carries several bits, the bit rate exceeds the baud rate. For example, if a system uses a modulation scheme where each signal change represents 4 bits, then a line running at 2,400 baud achieves:
bit rate=2400×4=9600 bit/s
Exam Tip: The phrase to remember is: baud rate measures signal changes per second; bit rate measures bits per second; they are equal only when one signal change carries exactly one bit. If a question gives "bits per symbol", multiply. Stating that "baud rate and bit rate are the same thing" is a guaranteed lost mark.
Students often blur "bandwidth", "latency" and "throughput" into one vague notion of "speed", but they are distinct and examinable.
A useful analogy: bandwidth is the number of lanes on a motorway, latency is how long the journey takes, and throughput is how many cars actually arrive per minute once congestion and junctions are accounted for. A satellite link can have high bandwidth yet high latency (the signal travels ~36,000 km to a geostationary satellite and back), which is why it feels sluggish for interactive tasks despite carrying lots of data. Conversely, a short fibre link has low latency.
A favourite quantitative question asks you to compute how long a transfer takes. The core relationship is:
time=bit rate (bits per second)amount of data (bits)
Example: How long, ignoring overhead, to transmit a 2 megabyte (MB) file over a link with a bit rate of 8 Mbit/s?
First convert the file size to bits. Taking 1 byte = 8 bits and using decimal megabytes (1 MB = 106 bytes) for clarity:
2 MB=2×106 bytes=2×106×8=1.6×107 bits
Then divide by the bit rate (8 Mbit/s = 8×106 bit/s):
time=8×1061.6×107=2 seconds
Exam Tip: In these calculations the two traps are (1) forgetting to convert bytes to bits (multiply by 8), and (2) mixing up bits (lower-case b, as in Mbit/s) with bytes (upper-case B, as in MB). Network speeds are quoted in bits per second; file sizes are quoted in bytes — always reconcile the units before dividing. The real transfer time is longer than the ideal because of framing overhead, latency and any retransmission.
To make parity concrete, suppose we use even parity and want to send the 7-bit data 1010101. Count the 1s: there are four, which is already even, so the parity bit is 0, giving the 8-bit frame 10101010.
Now suppose we want to send 1101001. Count the 1s: there are four — even again — so the parity bit is 0, giving 11010010. If instead the data were 1101000 (three 1s, odd), the even-parity bit would be 1 to make the total even, giving 11010001.
At the receiver, the total number of 1s (data + parity) is recounted. If even parity was agreed and the count comes out odd, at least one bit must have flipped in transit — the frame is rejected. But here is the limitation in action: if two bits flip (say two 0s become 1s), the count of 1s rises by two, staying even, so the check passes and the corruption goes undetected. This is exactly why parity detects only an odd number of errors and cannot correct anything.
Because the physical layer is imperfect — noise and interference flip bits — protocols add error detection so corruption can be spotted.
| Method | How It Works | Limitation |
|---|---|---|
| Parity bit | An extra bit makes the total number of 1s even (even parity) or odd (odd parity). The receiver recounts. | Detects only an odd number of bit errors; misses an even number. Cannot correct. |
| Checksum | The data values are combined arithmetically; the result is sent alongside. The receiver recomputes and compares. | Different errors can coincidentally produce the same checksum. |
| Check digit | A digit derived from numeric data and appended (e.g. ISBN, barcode). | Designed for human-entry transcription errors, not general transmission. |
Exam Tip: Be precise about parity's weakness: if two bits flip, the count of 1s changes by an even amount, so the parity still appears correct and the error slips through. This is the standard discriminating point in error-detection answers.
A real interface is described by all three properties at once — serial/parallel, the duplex mode, and synchronous/asynchronous. Reading a few familiar examples this way cements the vocabulary:
| Interface | Serial or parallel | Duplex mode | Sync or async |
|---|---|---|---|
| Modern USB | Serial | Full-duplex (modern versions) | Effectively synchronous (clock recovered from data) |
| RS-232 serial port | Serial | Full-duplex | Asynchronous (start/stop bits) |
| Switched Ethernet link | Serial | Full-duplex (separate Tx/Rx pairs) | Synchronous |
| Internal CPU system bus | Parallel | Often half-duplex (shared data bus) | Synchronous (CPU clock) |
| Walkie-talkie radio | Serial (single channel) | Half-duplex | — |
Notice that the three choices are independent: USB is serial and full-duplex and (effectively) synchronous, whereas a simple sensor link might be serial, half-duplex and asynchronous. When a question asks you to select a method, reason from the requirements: distance (favours serial), whether both ends must talk at once (favours full-duplex), and whether data is continuous-and-high-volume (favours synchronous) or sporadic-and-low-volume (favours asynchronous).
A short worked judgement: imagine connecting a barcode scanner that fires a short burst of data only when an item is scanned. The data is sporadic and small, the device is cheap, and the run may be a few metres. Serial avoids skew over the cable; asynchronous framing avoids the cost and complexity of a shared clock for such infrequent bursts; and half-duplex (or even simplex from scanner to till) is sufficient since the scanner rarely needs to receive. Contrast this with a backbone link between two switches carrying continuous heavy traffic: serial, synchronous (for low overhead at high volume) and full-duplex (both switches send and receive constantly) is the right combination. The same toolkit of concepts, applied to the requirements, yields opposite — and correct — answers.
A factory uses a long cable run to connect a temperature sensor on the production line to a central monitoring computer 80 metres away. The sensor sends a single reading roughly once per second. An engineer proposes using a parallel cable so that "all the bits of the reading arrive at once and it is faster."
(a) Explain one reason why parallel transmission is a poor choice for this 80-metre link. (2 marks) (b) The chosen serial link uses asynchronous transmission. Explain the purpose of the start bit and the stop bit. (2 marks) (c) Justify why asynchronous (rather than synchronous) transmission is appropriate for this particular sensor. (3 marks)
AO breakdown: Part (a) is AO1 (recall/understanding of data skew) shading into AO2 (apply to the 80-metre scenario). Part (b) is AO1 (knowledge of framing bits). Part (c) is AO2/AO3 — applying knowledge to the scenario and evaluating the trade-off for an intermittent, low-rate source.
(a) Parallel is bad over 80 metres because of data skew — the bits travel on different wires and arrive at slightly different times, so they get muddled. (b) The start bit tells the receiver a byte is coming and the stop bit tells it the byte has finished. (c) The sensor only sends data once a second so it does not need to be fast, so asynchronous is fine.
(a) Over an 80-metre run the wires of a parallel cable differ enough in length and electrical characteristics that bits experience data skew — they no longer arrive aligned in the same clock period, so the receiver cannot reliably reassemble the reading. (b) The start bit marks the beginning of a character and triggers the receiver to begin sampling at the agreed bit rate; the stop bit marks the end of the character and returns the line to a known idle state before the next start bit. (c) Because the sensor transmits only an occasional, small reading, high throughput is unnecessary. Asynchronous transmission needs no separate clock line, making the cabling simpler and cheaper, and re-synchronising per character is perfectly adequate at this low rate.
(a) A parallel cable splits the reading across several wires that are sampled together on a shared clock. Over 80 metres, differences in wire length, resistance and capacitance cause data skew: bits drift out of alignment relative to the clock edge, so a bit from one cycle can fall into the sampling window of the next, corrupting the value. (Crosstalk between the closely-packed wires compounds this.) A single-channel serial link has no inter-bit skew and is therefore far more reliable over this distance. (b) In asynchronous framing each character is delimited individually because there is no continuously shared clock. The start bit is a transition that announces "a character begins now," allowing the receiver to lock its sampling clock to this character; the stop bit(s) guarantee a defined idle gap after the data (and any parity) bit so the next start bit is unambiguous. (c) The source is intermittent and low-volume — one small reading per second. Synchronous transmission's advantage is low overhead at sustained high data rates, which is irrelevant here; its cost is the complexity of maintaining clock synchronisation, often via an extra line. Asynchronous transmission trades a small per-character overhead (start/stop bits) for the benefit of needing no shared clock and tolerating timing drift, which exactly suits a cheap sensor sending sporadic data. The throughput penalty is immaterial at one reading per second, so asynchronous is the well-judged choice.
Examiner-style commentary: The mid-band answer states the right labels (skew, start/stop, "not fast") but never explains the mechanism or engages with the 80-metre figure, so it caps at the lower marks. The stronger answer earns full marks on (a) and (b) by giving the underlying cause and the precise role of each framing bit, and makes a sound applied judgement in (c). The top-band answer adds the evaluative depth examiners reward at AO3: it weighs the advantage versus cost of each transmission type against the specific characteristics of the source, rather than merely asserting that asynchronous "is fine."
This content is aligned with the AQA A-Level Computer Science (7517) specification.