# Wireless Mesh Networking: An IoT-Oriented Perspective Survey on Relevant Technologies
## 5 Mesh Networking with IEEE 802.15.4
### Other solutions
#### 5.2.2 Lightweight Mesh (LWMesh)  
Another mesh protocol working on top of IEEE 802.15.4 specifications is the Atmel Lightweight Mesh (LWMesh) protocol [71], which is a small footprint, low-power WMN protocol defined to target several applications (such as domestic and industrial automation, AMRs, remote control, etc.) and mainly designed to work with a large amount of IEEE 802.15.4-based SoCs. LWMesh is characterized by several characteristics, whose main ones can be summarized as follows: (i) absence of a dedicated node required to start a network; (ii) absence of joining procedure required before attaching to a LWMesh-handled network; (iii) absence of leafs-roots relationships between the devices participating in the LWMesh topology; (iv) route discovery operation made automatically if the route to the target node is unknown, with routing tables updated automatically on the basis of the data contained into the frames; and (v) support to multicast communications and AODV routing protocol.  
A constrained network based on LWMesh can be composed by two types of nodes: (i) routing nodes (with a hexadecimal MAC address < 0x8000), forming the core network and expected to be powered; and (ii) non-routing nodes (with a network address \(\geq\) 0x8000), able to forward information until they have the radio on and are in the coverage range. Nevertheless, they may not be available in some cases (e.g., nodes outside the transmission range (at the edge of the LWMesh-based network), sleeping nodes, etc) and, due to this, not available as range extenders for routing purposes.  
Applications performing LWMesh are in charge of the following tasks: (i) basic and advanced network management operations and services (e.g., discovery, joining, commissioning, traffic forwarding to sleeping nodes, leaves-roots ties, etc.); (ii) information re-transmission in case of failure; (iii) packet format definition and security; (iv) MCU energy management; and (v) interaction with external hardware peripherals.  
As for similar network protocols, even LWMesh is characterized by a layered stack structure, each one composed by a set of interfaces allowing the wireless communications: (i) Hardware Abstraction Layer (HAL), containing hardware-dependent functions (e.g., sleep control, HW timers, and GPIO radio interfaces); (ii) Radio physical layer (PHY), containing functionalities for enabling the usage of the radio transceiver, for both the network and application layers; (iii) Network layer; (iv) System functions, needed for normal processing (e.g., software timers, configuration, security policies, etc.); and (v) Application policies (e.g., Over-The-Air (OTA) upgrades).  
Concerning the frame structure, as shown in Figure 6, the application payload and network header are both encapsulated inside the data frame payload proper of the IEEE 805.15.4 protocol. A more detailed description of the packet structure is carried out in [72], while it can be highlighted that, even supporting _unicast_, _broadcast_, and _multicast_ frames, LWMesh foresees a duplicate rejection mechanism, in this way avoiding messages flooding into the network.  
Thanks to the multiplicity of fields proper of the general IEEE 805.15.4 frame, LWMesh can support the following two routing algorithms, both using a routing table for their operations.  
1. Native routing: since, through this mechanism, LWMesh performs route discovery without any additional structure, then the native routing algorithm is not able to guarantee the optimality of discovered routes.
2. AODV routing: as introduced in Section 2.1, this is a standard routing algorithm using additional commands to perform route discovery, which might take longer time, but able to guarantee optimality in the discovered routes and to cope with groups of nodes.