## 2 The Ubiquitous Sensor Network Platform
### The USN-Enabler  
Integrated in the middleware element of the USN is the USN-Enabler. The mission of the USN-Enabler, the main component of the USN-Platform, is to manage the infrastructures and assist IoT applications by providing a set of OGC-SWE services which facilitate the integration of smart devices with the Sensor Web. This allows the implementation of sensor discovery, access and data publication services with enhanced properties. Figure 3 shows an example of Sensor Web Infrastructure using some of the services proposed by the OGC-SWE. In the OGC model applications do not interact directly with the data producers. Instead they rely on OGC services (two are shown in the example in Figure 3: the Sensor Observation Service (SOS) and the Sensor Event Service (SES)). Data producers must first register to these services in order to be discoverable by smart devices and applications. Since multiple instances of these services can co-exist, applications must first look up which of them is the most suitable provider of the desired information in its current context of use. This sensor information discovery is done through OGC Catalogues [21], as shown in Figure 3 (the CS-W: Catalogue Service). The OGC Catalogue is an optional component in the SWE architecture, but it is the only standard mechanism that allows clients to discover adequate service providers for the data they are interested in. Once the appropriate source is found, applications can access specific sensor information by querying the service. Two interaction mechanisms are available to access sensor information: a pull-based system, in which applications query the information when needed; and a push-based mode, in which applications subscribe to alerts to be notified when certain conditions or situations occur. For the first type of interaction the OGC-SWE defines the Sensor Observation Service (SOS) [22], while for the second it offers a Sensor Event Service (SES) [23]. The SES interface follows a publish/subscribe model where a sensor can send (advertise) a current observation value as an alert (for example, the number of vehicles per hour at a road intersection). A consumer application can subscribe to receive custom alerts when the sensed data meets set criteria (e.g., a measurement above a threshold, or occurring in a location area or a time interval). Figure 3: Sensor Web Infrastructure example with services defined by the OGC-SWE. SWE specifications rely on two main information models to describe the sensor systems and their related observations or sensed measurements: SensorML and Observations & Measurements (O&M), respectively. SensorML allows the definition of different types of sensors and sensor systems: simple sensors nodes, processors (components that process data to derive new information), complex sensor systems (e.g., earth observation satellites), _etc_. The O&M language defines a domain-independent conceptual model for the representation of sensed spatiotemporal data. Both standards offer syntactic uniformity for sensor and data representation respectively. However, the same item (e.g., a sensor) can be represented in different ways using these standards, which poses a challenge to achieve interoperability. Beyond the functionality specified by the OGC-SWE, the underlying NGN architecture makes it possible to enhance these services, as provided by the USN-Platform, as follows:  
* Simpler interactions for information providers: If an information provider wishes to offer data through more than one OGC service (e.g., SOS and SES, for storage and event management functions) it needs to register and publish the same information several times, using different protocols. This is inefficient and unreliable (race conditions and information inconsistencies may occur, among other undesirable effects). In the USN-Platform information is published and registered only once, using the SOS functions, and then made available to the other OGC services.