# Protocol overview
Z-Mesh is a royalty-free, open source, simple, secure IoT protocol that can be used for device-to-device and broadcast communication. It is designed for battery-driven sleepy devices and do not require a backend server for management. Content has names and can be requested or broadcast and the object of encryption is the data itself. Only devices with the correct encryption key for that content-name can decode the messages. All communication within a network is authenticated using a Network key, making sure only authenticated device can participate in the network.
Z-Mesh is inspired by Content centric networking (opens new window) where endpoints communicate via name-based data instead of IP-addresses. Like in CCN, the object of encryption is the data, not the connection. This makes Z-Mesh a very flexible architecture with no single point of failure while supporting one-to-many event-driven communication and opens up for features like edge computing, distributed management and message queueing.
# Event-based communication
Z-Mesh has been created to address the growing need for event-based communication in IoT applications. In event-based communication, an IoT device or microservice publishes an event when something happens, such as a door-open, person-presense, light-switch-on or a temperature reading. Other IoT devices or microservice applications then listens for these events and executes their business-logic for that event. Events can be queued by message-brokers, enabling asynchronous communication, such as a battery-driven sleepy device waking up for event-retrieval.
# MQTT-like topics
Content Names in a Z-Mesh network are typically hashes of MQTT-like topics. This allows MQTT Gateways to transparently translate between MQTT and Z-Mesh. Each Content-name has it's own unique encryption key, therefore, only devices or applications with the same encryption-key can decipher the information. It is possible to send information in clear text, but it is not recommended.
# Physical layer
Z-Mesh is independent of the physical layer. It SHOULD run directly on the PHY layer, be it sub-GHz, 2.4GHz, 802.11, 802.15.4, I2C or it can be sent over IP. This specification details the mapping for these physical layers.
# Device Management
Z-Mesh defines a management protocol that is tailored to fit constrained devices. It defines:
- Data-flow and encryption key management
- Device firmware upgrade
- Network monitoring
- Feture configuration
Devices and applications is born with a 64-bit Device ID, a 128-bit management key (plus 72-bit IV). The device encryption key is unique to the device and i used for device management purposes.
# Device Features
A Z-Mesh Device Feature defines some kind of function that the device has. Features can be anything from a temperature sensor or a window-opener to a network service that provides the current time. One can think of a Feature as the application layer functionality sitting on top of the Z-Mesh protocol. They make it easy to create sensors, as they act as an API for the Z-Mesh network.