SensiNact/Getting Started

Core concepts

The sensiNact Gateway allows interconnection of different networks to achieve access and communication with embedded devices. It is composed of six functional groups and their relative interfaces:

• The Device Protocol Adapter abstracts the specific connectivity technology of wireless sensor networks. It is composed of the bridges associated to protocol stacks. All the bridges comply with a generic Device Access API used to interact with northbound sensiNact’s services.
• The Smart Object Access and Control implements the core functionalities of sensiNact like discovering devices and resources and, securing communication among devices and consumers of their services.
• The Consumer API is protocol agnostic and exposes services of the Smart Object Access and Control functional to Consumers.
• The Consumer Protocol Adapter consists of a set of protocol bridges, translating the Consumer API interface into specific application protocols.
• The Platform Management functional group includes all the components needed to ease management of devices connected to sensiNact, regardless of their underlying technologies. A Device Management API is used for this purpose. This functional group also contains the components managing cache, resource directory and security services. These management features are exposed by means of the Platform Management API.
• And finally the Manager Protocol Adapter allows adapting the Platform Management API to the specific protocols used by different external management entities.

In terms of connectivity (cf. Figure 3), on the southbound side the sensiNact Gateway allows to cope both with “physical device” protocols and “virtual device” ones, allowing a uniform and transparent access to an XBee network, or an HTTP Restful web service for example. Here's pell-mell a non-exhaustive list of supported protocols:

• EnOcean, concerting energy harvesting wireless sensor technology (ultra-low-power radio technology for free wireless sensors), and protocols in use to interact with those sensors;
• Bluetooth Low Energy, which is a personal area network, low power protocol designed mainly for healthcare or entertainment type of applications;
• MQTT, which is a machine-to-machine protocol, lightweight publish/subscribe messaging transport, useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium;
• ZigBee based protocols (XBee for example);
• CoAP, which is a REST application protocol, designed to be “the HTTP for constrained networks and devices” whose concept originated from the idea that "the Internet Protocol could and should be applied even to the smallest devices," and that low-power devices with limited processing capabilities should be able to participate in the Internet of Things; it is usually used on top of a 6LoWPAN network, but it may travel regular IP networks as well (it is used by the OMA LWM2M protocol, for instance).

On the northbound side the sensiNact Gateway provides both client/server and publish/subscribe access protocols:

• MQTT;
• JSON-RPC (1.0 and 2.0);
• HTTP RESTful;
• CDMI.

[[Image:./images/architecture/gateway_protocol_2.svg|frame|none|alt=sensiNact Paltform architecture|caption sensiNact Paltform architecture]]

The Smart Object Access and Control functional group described above in this section includes a large number of functionalities:

• It handles the communication with the Consumer Protocol Adapter (REST API, JSON RPC, etc.) and IoT (and non-IoT) devices, providing URI mapping, incoming data/messages translation in an internal format and outgoing data/messages translation in Consumer format. Whenever a Consumer tries to access a resource via Consumer API, the requested URI is forwarded to the Resource Manager in order to check if a specific resource descriptor exists or not inside the Resource Directory and to verify its accessibility status. If a resource descriptor doesn’t exist, a message response with error code is returned to the Consumer API. Otherwise, the request is forwarded to the right interface. At the same time whenever response is originated from IoT device (or abstract IoT device), it will be also forwarded to its logical counterpart in order to update the resource representation in the platform.
• It manages the subscription/notification phases towards the Consumer, if it is not handled by the targeted device (service) itself
• It supports Devices and Resource Discovery and Resource Management capabilities, to keep track of IoT Resource descriptions that reflect those resources that are reachable via the platform. These can be both IoT Resources, or resources hosted by legacy devices that are exposed as abstracted IoT Resources. Moreover, resources can be hosted on the platform itself. The Resource Management functionality enables to publish resources in sensiNact, and also for the Consumer to discover what resources are actually available from the platform; sensiNact Service and Resource model allows exposing the resources provided by an individual service. The latter, characterized by a service identifier, represents a concrete physical device or a logical entity not directly bound to any device. Each service exposes resources and could use resources provided by other services. Figure 4 depicts the Service and Resource model.

[[Image:./images/architecture/data_model.svg|frame|none|alt=Generic data model|caption Generic data model]]

The Resource Directory allows storing information, i.e. resource descriptions, about the resources provided by individual devices connected to sensiNact. It also supports looking up resource descriptions, as well as publishing, updating and removing resource descriptions to it.

Discovering and using resources exposed by Services is a favored approach for avoiding using static service interfaces and then increase interoperability. Therefore, sensiNact Services and their exposed resources are registered into Service/Resource repositories. The platform uses the OSGi service registry as Service/Resource repository, where resources are registered as service properties. Clients ask the Service/Resource repository for resources fulfilling a set of specified properties (defined by LDAP filters). In response, the Service/Resource repository sends clients the list of service references that expose the requested and authorized resources. Clients can then access/manipulate the resources exposed by their selected service objects (cf. Figure 5).

Figure 5: Service Oriented Architecture (MacKenzie, 2006). When a service provider starts, it registers/publishes itself into the service broker. When a consumer appears, it looks for the reference to the service provider into the service broker. With this reference, the consumer can interact directly with the provider.

Resources and services can be exposed for remote discovery and access using different communication protocols, such as HTTP REST, JSON-RPC, etc., and advanced features may also be supported (as semantic-based lookup). Resources can be classified as shown in Table , while the access methods are described in Table 2: Resource's access method.

Type	Description
Sensor Data	Sensory data provided by a service. This is real-time information provided, for example, by the SmartObject that measures physical quantities.
Action	Functionality provided by a service. This is mostly an actuation on the physical environment via an actuator SmartObject supporting this functionality (turn on light, open door, etc.) but can also be a request to do a virtual action (play a multimedia on a TV, make a parking space reservation, etc.).
Property	Information representing a SmartObject state variable of the service. This variable is most likely to be modified by an action (turn on light modifies the light state, opening door changes the door state, etc.) but also to intrinsic conditions associated to the working procedure of the service.
State Variable	Property exposed by a service. This is information which is likely to be static (owner, model, vendor, static location, etc.). In some cases, this property can be allowed to be modified.

Table 1: Resources types and description

Type	Description
GET	Get the value attribute of the resource.
SET	Sets a given new value as the data value of the resource.
ACT	Invokes the resource (method execution) with a set of defined parameters.
SUBSCRIBE	Subscribes to the resource with optional condition and periodicity.
UNSUBSCRIBE	Remove an existing subscription.

Table 2: Resource's access method

The access methods that can be associated to a resource depend on the resource type, for example, a GET method can only be associated to resources of type Property, StateVariable and SensorData. A SET method can only be associated to StateVariable and modifiable Property resources. An ACT method can only be associated to an Action resources. SUBSCRIBE and UNSUBSCRIBE methods can be associated to any resources.