## 3 M2M Information and Services
### Sensor Web Enablement
#### Scenario 2--Sensors with Embedded IP Stack  
**2.1** A sensor registers itself to an SOS server by invoking the RegisterSensor operation. The request includes a SensorML document that describes the sensor capabilities. In this scenario the sensor system includes an embedded IP stack that allows it to communicate directly with the SOS server over the Internet.  
**2.2** The sensor sends streaming observation data to the SOS by invoking its InsertObservation operation. The data is encoded in O&M format and it is persisted on the SOS backend.  
**2.3** A SWE client invokes the GetCapabilities operation of the SOS. This operation allows clients to retrieve service metadata about a specific service instance.  
**2.4** SOS responds with the response with an XML encoded document. This document provides clients with service Filter Capabilities which indicate what types of query parameters are supported by the service and Contents Section in the form of Observation Offerings. These are sets of sensor observation groupings that can be queried using the GetObservation operation. Note that the response will not only include metadata that describe observations collected from the sensor mentioned in this scenario but also the observations received from the sensor nodes in the previous scenario.  
**2.5** Based on the information gained in the previous steps the client requests sensor observations by invoking the GetObservation operation. The request parameters are based on the Filter Capabilities information received in the previous GetCapabilities request. This may be a one-off operation or the client may poll the SOS periodically.  
**2.6** The response to a GetObservation request is an O&M Observation, an element in the Observation substitution group, or an ObservationCollection. These are historical sensor observations retrieved from the SOS backend.  
The SWE Common and O&M which are data models for exchanging heterogeneous sensor data at low and higher levels respectively allow applications and/or servers to structure, encode and transmit data in a self-describing and semantically enabled way. O&M, which is based on [PERSON]'s Observation & Measurements analysis pattern [71], is a dynamic model that can adapt smoothly to new requirements without necessarily needing to change implementation or the way objects interact. It is therefore, a particularly interesting solution for the description of device data across different business domains.  
One of the key requirements of M2M systems is the ability to fuse, interpret or transform device data into higher level information, required by various M2M applications. A mechanism that enables such on-demand processing, using generic software that utilizes standard process descriptors, simplifies M2M application development and facilitates interoperability. The view-point of the sensor as a process or a chain of processes in the SensorML model with detailed process input, output, parameter, and method descriptions makes it a possible candidate for such a generic process descriptor.  
The ongoing work on SensorML 2.0 is planning additional functionalities such as the Sensor Interface Descriptor (SID) extension. SID enables the precise description of a sensor's protocol and interface. This work may be used as a basis to develop generic device drivers carrying protocol definitions of legacy devices which in turn would allow on-the-fly, plug-and-play integration of such non-compliant devices into the standard M2M service network without the need for manual ad-hoc development for each device type [3].