1. Skip to navigation
  2. Skip to content
  3. Skip to sidebar

Requirements for Device Networking

Following are the 18 requirements we set out to meet in designing our control networking technologies. All 18 do not apply to all applications. However as application developers implement devices, they can be assured that they are building on a foundation that has been pre-thought to deal with a broad range of requirements and corner cases.

The scope of requirements for the protocol stack applies to the medium access control (MAC) and Physical Layer (PHY) interface and to the application itself. No attempt is made to mandate that some of the requirements be met in the Network, Transport, or Application layers.

  1. The protocol stack must recover from intermittent packet loss quickly via packet retransmission or report a message failure to the application.
    Rationale: The sorts of links that these networks run on have very low bandwidth compared to Ethernet, and unlike Ethernet the links are not nearly as reliable. Packets can be lost due to interference and noise as well as collisions. When these events occur, they are relatively frequent so that more bandwidth is consumed to recover from the loss using retransmission. Second, because these systems typically have real-time constraints, delivering the packet late is not desirable.
  2. It must be possible to engineer the control network so that the real-time requirements of the application are met. This involves:
    • Designing the network to meet response time criteria by limiting the number of nodes per link, and tuning the communications so the network will not become overloaded.
    • Specifying that a given communications transaction will either succeed or fail within a specified time, with the success or failure of that transaction known to the application.
    Rationale: In a control system, a late packet would result in some node not doing its function in synchronization with the other nodes.
  3. The protocol stack must implement all communications services that are needed by all nodes — without diminishing any of the services. Therefore, the protocol stack must be compact so that the control application also has adequate RAM. To put this requirement in perspective, currently available devices that combine a microcontroller and an IEEE 802.15.4 radio typically have 8–12kb of RAM to share between the protocol stack and the application. Most developers expect to be able to use most of this RAM for their applications.
    Rationale: In the world of low-cost systems-on-a-chip (SOCs), RAM is the most precious resource. In control networking applications, it is needed for buffers, to maintain state and know when to resend a packet, to detect a duplicate packet, to put packets in correct order for delivery, etc. These draws on the memory are in direct competition with the needs of the application. Given cost pressures, the use of SOCs is a reasonable solution.
  4. The protocol stack must be independent of the underlying MAC/PHY interface.
    Rationale: There is no single solution for all communication needs among all devices. Multiple RF, power line, and a variety of wired links are needed to implement various applications. Further, transceiver design continually evolves and improves, so the protocol stack must be able to take advantage of new technologies as they become available.
  5. The protocol stack must scale to thousands of nodes and to multiple links of different speeds in a single logical network.
    Rationale: Many building and factory systems are composed of well over 1,000 nodes that use many types of links to a high-speed backbone.
  6. Network wide multicast, with multicast group membership, must be supported. Grouping provides that all applications do not see and consume resources for multicasts not pertaining to them, other than to discard the packet at a low layer in the stack.
    Rationale: Multicast conserves bandwidth and improves response time over multiple, serial unicast messages. When closing a control loop over a network it is sometimes critical that all nodes that subscribe to a sensor value get that value very close to the same time. Applications cannot require that all the nodes in their group are on a common link because some messages, such as emergency messages, must go to most, or even all the nodes on the network. A node does not have the memory to process all multicasts just to discover which ones do not apply to it.
  7. Confirmed, network wide multicast must be supported.
    Rationale: In applications where the message must get through or a major equipment shutdown is required (for safety reasons, for example), the sending node must be able to have confirmation that its message was received by all the members of the multicast group.
  8. The protocol stack must support duplicate packet detection and resend the previously generated response without reprocessing or regenerating it.
    Rationale: Many types of packets should be ignored. For example, let's say a utility customer on a pre-pay contract adds money to their account, and the additional credit is transferred to their meter, but the meter’s acknowledgement packet is lost. So the utility re-sends the add credit message. Correct behavior would be for the meter to only add the credit one time.
  9. The protocol stack must support a mechanism that allows emergency messages to be routed in an expedited manner, bypassing router and node queues.
    Rationale: In control networks, sometimes all nodes respond to an event (for example, an oil refinery is about to catch fire), which causes a flood of messages. Not all those messages are crucial to resolving the problem, but the messages that are must be propagated quickly across the network.
  10. The protocol stack must ensure that packets are received in the order they are sent.
    Rationale: There are many control operations that depend on a sequence to prevent damage to equipment or simply to work correctly.
  11. The protocol stack must support a sender node being able to poll multiple nodes in sequence without waiting for the response from one node to arrive before going on to the next node.
    Rationale: Most control systems have supervisory nodes that query the status of all the nodes in the network and drive an operator display of the system health. Without a polling provision, if a single node is down, the update of the entire display will halt until communication with the down node times out after some number of retries. The protocol needs to support multiple responses outstanding, with a means to correlate those responses to original requests.
  12. The protocol stack must support peer-to-peer communications.
    Rationale: For response time reasons, nodes cannot wait to be granted access to the network by a server. For finely distributed systems, the nodes must interact as groups performing a function across the network, for example, dimming lights.
  13. It must be possible to provision timers in the protocol stack to indicate when to re-send a packet that has not been confirmed. These timers should be individually provisioned according to the destination address in the packet.
    Rationale: Individual node confirmation/resend settings can improve response time and limit bandwidth consumption. How quickly a node should retry a message is a function of the round trip delay to and from the destination address. Retrying too early wastes bandwidth and may cause network congestion and packet collisions. Retrying too late makes response time suffer when a packet is lost. In a network composed of multiple links of differing speeds, a resource-constrained node cannot be expected to know the round trip delays for all subscribers of its data. Therefore, for large networks, a node with topology knowledge needs to provision these parameters.
  14. It must be possible to discover the application level information that a node can publish over the network.
    Rationale: Some networks are spontaneous in their formation and allow nodes to come and go without a management station being available or required.
  15. The protocol must have a means to transfer a sequence of packets as a logical unit.
    Rationale: Data logging is a common control network function that includes upgrading firmware, provisioning for linearization of sensor tables, calibrating data, and other operations.
  16. Future versions of the protocol must work with prior versions and provide all the same capabilities.
    Rationale: Control networks are long-lived, 20+ years in many cases, and they are networks to which nodes and applications are added over time. It is unreasonable, and often prohibitively costly, to upgrade all existing network nodes to a new software version that might also impose new requirements, such as additional node memory or other constraint.
  17. There must be some lightweight application interoperability model to facilitate the exchange of data between publishers and subscribers.
    Rationale: Resource-constrained nodes cannot support parsers of data streams; For example, today’s XML parsers are code space and RAM intensive.
  18. Today, the vast majority of control networks are not secured. This will change, so the protocol must be able to support strong encryption, mutual authentication, and protection against record/playback attacks. To sell networks to the U.S. government, the requirement is that the algorithms be NSA suite B approved.
    Rationale: As the world moves from hardwired, closed, unconnected networks to networks that connect to the Internet, the chance of threats increases.
HTTP/1.1 200 OK Content-Length: 22260 Content-Type: text/html Server: Microsoft-IIS/7.5