The Less Common Networking Theories (1)

The "uncommon" terms here refer to technical jargon and theories that I have encountered less frequently.

For software engineers, we usually interact with the OSI seven-layer model at the transport layer and above, dealing with common protocols like TCP/IP and HTTP. Even if we don't know the details, we generally understand how they work. In contrast, we have less exposure to the layers below the OSI seven-layer model.

However, at the physical layer, there are many details to consider, particularly in software implementation. This is especially true since physical signal transmission occurs in a relatively unstable environment filled with noise, which means these factors must be accounted for during the design phase.

Encoding

How is data encoded over the network? Regardless of the content of the files, we ultimately need to convert data into physical signals, such as high and low voltages, to enable transmission. This process of converting data into different formats or structures for easier processing by computers is called encoding.

The same goes for circuits; generally, we consider a high voltage as 1 and a low voltage as 0.

NRZ (Non-Return-to-Zero)

NRZ is a method of encoding in digital communications that uses voltage to represent the values of bits.

The key feature of NRZ encoding is that during each unit time, the signal voltage remains constant until the next bit time starts.

An important point here is the "unit time," which means that the intervals between each bit are fixed. Both parties need a unified periodic signal to know how to read the data stream; otherwise, they might end up reading completely different results.

If the clock is too fast or too slow, it can lead to data errors. However, here's the problem: how do both parties know what the clock frequency is? We could add an additional line to serve as a clock signal, but in practical applications, we prefer to minimize the number of lines. Additionally, if the data remains at a constant voltage for an extended period, it can lead to synchronization issues.

Clock Recovery

In practical applications, we guess the original clock frequency from the source signal and generate a corresponding periodic waveform to decode it at the receiver. This process is known as Clock Recovery.

Clock Recovery can generally be divided into several steps:

• Detecting transitions, which can usually be accomplished with a delay circuit.
• Using FFT transformation to find the period.
• Synchronizing the signal through phase-locked loops (PLLs).

For detailed principles of clock recovery, you can refer to Wikipedia. However, the main goal is to adjust the phase or frequency via feedback when the frequency of the reference signal changes, ensuring that both signals remain aligned.

But this poses a problem: if the data consistently stays at a high or low voltage, how do we determine the frequency? To solve this issue, other encoding methods have also been adopted.

Manchester Encoding

Since we want to avoid having the data stream remain at a constant low or high voltage, let’s keep the voltage changing! Manchester encoding employs a clever method to distinguish between 0 and 1.

In Manchester encoding, the changes in voltage levels represent 0 and 1:

• 0: Transition from low voltage to high voltage
• 1: Transition from high voltage to low voltage

This way, even if the original data consists of a continuous sequence of 0s or 1s, it doesn’t matter because the voltage will keep changing, effectively facilitating clock recovery. IEEE 802.3 also uses this encoding scheme. However, the most significant drawback of this encoding method is that it requires double the bandwidth compared to NRZ, as it needs to detect voltage changes within a single cycle, effectively requiring twice the bandwidth.

4B/5B