Chapter 4: Basic Concepts and Management
Inter-frame Gap time
After the end of a transmission, if a network node is ready to transmit data out and if there is no carrier signal on the medium at that time, the device will wait for a period of time known as an inter-frame gap time to clear and stabilize the medium, as well as to have the jobs ready, such as adjusting buffer counter, updating counter, and so on, in the receiver site. Once the inter-frame gap time expires after the de-assertion of carrier sense, the MAC transmits data. In the IEEE 802.3 specification, this is 96-bits time or more.
Collision
Collision happens only in half-duplex operation. When two or more network nodes transmit frames at approximately the same time, a collision always occurs and interferes with each other. As a result, the carrier signal is distorted and un-discriminated. The MAC can detect, through the physical layer, the distortion of the carrier signal. When a collision is detected during a frame transmission, the transmission will not stop immediately but, instead, continues transmitting until the rest of the bits specified by jamSize are completely transmitted. This guarantees that the duration of the collision is long enough for all involved devices to detect the collision. This is referred to as jamming. After a jamming pattern is sent, MAC stops transmitting the rest of the data queued in the buffer and waits for a random period of time, known as backoff time with the following formula. When backoff time expires, the device goes back to attempting to transmit the frame. The backoff time is determined by the formula below. When the time of collision is increased, the backoff time increases up to the collision times plus 16. If this happens, the frame will be discarded and the backoff time will also be reset.
0 < or = r < 2k
where
k = min (n, 10)
Frame Reception
Frame reception is the same for both half-duplex and full-duplex operation, except that full-duplex operation uses two buffers to transmit and receive the frame independently. The receiving node always “listens” if there is traffic running over the medium when it is not receiving a frame. When a frame destined for the target device comes, the receiver of the target device begins receiving the bit stream, and looks for the Preamble (PRE) pattern and Start-of-Frame Delimiter (SFD) that indicates the next bit is the starting point of the MAC frame, until all bits of the frame are received.
For a received frame, the MAC will check:
1.Is it less than one slotTime in length, that is, a short packet? If yes, the frame will be discarded by MAC because, by definition, the valid frame must be longer than the slotTime. If the length of the frame is less than one slotTime, a collision may have happened somewhere or the interface might have malfunctioned in the LAN. When detecting the case, the MAC drops the packet and goes back to the ready state.
2.Does the DA of the received frame exactly match the physical address that the receiving MAC owns or the multicast address is designated to recognize? If not, the MAC discards it and passes the frame to its client and goes back to the ready state.
3.Is the frame is too long? If yes, the MAC throws it away and reports “Frame Too Long.”
4.Is the FCS of the received frame valid? If not, for 10M and 100M Ethernet, the MAC discards the frame. For Gigabit Ethernet or higher speed Ethernet, the MAC has to check one more field, that is, the extra bit field, if FCS is invalid. If any extra bits exist, they must meet the IEEE 802.3 specification to be considered valid. When both FCS and extra bits are valid, the received frame will be accepted; otherwise, the switch discards the received frame and reports frameCheckError if no extra bits are appended, or alignmentError if extra bits are appended.
5.Is the length/type valid? If not, the switch discards the packet and reports lengthError.
6.If all five procedures above are ok, then the MAC treats the frame as good and disassembles the frame.
