MeshCore protocol explained
Technical explanation of the MeshCore protocol: how messages are transmitted, delivered, and optimized in a decentralized LoRa network.
What is the MeshCore protocol?
The MeshCore protocol defines how nodes exchange messages over LoRa: transmission, reception, and forwarding through repeaters.
Core principle: clients do not repeat. Forwarding is handled by repeaters (and room servers with repeat enabled), which helps control channel load.
Real-world performance depends on radio settings and topology: frequency, spreading factor, bandwidth, coding rate, power, and repeater placement.
Protocol structure at a high level
Treat this as a functional model for understanding, not as a strict official byte-level specification:
1. Radio layer (LoRa PHY)
LoRa handles physical signal transmission over ISM spectrum using configurable radio parameters.
2. Transmission behavior and airtime
Practical network behavior is shaped by timing, retransmission behavior, and configuration choices that keep airtime manageable.
3. Mesh forwarding via repeaters
When no known path exists, discovery flood via repeaters can be used; after successful delivery, a usable path can be learned.
4. Message layer
Application content like text and room messages is sent compactly and can be encrypted.
Message structure at concept level
Avoid publishing invented fixed packet layouts as official MeshCore specification. Use this conceptual model instead:
MeshCore message (conceptual): [Send context] [Compact content] [Delivery/forwarding context] - source/target context - payload for direct or room communication - forwarding and delivery context - integrity and encryption context
Exact internal layout can vary by implementation/version. For website-level technical documentation, protocol behavior is safer than unverified byte-field claims.
Relevant message forms
Direct message
Node-to-node communication between two participants.
Room message
Message to a room so multiple participants receive the same content.
Discovery traffic
Traffic that can help establish initial reachability when no path is known yet.
Learned-path follow-up traffic
After successful delivery, follow-up traffic can be forwarded more directly via known repeaters.
Delivery status / reporting
Delivery context can be fed back to improve forwarding behavior for subsequent messages.
Encrypted content
Message content can be transmitted encrypted for confidential communication.
How does routing work?
MeshCore combines discovery behavior with targeted repeater forwarding.
Discovery with unknown path
When no path is known yet, discovery flood via repeaters can be used to reach the destination.
Upper bound and practical tuning
Documentation references an internal 64-hop upper bound. In practice, flood/forward behavior is tuned at repeater level (for example flood.max) based on terrain and airtime.
Benefits of this protocol approach
More targeted follow-up routing
After discovery, messages can move more efficiently over known repeater paths.
Decentralized
No central internet infrastructure is required for local mesh communication.
Encryption supported
Messages can be encrypted without relying on unverified channel-slot assumptions.
Airtime-aware
Compact messages and repeater-based forwarding help keep channel pressure under control.
Range via repeaters
Multi-hop repeater forwarding extends communication beyond direct radio range.
Regionally scalable
With strategic repeater placement, coverage and utility grow over time.
Technical focus points
| Frequency (EU) | Operate within 863-870 MHz ISM spectrum under local rules |
| Bandwidth | Part of the RF profile; affects robustness and data rate |
| Spreading Factor | Higher SF improves reach while reducing speed |
| Coding Rate | More error correction improves resilience but lowers throughput |
| Payload | Practical size depends on LoRa settings and configuration |
| Encryption | Supported; exact model depends on implementation/configuration |
Frequently asked protocol questions
Is MeshCore compatible with Meshtastic?
No. They are different protocol implementations and are not directly interoperable by default.
How fast is data transmission?
It depends on SF, bandwidth, coding rate, and environment. LoRa prioritizes reach and reliability over high throughput like WiFi.
Can I build custom applications?
Yes, as long as you design for limited LoRa bandwidth and keep compatibility with the network you operate in.
What happens when traffic overlaps?
Channel pressure increases under simultaneous traffic. Careful RF tuning, message discipline, and repeater configuration reduce collisions and delay.
Is protocol overhead a fixed byte number?
Avoid fixed overhead claims without official source data. Effective overhead and payload vary by implementation and radio settings.
Does MeshCore use internet-style IP addressing?
MeshCore is not a TCP/IP internet stack. Avoid unverified claims about fixed internet-style addressing models.
Start with MeshCore development
With this protocol baseline, you can reason about MeshCore correctly: LoRa as transport, repeater forwarding, and route optimization after successful delivery.