Circuitry for sending and receiving bit streams in networking

Question

To my little knowledge , I know that digital signals are transferred over continuous EM signals . At the receiver end a bit 1 is detected when the amplitude crosses a certain threshold and a bit 0 is detected when the amplitude falls below a certain signal .

But in networking streams of bits ,packets, are what communications take place over and a packet is simply a stream of bits .This packet is what contains various information about related to the protocol , the source and the destination .

At hardware level , how is this stream of bit sent and received ?

If the detection of bits is being done on the basis of EM signal amplitude , then does the gathering of bits involve checking the amplitude of the signal at different intervals of time ?

I see that I could be more specific and elaborate . So let me explain what I need in a bit more detail :

When do we detect a bit 1? when a signal amplitude exceeds a certain threshold ,right ? Now a packet will have a bit stream like 1,0,1,0... but how is this bit stream detected . Is there a circuit which detects a starting bit and then keeps on gathering amplitudes in frequent intervals of time till the end bit and hence constructs a bit stream ? As such is there a time-limit for which the hardware performs this gathering of amplitude process ?

Answer 1

There are a great number of line encoding schemes which deal with different special cases. I'm just going to talk about the simplest ones.

At base, don't think about it like software: "we keep checking it to see if it changes". The electronics is more like a spring which is unhooked when an event happens, such as a voltage exceeding a certain level. Or pushing something off a table: it doesn't "keep checking" to see if there's something under it: there's a force stopping it moving downwards. When the force is removed, it falls.

The simplest line encoding in common use is NRZ ("non-return-to-zero", a name which doesn't help much until you already understand it.) This is used in RS-232 and many other things. A line is at some voltage, say 5V. When it falls below say 1V, we start a timer. Suppose the bits are going to be one per second: we start a timer for half a second -- we should be in the middle of the here-comes-a-byte "start bit". After this half a second, we wait another second: now we're in the middle of the first bit: we just check the voltage. Wait another second, check the voltage and we have the second bit. Do this eight times till we have a byte.

You'll see that process is built of three mechanisms:

• waiting until an event occurred (voltage falling below a value)
• waiting a fixed amount of time (half or whole bit time)
• sampling the line at a given moment

That process normally happens in hardware, but sometimes firmware. All the details vary: the voltages, the speeds, whether high voltage is a one or a zero, whether the first bit is the low-value or the high-value bit. See Wikipedia for more.

It's true that the first of those (wait until signal is low) could be done by a processor sampling at speed. But it is more usually done by circuitry which performs an action after an event, perhaps by the signal feeding a latch which holds some timer chip in reset.

Once we have bytes there will be some scheme to get framing, of which the simplest is SLIP (serial line protocol), where, in essence, a particular byte value indicates the beginning of a frame. There's nothing like reading the real RFCs which define the internet, and the one which defines this is especially simple RFC1055.

There are very many other schemes for framing, such as "long time without signal" (used in DMX) or "no voltage at all means not inside a frame" (used in coax ethernet).

Ethernet is akin to the mechanism described, but much more complex. Especially the faster kinds, which are very much more complex. The simplest in current use is 10baseT, which uses "Manchester Encoding" (named after the university where it was developed). The basic idea is the same: wait for a particular type of transition, then wait a certain period, take a sample, repeat. But every detail is different. Wikipedia has a good article.

As said in comments, whole books on the subject of encodings: whole PhDs.

High performance framing and encoding schemes are all about

• errors -- what happens when noise or other problems mean the received signal isn't what was expected
• bandwidth -- how to get the most bits down the channel that we can
• money -- how to do it with cheapest materials
• reliability -- how to use parts which don't break

Seriously: if you understand RS-232, NRZ, SLIP, and that proper networking is much more complex, you know enough for a networking person. It's much more important to know about which kinds of networking have link detection than the details of how they work.

If you want more detail about how the circuits work, electronics.stackexchange.com is probably a better bet than here, but we're good for things like framing and CRC errors and similar.

Answer 2

Network line codes are not that easy to start with. They're designed for at least several dozen meters over (more or less) simple cabling. This requires elaborate coding schemes for high bit rates over copper (and for very high baudrates even over fiber). Generally, networking links don't use a separate clock signal, so the line codes need to be self-clocking and self-synchronizing.

The simplest code used in networking is the Manchester code used for 10 Mbit/s Ethernet: high-low = 1 and low-high = 0. Of course, this wastes a lot of bandwidth, but you can build custom hardware for this quite easily.

100 Mbit "Fast" Ethernet uses 4b/5b block code. Since 125 Mbit/s is too high for category 5 twisted pair copper (100BASE-TX), there's another sublayer coding with MLT3 (basically stepping through different voltage levels instead of jumping between just two). Custom hardware is doable but already pretty hard to build.

Gigabit Ethernet uses 8b/10b block code as the basic line code which is similar to 4b/5b but has some advantages. 1000BASE-T for twisted pair splits the stream into four lanes, uses additional PAM5 coding and scrambling to cope with the cable limits. Custom hardware is extremely hard to build if possible at all - one data bit translates to 1 nanosecond.

10G+ Ethernet generally uses the more efficient 64b/66b large block code. Twisted pair requires a very elaborate coding scheme in multiple layers involving Tomlinson-Harashima precoding (THP), PAM16 and DSQ128 "checkerboard" patterns to enable copper transmission. Even if you were able to custom hardware for 1000BASE-T, 10GBASE-T requires a sophisticated ASIC in any case - we've got 100 picoseconds per bit.

Except for the latest speeds, fiber generally just uses the basic line code and is much easier to code and decode than copper - but still.

All that just covers the physical layer. Networking standards usually cover the data link layer as well, so you need to build frames around your actual data (the network layer payload). This however, could be done in software with only a little hardware support.