Loading learning content...
Consider two ways to see a doctor: walk-in or by appointment. Walk-in clinics are simple—just show up and wait. But if the clinic is busy, you might wait hours, and there's no guarantee you'll be seen before closing time. Appointments, however, give you a guaranteed time slot. You know exactly when you'll be seen, and the clinic can plan its resources efficiently.
Reservation-based protocols bring this appointment model to network access. Instead of competing for the channel (contention) or waiting to be asked (polling) or waiting for a token, stations reserve transmission time in advance. The result is collision-free access with guaranteed bandwidth allocation—essential for applications like satellite communication where contention delays are catastrophic and resources are precious.
Reservation protocols represent a sophisticated hybrid: they use a small control period for reservation requests, then allocate dedicated time slots for actual data transmission. This architecture delivers both flexibility and determinism.
By the end of this page, you will understand reservation-based medium access—how reservation frames work, the structure of reservation periods and data periods, TDMA-based reservation schemes, Reservation ALOHA, Bit-Map protocols, and modern applications in satellite and cellular networks. You'll see how reservation bridges the gap between pure contention and pure controlled access.
Reservation protocols divide time into frames (not to be confused with data frames), each containing two distinct periods:
Reservation-Based MAC Structure:
Reservation Period (Control Phase)
Data Period (Transmission Phase)
Why Reservations Work:
| Benefit | Explanation |
|---|---|
| Collision avoidance | Reservations resolve contention before data transmission |
| Bandwidth efficiency | Only stations with data get slots; no polling of idle stations |
| Bounded delay | Successful reservation guarantees transmission time |
| Traffic adaptation | More active stations get more slots; bandwidth follows demand |
| Priority support | Reservation systems can prioritize by traffic type or source |
Key Design Decisions:
1. How are reservations made?
2. How are slots allocated?
3. How long is a frame?
If reservation overhead is R and data period is D, efficiency = D/(R+D). For efficiency >90%, you need D > 9R. A 10-slot reservation period requires at least a 90-slot data period for good efficiency. This is why reservation protocols excel with longer messages and consistent traffic patterns.
The Bit-Map Protocol (also called the Bit-Map Reservation Protocol) is the simplest and most intuitive reservation scheme. Each of N stations is assigned a dedicated mini-slot in the reservation period.
Protocol Operation:
Example with 8 Stations:
Reservation Period:
Slot: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
Bit: | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 |
Meaning: | - | 2 | 3 | - | - | 6 | - | 8 | ← Stations 2, 3, 6, 8 will transmit
Data Period:
Slot 1: Station 2 transmits
Slot 2: Station 3 transmits
Slot 3: Station 6 transmits
Slot 4: Station 8 transmits
(No slots wasted on stations 1, 4, 5, 7)
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293
from typing import List, Optionalfrom dataclasses import dataclassimport time @dataclassclass ReservationFrame: """Represents one reservation period + data period cycle.""" num_stations: int reservation_bits: List[bool] # One bit per station data_slots: List[Optional[bytes]] # Actual data to transmit slot_duration_ms: float @property def reservation_duration_ms(self) -> float: """Reservation period is very short - 1 bit per station.""" # Assume 1 bit per station at data rate return self.num_stations * 0.001 # ~1μs per bit at 1 Gbps @property def data_duration_ms(self) -> float: """Data period = num_active_stations × slot_duration.""" active = sum(self.reservation_bits) return active * self.slot_duration_ms class BitMapStation: """Station implementing Bit-Map reservation protocol.""" def __init__(self, station_id: int, num_stations: int): self.id = station_id self.num_stations = num_stations self.tx_queue: List[bytes] = [] self.current_bitmap: List[bool] = [False] * num_stations def has_data(self) -> bool: return len(self.tx_queue) > 0 def get_reservation_bit(self) -> bool: """Called during MY mini-slot in reservation period.""" return self.has_data() def observe_reservation_period(self, bitmap: List[bool]): """All stations hear the complete bitmap after reservation period.""" self.current_bitmap = bitmap.copy() def get_my_data_slot(self) -> int: """Calculate which data slot I transmit in (if I reserved).""" if not self.current_bitmap[self.id]: return -1 # I didn't reserve # My slot = count of 1s before my position return sum(self.current_bitmap[:self.id]) def transmit_in_slot(self, slot_number: int) -> Optional[bytes]: """Called during data period if it's my turn.""" my_slot = self.get_my_data_slot() if slot_number == my_slot and self.tx_queue: return self.tx_queue.pop(0) return None class BitMapController: """Coordinates Bit-Map protocol operation.""" def __init__(self, stations: List[BitMapStation], slot_duration_ms: float): self.stations = stations self.slot_duration = slot_duration_ms def run_frame(self) -> ReservationFrame: """Execute one reservation + data frame.""" # Reservation period bitmap = [station.get_reservation_bit() for station in self.stations] # Broadcast bitmap to all stations for station in self.stations: station.observe_reservation_period(bitmap) # Data period num_data_slots = sum(bitmap) data_slots = [] for slot in range(num_data_slots): # Find who transmits in this slot for station in self.stations: data = station.transmit_in_slot(slot) if data is not None: data_slots.append(data) break return ReservationFrame( num_stations=len(self.stations), reservation_bits=bitmap, data_slots=data_slots, slot_duration_ms=self.slot_duration )Bit-Map Protocol Analysis:
Reservation Overhead:
Delay Analysis:
Let:
For a low-numbered station (station 1):
For a high-numbered station (station N):
Fairness Concern:
Low-numbered stations consistently get served earlier in each frame, creating a systematic bias. This can be addressed by rotating slot assignments or using a different ordering.
Bit-Map requires N mini-slots regardless of activity. For N=1000 stations where only 10 are active, you're wasting 990 mini-slots every frame. This makes Bit-Map impractical for large networks with sparse traffic. Contention-based reservation is better for such scenarios.
Reservation ALOHA (R-ALOHA) combines the simplicity of slotted ALOHA with the efficiency of reservation. Stations contend for slots only when their traffic pattern changes; once acquired, a slot is retained for subsequent frames.
Core Concept:
R-ALOHA Protocol Rules:
For each slot in each frame:
IF slot is reserved by me:
Transmit my data (no collision possible)
Slot remains reserved for next frame
ELSE IF slot is unreserved (contention slot):
IF I have new data AND want to reserve:
Transmit with probability p
IF success → slot is now reserved for me
IF collision → retry in another contention slot
ELSE IF slot is reserved by another station:
Listen only; do not transmit
How Reservation State is Maintained:
Stations must agree on which slots are reserved and by whom:
Option 1: Implicit Reservation
Option 2: Explicit Reservation
Slot Release:
| Metric | R-ALOHA | Comparison to Pure ALOHA |
|---|---|---|
| Maximum throughput (steady-state) | Up to 100% | 36.8% for Slotted ALOHA |
| Collision rate (steady traffic) | Zero | Continuous collisions |
| Adaptation to new traffic | Contention delay until slot acquired | Immediate but collision-prone |
| Overhead | Reservation bookkeeping | Minimal |
| Fairness | FIFO slot acquisition | Random (probabilistic) |
R-ALOHA behaves like slotted ALOHA for bursty, irregular traffic (via contention slots) but like TDMA for steady, ongoing traffic (via reserved slots). This hybrid approach is ideal for traffic patterns that mix bursty requests with steady data streams.
Demand Assignment Multiple Access (DAMA) is a reservation protocol family widely used in satellite communication. Given the extreme cost of satellite bandwidth and the 250ms+ round-trip delays, efficient bandwidth utilization is critical.
DAMA Architecture:
Satellite
▲
│
Forward Channel (Broadcast)
Return Channel (DAMA-assigned)
│
┌──────────────────┼──────────────────┐
│ │ │
[VSAT 1] [VSAT 2] [VSAT N]
Hub Station (Network Control Center) coordinates assignments
DAMA Protocol Flow:
Request Phase:
Allocation Phase:
Transmission Phase:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108
from dataclasses import dataclassfrom typing import List, Dict, Optionalfrom enum import Enumimport heapq class RequestType(Enum): CRA = "Continuous Rate Assignment" # Constant bit rate RBDC = "Rate-Based Dynamic Capacity" # Variable rate, known VBDC = "Volume-Based Dynamic Capacity" # Bursty, volume known AVBDC = "Absolute VBDC" # Override default allocation @dataclassclass CapacityRequest: terminal_id: int request_type: RequestType slots_requested: int priority: int # Higher = more urgent timestamp: float @dataclassclass SlotAllocation: terminal_id: int frame_number: int slot_start: int slot_count: int class DAMAController: """ Hub-side DAMA controller for satellite network. Implements DVB-RCS2-style capacity allocation. """ def __init__(self, slots_per_frame: int, num_terminals: int): self.slots_per_frame = slots_per_frame self.num_terminals = num_terminals # Per-terminal state self.cra_allocations: Dict[int, int] = {} # Guaranteed slots self.pending_requests: List[CapacityRequest] = [] # Current frame allocation self.current_frame = 0 self.frame_allocations: Dict[int, List[SlotAllocation]] = {} def receive_request(self, request: CapacityRequest): """Process incoming capacity request from terminal.""" if request.request_type == RequestType.CRA: # CRA: Permanent allocation until released self.cra_allocations[request.terminal_id] = request.slots_requested else: # Dynamic requests go to queue heapq.heappush( self.pending_requests, (-request.priority, request.timestamp, request) # Max-heap by priority ) def allocate_frame(self, frame_number: int) -> List[SlotAllocation]: """Allocate slots for upcoming frame.""" allocations = [] remaining_slots = self.slots_per_frame current_slot = 0 # Step 1: Satisfy CRA (guaranteed) allocations first for terminal_id, cra_slots in self.cra_allocations.items(): if cra_slots > 0 and remaining_slots >= cra_slots: allocations.append(SlotAllocation( terminal_id=terminal_id, frame_number=frame_number, slot_start=current_slot, slot_count=cra_slots )) current_slot += cra_slots remaining_slots -= cra_slots # Step 2: Allocate remaining to dynamic requests (priority order) while remaining_slots > 0 and self.pending_requests: _, _, request = heapq.heappop(self.pending_requests) slots_to_give = min(request.slots_requested, remaining_slots) if slots_to_give > 0: allocations.append(SlotAllocation( terminal_id=request.terminal_id, frame_number=frame_number, slot_start=current_slot, slot_count=slots_to_give )) current_slot += slots_to_give remaining_slots -= slots_to_give # If request not fully satisfied, re-queue remainder if slots_to_give < request.slots_requested: request.slots_requested -= slots_to_give heapq.heappush( self.pending_requests, (-request.priority, request.timestamp, request) ) self.frame_allocations[frame_number] = allocations return allocations def get_tbtp(self, frame_number: int) -> bytes: """ Generate Time-Burst Time Plan (TBTP). This is broadcast to all terminals in the forward channel. """ allocations = self.frame_allocations.get(frame_number, []) # Encode as broadcast message... return self._encode_tbtp(frame_number, allocations)DAMA Request Types (DVB-RCS2 Standard):
| Type | Meaning | Use Case | Latency |
|---|---|---|---|
| CRA | Continuous Rate Assignment | VoIP, video conferencing | Lowest (pre-allocated) |
| RBDC | Rate-Based Dynamic Capacity | Known variable rate streams | Low (rate maintained) |
| VBDC | Volume-Based Dynamic Capacity | Bursty data, web browsing | Medium (per-request) |
| AVBDC | Absolute VBDC | Urgent traffic burst | Medium (priority) |
| Free Capacity | Unused slots | Best-effort overflow | High |
Request Channel Options:
How do terminals send requests to the hub?
With ~250ms round-trip time to geostationary satellites, a request-allocate-transmit cycle takes at least 500-750ms. DAMA systems often use predictive algorithms to pre-allocate capacity before requests arrive, based on historical traffic patterns. This 'bandwidth-on-demand' approach balances efficiency with latency.
Packet Reservation Multiple Access (PRMA) is a reservation protocol designed specifically for voice traffic over wireless channels. It exploits the talkspurt/silence pattern of human speech to achieve high efficiency.
Voice Traffic Characteristics:
PRMA Insight:
If we allocate dedicated slots to each voice call, 60% of bandwidth is wasted during silence. PRMA dynamically reassigns slots during silence periods to other users.
PRMA Frame Structure:
Frame (one speech frame duration, ~20ms)
┌───────┬───────┬───────┬───────┬───────┬─── ···
│ Slot 1│ Slot 2│ Slot 3│ Slot 4│ Slot 5│
└───────┴───────┴───────┴───────┴───────┴─── ···
Slots can be:
- Reserved (assigned to an active talkspurt)
- Available (can be contended for)
PRMA Protocol Operation:
When a user starts talking (talkspurt begins):
During the talkspurt:
When user stops talking (silence period):
Collision Handling:
| Metric | Value/Characteristic | Impact |
|---|---|---|
| Capacity gain | 3-4× over fixed TDMA | Exploits voice activity factor |
| Speech frame size | ~200 bits (20ms) | Matches speech codec framing |
| Access delay | 1-3 frame periods | Acceptable for speech |
| Packet drop rate | <1% target | Higher drops = audible degradation |
| Contention probability p | 0.2-0.5 typical | Trade-off: delay vs collision rate |
| Supported calls | 3-4× number of slots | Statistical multiplexing gain |
PRMA must drop speech packets that can't be transmitted within ~20-40ms (they become stale). Unlike data, speech can tolerate small loss rates (~1%) without perceptible quality degradation. But if contention is too high and drop rates exceed 1-2%, users hear annoying gaps and clipping.
PRMA Capacity Analysis:
Let:
Fixed TDMA: Can support C = N calls (one slot per call)
PRMA: Can support C ≈ N/v = 2.5N calls (statistical multiplexing)
Example:
N = 8 slots per frame
Fixed TDMA: 8 voice calls
PRMA: ~20 voice calls (with <1% dropping)
Capacity improvement: 2.5×
This capacity multiplier made PRMA attractive for early digital cellular systems and wireless LANs carrying voice traffic.
PRMA Variants:
Reservation concepts have evolved into sophisticated mechanisms in modern wireless and cellular networks.
LTE/5G Uplink Scheduling:
Modern cellular networks use centralized scheduling that is fundamentally reservation-based:
LTE Uplink Access Flow:
1. UE (User Equipment) sends Scheduling Request (SR) to eNodeB
2. eNodeB allocates uplink resources (PRBs - Physical Resource Blocks)
3. Allocation broadcast in PDCCH (Physical Downlink Control Channel)
4. UE transmits data in allocated PRBs
5. No collisions (exclusive resource use)
| System | Reservation Mechanism | Request Channel | Key Feature |
|---|---|---|---|
| LTE/5G Uplink | Dynamic scheduling | SR + BSR | 1ms scheduling granularity |
| DVB-RCS2 | DAMA + Superframe | Contention / SYNC | Satellite bandwidth-on-demand |
| DOCSIS 3.1 | Request-Grant | Contention mini-slots | Cable modem upstream |
| WiMAX | Bandwidth Request | Contention + polling | Flexible QoS support |
| Wi-Fi 6 (802.11ax) | OFDMA + TWT | Trigger-based | Deterministic latency option |
Wi-Fi 6 (802.11ax) OFDMA Resource Units:
Wi-Fi 6 introduces scheduled, reservation-like access to Wi-Fi:
Traditional Wi-Fi (CSMA/CA):
Only one station transmits at a time (entire channel)
Wi-Fi 6 OFDMA:
Channel divided into Resource Units (RUs)
AP schedules multiple stations simultaneously
Each station uses assigned RU (no contention within RU)
20 MHz channel:
┌──────┬──────┬──────┬──────┐
│ RU-1 │ RU-2 │ RU-3 │ RU-4 │ ← 4 stations, parallel
│ Stn A│ Stn B│ Stn C│ Stn D│
└──────┴──────┴──────┴──────┘
Target Wake Time (TWT):
TWT allows stations to negotiate wake schedules with the AP:
This is essentially a reservation for future access, enabling deterministic latency for IoT and real-time applications.
Modern systems often combine reservation with other approaches: random access for initial requests, scheduled access for ongoing traffic, and priority mechanisms for QoS differentiation. The pure reservation protocols taught here form the conceptual foundation for these sophisticated hybrid systems.
We've explored reservation-based controlled access protocols. Let's consolidate the key concepts:
What's Next:
In the next page, we'll dive deep into Token Passing Efficiency Analysis—quantifying the performance of token-based protocols. We'll derive throughput formulas, analyze latency bounds, and understand how ring size, token holding time, and traffic patterns affect protocol efficiency.
You now understand reservation-based controlled access protocols—from simple Bit-Map to sophisticated DAMA and PRMA. You've seen how reservation provides deterministic access by resolving contention before data transmission and how modern systems build on these foundational concepts.