| Internet-Draft | OEPB-BLE | September 2026 |
| Sharma | Expires 3 April 2027 | [Page] |
This document defines the Bluetooth Low Energy (BLE) Transport Binding Profile for the Offline Emergency Peer-to-Peer Broadcast Protocol (OEPB). It specifies the advertising mode, fragmentation and reassembly scheme, service and characteristic UUIDs, and channel access rules required to carry OEPB packets over BLE 4.x and BLE 5.x physical layers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The OEPB base specification [OEPB] requires the Transport Abstraction Layer (TAL) to expose a minimum datagram MTU of 256 bytes to the Mesh Intelligence Layer. Bluetooth Low Energy [BT54] offers two relevant carriers, with different limits:¶
Advertising. Legacy advertising PDUs (BLE 4.x and later) carry at most 31 bytes of advertising data. Extended advertising (BLE 5.0 and later) carries up to 254 bytes of advertising data in an AUX_ADV_IND PDU, and longer advertising data (up to 1650 bytes) by chaining further AUX_CHAIN_IND PDUs.¶
GATT connections. The default ATT_MTU is 23 bytes (20 bytes of attribute value per write or notification). A larger ATT_MTU can be negotiated. Data Length Extension (DLE) is a separate feature: it raises the link-layer payload from 27 to up to 251 bytes, which lets a larger ATT PDU travel in a single link-layer packet but does not by itself change ATT_MTU.¶
This binding profile defines the fragmentation and reassembly scheme that satisfies the 256-byte MTU requirement over legacy advertising and small-ATT_MTU connections, and the unfragmented paths over BLE 5.x extended advertising and large-ATT_MTU connections (Section 5).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
PDU: Protocol Data Unit.¶
ATT: Attribute Protocol (Bluetooth Core Specification).¶
GATT: Generic Attribute Profile (Bluetooth Core Specification).¶
DLE: Data Length Extension (introduced in Bluetooth 4.2; raises the link-layer payload size).¶
F&R: Fragmentation and Reassembly.¶
UUID: Universally Unique Identifier.¶
OEPB nodes operating over BLE MUST use Generic Broadcast (non-connectable, non-scannable) advertising for packet dissemination when carrying SOS, ALERT, or EVAC message types, to minimize connection setup latency.¶
For AUTH and INFO message types, OEPB nodes MAY use connectable advertising to allow GATT-based transfer of larger payloads that would otherwise require many advertising fragments.¶
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. The Bluetooth SIG reserves this value for internal and interoperability testing; it is not assigned to any company and MUST NOT be used in production deployments. This is a known limitation of this revision: deployments that each register their own Company Identifier will not recognize each other's frames, so interoperability between independent production deployments requires agreement on a single identifier. A future revision is expected to move the OEPB frame into a Service Data AD structure (AD type 0x16) keyed by a Bluetooth SIG-assigned 16-bit UUID, which avoids per-vendor Company Identifiers; this revision does not change the frame format.¶
The OEPB Frame in the manufacturer-specific data begins with a 1-byte Frame Type field:¶
| Value | Frame Type | Description |
|---|---|---|
| 0x4F | OEPB_SINGLE | Complete OEPB packet fits in one advertising PDU |
| 0x46 | OEPB_FRAG | Fragment of a larger OEPB packet |
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. Trickle suppression is per MsgID: when c >= k for a given MsgID, the node MUST NOT advertise that packet (or any of its fragments) for the remainder of the current Trickle interval. Advertising of other packets is unaffected; a node MUST NOT pause all advertising because one packet is suppressed.¶
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 advertising event (one AUX_ADV_IND, plus one AUX_CHAIN_IND for packets larger than 249 bytes; Section 5.1) and does not incur this delay.¶
BLE 4.x advertising PDUs have a maximum AdvData payload of 31 bytes (including AD structure headers). The byte budget per advertising PDU is:¶
AdvData total 31 bytes - AD structure header (Len+Type+CoID) -4 bytes - OEPB Frame Type (OEPB_FRAG) -1 byte - F&R header (Section 4.1) -3 bytes = usable fragment data 23 bytes¶
A maximum-size 256-byte OEPB packet requires ceil(256 / 23) = 12 fragments.¶
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).¶
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.¶
Before storing a fragment, the receiver MUST validate its F&R header and MUST silently discard the fragment if any of the following holds:¶
Total Frags is 0.¶
Frag Index is greater than or equal to Total Frags.¶
Total Frags is greater than MAX_TOTAL_FRAGS.¶
Total Frags differs from the Total Frags of fragments already buffered for the same (L2 source address, Fragment ID) key. In this case the receiver SHOULD also discard the existing buffer for that key, since the two fragment sets cannot belong to the same packet.¶
On successful reassembly (all Total Frags received and the Section 4.4 integrity check passed):¶
The complete OEPB packet is passed to the MIL for deduplication and Trickle processing.¶
The fragment buffer entry is freed.¶
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.¶
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.¶
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:¶
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.¶
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.¶
Two BLE carriers can deliver an OEPB packet without the fragmentation of Section 4. They differ in how the size limit arises.¶
An OEPB_SINGLE frame in extended advertising data occupies 5 bytes of framing (AD Length, AD Type, 2-byte Company ID, Frame Type) plus the OEPB packet. An AUX_ADV_IND PDU carries at most 254 bytes of advertising data, so:¶
A packet of at most 249 bytes fits in a single AUX_ADV_IND.¶
A packet of 250-256 bytes (for example, a signed packet with a payload of 146 bytes or more) exceeds the AUX_ADV_IND capacity and MUST be sent as chained advertising data: the AUX_ADV_IND followed by one AUX_CHAIN_IND.¶
Nodes that transmit extended advertising MUST use non-connectable, non-scannable extended advertising for SOS, ALERT, and EVAC, and MUST support transmitting chained advertising data. Nodes that scan for extended advertising MUST support receiving chained advertising data, because a maximum-size packet is not receivable otherwise. OEPB_SINGLE MUST be used on this path; OEPB_FRAG MUST NOT be used over extended advertising. Nodes MAY additionally transmit each packet over legacy advertising (Section 4), and SHOULD do so when they have received legacy-only OEPB traffic within the last MAX_EXPIRATION_WINDOW, since legacy scanners do not receive extended advertising; dual transmission roughly doubles airtime.¶
Over a GATT connection (Section 6), each Write Without Response or notification carries at most ATT_MTU - 3 bytes. Implementations SHOULD negotiate the largest ATT_MTU both peers support and SHOULD enable DLE so that large ATT PDUs are not segmented at the link layer. After negotiation:¶
If ATT_MTU - 3 is at least the OEPB_SINGLE frame size (packet length + 1), the sender MUST send the packet as one OEPB_SINGLE frame in one write or notification. For a maximum-size 256-byte packet this requires ATT_MTU of at least 260.¶
Otherwise the sender MUST fragment the packet using the OEPB_FRAG frame and F&R header of Section 4, with ATT_MTU - 7 bytes of fragment data per fragment (ATT_MTU - 3 for the attribute value, minus 1 byte of Frame Type and 3 bytes of F&R header). The reassembly, validation, and integrity rules of Sections 4.2 to 4.4 apply, with the connection taking the place of the L2 source address. At the default ATT_MTU of 23, each fragment carries 16 bytes and a maximum-size packet needs 16 fragments, within MAX_TOTAL_FRAGS.¶
OEPB nodes that support connectable mode MUST expose the following GATT service:¶
OEPB Primary Service UUID: 4F455042-0001-4F45-5042-4D4553480000¶
The leading four bytes spell "OEPB" (0x4F455042) for recognizability in packet captures. These are vendor-specific 128-bit UUIDs deliberately outside the Bluetooth SIG base UUID range (0000xxxx-0000-1000-8000-00805F9B34FB), which is reserved for SIG-assigned 16-bit identifiers. Deployments requiring a 16-bit UUID for advertising efficiency SHOULD obtain one through Bluetooth SIG membership.¶
| Characteristic | UUID | Properties |
|---|---|---|
| OEPB Packet RX |
4F455042-0002-4F45-5042-4D4553480000
|
Write Without Response |
| OEPB Packet TX |
4F455042-0003-4F45-5042-4D4553480000
|
Notify |
| OEPB MTU Cap |
4F455042-0004-4F45-5042-4D4553480000
|
Read |
OEPB Packet RX receives a complete or fragmented OEPB frame from a connected peer. OEPB Packet TX transmits OEPB frames to subscribed peers via notification. OEPB MTU Cap reports the maximum supported OEPB frame size as a single byte (0x01 = 256 bytes, 0x02 = 512 bytes).¶
GATT connected mode is an OPTIONAL optimization for peers that have already established a connection (e.g., bulk AUTH/CRL transfer per Section 3). Non-connectable advertising remains the canonical dissemination path; implementations MUST NOT require a GATT connection for SOS, ALERT, or EVAC delivery.¶
BLE operates on the 2.4 GHz ISM band across 40 channels (37 data + 3 advertising). OEPB nodes MUST use all three advertising channels (37, 38, 39) when transmitting OEPB advertising PDUs to maximize reach across environments with partial channel interference.¶
Nodes SHOULD implement adaptive advertising interval backoff when the received signal strength (RSSI) of other BLE traffic indicates heavy channel utilization, consistent with the Trickle algorithm's spirit of adaptive suppression.¶
OEPB over BLE is intended for emergency scenarios where battery may be limited. Implementations SHOULD:¶
Nodes with no active Trickle instance MAY duty-cycle scanning to conserve receive energy, but SHOULD keep a scan duty cycle of at least SCAN_DUTY_FLOOR = 10% (for example, a 100 ms scan window every 1000 ms) so that new packets are still received. Nodes with one or more active Trickle instances MUST NOT reduce scanning below the highest duty cycle the platform permits in the foreground: relays must hear redundant copies to count c, and a node that stops scanning between intervals misses packets it should relay.¶
Use the lowest advertising power sufficient to reach neighboring nodes (typically -12 dBm to 0 dBm at 10-50m range).¶
Transmit the fragments of one packet in consecutive advertising events (one fragment per event, i.e., one advertising interval apart) rather than interleaving fragments of multiple packets, to minimize reassembly buffer residency at receivers.¶
Respect the Imax = 1000ms Trickle ceiling; do not transmit more frequently than once per 50ms (Imin) per OEPB packet.¶
BLE 4.x and BLE 5.x operate in the 2.4 GHz ISM band (2.400-2.4835 GHz) and are subject to regional regulations:¶
EU: ETSI EN 300 328; requires adaptivity (for example, listen-before-talk or detect-and-avoid) for adaptive equipment and limits medium utilization for non-adaptive equipment. The per-sub-band duty-cycle limits of ETSI EN 300 220 apply to sub-GHz bands, not to 2.4 GHz.¶
US: FCC Part 15.247; no mandatory duty cycle, but EIRP limits apply.¶
India: WPC/DoT regulations for ISM band devices.¶
Implementations MUST comply with applicable regional radio regulations. OEPB does not impose airtime constraints beyond the Trickle bounds of [OEPB] at the protocol layer; TAL implementations MUST enforce applicable regional limits (such as medium-utilization limits) independently.¶
This document inherits all security properties of the OEPB base specification [OEPB]. No additional security mechanisms are introduced by this binding.¶
BLE advertisement packets do not provide L2 confidentiality or integrity. OEPB's end-to-end Ed25519 signatures provide authenticity and integrity independent of L2 transport security. Confidentiality of OEPB payloads is intentionally not provided: emergency broadcasts are intended for public consumption by all reachable nodes.¶
BLE MAC address randomization SHOULD be enabled on OEPB nodes to prevent physical tracking via stable MAC addresses. This applies independently of OEPB's ephemeral key rotation (Section 9.1 of [OEPB]).¶
This document has no IANA actions. GATT service and characteristic UUID assignment requires Bluetooth SIG registration, which is outside the IANA process.¶
(Note to the RFC Editor: please remove this section and the reference to [RFC7942] before publication.)¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
No implementation of this binding exists. The fragments in Appendix A were computed by script from the base specification's test vector and checked to reassemble to it; they were not captured over the air. The author's Android prototypes (see [OEPB], Implementation Status) use Android Nearby Connections rather than this binding. No testing on real BLE controllers has been performed.¶
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.¶
Over BLE 5.x extended advertising, this 120-byte packet (125 bytes of advertising data including framing) fits in a single AUX_ADV_IND as an OEPB_SINGLE frame (Section 5.1). Over a GATT connection it fits in a single OEPB_SINGLE write once ATT_MTU is at least 124 (Section 5.2).¶
(Note to the RFC Editor: please remove this appendix before publication.)¶
Identifiers refer to the pre-submission review findings for this revision.¶
B1: Rendered as an Independent Submission; appendices moved to back matter; references generated once.¶
B8: New Section 12, Implementation Status.¶
S13: Scan duty cycling restricted to nodes with no active Trickle instance, with a 10% scan floor.¶
S14: Advertising suppression is per MsgID, not all advertising.¶
S15: Section 5 rewritten as two paths: extended advertising with AUX_CHAIN_IND chaining, and GATT with ATT_MTU negotiation (with fragmentation defined when ATT_MTU is small); DLE no longer conflated with ATT payload size.¶
S16: F&R header validation rules added to Section 4.2.¶
S17: Company ID 0xFFFF stated as test-only; interoperability limitation and Service Data direction noted.¶
S18: Complete BCP 14 boilerplate.¶
N6, N8: [BT54] cited; [OEPB] reference updated to draft-sharma-oepb-01 (2026).¶
N9: EN 300 328 description corrected.¶
Section 5.1: dual legacy + extended advertising is MAY, and SHOULD only when legacy-only OEPB traffic has been received within the last MAX_EXPIRATION_WINDOW (airtime cost stated).¶