diff options
Diffstat (limited to 'comp347/assignment3/assignment3.md')
| -rw-r--r-- | comp347/assignment3/assignment3.md | 216 |
1 files changed, 215 insertions, 1 deletions
diff --git a/comp347/assignment3/assignment3.md b/comp347/assignment3/assignment3.md index 6a8c850..26c7796 100644 --- a/comp347/assignment3/assignment3.md +++ b/comp347/assignment3/assignment3.md @@ -1052,4 +1052,218 @@ This marks the successful completion of the entire RTS/CTS/Data/ACK sequence. ### 2.5 Bluetooth Frame Format Analysis (10%) -[To be completed]
\ No newline at end of file +## Bluetooth Technology Overview + +Bluetooth is a short-range wireless communication technology operating in the 2.4 GHz ISM band, designed for personal area networks (PANs). Originally developed by Ericsson in 1994, Bluetooth uses frequency-hopping spread spectrum (FHSS) and time division duplex (TDD) to enable multiple devices to communicate within a small coverage area. + +## Bluetooth Frame Format Structure + +### Basic Frame Components + +Bluetooth frames consist of three main components arranged in the following structure: + +``` +[Access Code] [Header] [Payload] + 72 bits 54 bits 0-2745 bits +``` + +### 1. Access Code (72 bits) +The Access Code serves multiple critical functions: + +**Structure:** +- **Preamble:** 4 bits (fixed pattern for synchronization) +- **Sync Word:** 64 bits (derived from master device's clock and ID) +- **Trailer:** 4 bits (optional, used for better correlation) + +**Functions:** +- **Device Identification:** Uniquely identifies the piconet master +- **Synchronization:** Enables receiver clock and frequency synchronization +- **Packet Detection:** Allows devices to distinguish Bluetooth signals from noise +- **Piconet Separation:** Different piconets use different access codes + +**Types of Access Codes:** +- **Channel Access Code (CAC):** Used for regular data transmission +- **Device Access Code (DAC):** Used during inquiry and paging procedures +- **Inquiry Access Code (IAC):** Used for device discovery + +### 2. Header (54 bits) +The Header contains control and addressing information: + +**Header Fields:** +- **AM_ADDR (3 bits):** Active Member Address - identifies active devices in piconet +- **TYPE (4 bits):** Packet type specification +- **FLOW (1 bit):** Flow control for stop-and-wait ARQ +- **ARQN (1 bit):** Automatic Repeat Request acknowledgment +- **SEQN (1 bit):** Sequence number for packet ordering +- **HEC (8 bits):** Header Error Check for error detection + +**Header Encoding:** +- The 18-bit header is encoded with a 1/3 rate FEC (Forward Error Correction) +- Results in 54 transmitted bits for enhanced error protection +- Uses repetition coding where each bit is repeated three times + +### 3. Payload (0-2745 bits) +The Payload carries actual user data and varies by packet type: + +**Payload Structure:** +- **Payload Header:** Contains length and flow control information +- **Payload Body:** User data (voice, text, files, etc.) +- **CRC (Cyclic Redundancy Check):** Error detection for payload data + +## Detailed Frame Analysis + +### Packet Types and Payload Sizes + +**Control Packets:** +- **ID packets:** 0 bits payload (only Access Code and Header) +- **NULL packets:** 0 bits payload (used for acknowledgment) +- **POLL packets:** 0 bits payload (used to poll slave devices) + +**SCO (Synchronous Connection-Oriented) Packets:** +- **HV1:** 80 bits payload (voice data, 1/3 FEC protection) +- **HV2:** 160 bits payload (voice data, 2/3 FEC protection) +- **HV3:** 240 bits payload (voice data, no FEC protection) + +**ACL (Asynchronous Connectionless) Packets:** +- **DM1:** 136 bits payload (medium data rate, 2/3 FEC) +- **DH1:** 240 bits payload (high data rate, no FEC) +- **DM3:** 968 bits payload (medium data rate, 2/3 FEC) +- **DH3:** 1464 bits payload (high data rate, no FEC) +- **DM5:** 1784 bits payload (medium data rate, 2/3 FEC) +- **DH5:** 2744 bits payload (high data rate, no FEC) + +### Frame Features and Characteristics + +#### 1. Error Protection Mechanisms +**Forward Error Correction (FEC):** +- **1/3 Rate FEC:** Each bit repeated three times (used for header and some payloads) +- **2/3 Rate FEC:** Uses (15,10) shortened Hamming code +- **ARQ (Automatic Repeat Request):** Stop-and-wait protocol for reliable transmission + +**Error Detection:** +- **Header Error Check (HEC):** 8-bit CRC for header protection +- **Payload CRC:** 16-bit CRC for payload data integrity + +#### 2. Addressing and Flow Control +**Active Member Address (AM_ADDR):** +- **3-bit field:** Supports up to 7 active devices (0 reserved for broadcast) +- **Temporary Assignment:** Assigned by master when device becomes active +- **Limitation Factor:** This is the primary reason for the 8-device limit + +**Flow Control:** +- **FLOW bit:** Implements stop-and-wait flow control +- **ARQN/SEQN:** Provides reliable data transfer with acknowledgments + +#### 3. Frequency Hopping Integration +- **Access Code synchronization:** Enables proper frequency hop timing +- **Hop Selection:** Based on master's clock and device ID +- **79 Frequencies:** Uses 79 different frequencies in 2.4 GHz band +- **1600 hops/second:** Changes frequency every 625 μs + +## Analysis of Eight-Device Limitation + +### Why is Bluetooth Limited to Eight Active Nodes? + +The limitation to eight active nodes in a Bluetooth piconet is **directly imposed by the frame format**, specifically the AM_ADDR field: + +#### 1. AM_ADDR Field Constraint +- **Field Size:** 3 bits in the frame header +- **Possible Values:** 2³ = 8 possible combinations (000 to 111) +- **Reserved Value:** 000 is reserved for broadcast messages +- **Available Addresses:** 7 addresses available for individual devices (001 to 111) +- **Total Active Devices:** 7 active slaves + 1 master = 8 total devices + +#### 2. Frame Format Impact +**Why the AM_ADDR field is this small:** +- **Header Size Optimization:** Bluetooth was designed for low-power, low-complexity devices +- **Overhead Minimization:** Smaller addressing reduces frame overhead +- **Processing Simplicity:** 3-bit addresses simplify hardware implementation +- **Battery Life:** Shorter frames mean less transmission time and lower power consumption + +#### 3. Alternative Addressing Mechanisms +**Parked Devices:** +- Use different addressing scheme with 8-bit Parked Member Address (PM_ADDR) +- Can support up to 255 parked devices +- Parked devices cannot actively communicate without becoming active +- Must transition from parked to active state to participate in data exchange + +**Device Access Code (DAC):** +- Each device has unique 48-bit BD_ADDR (Bluetooth Device Address) +- Used during connection establishment, not regular data transmission +- Would create excessive overhead if used in every frame + +### Comparison with Other Wireless Technologies + +| Technology | Max Active Devices | Addressing Mechanism | Address Size | +|------------|-------------------|---------------------|--------------| +| **Bluetooth** | 8 (7 active slaves) | AM_ADDR in frame header | 3 bits | +| **Wi-Fi** | 2007+ devices | MAC addresses | 48 bits | +| **Zigbee** | 65,000+ devices | Network + device addresses | 16 + 64 bits | + +## Limitations and Design Trade-offs + +### Frame Format Limitations + +#### 1. Addressing Constraints +**Limited Active Devices:** +- Only 8 devices can actively participate in data transmission +- Additional devices must be in parked or standby states +- Requires complex state management for larger networks + +**No Mesh Networking:** +- Frame format designed for star topology only +- Master-slave architecture inherent in addressing scheme +- Cannot support native mesh networking without protocol modifications + +#### 2. Overhead Considerations +**High Overhead for Small Payloads:** +- Access Code (72 bits) and Header (54 bits) = 126 bits fixed overhead +- For small payloads, overhead percentage is very high +- Example: ID packet has 126 bits overhead with 0 bits payload + +**FEC Redundancy:** +- 1/3 FEC triples header size (18 → 54 bits) +- Trades bandwidth efficiency for error resilience +- Appropriate for noisy 2.4 GHz environment + +#### 3. Scalability Issues +**Piconet Size Limitation:** +- Inherently limits network scalability +- Requires scatternet formation for larger networks +- Complex inter-piconet communication protocols needed + +**Master Bottleneck:** +- All communication must pass through master device +- Single point of failure for the entire piconet +- Master must manage all slaves' timing and addressing + +### Design Strengths + +#### 1. Error Resilience +**Robust Error Protection:** +- Multiple layers of error detection and correction +- Suitable for industrial and interference-prone environments +- Automatic retransmission ensures reliability + +#### 2. Low Power Design +**Efficient Power Management:** +- Short frames reduce transmission time +- Simple addressing minimizes processing requirements +- Frequency hopping provides interference resistance + +#### 3. Simplicity +**Implementation Efficiency:** +- Simple frame structure reduces hardware complexity +- Fixed field sizes enable fast processing +- Minimal protocol overhead for basic operations + +## Conclusion + +**The Bluetooth frame format reflects design priorities of the 1990s:** low power consumption, simple implementation, and reliable short-range communication. The eight-device limitation is a **direct consequence** of the 3-bit AM_ADDR field in the frame header, which was chosen to minimize overhead and complexity. + +**Key Trade-offs:** +- **Simplicity vs. Scalability:** Chose simple addressing over large network support +- **Reliability vs. Efficiency:** Emphasized error protection over bandwidth efficiency +- **Power vs. Performance:** Optimized for battery life over high data rates + +**Modern Context:** While these limitations restrict Bluetooth's use in large-scale networking applications, they make it ideal for personal area networks, IoT devices, and applications requiring reliable, low-power, short-range communication. The frame format limitations have been partially addressed in newer Bluetooth versions (BLE, mesh networking) while maintaining backward compatibility with the original design principles.
\ No newline at end of file |