User Tools

Site Tools


IoTivity discovery consumes precious resources and the consumption can be reduced but not eliminated. This article attempts to fully characterize the problem, without proposing a solution. Other articles will propose a solution to the problem, and provide a critique of other proposals to solve the problem.

First, here is a summary of the discovery problem and its context:

  • IoTivity discovery depends on multicast network packets. Multicast packets are like shouting in a crowded room. They need to reach and be considered by all possible IoTivity servers.
  • Currently, IoTivity discovery typically requires many (if not most) IoTivity servers to respond, given the small amount of information in the discovery packets on which to base a response.
  • As IoTivity becomes ubiquitous, two issues will become critical that may not be considered very important today: scaling and energy. We should start orienting IoTivity to support those issues now.
    • The scaling issue is that IoTivity is intended to support large number of systems from a variety of companies, and each system may consist of multiple client, gateway and server applications. For example, a server node might have a dozen or more independent IoTivity server applications sharing the same IP stack, and a network may support hundreds of different server applications in various groupings across thousands of server nodes.
    • The energy issue only becomes apparent when we consider the intended scale of IoTivity. Over time, we expect IoTivity to be used in millions and possibly billions of devices. This means that any unnecessarily repetitive activity can potentially waste much energy. Making the problem worse is that much of that energy will be in devices depending on batteries or scavenged power, where energy usage can determine the lifetime or availability of IoTivity systems.
  • Networks can experience temporary disruptions. Such disruptions can interrupt or otherwise interfere with IoTivity systems. The disruptions can occur in both wired and wireless networks, and their cause can be natural (such as wireless interference) or as a result of technology issues such as re-configuring a network. Networks talking directly to IoTivity server nodes are more likely to experience disruptions. We can't eliminate disruptions.
  • The consistency issue is that many IoTivity systems want to present predictable behavior as much as possible. For example, a sensor value coming from an IoTivity server node may be presented to a user or an application on a regular basis. For another example, an actuator on an IoTivity server node may want to be exercised on a regular basis. A disruption in network connectivity may interfere with the regular action in either case. Minimizing the apparent disruption in both cases may make an IoTivity-based system appear “better” to humans observing it.

The need for optimizing re-discovery comes from the energy issue and the consistency issue. The scaling issue places constraints on the solution.

Here is a practical demonstration of the re-discovery problem:

  1. Client A uses IoTivity discovery (multicast) to discover Server B.
  2. Client A uses the IP address and port number of Server B to perform IoT functions using IoTivity protocol.
  3. The power of Server B is cycled, causing it to restart. The restart will likely result in Server B getting a new port number, and it may also get a new IP address. Client A needs to know how to communicate with the new instance of Server B.
  4. Client A will note that Server B fails to respond to requests or fails to make any more Observer reports. After some indefinite time (likely determined by timeout processes), Client A determines that Server B seems no longer available.
  5. Client A performs IoTivity discovery and determines the connection information for the new instance of Server B. System operation resumes.

The example shows that long term operation of the system containing Client A and Client B will continue reliably under the current regime. However several shortcomings can be seen:

  • The recovery time is highly dependent on timeouts. Setting the timeout values is a difficult balancing act between minimizing the recovery time and minimizing the energy expenditures associated with recovery. For example, if the network connection is subject to random temporary disruptions, a small timeout value may unnecessarily introduce re-connection activity, wasting time and likely prolonging the effect of the disruption.
  • If the disruption results from a server node restarting, the recovery time may be indeterminate and long. Many small nodes take considerable time to restart because of limited power and processing, and restarting may result in a changed IP address and port number. A client may be tempted to perform re-discovery early and often in order to minimize the effect of the disruption, but that will consume additional energy and place additional traffic on the network link.
  • Many nodes may be unnecessarily involved. Each recovery process may involve only one or a few server nodes, but the multicast re-discovery process requires processing in every node that receives the multicast, and some working nodes (not otherwise disrupted) will respond. This results in considerable traffic and energy usage.
  • The variable and prolonged nature of the current recovery process results in delays that hurt the consistency issue.

In summary, the current IoTivity protocol will result in excess traffic, unneeded energy consumption and inferior quality of service in real-world usage.

the_re-discovery_problem.txt · Last modified: 2016/05/19 15:29 by John Light