<p>Added the following node query events: <strong>title</strong>, <strong>status</strong>, <strong>beginSection</strong> and <strong>endSection</strong>.</p>
<p>Updated the schema to more strictly validate references to x-data forms.</p>
<p>Updated attribute names so queries and responses are consistent.</p>
<p>Updated the language.</p>
<p>Added section about how to determine support.</p>
<p>Corrected language and examples.</p>
<p>Node Query command type added.</p>
<p>Fixed links to documents with new numbers.</p>
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
Concentrators are devices in sensor networks, concentrating the management of a sub set of devices to one point. They can be small (for example: PLC:s managing a small
set of sensors and actuators), medium-sized (for example: mid-level concentrators, controlling branches of the network, islands, perhaps using separate communication protocols),
large (for example: entire sub-systems, perhaps managed by a separate child/partner organization) to massive (for example: The entire top-level system, smart-grid, IoT network).
</p>
<p>
Even though this XEP is generally written and can be used by other implementations not based on sensor networks, much of the requirements used to define this specification
comes from requirements used in sensor networks and Internet of Things applications and infrastructure.
</p>
<p>
This specification will define the following aspects of a general concentrator profile, that can handle all different types of concentrators available in sensor network architectures:
</p>
<ul>
<li>
A concentrator works with multiple <strong>data sources</strong>. Effective management of data sources and their contents is a vital part of this XEP.
</li>
<li>The ability to work with massive quantities of entities.</li>
<li>Effective synchronization of contents between interested parties.</li>
<li>Effective ways to interact with entities controlled by the concentrator.</li>
</ul>
<p>
Sensor networks contains many different architectures and use cases. For this reason, the sensor network standards have been divided into multiple XEPs according to the following table:
</p>
<tablecaption='Sensor Network XEPs'>
<tr>
<th>XEP</th>
<th>Description</th>
</tr>
<tr>
<td>xep-0000-IoT-BatteryPoweredSensors</td>
<td>Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.</td>
</tr>
<tr>
<td>xep-0000-IoT-Discovery</td>
<td>Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.</td>
</tr>
<tr>
<td>xep-0000-IoT-Events</td>
<td>Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.</td>
</tr>
<tr>
<td>xep-0000-IoT-Interoperability</td>
<td>Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.</td>
</tr>
<tr>
<td>xep-0000-IoT-Multicast</td>
<td>Defines how sensor data can be multicast in efficient ways.</td>
</tr>
<tr>
<td>xep-0000-IoT-PubSub</td>
<td>Defines how efficient publication of sensor data can be made in sensor networks.</td>
</tr>
<tr>
<td>xep-0000-IoT-Chat</td>
<td>Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture.</td>
</tr>
<tr>
<td>XEP-0322</td>
<td>
Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered
in all sensor network implementations where memory and packet size is an issue.
</td>
</tr>
<tr>
<td>XEP-0323</td>
<td>
Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks.
It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other sensor network XEPs.
</td>
</tr>
<tr>
<td>XEP-0324</td>
<td>Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
</tr>
<tr>
<td>XEP-0325</td>
<td>Defines how to control actuators and other devices in Internet of Things.</td>
</tr>
<tr>
<td>XEP-0326</td>
<td>This specification. Defines how to handle architectures containing concentrators or servers handling multiple sensors.</td>
</tr>
<tr>
<td>XEP-0331</td>
<td>Defines extensions for how color parameters can be handled, based on &xep0004;</td>
</tr>
<tr>
<td>XEP-0336</td>
<td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
</tr>
</table>
<section2topic='Relations to other extensions'>
<p>
Even though there are technologies available in forms of XEPs that solve parts of the above mentioned problem, they do not provide sufficient support. The following paragraphs will
take the time to list why different technologies are not applicable.
</p>
<section3topic='XEP-0060'>
<p>
This XEP defines tree structures for nodes in different data sources. &xep0060; defines a model where a tree structure of nodes is published and users can browse this
tree structure. Furthermore, it allows the possibility to publish items on these nodes as well as syndication of this information.
</p>
<p>
This XEP also defines data sources (in a tree structure). These data sources contain nodes. &xep0248; defines a structure called a node collection, a structure that
allows the creation of collections containing loosely coupled nodes.
The structures defined in this specification do not include items to publish for each node.
</li>
<li>
We want to be able to use XEP-0060 in parallel to this specification, for the purpose of publishing sensor data.
More information about this is found in <linkurl='xep-0000-IoT-PubSub.html'>xep-0000-IoT-PubSub.html</link>.
</li>
<li>
For massive systems (hundreds of thousands, or millions, of nodes behind a concentrator, its vitally important to be able to manage sets of nodes directly
(for example: Edit multiple nodes at once). Many of the operations in XEP-0060 only allow for operations of singular nodes. Furthermore, many simple operations
require multiple messages per node. This document defines way to operate of sets of nodes simultaneously, as well as ways to perform operations with a smaller
number of operations.
</li>
<li>
In this document, nodes have specific functions, controlled by a specific Node Type. Different Node Types have different parameter sets, different options, commands,
capabilities, etc. XEP-0060 does not differ between node types. There, nodes are only a structural way to sort data into a tree graph.
</li>
<li>
In this document, nodes have real-time status, like errors, warnings, etc.
XEP-0248 defines the concept of node collections and syndication of information from nodes in these collections. But XEP-0248 is not used in this specification.
We want to be able to use XEP-0248 in parallel to this specification, for the purpose of publishing sensor data.
More information about this is found in <linkurl='xep-0000-IoT-PubSub.html'>xep-0000-IoT-PubSub.html</link>.
</li>
<li>
Node IDs are not necessarily unique by themselves in the system. This document defines a uniqueness concept based on a triple of data: (Data Source ID, Cache Type, Node ID). This
means that Nodes must have IDs unique within a given Cache Type, within a given data source.
</li>
<li>
We need to expand on types of events generated from a data source, to make them adhere to the particulars of nodes as defined in this specification.
</li>
<li>
Data sources own their nodes. XEP-0248 define a loosely coupled structure with references to nodes. In this document, a data source is the owner of all nodes
&xep0050; defines how ad-hoc commands can be implemented and how clients can use such commands to interact with underlying logic. But XEP-0050 is not used in this specification.
We want to be able to use XEP-0050 for other types of commands, than commands defined in this specification. Generally, XEP-0050 is used to implement
system-wide commands.
</li>
<li>
Commands defined in this specification are context sensitive, i.e. they depend on the type of node and the context of the node on which the act.
</li>
<li>
It is a requirement to be able to execute commands on sets of nodes directly.
</li>
<li>
Since commands have to be context sensitive, a large concentrator system may have hundreds or thousands of different commands, making it impossible to create
context sensitive GUI's using XEP-0050.
</li>
<li>
Dialog types used for Ad-Hoc-commands are not sufficient. First, dynamic dialogs are required in the general case.
(<linkurl='http://xmpp.org/extensions/xep-0336.html'>XEP-0326</link> define how to create dynamic forms.) Furthermore, the
wizard style type of dialogs used for more complex dialogs in ad-hoc commands, are difficult to automate.
<p>The following table lists common terms and corresponding descriptions.</p>
<dl>
<di>
<dt>Actuator</dt>
<dd>Device containing at least one configurable property or output that can and should be controlled by some other entity or device.</dd>
</di>
<di>
<dt>Computed Value</dt>
<dd>A value that is computed instead of measured.</dd>
</di>
<di>
<dt>Concentrator</dt>
<dd>Device managing a set of devices which it publishes on the XMPP network.</dd>
</di>
<di>
<dt>Data Source</dt>
<dd>
A Data source contains a collection of nodes. Three types of data sources exist: Singular, Flat and Tree. Singular data sources only include one object.
Flat data sources contain a list of objects and Tree data sources contain nodes formed as a tree graph with one root element.
</dd>
</di>
<di>
<dt>Field</dt>
<dd>
One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc.
Fields should be unique within the triple (Node ID, Field Name, Timestamp).
</dd>
</di>
<di>
<dt>Field Name</dt>
<dd>Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.</dd>
</di>
<di>
<dt>Field Type</dt>
<dd>What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.</dd>
</di>
<di>
<dt>Historical Value</dt>
<dd>A value stored in memory from a previous timestamp.</dd>
</di>
<di>
<dt>Identification Value</dt>
<dd>A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)</dd>
</di>
<di>
<dt>Localization information</dt>
<dd>Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.</dd>
</di>
<di>
<dt>Meter</dt>
<dd>A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.</dd>
</di>
<di>
<dt>Momentary Value</dt>
<dd>A momentary value represents a value measured at the time of the read-out.</dd>
</di>
<di>
<dt>Node</dt>
<dd>
Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships)
are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
Each Node has a Node ID. Nodes belong to a data source, and all nodes have a Node Type. Some nodes have a parent node, and some nodes have child nodes. Nodes with the same
parent nodes a called sibling nodes.
</dd>
</di>
<di>
<dt>Node ID</dt>
<dd>
An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
ID scheme.
</dd>
</di>
<di>
<dt>Node Type</dt>
<dd>Each node has a Node Type. The Node Type defines the functionality of the node in the system.</dd>
</di>
<di>
<dt>Parameter</dt>
<dd>
Readable and/or writable property on a node/device. The XEP-0326 &xep0326; deals with reading and writing parameters
on nodes/devices. Fields are not parameters, and parameters are not fields.
</dd>
</di>
<di>
<dt>Peak Value</dt>
<dd>A maximum or minimum value during a given period.</dd>
</di>
<di>
<dt>Precision</dt>
<dd>
In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision
determines, for example, the number of decimals of precision, or power of precision. Example: 123.200 MWh contains 3 decimals of precision. All entities parsing and
delivering field information in sensor networks should always retain the number of decimals in a message.
</dd>
</di>
<di>
<dt>Sensor</dt>
<dd>
Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc.
Sensor values are reported as fields during read-out. Each sensor has a unique Node ID.
</dd>
</di>
<di>
<dt>SN</dt>
<dd>Sensor Network. A network consisting, but not limited to sensors, where transport and use of sensor data is of primary concern. A sensor network may contain actuators, network applications, monitors, services, etc.</dd>
</di>
<di>
<dt>Status Value</dt>
<dd>A value displaying status information about something.</dd>
</di>
<di>
<dt>Timestamp</dt>
<dd>Timestamp of value, when the value was sampled or recorded.</dd>
</di>
<di>
<dt>Token</dt>
<dd>
A client, device or user can get a token from a provisioning server. These tokens can be included in requests to other entities in the network, so these entities can validate
access rights with the provisioning server.
</dd>
</di>
<di>
<dt>Unit</dt>
<dd>Physical unit of value. Example: MWh, l/s, etc.</dd>
</di>
<di>
<dt>Value</dt>
<dd>A field value.</dd>
</di>
<di>
<dt>Value Status</dt>
<dd>Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.</dd>
</di>
<di>
<dt>Value Type</dt>
<dd>Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.</dd>
</di>
<di>
<dt>WSN</dt>
<dd>Wireless Sensor Network, a sensor network including wireless devices.</dd>
</di>
<di>
<dt>XMPP Client</dt>
<dd>Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.</dd>
</di>
</dl>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<p>
To create a complete set of operations supported by all types of concentrators, ranging from PLCs to subsystems to entire systems is very difficult. So, the aim
of this document is instead to create a very small reduced set of operations, a common denominator, that would allow for basic maintenance and interoperability of
concentrators of different makes and models and of these varying ranges.
</p>
<section2topic='Capabilities'>
<section3topic='Get Capabilities'>
<p>
This document lists a sequence of commands. Some are very basic, while others are used for managing massive amounts of devices. When developing a small PLC, it might
be difficult to motivate the implementation of the more advanced commands. They are simply not necessary for the management of the device. So, clients connecting to
the concentrator need a way to learn what operations are available in the concentrator, and as a consequence what operations are not. To do this, the
<strong>getCapabilities</strong> command is sent, as is shown in the following example.
So, clients who need to interact with different types of concentrators need to be aware of what commands are supported, and limit operations to those commands.
</p>
</section3>
</section2>
<section2topic='Data Sources'>
<section3topic='Get All Data Sources'>
<p>
This command will return a flat list of all available data sources on the concentrator. It is not structured hierarchically.
If the client is interested in the hierarchical structure of available data sources, it should request only the root sources, and then ask the client for their
corresponding child data sources. If the client wants to present the data sources to a user, presenting them in their hierarchical order may be more intuitive.
Multiple subscriptions to the same source will not result in an error, however the server will still only send one event message for each event in the data source.
</p>
<p>
<strong>Important:</strong> Event subscriptions only last for as long as the client and concentrator both maintain presence. The concentrator must not persist
event notification subscriptions, and if it goes offline and back online, or if the client goes offline or online again for any reason, the event subscription
is removed.
</p>
<p>
<strong>Note:</strong> The <strong>parameters</strong> and <strong>messages</strong> attributes can be used to retrieve parameter and status message information
about the nodes in event messages sent from the concentrator. Note that the <strong>xml:lang</strong> may be used to select the language used in such events,
if the concentrator supports localization of strings.
</p>
<examplecaption='Subscribing to data source events with localized parameters'>
The <strong>subscribe</strong> command has a set of optional attributes, one for each event type available, and with the same names (<strong>nodeAdded</strong>,
<strong>nodeUpdated</strong>, <strong>nodeStatusChanged</strong>, <strong>nodeRemoved</strong>, <strong>nodeMovedUp</strong> and <strong>nodeMovedDown</strong>), that the
client can use to subscribe to individual events, but not to others. They have the default value of true implying that if not provided, the
default action is to subscribe to those events. The attributes <strong>parameters</strong> and <strong>messages</strong> can also be used to specify
if node parameters and node messages respectively should be available in event messages. The default value for the these later attributes is false, implying
that normal events do not include node parameter and node message information.
</p>
<p>
The following example shows how a client can subscribe to a set of events only:
</p>
<examplecaption='Subscribing to data source events, avoiding state events'>
For more information on types of events sent, see the <linkurl='#sourceevents'>Data Source Events</link> section.
</p>
</section3>
<section3topic='Unsubscribe from data source events'>
<p>
A client can unsubscribe to changes made in a data source it is subscribed to. It does this by sending the <strong>unsubscribe</strong> command to the concentrator,
as is shown in the following example:
</p>
<examplecaption='Unsubscribing from data source events'>
... Sequence of event messages sent from concentrator to client.]]>
</example>
<p>
<strong>Important:</strong> Event subscriptions only last for as long as the client and concentrator both maintain presence. The concentrator must not persist
event notification subscriptions, and if it goes offline and back online, or if the client goes offline or online again for any reason, the event subscription
is removed.
</p>
<p>
<strong>Note:</strong> The <strong>parameters</strong> and <strong>messages</strong> attributes can be used to retrieve parameter and status message information
about the nodes in event messages sent from the concentrator.
</p>
<p>
For more information on types of events sent, see the <linkurl='#sourceevents'>Data Source Events</link> section.
</p>
</section3>
<section3topic='Get changes since given timestamp before subscribing, Failure'>
<p>
If during a subscription request the concentrator is not able to fulfill the request of retrieving previous events using the <strong>getEventsSince</strong> attribute,
perhaps the attribute stretches too far back, or includes too many records, the concentrator can return an error message using a response code of <strong>NotImplemented</strong>.
In this case, the subscription must not be made.
</p>
<p>
When receiving such an error from the concentrator, the client must make a decision if it should download the data source again, or keep the data source as is, and
subscribing again without the <strong>getEventsSince</strong> attribute.
</p>
<examplecaption='Get changes since given timestamp before subscribing, Failure'>
