# Naming Scheme specification
Z-Mesh uses a hybrid naming scheme that combines a Network-ID and a Content Name. Together they uniquely identifies a Content producer, such as a motion-sensor in the meeting room or a water-meter. Being hybrid, it combines the strengths of being globally unique as well as customized for the local application:
- Network-ID: A globally unique 32-bit identifier, assigned by the Z-Mesh alliance.
- Content Name: A locally unique 48-bit identifier assigned to a Content producer (Device Feature).
Please see the Content Naming page for an in depth description.
# Human readable Unique Resource Identifier (Content Name URI)
In many IoT environments, a hierarchical resource identifier is used to name the data. For example, MQTT calls it a "Topic" and for CoAP- or web-based environments they are URLs. Z-Mesh uses the term Content Name URI to refer to a hierarchical URI String. An example of a Content Name URI would be: location/hq/floor/2/room/22/event/temp.
# Example mapping
The Content Name URI location/hq/floor/2/room/merkur/event/temp is mapped to the hex-value = 010203010000 can be translated from URI to Content Name in the following way:
- Byte0 = 01: location=hq
- Byte1 = 02: floor=2
- Byte2 = 03: room=merkur
- Byte3 = 01: event=temp
- Byte4 = 00: No value
- Byte5 = 00: No value
# Content Names
Some Content Names are reserved for Device Management, some for wildcards and others for non-cacheable data, such as video-streams.
The following tables lists the Content Names prefixes (byte[0]) and their usage:
| Byte 0 | Description |
|---|---|
| 00 | Reserved |
| 01 - 9F | User Content |
| A0 - AF | Non-Cacheable Content |
| B0 - FC | Reserved |
| FD | Proprietary Device Management |
| FE | Z-Mesh Device Management |
| FF | Reserved |
# End-of-Content-Name (0x00)
A Content Names byte with the value = 0x00 (zero) will be interpreted as a name-terminating entity. Names shorter than 6-bytes will end with one or more zero-bytes. Byte-0 MUST not be zero.
# Wildcards (0xFF)
Wildcards (hex value 0xFF) can be used to retrieve or subscribe multiple Content Names at once. This is useful if one does not know the Content Name of the producing devices or apps or if one simply wants to query many Content Names at once.
For example, if a Mobile Phone App wants to know the availability status of all meeting rooms on 2nd floor, it will generate a Content Name where the ContentName-byte representing the room=xxx is replaced with a wildcard (0xFF). An example could be to all motion-sensors in the HQ 2nd floor: 0102FF020000 indicating location/hq/floor/2/room/*/event/motion.
Byte-0 MUST not be 0xFF.
# User Content (0x01 - 0x9F)
Content used for any purpose. Forwarders will cache User Content.
# Non-Cacheable (0xA0 - 0xAF)
Forwarders will not cache Content in this range. This is useful when sending streams of data such as video.
# Z-Mesh Device Management (0xFE)
Device Management Content Names:
Overview (B0 = Byte 0, B1 = Byte 1 etc. NID-H = NodeID High-byte, NID-L = NodeID Low-Byte):
| B0 | B1 | B2 | B3 | B4 | B5 | Description |
|---|---|---|---|---|---|---|
| FE | Device Management | |||||
| FE | 01 | Network Services | ||||
| FE | 01 | 01 | NID-H | NID-L | 00 | Time Service |
| FE | 01 | 02 | NID-H | NID-L | 00 | Directory Service |
| FE | 02 | Forwarder specific | ||||
| FE | 02 | 01 | NID-H | NID-L | 00 | Ping (Interest to NID-H=FF NID-L=FF) |
| FE | 02 | F0 | NID-H | NID-L | 00 | FOTA Broadcast Service |
| FE | 03 | Device Specific | ||||
| FE | 03 | 01 | NID-H | NID-L | 00 | Ping (Interest to NID-H=FF NID-L=FF) |
| FE | 03 | 02 | NID-H | NID-L | 00 | Command |
| FE | 03 | 03 | NID-H | NID-L | 00 | Event |
| FE | 04 | Software specific | ||||
| FE | 04 | 02 | Software Directory | |||
| FE | 04 | 02 | SWID1 | SWID2 | SWID3 | Software ID |