You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Once you know what a network is made of, the next question is how the bits actually travel between devices. This lesson is about the physical and logical mechanics of data transmission: whether bits go one at a time or many abreast, whether a link can carry data one way or both ways at once, how the sender and receiver stay in step, and how we measure a link's capacity and responsiveness.
These ideas matter because they explain real engineering decisions — why your phone charges and syncs over a single thin serial cable rather than a thick ribbon, why a video call needs a full-duplex link, and why "fast broadband" still feels sluggish over a satellite connection. The lesson works through serial versus parallel transmission, the three directional modes (simplex, half-duplex, full-duplex), synchronous versus asynchronous timing, and the four key measures — bandwidth, latency, bit rate and baud rate — with worked calculations. The recurring exam skill is distinguishing closely related terms precisely and justifying a transmission choice for a given situation.
This lesson covers the parts of OCR H446 section 1.3.3 dealing with how data is communicated, specifically:
Examiners reward candidates who can calculate bit rate from baud rate and bits-per-symbol, and who avoid the very common confusion between bandwidth (capacity) and latency (delay).
In serial transmission the bits of a message travel one after another along a single channel.
graph LR
S[Sender] -->|1 0 1 1 0 1 0 0 — one wire, one bit at a time| R[Receiver]
| Feature | Detail |
|---|---|
| Wires | One data channel |
| Distance | Excellent over long distances — fewer interference problems |
| Cost | Lower — fewer conductors |
| Skew | None — there is only one channel, so bits cannot arrive out of step |
| Examples | USB, SATA, Ethernet, HDMI, PCIe |
In parallel transmission several bits travel simultaneously, each on its own wire — for example eight wires carrying a whole byte at once.
graph LR
S[Sender] -->|bit 0| R[Receiver]
S -->|bit 1| R
S -->|bit 2| R
S -->|bit 3| R
S -->|... up to bit 7| R
| Feature | Detail |
|---|---|
| Wires | Many data channels in parallel |
| Distance | Poor over long distances — timing problems worsen with length |
| Cost | Higher — many conductors |
| Skew | Data skew: bits can arrive at slightly different times because wires differ minutely in length and electrical properties |
| Examples | Internal computer buses; legacy parallel printer ports |
It is tempting to assume parallel must be faster — it sends more bits per cycle. Yet serial has won for almost every external connection, for two reasons that intensify with speed:
Modern serial standards such as USB and SATA exploit this by running a single, very high-frequency channel with sophisticated encoding, comfortably outpacing the old parallel buses they replaced. The lesson: more wires is not more speed once skew and crosstalk dominate.
It is worth understanding why parallel was ever used, because it stops the topic feeling like arbitrary history. In the era of slower clock speeds, sending eight bits at once over a short internal cable genuinely was faster than sending them one at a time, and skew over a few centimetres at low frequencies was negligible. The parallel printer port and the old IDE hard-disk cable date from that world. But as engineers pushed clock frequencies up to gain speed, the skew that had been harmless suddenly became fatal: at gigahertz speeds, the time for one bit is so short that even nanosecond differences between wires scramble the data. Rather than fight skew across many wires, designers switched strategy — one very fast, carefully engineered serial channel sidesteps the problem entirely. This is why nearly every modern interface name ends in a serial technology: USB (Universal Serial Bus), SATA (Serial ATA), PCIe (PCI Express, serial lanes). The same shift happened inside computers too, linking this directly to the systems-architecture unit's treatment of buses.
A second property of a link is which directions data can flow, and when.
graph TD
subgraph Simplex
A1[A] -->|one way only| B1[B]
end
subgraph Half-duplex
A2[A] -->|one direction at a time| B2[B]
B2 -.then the other.-> A2
end
subgraph Full-duplex
A3[A] -->|both directions at once| B3[B]
B3 -->|simultaneously| A3
end
| Mode | Behaviour | Direction | Example |
|---|---|---|---|
| Simplex | Data flows in one direction only, ever | A -> B, never B -> A | A broadcast TV signal; a sensor feeding a display |
| Half-duplex | Data flows both ways but only one way at a time | A -> B or B -> A, taking turns | Walkie-talkies; older shared-medium Ethernet |
| Full-duplex | Data flows both ways at the same time | A <-> B simultaneously | A telephone call; a modern switched Ethernet link |
| Feature | Simplex | Half-duplex | Full-duplex |
|---|---|---|---|
| Directions | One-way | Two-way, alternating | Two-way, simultaneous |
| Use of capacity | All capacity one way | Shared between directions over time | Capacity available in both directions |
| Complexity / cost | Lowest | Moderate | Highest |
A subtle but examinable point: full-duplex effectively doubles the conversation throughput compared with half-duplex on the same link, because neither side has to wait for the other to finish, and there is no "turnaround" delay each time the direction of flow has to reverse. This is one reason switched Ethernet (full-duplex, dedicated link per port) so decisively outperformed the old half-duplex shared medium discussed in the topologies lesson.
Choosing a mode is a matter of matching it to the communication pattern, and exam scenarios test exactly this judgement. If data only ever needs to flow one way — a temperature sensor reporting to a display, a broadcast signal to many receivers — simplex is sufficient and cheapest; adding return capability would be wasted. If both ends need to communicate but rarely at the same instant, and cost or simplicity matters, half-duplex suffices: a walkie-talkie works perfectly well taking turns, and the "over" convention is precisely a human protocol for managing a half-duplex channel. But where both ends must send and receive continuously and simultaneously — a phone call, a video conference, two servers exchanging data — only full-duplex delivers an acceptable experience, because the alternating delays of half-duplex would cripple a real-time conversation. Notice that the medium often dictates the mode: a single shared radio frequency naturally tends toward half-duplex (two stations transmitting at once would jam each other), whereas a switched link with separate send and receive paths supports full-duplex easily. A subtle exam trap is to assume "duplex" implies "fast" or "two cables": it describes only directionality and simultaneity, and full-duplex can be achieved on a single physical link by using separate frequencies or time-division — what matters is whether both directions can be active at the same time, not how many wires are involved.
For the receiver to read a stream of bits correctly it must know where each bit (and each character) begins and ends. The two approaches to this differ in how timing is coordinated.
In synchronous transmission the sender and receiver share a common clock signal, so both step through the data in lockstep. Data flows as a continuous stream of blocks with no per-character framing, making it highly efficient for large, continuous transfers.
| Feature | Detail |
|---|---|
| Timing | A shared clock keeps both ends synchronised |
| Framing | Continuous blocks, no start/stop bits per character |
| Overhead | Low — almost all transmitted bits are payload |
| Best for | High-speed, sustained transfers (e.g. between fast components, network backbones) |
In asynchronous transmission there is no shared clock. Instead each character is wrapped with a start bit to signal "a character is coming" and one or more stop bits to signal its end, letting the receiver resynchronise on every character. This is simple and tolerant of irregular timing but adds overhead.
| Feature | Detail |
|---|---|
| Timing | No shared clock; start/stop bits frame each character |
| Framing | Each character bounded by a start bit and stop bit(s) |
| Overhead | Higher — extra bits per character reduce efficiency |
| Best for | Low-speed, intermittent data (e.g. keyboard input, simple serial links) |
| Feature | Synchronous | Asynchronous |
|---|---|---|
| Clock | Shared/external clock | None — start/stop bits |
| Overhead per character | None | Start + stop bits |
| Efficiency | Higher for continuous data | Lower |
| Complexity | Higher (clock coordination) | Lower |
You can quantify the asynchronous overhead, which makes a good exam point. Sending 8-bit characters each framed by 1 start bit and 1 stop bit means 10 bits are transmitted for every 8 bits of useful data, so the efficiency is 8 / 10 = 80% — a fifth of the link's capacity is "wasted" on framing. Synchronous transmission avoids this, which is why sustained high-speed links are synchronous.
The deeper trade-off is between simplicity and efficiency. Asynchronous transmission is self-clocking on a per-character basis: the receiver does not need its own accurate clock running continuously, because the start bit tells it exactly when each character begins, and it only has to stay in step for the handful of bits until the stop bit. This makes asynchronous hardware cheap and forgiving — ideal for a keyboard, where keystrokes arrive irregularly and the data rate is trivial. Synchronous transmission, by contrast, demands that both ends maintain precise, continuous clock agreement (often by recovering the clock from the data stream itself), which is more complex to engineer — but once that investment is made, no bits are spent on per-character framing, so it is far more efficient for the sustained, high-volume transfers found on network backbones and between fast components. The choice therefore mirrors the data pattern: bursty and slow favours asynchronous simplicity; continuous and fast favours synchronous efficiency. This is the same "match the method to the workload" theme that runs through the serial/parallel and duplex decisions.
Bandwidth is the maximum rate at which data can be carried over a connection, measured in bits per second (bps). In networking the prefixes are decimal (powers of ten), not the binary powers used for file sizes:
| Unit | Bits per second |
|---|---|
| bps | 1 |
| Kbps | 1,000 |
| Mbps | 1,000,000 |
| Gbps | 1,000,000,000 |
Key things to hold onto:
Bandwidth questions almost always involve a time calculation, and the classic trap is mixing up bits and bytes. Suppose you must download a 30 MB file over a 24 Mbps connection. First convert the file size from bytes to bits (since bandwidth is in bits per second), using 1 byte = 8 bits:
Then divide the size by the rate:
time=24 Mbps240 Mb=10 secondsThe most frequent mistake here is forgetting the \times 8 conversion and reporting 1.25 seconds — eight times too fast. Always check whether a quantity is in bits (lower-case b, used for rates) or bytes (upper-case B, used for file sizes) before dividing. This bits-versus-bytes discipline is shared with the data-capacity arithmetic in the data-representation unit.
Be careful, too, to distinguish bandwidth from throughput. Bandwidth is the link's advertised maximum; throughput is the rate actually achieved once protocol overhead (headers, acknowledgements), retransmissions of corrupted data, and contention with other users are taken into account. Real throughput is almost always lower than the headline bandwidth — which is why a "100 Mbps" connection rarely transfers a file at a full 100 Mbps. In the calculation above we assumed the full bandwidth was usable; a more realistic estimate would apply an efficiency factor, and an exam question that gives you a "75% effective" figure is testing exactly this awareness.
Latency is the time delay between data being sent and being received, usually measured in milliseconds (ms). It is a completely different quantity from bandwidth — capacity versus delay — and conflating the two is the single most common error in this topic.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.