Z-Wave Network Layer Specification ( Z-Wave Routing ) Released

So I stumbled across the long promised (announced 12/19, expected 2H20) Z-Wave Network Layer specification; evidently unveiled this past August and bundled along with the Z-Wave Long Range Network Layer spec.

Heretofore all that was publicly known about Zensys-designed Z-Wave routing internals was inferred by experimentation (and a few Si Labs tutorials).

Browsing the 130 (!) pages devoted to the non-LR Z-Wave network layer doesn't reveal much that hadn't been surmised before, though the provided definitions of routing frame bit fields will be useful to Zniffer users.

PDF is here: https://sdomembers.z-wavealliance.org/document/dl/897

Key assumptions are confirmed:

  • Controllers "are aware of network topology and determine routes between any two nodes in the network"

  • End nodes "do not calculate routes, they simply rely on route information provided by the controllers"

  • End nodes without return route assigned to a destination should try direct range transmission. If direct range transmission fails, they should issue their command using a Normal Explore Frame or may request a static route to the SUC

  • The following route resolution is recommended:
    • Priority route (if any) or last working route
    • Calculated routes for controllers / Assigned return routes for end nodes
    • Explorer Frames

A feature I hadn't heard of before is the "Routed Speed Modified" bit present in the singlecast routing header; signifying retransmission at lower speed and implying that the destination should not reuse the current route as main route (good thing, too, as 9.6kbps frames don't use CRC's, only simple checksums.. yikes)

And then there's stuff like this (SHALL, SHOULD, MAY definitions are provided):

A controller SHOULD assign up to 4 return routes to a destination if possible.
All Routed Frame transmissions attempts MAY use the same route. Controllers SHOULD try to calculate new routes based on their network topology information.
A Primary or SUC/SIS controller MAY perform a Neighbour Discovery periodically to keep the network topology accurate.

...and the recipe for Ghost Nodes:

"In case of an unsuccessful SmartStart inclusion:
• The joining node SHALL leave the network automatically and consider itself not included in any network. The joining node SHALL return to SmartStart learn mode.
• The including controller SHOULD consider the joining node removed from the network. It MAY verify if the joining node has left the network properly using the NOP Command Class".

Given Z-Wave's tacked-on architecture (evolving from home lighting control in 1999 to sensor driven home automation system of today) it's clear that Z-Wave LR is the holy grail. Z-Wave LR routing takes a relatively short 50 pages to describe; it doesn't need to contend with in-range neighbor discovery/reporting and Tx power dampening, 3 optional data rates (some dictating unique routing frames), optional RSSI reporting, optional NWI and NWE.

Still, the controller handling a combo Z-Wave + Z-Wave LR network needs to do all of that, and more.

4 Likes

Very cool thanks for the quick overview and link!

I found that the Hub's idea of what constitutes "neighbor" nodes can sometimes be quite different from the real world layout - EM propagation weirdness aside. My semi-educated guess this is because the way things were paired originally. The fallback to original routing, and frame exploring can cause strange stuff.. slowness, questionable routing decisions etc.

1 Like