OEPB Transport Binding: Bluetooth Low Energy

3.1. Advertising Data Format

OEPB advertising PDUs MUST carry the OEPB frame in a single Manufacturer Specific Data AD structure:¶

+----------+----------+---------------+----------------------------+
| Length   | AD Type  | Company ID    | OEPB Frame                 |
| (1 byte) | 0xFF     | (2 bytes, LE) | (Frame Type + frame data)  |
+----------+----------+---------------+----------------------------+

The Length field covers the AD Type, Company ID, and OEPB Frame (Length = 3 + frame size). On BLE 4.x legacy advertising (31-byte AdvData), the AD structure overhead is 4 bytes (Length + AD Type + Company ID), leaving 27 bytes of manufacturer payload per PDU. The AD Flags structure SHOULD be omitted: it is optional for non-connectable advertising and would consume 3 of the 31 available bytes.¶

Company ID: 0xFFFF (reserved for prototyping). Production deployments SHOULD register a Bluetooth SIG Company Identifier.¶

The OEPB Frame in the manufacturer-specific data begins with a 1-byte Frame Type field:¶

3.2. Advertising Interval

OEPB nodes SHOULD use an advertising interval of 100ms-200ms during active mesh participation. Shorter intervals reduce delivery latency but increase energy consumption. Note that the minimum advertising interval permitted for non-connectable undirected advertising is 100ms on Bluetooth 4.0/4.1 controllers (relaxed to 20ms in Bluetooth 4.2 and later); implementations MUST NOT assume sub-100ms intervals are available on legacy hardware. During Trickle suppression periods (when c >= k), advertising SHOULD be paused.¶

A consequence for fragmented transfer on BLE 4.x: each fragment occupies one advertising event, so a maximum-size 256-byte OEPB packet (12 fragments, Section 4) requires approximately 1.2-2.4 seconds of advertising at the 100-200ms interval -- before accounting for fragment loss and train repetition. This transport-level serialization delay dominates the protocol-layer latency figures of [OEPB] Section 6.1 on BLE 4.x deployments, consistent with the lower-bound caveat stated there. BLE 5.x extended advertising carries the full packet in one PDU and does not incur this delay.¶

4.1. Fragment Header Format

Each fragment carries a 3-byte F&R header prepended to the fragment data:¶

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Fragment ID  |  Frag Index   |  Total Frags  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Fragment ID (1 byte): An 8-bit identifier shared by all fragments of the same OEPB packet. Derived as MsgID[0] XOR MsgID[1]. Allows receivers to correlate fragments without storing the full MsgID before reassembly is complete. The 8-bit space means Fragment ID is NOT unique across packets; Section 4.4 defines the integrity check that makes collisions safe.¶

• Frag Index (1 byte): Zero-based index of this fragment (0 to Total Frags - 1).¶

• Total Frags (1 byte): Total number of fragments comprising the OEPB packet.¶

Usable data per fragment after the F&R header is 23 bytes (Section 4 byte budget).¶

4.2. Reassembly

Receivers MUST maintain a fragment reassembly buffer keyed on the tuple (L2 source address, Fragment ID). Keying on the source address prevents fragments of different packets that share an 8-bit Fragment ID (a 1-in-256 collision, guaranteed to occur under sustained traffic) from being interleaved when they originate from different transmitters. BLE MAC address randomization does not defeat this keying in practice: a randomized address is stable for the duration of an advertising train; a rotation mid-train causes a reassembly failure that is recovered by the timeout below and the next repetition of the train.¶

The buffer:¶

• Stores received fragment payloads indexed by Frag Index.¶

• Times out after FRAG_INACTIVITY_TIMEOUT = 5 seconds with no new fragment received for that key; partially assembled packets MUST then be discarded. The inactivity timeout MUST be substantially longer than the advertising interval: at the RECOMMENDED 100-200ms interval (Section 3.2), consecutive fragments arrive at least one advertising interval apart, and a lost fragment is recovered only on the next repetition of the fragment train. (An earlier revision of this profile specified 2 * Imin = 100ms, which is shorter than the inter-fragment arrival gap itself and would discard essentially every multi-fragment packet.)¶

• Is additionally bounded by the base specification's total reassembly budget: per [OEPB] Section 3.1, a fragment set that has not completed within MAX_FRAG_TIMEOUT = 30 seconds of the first fragment's arrival MUST be discarded regardless of recent activity.¶

• Accepts up to MAX_TOTAL_FRAGS = 16 fragments per packet. Packets claiming more than 16 fragments MUST be silently discarded.¶

On successful reassembly (all Total Frags received and the Section 4.4 integrity check passed):¶

1. The complete OEPB packet is passed to the MIL for deduplication and Trickle processing.¶

2. The fragment buffer entry is freed.¶

3. The (source address, Fragment ID) key is retained for FRAG_HOLD = FRAG_INACTIVITY_TIMEOUT (5 seconds) to suppress redundant re-reassembly of repetitions of the same fragment train. Long-term duplicate suppression is the responsibility of the MIL MsgID deduplication cache, not the F&R layer: the 8-bit Fragment ID space makes any retention beyond a few seconds actively harmful, as retained IDs would collide with, and block, unrelated future packets.¶

4.3. Fragment Deduplication

Multiple advertising nodes may relay the same packet simultaneously. Receivers MUST deduplicate received fragments on the tuple (L2 source address, Fragment ID, Frag Index) to avoid double-processing repeated advertisements within a train. Identical fragments arriving from different source addresses are independent reassembly streams per Section 4.2 and are reconciled by the MIL MsgID deduplication cache after reassembly.¶

4.4. Post-Reassembly Integrity Verification

The F&R header carries no checksum; corruption is detected end-to-end. After reassembly, and before passing the packet to the MIL, the receiver MUST:¶

1. Recompute the MsgID over the reassembled packet's immutable fields per [OEPB] Section 5.3 and compare it to the MsgID field carried in the reassembled header. On mismatch, the packet MUST be silently discarded.¶

2. Verify that the Fragment ID used during reassembly equals MsgID[0] XOR MsgID[1] of the reassembled packet. On mismatch, the packet MUST be silently discarded.¶

These checks guarantee that an interleaving of fragments from two colliding packets (same source and Fragment ID) cannot produce an accepted corrupt packet: any byte substitution in the immutable fields or payload changes the recomputed MsgID with overwhelming probability. The checks cost one SHA-256 computation per reassembled packet and require no per-fragment overhead.¶

12.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.¶

• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.¶

• [OEPB] Sharma, K., "Offline Emergency Peer-to-Peer Broadcast Protocol", draft-sharma-oepb-00, 2025.¶

12.2. Informative References

• [BT54] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 5.4", 2023.¶

---¶

12.3. : Fragment Reassembly Example

A 120-byte OEPB SOS packet (the verifiable test vector from Appendix A.2 of [OEPB], MsgID 11 84 78 44 E6 41 C2 8C 0F 40 48 24 08 8B 09 6B) transmitted over BLE 4.x, fragmented at 23 data bytes per fragment (Section 4): ceil(120 / 23) = 6 fragments.¶

FragID = MsgID[0] XOR MsgID[1] = 0x11 XOR 0x84 = 0x95.¶

Fragment 0 of 6:
  F&R Header: FragID=0x95, Index=0, Total=6
  Data (23B): 01 01 0A 00 00 00 00 00 67 87 A3 40 4F 45 50 42
              5F 56 31 00 11 84 78

Fragment 1 of 6:
  F&R Header: FragID=0x95, Index=1, Total=6
  Data (23B): 44 E6 41 C2 8C 0F 40 48 24 08 8B 09 6B 00 10 00
              01 A3 01 1A 01 B4 9D

Fragment 2 of 6:
  F&R Header: FragID=0x95, Index=2, Total=6
  Data (23B): 70 02 1A 04 9A 03 7C 03 18 1E B9 81 45 84 5F DD
              D9 6F 0F 49 FE 2F 95

Fragment 3 of 6:
  F&R Header: FragID=0x95, Index=3, Total=6
  Data (23B): 23 16 EE 0A DE 69 53 66 E2 85 92 E3 3C 91 28 B1
              59 B8 98 A8 51 E4 66

Fragment 4 of 6:
  F&R Header: FragID=0x95, Index=4, Total=6
  Data (23B): 11 E6 2F F5 CE C8 36 D1 E9 15 2D 06 A9 99 C1 4C
              28 E4 37 A7 25 07 6B

Fragment 5 of 6:
  F&R Header: FragID=0x95, Index=5, Total=6
  Data (5B):  97 58 16 FA 08

Each fragment travels in one advertising PDU: AD Length (1) + AD Type 0xFF (1) + Company ID (2) + Frame Type OEPB_FRAG 0x46 (1) + F&R header (3) + data -- 31 bytes total for the full fragments, 13 bytes for the final fragment.¶

On reassembly, the receiver recomputes the MsgID over the reassembled packet per Section 4.4, obtaining 11 84 78 44 ..., which matches both the carried MsgID field and FragID 0x95 -- the packet is accepted and passed to the MIL.¶

On BLE 5.x with DLE (244-byte ATT payload), this 120-byte packet fits in a single OEPB_SINGLE frame with no fragmentation required.¶