Computer NetworksCSMA/CD

CSMA/CD: Carrier Sense Multiple Access with Collision Detection

LevelIntermediate

Duration60 mins

TopicCSMA/CD

3 / 5

Jam Signal — Enforcing Collision Acknowledgment

The Universal Stop Signal

When a collision occurs on an Ethernet network, simply stopping transmission isn't enough. The station that detected the collision might be closest to the collision point—what about other stations farther away that haven't detected it yet?

The jam signal solves this problem. When a station detects a collision, it transmits a special signal designed to enforce the collision—to make it unmistakably obvious to every station on the network that a collision has occurred. The jam signal guarantees that all parties recognize the collision and enter the recovery procedure simultaneously.

Without the jam signal, different stations might have different views of the collision event, leading to protocol inconsistencies and potential data loss.

What You Will Learn

By the end of this page, you will understand the purpose and necessity of the jam signal, its exact specification (32 bits of specific pattern), how it propagates through the network, and its role in ensuring consistent collision detection across all stations.

Why Jam Signals Are Necessary

To understand the necessity of jam signals, consider a scenario without them:

The Problem Scenario:

Station A (at one end of network) starts transmitting a frame
Station B (at the other end) starts transmitting before A's signal reaches it
The signals collide somewhere in the middle of the network
Station A detects the collision (it sees B's signal mixed with its own)
Station A stops transmitting
Problem: Station B may not have detected the collision yet!

If Station A simply stops transmitting, several issues arise:

The network might return to idle before station B realizes there was a collision
Station B might continue transmitting, believing everything is normal
The partial frame from A might not be long enough for B to recognize as a collision

Collision Detection Without vs. With Jam Signal
Scenario	Without Jam	With Jam
Station A detects collision	Stops transmitting	Transmits jam, then stops
Signal on medium	Goes idle quickly	Remains corrupted longer
Station B detection	May miss collision	Guaranteed to detect
Protocol state	Potentially inconsistent	Always consistent
Recovery	B may finish corrupted frame	Both stations backoff

The Jam Signal Solution:

The jam signal addresses these issues by:

Extending collision duration: The jam signal ensures the collision condition persists long enough for all stations to detect it
Reinforcing collision signature: The jam signal's pattern, combined with other transmissions, produces unmistakable collision characteristics
Guaranteeing minimum collision fragment: The jam ensures that even the shortest collision produces a detectable fragment

Timeline Without Jam Signal:
    Station A: [--Transmitting--]<STOP>              (stops immediately)
    Station B:          [--Transmitting--]           (might continue!)
    Collision:          [XXXX]                       (brief overlap)
                              ↑
                        B might miss this

Timeline With Jam Signal:
    Station A: [--Transmitting--][JAM]<STOP>         (jam before stop)
    Station B:          [--Transmitting--][JAM]<STOP>
    Collision:          [XXXXXXXX][JJJJJJ]           (extended overlap)
                        ↑                ↑
                  Both stations MUST detect this

Collision Enforcement

The jam signal doesn't just signal a collision—it enforces one. By transmitting additional bits after collision detection, the jamming station ensures the medium remains in a collision state long enough for all network participants to recognize the event.

Jam Signal Specification

The IEEE 802.3 standard precisely defines the jam signal characteristics to ensure consistent behavior across all CSMA/CD implementations.

Official Specification:

Parameter	Value	Notes
Length	32 bits (4 bytes)	Minimum jam duration
Pattern	Any valid bit sequence	Not FCS-valid
Content	Implementation-dependent	Often alternating 1s and 0s
Purpose	Extend collision for detection	Must not match valid frame

The 32-Bit Requirement:

The jam signal must be exactly 32 bits (minimum). This duration was chosen because:

Propagation Coverage: 32 bits at 10 Mbps = 3.2 μs, providing time for the jam to propagate across the collision domain
Detection Threshold: Receivers can reliably detect 32+ bits of collision-quality signal
Fragment Differentiation: 32 bits added to any collision fragment helps distinguish collisions from noise
Minimum Collision Fragment: The slot time ensures a station transmits at least 64 bytes; with jam, even early collisions produce at least ~10-20 bytes of recognizable collision fragment

jam_signal.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// IEEE 802.3 Jam Signal Implementation
 
const JAM_LENGTH_BITS = 32;  // Minimum jam signal length
const JAM_LENGTH_BYTES = 4;  // 32 bits / 8 = 4 bytes
 
// Common jam patterns (implementation-dependent)
const JAM_PATTERNS = {
    // Alternating pattern - easy to generate, distinct from data
    ALTERNATING: 0b10101010101010101010101010101010,
    
    // All ones - maximizes signal energy
    ALL_ONES: 0b11111111111111111111111111111111,
    
    // Pseudo-random - some implementations use this
    RANDOM: "implementation-specific",
    
    // The standard allows ANY pattern as long as:
    // 1. It's at least 32 bits
    // 2. It produces collision characteristics on the medium
    // 3. It doesn't form a valid FCS
};
 
interface JamSignalConfig {
    pattern: number;
    lengthBits: number;
    transmissionTime: number;  // in nanoseconds at given speed
}
 
function calculateJamTiming(speedMbps: number): JamSignalConfig {
    const bitTimeNs = 1000 / speedMbps;  // nanoseconds per bit
    const transmissionTime = JAM_LENGTH_BITS * bitTimeNs;
    
    return {
        pattern: JAM_PATTERNS.ALTERNATING,
        lengthBits: JAM_LENGTH_BITS,
        transmissionTime,  // ns
    };
}
 
// Jam signal timing at different speeds
console.log("10 Mbps:", calculateJamTiming(10));
// { transmissionTime: 3200 ns = 3.2 μs }
 
console.log("100 Mbps:", calculateJamTiming(100));
// { transmissionTime: 320 ns }
 
console.log("1000 Mbps:", calculateJamTiming(1000));
// { transmissionTime: 32 ns }

Why the Pattern Doesn't Matter:

The specific bit pattern of the jam signal is not critical because:

It combines with other signals: The jam overlaps with the other station's transmission, creating an additive signal that exceeds normal voltage thresholds regardless of bit pattern
It's already in a collision state: Any additional bits during a collision reinforce the collision signature
FCS invalidity is guaranteed: Since the original frame's FCS is computed over the complete payload (which won't be transmitted), any received frame will fail FCS verification

However, the pattern should not be:

All zeros (might be confused with idle in some encodings)
A valid preamble/SFD (might trigger false frame detection)
A valid FCS of a truncated frame (extremely unlikely but theoretically possible)

Common Implementation

Most Ethernet controllers use an alternating 1-0 pattern (0xAA or 0x55) for the jam signal. This pattern is easy to generate with a simple flip-flop circuit and produces a strong, identifiable signal on the medium.

Jam Signal Transmission Process

The jam signal is part of a precise sequence of events that occurs when a collision is detected. Understanding this sequence is essential for grasping CSMA/CD operation.

Complete Collision Handling Sequence:

Collision Detection and Jam Sequence

•Collision Detection: Transceiver detects collision signature (elevated voltage, DC bias shift, bit errors)
•Signal MAC Controller: Transceiver immediately signals the MAC layer that collision has occurred
•Abort Frame Data: MAC controller stops sending frame data to the transceiver
•Initiate Jam: MAC controller commands transceiver to send 32-bit jam signal
•Transmit Jam: Transceiver sends jam pattern onto the medium
•End Transmission: After jam completes, transceiver releases the medium
•Increment Attempt Counter: MAC controller increments collision/retry counter
•Calculate Backoff: Binary exponential backoff algorithm determines wait time
•Wait: Station remains idle for the calculated backoff period
•Retry: After backoff, station returns to carrier sense state

Timing Diagram:

Station A Timeline (collision initiator from A's perspective):

      ┌─────────────────────────────────────────────────────────────────────┐
      │    TRANSMITTING    │ COLLISION │    JAM    │  BACKOFF  │  RETRY    │
      │                     │ DETECTED  │  (32 bits)│           │           │
Time: 0───────────────────→T_col──────→T_jam─────→T_wait─────→T_retry────→
      │                     │           │           │           │           │
      │ Sending frame data  │Stop data  │Send jam   │ Idle      │ CS again  │
      └─────────────────────────────────────────────────────────────────────┘

Medium State:

      ┌─────────────────────────────────────────────────────────────────────┐
      │ A's signal only     │ A+B mixed │ Jam+B     │ Settling  │ Idle      │
      │ (normal)            │(collision)│ (still CD)│           │           │
      └─────────────────────────────────────────────────────────────────────┘

The key insight is that the jam signal extends the collision state on the medium, giving more distant stations additional time to recognize the collision.

collision_handler.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Collision Handling Procedure (MAC Controller)
 
class CSMAController {
    private attemptCount: number = 0;
    private readonly MAX_ATTEMPTS = 16;
    private readonly JAM_BITS = 32;
    private readonly SLOT_TIME = 512;  // bit times
    
    async handleCollision(): Promise<void> {
        // Step 1: Stop transmitting frame data immediately
        this.transceiver.abortFrame();
        
        // Step 2: Transmit jam signal
        // The jam signal must be at least 32 bits
        // and must be transmitted while collision is active
        await this.transceiver.transmitJam(this.JAM_BITS);
        
        // Step 3: Increment attempt counter
        this.attemptCount++;
        
        // Step 4: Check for excessive collisions
        if (this.attemptCount > this.MAX_ATTEMPTS) {
            throw new ExcessiveCollisionError(
                "Frame discarded after 16 collision attempts"
            );
        }
        
        // Step 5: Calculate backoff
        const backoffSlots = this.binaryExponentialBackoff();
        const backoffTime = backoffSlots * this.SLOT_TIME;
        
        // Step 6: Wait for backoff period
        await this.wait(backoffTime);
        
        // Step 7: Return to carrier sense
        // (handled by calling code)
    }
    
    private binaryExponentialBackoff(): number {
        // k = min(attemptCount, 10)
        const k = Math.min(this.attemptCount, 10);
        
        // Choose random value from [0, 2^k - 1]
        const maxSlots = Math.pow(2, k) - 1;
        return Math.floor(Math.random() * (maxSlots + 1));
    }
}

Critical Timing

The jam signal must be transmitted very quickly after collision detection—within a few bit times. Any delay reduces the effectiveness of collision enforcement and may allow other stations to miss the collision. Hardware implementations achieve this with dedicated circuits that react within nanoseconds.

Jam Signal Propagation Analysis

Understanding how the jam signal propagates through the network reveals why 32 bits is sufficient to ensure universal collision detection.

Propagation Scenario Analysis:

Consider the worst-case scenario for collision detection:

Station A is at one end of a maximum-length network (2,500 m for 10BASE5)
Station B is at the opposite end
Both start transmitting at nearly the same instant
The collision occurs near B (A's signal just arrives as B starts)
B detects the collision first
B transmits its jam signal
The jam must propagate all the way back to A

Propagation Timing Calculation:

Network layout (worst case):

Station A ←————————————— 2,500 m ——————————————→ Station B
    ↓                                                ↓
  Starts TX                                      Starts TX
  t = 0                                          t ≈ 0 (just before
                                                    A's signal arrives)

Propagation timeline:

    t = 0:       A begins transmitting, B sees idle medium, B begins transmitting
    
    t = 12.5 μs: A's signal reaches B (one-way propagation delay)
                 B detects collision immediately
                 B stops frame data, begins jam signal
    
    t = 12.5 + 3.2 μs = 15.7 μs:
                 B's jam signal complete
                 Jam propagates toward A
    
    t = 25 μs:   A receives evidence of collision
                 (includes B's signal + jam)

Critical check: A's frame at t = 25 μs:
    A has been transmitting for 25 μs
    At 10 Mbps = 250 bits = 31.25 bytes
    Minimum frame = 64 bytes = 51.2 μs transmission
    ∴ A is still transmitting when collision evidence arrives ✓

Jam Signal Propagation Timing (10 Mbps Ethernet)
Event	Time (μs)	Description
A starts transmitting	0	Frame transmission begins
B sees idle, starts transmitting	~0	Near-simultaneous transmission
A's signal reaches B	12.5	One-way propagation delay
B detects collision	12.5 + ε	Detection latency ~100ns
B starts jam signal	12.5 + ε	Immediate jam response
B's jam completes	15.7	32 bits @ 10Mbps = 3.2 μs
Collision evidence reaches A	25.0	Full round-trip time
A detects collision	25.0 + ε	Within slot time (51.2 μs)

Why 32 Bits is Sufficient:

The jam signal needs to ensure that:

The collision state is extended: The combined signal from the jam + any residual transmissions exceeds collision detection thresholds
All stations detect within slot time: Since the slot time (512 bits = 51.2 μs) exceeds the round-trip time (25 μs) plus jam duration (3.2 μs), all stations will detect the collision before any of them should finish a minimum-length frame
The collision fragment is recognizable: A 32-bit jam added to any partial frame creates a distinctive collision fragment

The Math:

Worst-case collision detection time:
= Round-trip propagation + Jam duration + Detection latency
= 25 μs + 3.2 μs + 0.1 μs
= 28.3 μs

Minimum frame transmission time:
= 64 bytes × 8 bits/byte ÷ 10 Mbps
= 512 bits ÷ 10 Mbps
= 51.2 μs

∴ 51.2 μs > 28.3 μs → All collisions detected while still transmitting ✓

Safety Margin

The slot time (51.2 μs) is almost twice the worst-case collision detection time (28.3 μs). This generous margin accounts for component variations, cable length uncertainties, repeater delays, and ensures reliable operation under all conditions.

Collision Fragments and Their Characteristics

When collisions occur, they produce collision fragments—the remnants of truncated transmissions combined with jam signals. Understanding these fragments helps in network troubleshooting.

Anatomy of a Collision Fragment:

A collision produces fragments from both transmitting stations. The characteristics of these fragments provide clues about the collision:

Size: Typically < 64 bytes (the defining characteristic of runts)
FCS: Invalid (the frame was truncated)
Content: Partial preamble + partial header + possible jam bits
Encoding: May have Manchester violations due to overlapping signals

Types of Collision Fragments:

Early Collision (within 64 bytes):
┌─────────────────────────────────────────────────────┐
│ Preamble │ Partial Header │ [Collision] │ Jam │    │
│  (8B)    │    (0-14B)     │    ~~~~     │(4B) │    │
└─────────────────────────────────────────────────────┘
                 Size: < 64 bytes (RUNT)
                 FCS: Invalid (not computed)
                 Result: Discarded by receivers

Late Collision (after 64 bytes) - SHOULD NOT HAPPEN:
┌────────────────────────────────────────────────────────────────┐
│ Preamble │ Header │ Payload (partial) │ [Collision] │ Jam │   │
│  (8B)    │ (14B)  │    (> 32B)        │    ~~~~     │(4B) │   │
└────────────────────────────────────────────────────────────────┘
                 Size: > 64 bytes
                 FCS: Invalid
                 Result: Serious problem! Indicates network issue

Normal Collision Fragments

•Size: < 64 bytes
•FCS: Invalid or absent
•Includes jam signal bits
•Normal consequence of CSMA/CD
•Expected on shared media
•Handled by retransmission

Late Collision Fragments

•Size: ≥ 64 bytes
•FCS: Invalid
•Collision after slot time
•Indicates network problem!
•Cable too long or duplex mismatch
•Sender may not retry!

Late Collisions: A Serious Problem

A late collision occurs when a collision is detected after the station has been transmitting for more than the slot time (64 bytes). This indicates a fundamental network problem:

Cause	Explanation	Resolution
Cable too long	Signal takes longer than slot time to propagate	Reduce cable lengths
Too many repeaters	Each repeater adds delay	Follow 5-4-3 rule
Duplex mismatch	One side full-duplex (no CSMA/CD), one half-duplex	Configure matching duplex
Faulty NIC	Transceiver not detecting collisions properly	Replace hardware

Why late collisions are dangerous:

If a late collision occurs, the transmitting station has already transmitted more than 64 bytes. According to the protocol, the station believes it has "won" the slot time and might not retry the transmission. The frame is lost without recovery!

Duplex Mismatch Warning

The most common cause of late collisions in modern networks is duplex mismatch. When one port is configured for full-duplex (no CSMA/CD) and the connected port is half-duplex (uses CSMA/CD), the full-duplex side transmits without carrier sensing, causing collisions that the half-duplex side cannot recover from properly. Always verify duplex settings on both ends of a link.

Jam Signals and Network Monitoring

Network monitoring tools track collision-related metrics that include jam signal activity. Understanding these metrics helps diagnose network health.

Key Collision Metrics:

SNMP MIB Variables for Collision Monitoring (IF-MIB)
Counter	OID	Meaning	Healthy Value
ifInErrors	1.3.6.1.2.1.2.2.1.14	Inbound packets with errors	< 0.1% of traffic
dot3StatsSingleCollisionFrames	1.3.6.1.2.1.10.7.2.1.4	Frames succeeded after 1 collision	Low on switched networks
dot3StatsMultipleCollisionFrames	1.3.6.1.2.1.10.7.2.1.5	Frames succeeded after 2-15 collisions	Very low
dot3StatsDeferredTransmissions	1.3.6.1.2.1.10.7.2.1.6	Frames delayed due to busy medium	Expected on shared media
dot3StatsLateCollisions	1.3.6.1.2.1.10.7.2.1.8	Collisions after slot time	Should be ZERO
dot3StatsExcessiveCollisions	1.3.6.1.2.1.10.7.2.1.9	Frames dropped after 16 collisions	Should be ZERO

Interpreting Collision Statistics:

Healthy Network (Half-Duplex):

Some single-collision frames are normal
Low percentage of multi-collision frames
Zero late collisions
Zero excessive collisions

Troubled Network Signs:

High percentage of collisions (> 10% is concerning)
Any late collisions (indicates infrastructure problem)
Excessive collisions (indicates severe congestion or failure)
Rising trend in collision metrics

Healthy Network (Full-Duplex/Switched):

All collision counters should be zero
Any collisions indicate configuration error

collision_monitor.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
#!/usr/bin/env python3
"""
Ethernet Collision Monitor
Analyzes collision statistics to assess network health
"""
 
from dataclasses import dataclass
from typing import Tuple
 
@dataclass
class CollisionStats:
    total_frames: int
    single_collision_frames: int
    multi_collision_frames: int
    late_collisions: int
    excessive_collisions: int
    
def analyze_collision_health(stats: CollisionStats) -> Tuple[str, list]:
    """
    Analyzes collision statistics and returns health assessment
    Returns: (status, list_of_issues)
    """
    issues = []
    
    # Calculate collision rate
    total_collisions = stats.single_collision_frames + stats.multi_collision_frames
    
    if stats.total_frames > 0:
        collision_rate = (total_collisions / stats.total_frames) * 100
    else:
        collision_rate = 0.0
    
    # Check for late collisions (CRITICAL)
    if stats.late_collisions > 0:
        issues.append(
            f"CRITICAL: {stats.late_collisions} late collisions detected. "
            "Check for: cable length violations, duplex mismatch, or faulty NIC"
        )
    
    # Check for excessive collisions (CRITICAL)
    if stats.excessive_collisions > 0:
        issues.append(
            f"CRITICAL: {stats.excessive_collisions} frames dropped due to "
            "excessive collisions. Network is severely congested or misconfigured"
        )
    
    # Check collision rate (WARNING at >5%, CRITICAL at >10%)
    if collision_rate > 10:
        issues.append(
            f"CRITICAL: Collision rate {collision_rate:.1f}% exceeds 10%. "
            "Network performance severely degraded"
        )
    elif collision_rate > 5:
        issues.append(
            f"WARNING: Collision rate {collision_rate:.1f}% exceeds 5%. "
            "Consider network segmentation"
        )
    elif collision_rate > 1:
        issues.append(
            f"INFO: Collision rate {collision_rate:.1f}% is elevated. "
            "Monitor for increasing trend"
        )
    
    # Full-duplex check (any collisions on full-duplex = misconfiguration)
    # This would need additional context about port configuration
    
    # Determine overall status
    if stats.late_collisions > 0 or stats.excessive_collisions > 0:
        status = "CRITICAL"
    elif collision_rate > 10:
        status = "CRITICAL"
    elif collision_rate > 5:
        status = "WARNING"
    elif collision_rate > 0:
        status = "NORMAL"
    else:
        status = "OPTIMAL"
    
    return status, issues
 
# Example usage
stats = CollisionStats(
    total_frames=1000000,
    single_collision_frames=5000,
    multi_collision_frames=500,
    late_collisions=0,
    excessive_collisions=0
)
 
status, issues = analyze_collision_health(stats)
print(f"Status: {status}")
for issue in issues:
    print(f"  - {issue}")

Modern Networks

In properly configured modern networks with full-duplex switched ports, ALL collision counters should read zero. Non-zero values are a clear indication of misconfiguration, typically an auto-negotiation failure causing a duplex mismatch.

Summary: The Critical Role of Jam Signals

The jam signal is a small but critical component of CSMA/CD that ensures reliable collision handling across all network stations.

Key Takeaways

•Jam signals enforce collisions — They extend collision state long enough for all stations to detect it.
•32 bits is the standard length — 3.2 μs at 10 Mbps, sufficient for network-wide propagation.
•Pattern is implementation-dependent — Often alternating bits (0xAA), but any valid pattern works.
•Jam follows collision detection — Immediate transmission after collision is detected, before backoff.
•Late collisions indicate problems — Collisions after slot time suggest infrastructure or configuration issues.
•Full-duplex eliminates jam need — Modern switched networks disable CSMA/CD entirely.

What's Next:

With collision detection, minimum frame size, and jam signals understood, we can now analyze the efficiency of CSMA/CD. How much of the network's capacity is actually used for data versus collision overhead? The next page presents the mathematical analysis of CSMA/CD throughput.

Page Complete

You now understand the jam signal's role in CSMA/CD—how it enforces collision detection across all network stations and enables the protocol to function reliably. Next, we'll analyze the efficiency of CSMA/CD to understand its practical performance characteristics.

3 / 5

Loading learning content...

Computer NetworksCSMA/CD

CSMA/CD: Carrier Sense Multiple Access with Collision Detection

LevelIntermediate

Duration60 mins

TopicCSMA/CD

3 / 5

Jam Signal — Enforcing Collision Acknowledgment

The Universal Stop Signal

Without the jam signal, different stations might have different views of the collision event, leading to protocol inconsistencies and potential data loss.

What You Will Learn

Why Jam Signals Are Necessary

To understand the necessity of jam signals, consider a scenario without them:

The Problem Scenario:

Station A (at one end of network) starts transmitting a frame
Station B (at the other end) starts transmitting before A's signal reaches it
The signals collide somewhere in the middle of the network
Station A detects the collision (it sees B's signal mixed with its own)
Station A stops transmitting
Problem: Station B may not have detected the collision yet!

If Station A simply stops transmitting, several issues arise:

The network might return to idle before station B realizes there was a collision
Station B might continue transmitting, believing everything is normal
The partial frame from A might not be long enough for B to recognize as a collision

Collision Detection Without vs. With Jam Signal
Scenario	Without Jam	With Jam
Station A detects collision	Stops transmitting	Transmits jam, then stops
Signal on medium	Goes idle quickly	Remains corrupted longer
Station B detection	May miss collision	Guaranteed to detect
Protocol state	Potentially inconsistent	Always consistent
Recovery	B may finish corrupted frame	Both stations backoff

The Jam Signal Solution:

The jam signal addresses these issues by:

Extending collision duration: The jam signal ensures the collision condition persists long enough for all stations to detect it
Reinforcing collision signature: The jam signal's pattern, combined with other transmissions, produces unmistakable collision characteristics
Guaranteeing minimum collision fragment: The jam ensures that even the shortest collision produces a detectable fragment

Timeline Without Jam Signal:
    Station A: [--Transmitting--]<STOP>              (stops immediately)
    Station B:          [--Transmitting--]           (might continue!)
    Collision:          [XXXX]                       (brief overlap)
                              ↑
                        B might miss this

Timeline With Jam Signal:
    Station A: [--Transmitting--][JAM]<STOP>         (jam before stop)
    Station B:          [--Transmitting--][JAM]<STOP>
    Collision:          [XXXXXXXX][JJJJJJ]           (extended overlap)
                        ↑                ↑
                  Both stations MUST detect this

Collision Enforcement

Jam Signal Specification

The IEEE 802.3 standard precisely defines the jam signal characteristics to ensure consistent behavior across all CSMA/CD implementations.

Official Specification:

Parameter	Value	Notes
Length	32 bits (4 bytes)	Minimum jam duration
Pattern	Any valid bit sequence	Not FCS-valid
Content	Implementation-dependent	Often alternating 1s and 0s
Purpose	Extend collision for detection	Must not match valid frame

The 32-Bit Requirement:

The jam signal must be exactly 32 bits (minimum). This duration was chosen because:

Propagation Coverage: 32 bits at 10 Mbps = 3.2 μs, providing time for the jam to propagate across the collision domain
Detection Threshold: Receivers can reliably detect 32+ bits of collision-quality signal
Fragment Differentiation: 32 bits added to any collision fragment helps distinguish collisions from noise
Minimum Collision Fragment: The slot time ensures a station transmits at least 64 bytes; with jam, even early collisions produce at least ~10-20 bytes of recognizable collision fragment

jam_signal.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// IEEE 802.3 Jam Signal Implementation
 
const JAM_LENGTH_BITS = 32;  // Minimum jam signal length
const JAM_LENGTH_BYTES = 4;  // 32 bits / 8 = 4 bytes
 
// Common jam patterns (implementation-dependent)
const JAM_PATTERNS = {
    // Alternating pattern - easy to generate, distinct from data
    ALTERNATING: 0b10101010101010101010101010101010,
    
    // All ones - maximizes signal energy
    ALL_ONES: 0b11111111111111111111111111111111,
    
    // Pseudo-random - some implementations use this
    RANDOM: "implementation-specific",
    
    // The standard allows ANY pattern as long as:
    // 1. It's at least 32 bits
    // 2. It produces collision characteristics on the medium
    // 3. It doesn't form a valid FCS
};
 
interface JamSignalConfig {
    pattern: number;
    lengthBits: number;
    transmissionTime: number;  // in nanoseconds at given speed
}
 
function calculateJamTiming(speedMbps: number): JamSignalConfig {
    const bitTimeNs = 1000 / speedMbps;  // nanoseconds per bit
    const transmissionTime = JAM_LENGTH_BITS * bitTimeNs;
    
    return {
        pattern: JAM_PATTERNS.ALTERNATING,
        lengthBits: JAM_LENGTH_BITS,
        transmissionTime,  // ns
    };
}
 
// Jam signal timing at different speeds
console.log("10 Mbps:", calculateJamTiming(10));
// { transmissionTime: 3200 ns = 3.2 μs }
 
console.log("100 Mbps:", calculateJamTiming(100));
// { transmissionTime: 320 ns }
 
console.log("1000 Mbps:", calculateJamTiming(1000));
// { transmissionTime: 32 ns }

Why the Pattern Doesn't Matter:

The specific bit pattern of the jam signal is not critical because:

It combines with other signals: The jam overlaps with the other station's transmission, creating an additive signal that exceeds normal voltage thresholds regardless of bit pattern
It's already in a collision state: Any additional bits during a collision reinforce the collision signature
FCS invalidity is guaranteed: Since the original frame's FCS is computed over the complete payload (which won't be transmitted), any received frame will fail FCS verification

However, the pattern should not be:

All zeros (might be confused with idle in some encodings)
A valid preamble/SFD (might trigger false frame detection)
A valid FCS of a truncated frame (extremely unlikely but theoretically possible)

Common Implementation

Jam Signal Transmission Process

The jam signal is part of a precise sequence of events that occurs when a collision is detected. Understanding this sequence is essential for grasping CSMA/CD operation.

Complete Collision Handling Sequence:

Collision Detection and Jam Sequence

•Collision Detection: Transceiver detects collision signature (elevated voltage, DC bias shift, bit errors)
•Signal MAC Controller: Transceiver immediately signals the MAC layer that collision has occurred
•Abort Frame Data: MAC controller stops sending frame data to the transceiver
•Initiate Jam: MAC controller commands transceiver to send 32-bit jam signal
•Transmit Jam: Transceiver sends jam pattern onto the medium
•End Transmission: After jam completes, transceiver releases the medium
•Increment Attempt Counter: MAC controller increments collision/retry counter
•Calculate Backoff: Binary exponential backoff algorithm determines wait time
•Wait: Station remains idle for the calculated backoff period
•Retry: After backoff, station returns to carrier sense state

Timing Diagram:

Station A Timeline (collision initiator from A's perspective):

      ┌─────────────────────────────────────────────────────────────────────┐
      │    TRANSMITTING    │ COLLISION │    JAM    │  BACKOFF  │  RETRY    │
      │                     │ DETECTED  │  (32 bits)│           │           │
Time: 0───────────────────→T_col──────→T_jam─────→T_wait─────→T_retry────→
      │                     │           │           │           │           │
      │ Sending frame data  │Stop data  │Send jam   │ Idle      │ CS again  │
      └─────────────────────────────────────────────────────────────────────┘

Medium State:

      ┌─────────────────────────────────────────────────────────────────────┐
      │ A's signal only     │ A+B mixed │ Jam+B     │ Settling  │ Idle      │
      │ (normal)            │(collision)│ (still CD)│           │           │
      └─────────────────────────────────────────────────────────────────────┘

The key insight is that the jam signal extends the collision state on the medium, giving more distant stations additional time to recognize the collision.

collision_handler.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Collision Handling Procedure (MAC Controller)
 
class CSMAController {
    private attemptCount: number = 0;
    private readonly MAX_ATTEMPTS = 16;
    private readonly JAM_BITS = 32;
    private readonly SLOT_TIME = 512;  // bit times
    
    async handleCollision(): Promise<void> {
        // Step 1: Stop transmitting frame data immediately
        this.transceiver.abortFrame();
        
        // Step 2: Transmit jam signal
        // The jam signal must be at least 32 bits
        // and must be transmitted while collision is active
        await this.transceiver.transmitJam(this.JAM_BITS);
        
        // Step 3: Increment attempt counter
        this.attemptCount++;
        
        // Step 4: Check for excessive collisions
        if (this.attemptCount > this.MAX_ATTEMPTS) {
            throw new ExcessiveCollisionError(
                "Frame discarded after 16 collision attempts"
            );
        }
        
        // Step 5: Calculate backoff
        const backoffSlots = this.binaryExponentialBackoff();
        const backoffTime = backoffSlots * this.SLOT_TIME;
        
        // Step 6: Wait for backoff period
        await this.wait(backoffTime);
        
        // Step 7: Return to carrier sense
        // (handled by calling code)
    }
    
    private binaryExponentialBackoff(): number {
        // k = min(attemptCount, 10)
        const k = Math.min(this.attemptCount, 10);
        
        // Choose random value from [0, 2^k - 1]
        const maxSlots = Math.pow(2, k) - 1;
        return Math.floor(Math.random() * (maxSlots + 1));
    }
}

Critical Timing

Jam Signal Propagation Analysis

Understanding how the jam signal propagates through the network reveals why 32 bits is sufficient to ensure universal collision detection.

Propagation Scenario Analysis:

Consider the worst-case scenario for collision detection:

Station A is at one end of a maximum-length network (2,500 m for 10BASE5)
Station B is at the opposite end
Both start transmitting at nearly the same instant
The collision occurs near B (A's signal just arrives as B starts)
B detects the collision first
B transmits its jam signal
The jam must propagate all the way back to A

Propagation Timing Calculation:

Network layout (worst case):

Station A ←————————————— 2,500 m ——————————————→ Station B
    ↓                                                ↓
  Starts TX                                      Starts TX
  t = 0                                          t ≈ 0 (just before
                                                    A's signal arrives)

Propagation timeline:

    t = 0:       A begins transmitting, B sees idle medium, B begins transmitting
    
    t = 12.5 μs: A's signal reaches B (one-way propagation delay)
                 B detects collision immediately
                 B stops frame data, begins jam signal
    
    t = 12.5 + 3.2 μs = 15.7 μs:
                 B's jam signal complete
                 Jam propagates toward A
    
    t = 25 μs:   A receives evidence of collision
                 (includes B's signal + jam)

Critical check: A's frame at t = 25 μs:
    A has been transmitting for 25 μs
    At 10 Mbps = 250 bits = 31.25 bytes
    Minimum frame = 64 bytes = 51.2 μs transmission
    ∴ A is still transmitting when collision evidence arrives ✓

Jam Signal Propagation Timing (10 Mbps Ethernet)
Event	Time (μs)	Description
A starts transmitting	0	Frame transmission begins
B sees idle, starts transmitting	~0	Near-simultaneous transmission
A's signal reaches B	12.5	One-way propagation delay
B detects collision	12.5 + ε	Detection latency ~100ns
B starts jam signal	12.5 + ε	Immediate jam response
B's jam completes	15.7	32 bits @ 10Mbps = 3.2 μs
Collision evidence reaches A	25.0	Full round-trip time
A detects collision	25.0 + ε	Within slot time (51.2 μs)

Why 32 Bits is Sufficient:

The jam signal needs to ensure that:

The collision state is extended: The combined signal from the jam + any residual transmissions exceeds collision detection thresholds
All stations detect within slot time: Since the slot time (512 bits = 51.2 μs) exceeds the round-trip time (25 μs) plus jam duration (3.2 μs), all stations will detect the collision before any of them should finish a minimum-length frame
The collision fragment is recognizable: A 32-bit jam added to any partial frame creates a distinctive collision fragment

The Math:

Worst-case collision detection time:
= Round-trip propagation + Jam duration + Detection latency
= 25 μs + 3.2 μs + 0.1 μs
= 28.3 μs

Minimum frame transmission time:
= 64 bytes × 8 bits/byte ÷ 10 Mbps
= 512 bits ÷ 10 Mbps
= 51.2 μs

∴ 51.2 μs > 28.3 μs → All collisions detected while still transmitting ✓

Safety Margin

Collision Fragments and Their Characteristics

When collisions occur, they produce collision fragments—the remnants of truncated transmissions combined with jam signals. Understanding these fragments helps in network troubleshooting.

Anatomy of a Collision Fragment:

A collision produces fragments from both transmitting stations. The characteristics of these fragments provide clues about the collision:

Size: Typically < 64 bytes (the defining characteristic of runts)
FCS: Invalid (the frame was truncated)
Content: Partial preamble + partial header + possible jam bits
Encoding: May have Manchester violations due to overlapping signals

Types of Collision Fragments:

Early Collision (within 64 bytes):
┌─────────────────────────────────────────────────────┐
│ Preamble │ Partial Header │ [Collision] │ Jam │    │
│  (8B)    │    (0-14B)     │    ~~~~     │(4B) │    │
└─────────────────────────────────────────────────────┘
                 Size: < 64 bytes (RUNT)
                 FCS: Invalid (not computed)
                 Result: Discarded by receivers

Late Collision (after 64 bytes) - SHOULD NOT HAPPEN:
┌────────────────────────────────────────────────────────────────┐
│ Preamble │ Header │ Payload (partial) │ [Collision] │ Jam │   │
│  (8B)    │ (14B)  │    (> 32B)        │    ~~~~     │(4B) │   │
└────────────────────────────────────────────────────────────────┘
                 Size: > 64 bytes
                 FCS: Invalid
                 Result: Serious problem! Indicates network issue

Normal Collision Fragments

•Size: < 64 bytes
•FCS: Invalid or absent
•Includes jam signal bits
•Normal consequence of CSMA/CD
•Expected on shared media
•Handled by retransmission

Late Collision Fragments

•Size: ≥ 64 bytes
•FCS: Invalid
•Collision after slot time
•Indicates network problem!
•Cable too long or duplex mismatch
•Sender may not retry!

Late Collisions: A Serious Problem

A late collision occurs when a collision is detected after the station has been transmitting for more than the slot time (64 bytes). This indicates a fundamental network problem:

Cause	Explanation	Resolution
Cable too long	Signal takes longer than slot time to propagate	Reduce cable lengths
Too many repeaters	Each repeater adds delay	Follow 5-4-3 rule
Duplex mismatch	One side full-duplex (no CSMA/CD), one half-duplex	Configure matching duplex
Faulty NIC	Transceiver not detecting collisions properly	Replace hardware

Why late collisions are dangerous:

Duplex Mismatch Warning

Jam Signals and Network Monitoring

Network monitoring tools track collision-related metrics that include jam signal activity. Understanding these metrics helps diagnose network health.

Key Collision Metrics:

SNMP MIB Variables for Collision Monitoring (IF-MIB)
Counter	OID	Meaning	Healthy Value
ifInErrors	1.3.6.1.2.1.2.2.1.14	Inbound packets with errors	< 0.1% of traffic
dot3StatsSingleCollisionFrames	1.3.6.1.2.1.10.7.2.1.4	Frames succeeded after 1 collision	Low on switched networks
dot3StatsMultipleCollisionFrames	1.3.6.1.2.1.10.7.2.1.5	Frames succeeded after 2-15 collisions	Very low
dot3StatsDeferredTransmissions	1.3.6.1.2.1.10.7.2.1.6	Frames delayed due to busy medium	Expected on shared media
dot3StatsLateCollisions	1.3.6.1.2.1.10.7.2.1.8	Collisions after slot time	Should be ZERO
dot3StatsExcessiveCollisions	1.3.6.1.2.1.10.7.2.1.9	Frames dropped after 16 collisions	Should be ZERO

Interpreting Collision Statistics:

Healthy Network (Half-Duplex):

Some single-collision frames are normal
Low percentage of multi-collision frames
Zero late collisions
Zero excessive collisions

Troubled Network Signs:

High percentage of collisions (> 10% is concerning)
Any late collisions (indicates infrastructure problem)
Excessive collisions (indicates severe congestion or failure)
Rising trend in collision metrics

Healthy Network (Full-Duplex/Switched):

All collision counters should be zero
Any collisions indicate configuration error

collision_monitor.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
#!/usr/bin/env python3
"""
Ethernet Collision Monitor
Analyzes collision statistics to assess network health
"""
 
from dataclasses import dataclass
from typing import Tuple
 
@dataclass
class CollisionStats:
    total_frames: int
    single_collision_frames: int
    multi_collision_frames: int
    late_collisions: int
    excessive_collisions: int
    
def analyze_collision_health(stats: CollisionStats) -> Tuple[str, list]:
    """
    Analyzes collision statistics and returns health assessment
    Returns: (status, list_of_issues)
    """
    issues = []
    
    # Calculate collision rate
    total_collisions = stats.single_collision_frames + stats.multi_collision_frames
    
    if stats.total_frames > 0:
        collision_rate = (total_collisions / stats.total_frames) * 100
    else:
        collision_rate = 0.0
    
    # Check for late collisions (CRITICAL)
    if stats.late_collisions > 0:
        issues.append(
            f"CRITICAL: {stats.late_collisions} late collisions detected. "
            "Check for: cable length violations, duplex mismatch, or faulty NIC"
        )
    
    # Check for excessive collisions (CRITICAL)
    if stats.excessive_collisions > 0:
        issues.append(
            f"CRITICAL: {stats.excessive_collisions} frames dropped due to "
            "excessive collisions. Network is severely congested or misconfigured"
        )
    
    # Check collision rate (WARNING at >5%, CRITICAL at >10%)
    if collision_rate > 10:
        issues.append(
            f"CRITICAL: Collision rate {collision_rate:.1f}% exceeds 10%. "
            "Network performance severely degraded"
        )
    elif collision_rate > 5:
        issues.append(
            f"WARNING: Collision rate {collision_rate:.1f}% exceeds 5%. "
            "Consider network segmentation"
        )
    elif collision_rate > 1:
        issues.append(
            f"INFO: Collision rate {collision_rate:.1f}% is elevated. "
            "Monitor for increasing trend"
        )
    
    # Full-duplex check (any collisions on full-duplex = misconfiguration)
    # This would need additional context about port configuration
    
    # Determine overall status
    if stats.late_collisions > 0 or stats.excessive_collisions > 0:
        status = "CRITICAL"
    elif collision_rate > 10:
        status = "CRITICAL"
    elif collision_rate > 5:
        status = "WARNING"
    elif collision_rate > 0:
        status = "NORMAL"
    else:
        status = "OPTIMAL"
    
    return status, issues
 
# Example usage
stats = CollisionStats(
    total_frames=1000000,
    single_collision_frames=5000,
    multi_collision_frames=500,
    late_collisions=0,
    excessive_collisions=0
)
 
status, issues = analyze_collision_health(stats)
print(f"Status: {status}")
for issue in issues:
    print(f"  - {issue}")

Modern Networks

Summary: The Critical Role of Jam Signals

The jam signal is a small but critical component of CSMA/CD that ensures reliable collision handling across all network stations.

Key Takeaways

•Jam signals enforce collisions — They extend collision state long enough for all stations to detect it.
•32 bits is the standard length — 3.2 μs at 10 Mbps, sufficient for network-wide propagation.
•Pattern is implementation-dependent — Often alternating bits (0xAA), but any valid pattern works.
•Jam follows collision detection — Immediate transmission after collision is detected, before backoff.
•Late collisions indicate problems — Collisions after slot time suggest infrastructure or configuration issues.
•Full-duplex eliminates jam need — Modern switched networks disable CSMA/CD entirely.

What's Next:

Page Complete

3 / 5