BU-LoRaWAN: Uplink Scheduling for DtS IoT

• BU-LoRaWAN is a MAC-layer scheduling scheme that repurposes Class B beacons to create slotted uplink windows for direct-to-satellite IoT systems.
• It enhances network performance by reducing collision probability by 20–30% and nearly doubling packet delivery in congested LEO satellite environments.
• Simulation results using OMNeT++ and FLoRaSat validate the protocol’s efficiency in managing timing, slot allocation, and queue scheduling without modifying the PHY layer.

Beacon-based Uplink LoRaWAN (BU-LoRaWAN) is a MAC-layer scheduling scheme designed to enhance uplink efficiency and collision avoidance for direct-to-satellite (DtS) Internet of Things systems utilizing LoRaWAN over Low Earth Orbit (LEO) constellations. The protocol repurposes the existing LoRaWAN Class B beacon synchronization mechanism to orchestrate ground device transmission windows, enabling scalable and efficient slotted uplink access without modifications to the PHY layer or significant changes to the LoRaWAN standard. The approach is evaluated in simulation using OMNeT++ and the FLoRaSat framework, with results demonstrating substantial improvements in traffic delivery and collision reduction compared to baseline LoRaWAN (Mojamed, 2024).

1. System Topology and Frame Structure

Overall Network Architecture

BU-LoRaWAN is designed for a system comprising:

• End Devices: Terrestrial, Class B-capable LoRaWAN sensors (Spreading Factor 12, 125 kHz bandwidth, Code Rate 4/8, $P_{tx}\approx 14$ dBm) equipped with MAC-layer uplink queues.
• LEO Satellite Gateways: A constellation of 16 satellites organized in four planes, each at 600 km altitude and 98° inclination, serving as LoRaWAN gateways with inter-satellite links (ISL) to the ground network server.
• Network Server: A terrestrial aggregator for uplink traffic, responsible for disseminating beacons to synchronize uplink access.

Beacon Window Repurposing

Standard LoRaWAN Class B periodically broadcasts a 64-bit time-reference beacon every $T_b = 128$ s, defining the following interval structure:

• Beacon period ($T_f = T_b$): 128 s
• Beacon guard ($T_g$): 3 s
• Reserved beacon duration ($T_r$): 2.12 s
• Beacon window ($T_w = T_f - (2T_g + T_r) \approx 122.88$ s)

BU-LoRaWAN inverts the typical Class B behavior: the $T_w$ window, offset by a pseudo-random pingOffset, becomes an uplink transmission window, subdivided into random slots for collision avoidance. All synchronization occurs via MAC-layer scheduling, avoiding additional downlink traffic.

2. Uplink Slot Allocation, Timing, and Collision Probability

Timing Parameters

Key parameters in the BU-LoRaWAN frame are:

Parameter	Symbol	Typical Value
Beacon period	$T_b$	128 s
Guard time	$T_g$	3 s
Beacon window	$T_w$	$T_b = 128$0122.88 s
TX-slot length	$T_b = 128$1	Time-on-air (e.g., 1 s)
pingOffset		$T_b = 128$2

The effective uplink window is $T_b = 128$3.

The available slot count is $T_b = 128$4. When $T_b = 128$5, this is commonly approximated as $T_b = 128$6.

Random Slot Selection and Collision Analysis

Upon beacon reception at time $T_b = 128$7, each device independently:

• Computes transmission time $T_b = 128$8, where $T_b = 128$9 is a uniform random variable.
• Alternatively, selects a slot $T_f = T_b$0 and schedules transmission at $T_f = T_b$1.

The probability that no collisions occur among $T_f = T_b$2 devices in one beacon window is:

$T_f = T_b$3

Thus, the collision probability is:

$T_f = T_b$4

For $T_f = T_b$5, this simplifies to $T_f = T_b$6.

3. MAC-Layer Queue Management and Slot Scheduling

Workflow and State

Each device maintains a FIFO queue $T_f = T_b$7 for uplink packets. Incoming packets are enqueued immediately. Dequeue and transmission occur only when the device’s internal TX-timer fires after beacon synchronization.

Pseudocode Outline

$T_g$2

Slot Optimization

BU-LoRaWAN instantiates a “framed slotted ALOHA” per $T_f = T_b$8, balancing slot length $T_f = T_b$9 (aligned with LoRaWAN time-on-air) and collision probability. Excessively small $T_g$0 wastes bandwidth, while excessively large $T_g$1 increases $T_g$2.

4. Analytical Model of Performance Metrics

Definitions and Expressions

• Offered load ($T_g$3): Total requests per second from all devices.
• Throughput ($T_g$4): $T_g$5.
• Packet Delivery Ratio (PDR): $T_g$6.
• Latency ($T_g$7): $T_g$8.

If each of $T_g$9 devices generates one packet every interval ($T_r$0), then:

• Slot Poisson load ($T_r$1): $T_r$2
• Throughput per frame: $T_r$3
• PDR (under Poisson arrivals): $T_r$4

Approximate metrics:

$T_r$5

$T_r$6

5. Simulated Evaluation and Key Results

Experimental Setup

• Simulator: OMNeT++ with FLoRaSat
• LEO constellation: 16 satellites, 4 orbital planes (RAAN = 310°–370°, 98° inclination, 600 km altitude)
• Ground devices: Uniformly within 2000 km radius
• Device configuration: SF12, BW=125 kHz, CR=4/8, $T_r$7 dBm, $T_r$8 MHz
• Traffic pattern: 20 B payloads, one packet every 8–12 min per device
• Tested populations: $T_r$9, durations $T_w = T_f - (2T_g + T_r) \approx 122.88$0–$T_w = T_f - (2T_g + T_r) \approx 122.88$1 s, ten runs per point

Principal Findings

• Packet Delivery Ratio vs. Network Size: For $T_w = T_f - (2T_g + T_r) \approx 122.88$2 s, PDR falls from $T_w = T_f - (2T_g + T_r) \approx 122.88$3 to $T_w = T_f - (2T_g + T_r) \approx 122.88$4 (baseline), $T_w = T_f - (2T_g + T_r) \approx 122.88$5 to $T_w = T_f - (2T_g + T_r) \approx 122.88$6 (BU-LoRaWAN) as $T_w = T_f - (2T_g + T_r) \approx 122.88$7 increases $T_w = T_f - (2T_g + T_r) \approx 122.88$8.
• PDR vs. Simulation Time ($T_w = T_f - (2T_g + T_r) \approx 122.88$9): Baseline degrades ($T_w$0); BU-LoRaWAN remains stable ($T_w$1–$T_w$2).
• Collision rates: Baseline grows approximately linearly with $T_w$3 (to $T_w$4 collisions at $T_w$5); BU-LoRaWAN reduces collisions by $T_w$6–$T_w$7\%.
• Throughput: BU-LoRaWAN delivers nearly double the successfully received packets per hour compared to baseline at moderate $T_w$8.
• Latency: Average waiting time $T_w$9 s plus negligible queueing for $T_b$0.

6. Protocol Trade-offs and Future Directions

Parameter Tuning

• Beacon interval ($T_b$1): Larger $T_b$2 lowers beacon overhead but increases worst-case latency ($T_b$3).
• Slot duration ($T_b$4): Lower $T_b$5 reduces $T_b$6 but risks under-utilizing bandwidth. Optimal $T_b$7 aligns with typical uplink packet time-on-air.
• Slot count ($T_b$8): $T_b$9 ensures low collision rates.

Limitations and Possible Enhancements

• Synchronization Assumptions: Current analysis presumes perfect clock alignment and unfailing beacon reception; redundant beacon strategies or second satellite passes could mitigate discrepancies.
• Slot Assignment Strategies: Uniform slot selection can be enhanced with traffic-aware or distance-aware slot weighting to further suppress collisions.
• Potential Extensions: Dynamic slot adaptation ($T_g$0) based on payload size, prioritized slotting for latency-sensitive data, integration of LR-FHSS for improved capture, and closed-form optimization of $T_g$1 for target PDRs are proposed directions.

The BU-LoRaWAN protocol, as specified, provides a practical enhancement to LoRaWAN for DtS IoT by maximizing uplink delivery and mitigating network congestion under satellite-constrained topologies (Mojamed, 2024).