SmartMesh_IP_User_s_Guide
SmartMesh IP User's Guide
Table of Contents
1About This Guide _________________________________________________________________________________ 4
1.1Related Documents __________________________________________________________________________ 4
1.2Conventions Used ___________________________________________________________________________ 6
1.3Revision History _____________________________________________________________________________ 6 2SmartMesh Glossary ______________________________________________________________________________ 7 3The SmartMesh IP Network ________________________________________________________________________ 11
3.1Introduction _______________________________________________________________________________ 11
3.1.1Network Overview ____________________________________________________________________ 11
3.1.2About SmartMesh IP __________________________________________________________________ 13
3.2Network Formation __________________________________________________________________________ 15
3.3Bandwidth and Latency ______________________________________________________________________ 16
3.3.1NumParents Parameter ________________________________________________________________ 16
3.3.2BWMult Parameter ____________________________________________________________________ 17
3.3.3BaseBW Parameter ___________________________________________________________________ 17
3.3.4Services ____________________________________________________________________________ 17
3.3.5Cascading Links ______________________________________________________________________ 18
3.3.6Low-Latency Backbone ________________________________________________________________ 18
3.3.7Normal/Fast Downstream Modes _________________________________________________________ 19
3.4Data Traffic ________________________________________________________________________________ 19
3.4.1Serially Connected "Gateway" Application __________________________________________________ 20
3.4.2End-to-End IP _______________________________________________________________________ 21
3.5Network Security ___________________________________________________________________________ 22
3.5.1Security Layers ______________________________________________________________________ 22
3.5.2Security Modes ______________________________________________________________________ 23 4The SmartMesh IP Manager _______________________________________________________________________ 24
4.1Introduction _______________________________________________________________________________ 24
4.1.1Steps in Designing a Manager Client Application _____________________________________________ 24
4.2Accessing the Manager ______________________________________________________________________ 25
4.2.1Command Line Interface (CLI) ___________________________________________________________ 25
4.2.2Application Programming Interface (API) __________________________________________________ 25
4.3Configuration and Usage _____________________________________________________________________ 26
4.3.1Network ID __________________________________________________________________________ 26
4.3.2Network Time ________________________________________________________________________ 26
4.3.3Communicating with Motes _____________________________________________________________ 27
4.3.4Licensing ___________________________________________________________________________ 27
4.4Network Activity ____________________________________________________________________________ 28
4.4.1Network Structure and Formation ________________________________________________________ 28
4.4.2Network Health ______________________________________________________________________ 28
4.4.3Health Reports _______________________________________________________________________ 30
4.4.4Optimization _________________________________________________________________________ 30
4.5Access Control _____________________________________________________________________________ 30
4.5.1ACL Management _____________________________________________________________________ 30
4.6Over the Air Programming (OTAP) ______________________________________________________________ 31
4.7Restoring Manager Factory Default Settings ______________________________________________________ 32 5The SmartMesh IP Mote __________________________________________________________________________ 34
5.1Introduction _______________________________________________________________________________ 34
5.1.1Steps in a Mote Design ________________________________________________________________ 34
5.2Mote State Machine _________________________________________________________________________ 34
5.3Joining ___________________________________________________________________________________ 36
5.3.1Programmatic Join ___________________________________________________________________ 36
5.3.2Auto Join ___________________________________________________________________________ 37
5.3.3Joining Adjacent Network ______________________________________________________________ 38
5.4Services __________________________________________________________________________________ 38
5.4.1Requesting Bandwidth _________________________________________________________________ 38
5.4.2Back-Off Mechanism __________________________________________________________________ 39
5.5Communication ____________________________________________________________________________ 40
5.5.1Sockets ____________________________________________________________________________ 40
5.5.2UDP Port Assignment _________________________________________________________________ 40
5.5.3Sending and Receiving Data ____________________________________________________________ 41
5.6Events and Alarms __________________________________________________________________________ 41
5.7Factory Default Settings ______________________________________________________________________ 42
5.8Power Considerations _______________________________________________________________________ 42
5.8.1Power Source Information ______________________________________________________________ 42
5.8.2Routing Mode _______________________________________________________________________ 43
5.8.3Join Duty Cycle ______________________________________________________________________ 43
5.9Master vs. Slave ____________________________________________________________________________ 44
5.9.1Mode Behavior _______________________________________________________________________ 44
5.9.2Switching To Slave Mode _______________________________________________________________ 45
5.9.3Switching To Master Mode _____________________________________________________________ 45
1 About This Guide
1.1 Related Documents
The following documents are available for the SmartMesh IP network:
Getting Started with a Starter Kit
- walks you through basic installation and a few tests to make sure your network is SmartMesh IP Easy Start Guide
working
- the Installation section contains instructions for the installing the serial drivers and SmartMesh IP Tools Guide
example programs used in the Easy Start Guide and other tutorials.
User Guide
- describes network concepts, and discusses how to drive mote and manager APIs to SmartMesh IP User's Guide
perform specific tasks, e.g. to send data or collect statistics. This document provides context for the API guides. Interfaces for Interaction with a Device
- used for human interaction with a Manager (e.g. during development of a client, or SmartMesh IP Manager CLI Guide
for troubleshooting). This document covers connecting to the CLI and its command set.
- used for programmatic interaction with a manager. This document covers SmartMesh IP Manager API Guide
connecting to the API and its command set.
- used for human interaction with a mote (e.g. during development of a sensor SmartMesh IP Mote CLI Guide
applicaition, or for troubleshooting). This document covers connecting to the CLI and its command set.
- used for programmatic interaction with a mote. This document covers connecting to SmartMesh IP Mote API Guide
the API and its command set.
Software Development Tools
- describes the various evaluation and development support tools included in the SmartMesh IP Tools Guide
, including tools for exercising mote and manager APIs and visualizing the network.
SmartMesh SDK
Application Notes
- Cover a wide range of topics specific to SmartMesh IP networks and topics that SmartMesh IP Application Notes
apply to SmartMesh networks in general.
Documents Useful When Starting a New Design
The Datasheet for the , or one of the based on it.
LTC5800-IPM SoC modules
The Datasheet for the , or one of the based on it.
LTC5800-IPR SoC embedded managers
A for the mote/manager SoC or - this discusses best practices for integrating the
SoC or module into your design.
Hardware Integration Guide
A for the embedded manager - this discusses best practices for integrating the embedded
manager into your design.
Board Specific Integration Guide
A - For SoC motes and Managers. Discusses how to set default IO configuration and
crystal calibration information via a "fuse table".
Hardware Integration Application Notes
- contains an SoC design checklist, antenna selection guide, etc.
ESP Programmer Guide DC9010
The - a guide to the Programmer Board and ESP software used to program firmware on a device.
ESP software - used to program firmware images onto a mote or module.
Fuse Table software - used to construct the fuse table as discussed in the Board Specific Integration Guide.
Other Useful Documents
A glossary of wireless networking terms used in SmartMesh documentation can be found in the SmartMesh IP User's
Guide
.
A list of Frequently Asked Questions
1.2 Conventions Used
The following conventions are used in this document:
indicates information that you enter, such as specifying a URL.
Computer type
indicates buttons, fields, menu commands, and device states and modes.
Bold type
is used to introduce a new term, and to refer to APIs and their parameters.
Italic type
Tips provide useful information about the product.
Informational text provides additional information for background and context
Notes provide more detailed information about concepts.
Warning! Warnings advise you about actions that may cause loss of data, physical harm to the hardware or your person.
1.3 Revision History
2 SmartMesh Glossary
Access point (or AP)
- The device that bridges the wireless and wired networks. Converts wireless MAC packets to wired Net packets and vice versa.
Acknowledgement (or ACK)
- A frame sent in response to receiving a packet, confirming that the packet was properly received. The ACK contains the time difference between the packet receiver and sender.
Advertisement
- A frame sent to allow other devices to synchronize to the network and containing link information required for a new mote to join.
ASN
- Absolute Slot Number. The number of timeslots that have elapsed since the start of the network (WirelessHART) or 20:00:00 UTC July 2,2002 (IP if UTC is set before starting the network)
Authentication
- The cryptographic process of ensuring that the packet received has not been modified, and that it originated from the claimed net layer sender.
Backbone
- A feature in a SmartMesh network that allows motes to share a fast superframe to enable low-latency alarm traffic.
- The capacity of a mote to transmit data, usually expressed in packets/s.
Bandwidth
Base Bandwidth
- The bandwidth each mote in a network gets without having to request a service.
CCM*C C M
- ounter mode with BC-AC. The authentication/encryption scheme used in Dust products. See the application note "SmartMesh Security" for a more detailed description,
Channel
- The index into a list of center frequencies used by the PHY. In 802.15.4, there are 16 channels in the 2.4-2.4835 GHz Instrumentation, Scientific, and Medical (ISM) band.
Channel Hopping
- Changing channel between slots, also called "slow hopping" to distinguish from PHY's that change channel within a message, such as Bluetooth.
- A link-specific number used in the channel calculation function to pick which channel to use in this ASN. Channel Offset
Child
- A device that receives time information from another mote is its child. A child forwards data through its parent.
- Carrier Sense Multiple Access. A communications architecture where an unsynchronized transmitter first senses if CSMA
others are transmitting before attempting its transmission.
Commissioning
- The act of configuring motes for use in a deployment, typically by setting Network ID, join key, and other joining parameters.
Discovery
- The process by which motes find potential neighbors, and report that information back to the manager. Downstream
- The direction away from the manager or wired-side application and into the mesh network.
- The cryptographic process of converting payload information into a form indistinguishable from random noise, Encryption
such that it can only be read by the intended recipient.
- Information sent by the PHY layer. Typically containing per-hop (MAC) and end-to-end (Net) layer Frame (or packet)
headers and a payload.
- The device in a WirelessHART network responsible for abstracting the wired HART data model from the Gateway
WirelessHART mesh implementation.
- A numbered routing element included in the WirelessHART net and IP mesh layer headers which tells a mote where to Graph
send each packet. Superframes and slotframes also have a graph ID.
- A route where only the graph ID is specified in the packet header. A packet can follow the graph route through Graph route
multiple motes to its destination. Compare with source route.
- The time a device listens in advance or after the expected packet arrival time to allow for imperfect
Guard time
synchronization between devices.
- A packet sent by a mote conveying its internal state and the quality of its neighbor paths. Health reports are Health report
used by the manager in optimization and diagnostics.
- A slot where the receiving device wakes up to receive a packet but the transmitting device does not send one. Idle listen
About two-thirds of all receive slots end up as idle listens in a typical network.
- The sequence of handshakes between a new mote and a manager to bring the mote into the network. It begins with Joining
a mote presenting an encrypted request and ends with link and run-time security credential assignment.
- An empty packet sent to keep devices synchronized after a timeout during which no data packets have been sent Keep alive
on a path. This timeout is typically 30 seconds in WirelessHART and 15 seconds in IP.
- The time difference between packet generation and arrival at its final destination.
Latency
- A mote that presently has no upstream RX links, and thus no children. Also called a leaf node or leaf mote.
Leaf
- A logical or physical device which converts 6LowPAN (IPv6 for Low power Wireless
Low Power Border Router (LBR)
Personal Area Networks, RFC 4944) packets into IPv6 packets. Also called an Edge Router.
- The Medium Access Control layer. Technically a sublayer of the Data Link Layer (OSI layer 2), but typically used
MAC
interchangeably in Dust documentation.
- The device or process responsible for establishing and maintaining the network.
Manager
- a mode of mote operation where the mote automatically joins the network for which it was configured, the Master (mode)
serial API is disabled, and a resident application allows for interacting with some onboard I/O.
- A network topology where each mote may be connected to one or more motes.
Mesh
- A device which provides wireless communications for a field device to transmit sensor or other data. The basic
Mote
building block of a network.
- A network where one or more motes has no path to the access point. Data packets may sometimes take multiple Multi-hop
hops from source to destination.
- A radio signal that is the superposition of many reflected signals. Used as an adjective to describe phenomenon Multipath
where signal level can vary dramatically with small environmental changes, . multipath propagation, or multipath fading.
i.e
- A special ACK frame sent in response to receiving a packet, stating that it was correctly received but NOT accepted for NACK
forwarding.
- A mote in range of the mote in question.
Neighbor
- A mote that has been configured to not advertise. A non-routing mote never forwards packets along a graph or Non-routing
has children.
- The manager process of taking health report information and using it to modify the network to minimize energy Optimization
consumption and latency.
- Also called a frame. The variable sized unit of data exchange.
Packet
- A device that serves as a source of time synchronization. In Dust networks, a mote's parent is one Parent (or time parent)
hop closer to the AP. A parent forwards a child's data towards the manager.
- The potential connection between two motes. A path that has assigned links is a used path. One that has been
Path
discovered but has no links is an unused path.
- The ratio of acknowledged packets to sent packets between two motes. Each of the two motes keeps a
Path stability
separate count of the path stability denoted by A->B and B->A. A path where the two motes have significantly different counts of path stability is called an asymmetric path.
- A feature in a SmartMesh WirelessHART network that enables rapid publishing to and/or from a single target mote. Pipe
- The number of links assigned by the manager per packet generated by the mote to allow for imperfect stability. Provisioning
Default provisioning is 3x meaning that on average each packet has three chances to be successfully transmitted before the mote starts to accumulate packets.
- The rate at which an mote application transmits upstream data. In WirelessHART the term burst Publishing rate (Burst rate)
rate is equivalent to Publishing rate.
- The physical layer, . the radio.
PHY i.e
- The percentage of unique packets received relative to the number generated.
Reliability
- The motes that a packet passes through between source and destination, . a packet from mote 3 might use the Route e.g
route 3-2-6-AP. Because of the graph routing used upstream, packets originating at the same mote randomly take a variety of routes.
- The collection of superframes and links in the network, particularly those organized for a particular purpose. Schedule
- The process of requesting and receiving (or not) task-specific bandwidth.
Services (or Timetables)
- a mode of mote operation where the mote requires an application to drive its API in order to join the network. Slave (mode)
- A collection of timeslots with a particular repetition period (length) and labeled with a Graph ID. Slotframe or Superframe
- A route where every hop between source and destination is explicitly specified in the packet header. Dust Source route
networks only use source routing for downstream packets.
- A network topology where all motes only have a connection to the the access point (in ZigBee, the PAN coordinator) Star
and are non-routing leafs.
- A network topology where motes form stars around routers, where the routers may have one or more neighbors Star-mesh
through whom they can forward mote data.
- The aggregated information about network topology and performance constructed from the raw mote health Statistics
reports.
- Time Division Multiple Access. A communications architecture where packetized information exchange only occurs TDMA
within timeslots and channel offsets that are assigned exclusively to a pair of devices.
- A defined period of time just long enough for a pair of motes to exchange a maximum-length packet and an Timeslot
acknowledgement. Time in the network is broken up into synchronized timeslots.
- The direction towards the manager or wired-side application from the mesh network.
Upstream
- A single channel, CSMA network protocol.
ZigBee
3 The SmartMesh IP Network
3.1 Introduction
The Network User's Guide is intended to explain fundamental network and device behavior and features at a high level. For details on the APIs referenced, see the SmartMesh IP Manager Guides and Mote Guides.
3.1.1 Network Overview
motes
A SmartMesh? network consists of a self-forming multi-hop, mesh of nodes, known as , which collect and relay data,
Network Manager
and a that monitors and manages network performance and security, and exchanges data with a host application.
SmartMesh networks communicate using a Time Slotted Channel Hopping (TSCH) link layer, pioneered by Linear's Dust Networks group. In a TSCH network, all motes in the network are synchronized to within less than a millisecond. Time in the network is organized into timeslots, which enables collision-free packet exchange and per-transmission channel-hopping. In a
parents e.g.
SmartMesh network, every device has one or more (mote 3 has motes 1 and 2 as parents) that provide redundant paths
to overcome communications interruption due to interference, physical obstruction or multi-path fading. If a packet transmission fails on one path, the next retransmission may try on a different path and different RF channel. Building networks with sufficient redundancy requires following some simple deployment guidelines - these are outlined in the application note
"Planning a Deployment."
A network begins to form when the network manager instructs its on-board access point radio (AP) to begin sending
packets that contain information that enables a device to synchronize to the network and request to join. This advertisements -
message exchange is part of the security handshake that establishes encrypted communications between the manager or application, and mote. Once motes have joined the network, they maintain synchronization through time corrections when a packet is acknowledged.
An ongoing process ensures that the network continually discovers new paths as the RF conditions change. In discovery
addition, each mote in the network tracks performance statistics (quality of used paths, and lists of potential paths) and
e.g.
periodically sends that information to the network manager in packets called . The Network Manager uses health
health reports
reports to continually optimize the network to maintain >99.999% data reliability even in the most challenging RF environments.
The use of TSCH allows SmartMesh devices to sleep in-between scheduled communications and draw very little power in this state. Motes are only active in timeslots where they are scheduled to transmit or receive, typically resulting in a duty cycle of <1%. The optimization software in the Network Manager coordinates this schedule automatically. When combined with the Eterna low-power radio, every mote in a SmartMesh network – even busy routing ones – can run on batteries for years. By default, all motes in a network are capable of routing traffic from other motes, which simplifies installation by avoiding the complexity of having distinct routers vs. non-routing end nodes. Motes may be configured as to further reduce
non-routing
that particular mote’s power consumption and to support a wide variety of network topologies.
At the heart of SmartMesh motes and network managers is the Eterna IEEE 802.15.4e System-on-Chip (SoC), featuring our highly-integrated, low power radio design, plus an ARM Cortex?-M3 32-bit microprocessor running SmartMesh networking
?
software. The SmartMesh software comes fully compiled yet is configurable via a rich set of application programming interfaces (APIs) which allows a host application to interact with the network, e.g. to transfer information to a device, to configure data publishing rates on one or more motes, or to monitor network state or performance metrics. Data publishing can be uniform or different for each device, with motes being able to publish infrequently or faster than once per second as needed.
3.1.2 About SmartMesh IP
combines reliability and ultra low-power with a native Internet Protocol (IP) layer for a robust, standards-based SmartMesh IP
offering perfect for a broad range of applications. provides robust wire-free connectivity for applications where
SmartMesh IP
low power, reliability, and ease of deployment matter. With Linear's Eterna? 802.15.4e SoC technology, every node in a network can run on batteries for 10 years, or virtually forever with an energy harvesting power source. The SmartMesh IP
ability to put a sensor anywhere, without wiring, allows network deployments that do not disrupt building operations or occupants. With built-in intelligence that enables the mesh network to self-form and self-maintain, SmartMesh IP systems are easily deployed by field technicians with no wireless technology expertise. A SmartMesh IP network consists of at least one SmartMesh manager and up to 32 or 100 (on managers with external RAM) devices containing embedded SmartMesh Eterna chips. Each manager supports 24 packets/s total egress, or 36 packets/s when external RAM is used. Multiple overlapping networks can be easily used to cover larger deployments or when more egress is needed.
The Starter Kit () comes standard with one SmartMesh manager and 5 motes. You can configure, SmartMesh IP DC9000
monitor, and manage your networks from a PC using Stargazer, a Windows-based graphical user interface provided in the kit. Motes in the kits ship in a standalone mode - they contain a sample application that controls joining and can interact
master
with onboard sensors. In the production default mode, the mote expects an application to drive its API. This is
slave
discussed in more detail in the mote section of this guide.
SmartMesh IP Network
SmartMesh IP Features
SmartMesh IP system features include:
- The network can run on batteries, energy harvesting, or line power.
Ultra low-power network
- >99.9% network reliability even in harsh RF environments.
High network reliability
- Combines 6LoWPAN with IEEE 802.15.4e.
IPv6 addressability
- Allows you to take advantage of a powered backbone to dramatically lower latency for Low-latency mode
infrequently reporting networks.
- Allows you to configure security to meet your requirements.
Comprehensive security management
The SmartMesh IP Network User Guide is intended to explain fundamental network behavior and features at a high level. For details on the APIs referenced, see the or the .
SmartMesh IP Manager API Guide SmartMesh IP Mote API Guide
3.2 Network Formation
For a mote to join a network, it must get time-synchronized to other devices in the network by hearing an from
advertisement
a mote or Access Point (AP) already in the network. The network starts forming when the manager instructs the AP to begin
sending advertisements. One mote will hear the AP advertisement, then join, and start advertising itself. This process repeats
in parallel as other motes join and begin their own advertising. The advertisements are IEEE 802.15.4e Beacon frames that
contain synchronization and link information. In addition to synchronizing the new device, the advertisement also describes
when the new device can send in a request to join the network, and when it should expect a reply. This results in temporary
links being assigned to the joining mote that it will use until it gets its specific links from the manager.
In SmartMesh IP networks, AP advertising can occur either automatically upon boot, or explicitly through the startNetwork
API - the boot behavior is set via the nonvolatile config parameter. A SmartMesh IP manager advertises four times
autostart
per 256-slot slotframe, on average approximately once every 500 ms. Motes within radio range of the AP will join after they
have heard one of these advertisements. Average synchronization time for the first-hop motes, at a 5% duty cycle and a
typical 80% path stability is expected to be:
Mote join duty cycle is configurable by setting the mote parameter - at 100% duty cycle this falls to < 10 s.
joinDutyCycle
Setting a higher join duty cycle increases the power of the searching mote but allows it to synch up more quickly. If your
network has a lot of 1-hop motes though, a low join duty cycle might not slow down the total join time significantly. For
applications with ultra-low power limits, the join duty cycle can be set as low as 0.5%.
After synchronizing, the mote waits for one slotframe while continuing to listen with the goal of hearing more advertisements
from other motes. After this additional listening, the joining mote sends in a consisting of power source and
join request
routing-capability information, as well as a list of heard neighbors. This message exchange is part of the handshake
security
that establishes encrypted communications between the manager or application, and mote, and is encrypted using a shared
secret . The manager responds with a run-time MAC layer authentication key, a session to the manager, a short join key
address to be used by the mote for all communications from this point on, and a route to the manager. Additional packets are
exchanged to establish a broadcast session and associated route, slotframe and link assignment, setting of a time parent, and,
unlike in WirelessHART, an explicit activate command which tells the mote to switch from temporary links to those explicitly
added.
At this point the device may request additional bandwidth for publishing data. A mote that is fully joined into the network will
also be advertising, as instructed by the manager. In this way the network will form 'inside out', starting with just the AP, then
the one-hop motes, then two-hop motes, and so on. For any one mote to join, it need not ever be brought into range of the
manager. It only needs to be within range of some motes that are in the network.
In addition to the motes a joining mote hears, an ongoing process runs continuously. Each discovery interval, a
discovery
single mote transmits, and all others listen. Motes tell the manager who they've heard in a periodic which gives
health report,
the manager a stream of potential path information to use in optimization and healing.
3.3 Bandwidth and Latency
There are several settable parameters that influence how many upstream links each mote will get. These sometimes have complicated interactions. The system is designed to have the flexibility to both scale to large numbers of devices and to achieve ultra-low power for scavenging devices. In the case that the deployment has uniform data generation requirements at all motes, we recommend using parameter on the manager to set network-wide, uniform bandwidth allocation. When
basebw
the requirements vary between motes, we recommend using the service model on each mote individually. Only for special use cases do we recommend changing the other values from their defaults. All devices are given a minimum of two upstream links regardless of any other constraints, and this includes the scenario where a mote has only a single parent.
In general, adding more links to motes:
Decreases latency
Increases packet/s throughput
Increases power
There is no requirement to actually use all the bandwidth assigned to a mote. An application with low latency requirements can request more bandwidth than it needs to get additional links for itself and its ancestors and thereby decrease its upstream latency. Because of the uncertainty in path stability, the network does not guarantee upper bounds on latency. In certain cases, the low-latency backbone discussed below can be used.
3.3.1 NumParents Parameter
The parameter(default = 2) on the manager sets the number of desired parents for each mote. This parameter numParents
applies to the entire network. If set to 2, there will always be one mote with a single parent to avoid timing and data loops. Similarly, if it is set to 3, there will be one single-parent mote and one with two parents. In optimizing the networks, the manager tests links to new parents for some motes, so occasionally motes will have more than parents. In
numParents
deployments where frequent environmental changes lead to high path failure rates, setting to 3 or 4 reduces the
numParents
chance of mote disconnect with the cost of higher power on parent motes.
3.3.2 BWMult Parameter
The parameter (default = 300%) on the manager sets the provisioning safety margin in the network. This parameter BWMult
applies to the entire network. If a mote is requesting to generate a packet every 12 seconds and is set to 300%, then
BWMult
the mote will be given at least one link per 4 seconds. Extreme caution should be used when lowering this below 300% as the vast majority of Dust deployments have been using this value for years. Conceptually, it allows motes to drop down to 33% path stability without filling up any packet queues. Lower settings should only be used for tight energy budgets requiring multi-hop networks.
3.3.3 BaseBW Parameter
The parameter (default = 9000 ms) on the manager is the interval between packets generated at all motes. This BaseBW
parameter applies to the entire network. A setting of 9000 ms is enough to carry all command and diagnostic packets as well as having each mote application generate one packet every 10 s. With the other values above kept at their default settings, > 3100 ms will not result in links added beyond the default of 2. If a deployment has the same data generation rates BaseBW
at all motes, we recommend changing using exclusively to set the network bandwidth.
BaseBW
3.3.4 Services
Applications wishing to support different data generation rates or run-time configurable data rates must use the services model. In this model, the application is responsible for configuring the desired publish rate - the sensor processor could be preconfigured or an application message could be used to configure publishing dynamically - this is left to the OEM integrator. After opening a socket to the desired destination, the sensor processor uses the API to request a target packet
requestService
interval and destination. The sensor processor can expect a notification when the service level has been
serviceChanged
established or modified. In addition to observing granted bandwidth, it is expected that the sensor processor implement back-off to deal with network congestion.
The service may initially be granted at a level lower than that requested. In addition to the notification,
serviceChanged
the sensor processor can use the API at any time to query the status of pending request. The sensor processor
getServiceInfo
could also notify a network-side application that the target service level has not been granted - however this kind of application level message is left to the OEM integrator to implement. The network-side application can also periodically query the manager API to see the difference between requested and granted bandwidth - this information could be used to getMoteInfo
determine the cause of the service rejection, . more repeaters are needed if existing 1-hop motes are link limited.
e.g
3.3.5 Cascading Links
All of the above parameters determine how many links a mote needs for its local traffic. If a mote has children, the network manager will add more links to carry the traffic of all its descendants. The calculation of this requirement is called cascading links. The manager looks at how many upstream RX links it has from its children, and adds the local traffic requirement to get the number of upstream TX links for that mote. In a multi-hop network the one-hop motes may have many more links than the leaf motes even if there isn't much traffic in the network.
3.3.6 Low-Latency Backbone
SmartMesh IP networks support a low-latency backbone superframe for networks that include powered motes. The backbone is a short, contention-based superframe that provides upstream links that all motes share. Because the bandwidth is shared, low-latency communication is enabled at all motes for less power than the equivalent assignment of services. The downside to shared bandwidth is that if too many motes are trying to use it, there will be collisions that prevent anyone from effectively using it. The backbone works best if it is much faster than the average service level in the network and is well suited to rapidly delivering the occasional alarm in a network otherwise provisioned for low traffic.
The setting is a nonvolatile parameter on the manager (default = 0, off). When active, it can be either upstream only, bbmode
or bidirectional. Changing this parameter takes effect after a network reset. The length of the backbone can be changed by modifying the parameter. Larger numbers slow down the superframe, saving power, but increasing latency.
bbsize
When the upstream backbone is enabled, only motes with a sufficient power budget will have children ( listen links) in the
i.e.
backbone. All motes regardless of power will have a transmit link in the upstream backbone. The upstream backbone is intended to minimize sensor latency in ZigBee-like networks with powered infrastructure, where the chance of packet collisions is low.
When the bidirectional backbone is enabled, all motes participate regardless of power considerations, so it has the potential to deplete power-constrained devices quickly. It should only be used where all motes can be guaranteed to have a >1 mA supply available at all times.
If the AP does not have power restrictions, is using fewer than 1/3 of its available links, and the backbone would be otherwise unused in a deployment, we recommend turning on the upstream backbone. The default mote power source information results in motes not having backbone children, so the AP is the only device that will have backbone RX links and the 1-hop motes are the only devices that will have backbone TX links. This means that there is no power penalty at any motes and that the latency from the 1-hop motes to the AP is significantly reduced. All dedicated links continue to work normally, and effectively any time the AP is not servicing a dedicated link it will be listening for transmissions from the 1-hop motes. If the AP is powered, there is no downside to this policy.
3.3.7 Normal/Fast Downstream Modes
Networks used primarily for sensor data collection tend to see a large amount of downstream control traffic during network
formation, and significantly less traffic for optimization and healing during operation. The SmartMesh IP manager supports
automatic transition between a "fast" downstream frame building phase, and a "normal" downstream frame operational phase.
The default frame size for both upstream and downstream frames is 256 slots. The user can modify the nonvolatile
dnfr_mult
'config' parameter via CLI (default = 1) to 2 or 4 to increase the "slow" to 512 or 1024 slots respectively. This can also be done
programmatically by calling the API with the parameter. This lowers the average mote
setNetworkConfig downFrameMultVal
current by ~4 and 8 μA, respectively. As this feature, when enabled, limits the rate at which the manager can fix problems in
the network, a > 1 should only be used in cases where the mote current using default settings is downFrameMultVal
unacceptable.The user can also force the manager to switch between normal and fast downstream modes (framelength
determined by ) via the command. Once this command is executed, the downFrameMultVal SetDownstreamFrameMode
manager switches to manual mode and no longer changes frame size automatically.
3.4 Data Traffic
Motes use unreliable transport (UDP) for user data. However, this does not mean that data is likely to get lost. Downstream,
messages sent to motes < 8 hops deep use source routing with multiple retries per hop. This 8 hops includes the AP. For
packets sent to motes deeper than the source route limit of 8 hops, packets are flooded, and have a small chance of not
reaching the destination. In the case where this is unacceptable, application layer acknowledgements can be used to ensure
downstream delivery.
Upstream, packets are retried indefinitely at the link level until acknowledged. In rare cases (<0.001% typically) data that is
accepted by a mote for forwarding is lost when the forwarding mote resets. If this is not acceptable, then application level
acknowledgements can be used to verify all packets, although this will slow publishing to the rate at which acknowledgements
can be sent downstream (once per 1.9 s).
3.4.1 Serially Connected "Gateway" Application
An application connected directly to the manager can use the API to send packets to an arbitrary UDP port on a
sendData
mote. With the API, the application is only responsible for providing the destination, port, and payload. The sendData
destination address in this case is the EUI-64 of the mote, which is also the lower 8-bytes of its IPv6 address. When the API is
called, a is returned - this will be included in the notification when this packet is injected into callbackId callbackId packetSent
the network. When the packet is received at the mote, a notification is generated which contains IPv6 source/port
receive
information in addition to the UDP payload. It does not contain the UDP checksum information as this is elided.
The sensor processor may use the API at the mote to send packets to the gateway via the manager
sendTo. These will result
in a notification, which contains the EUI-64 address of the mote and port information, a timestamp, and the UDP payload.
data