## 2 Integration of Constrained Devices into the Internet  
In the absence of widely accepted standard protocols for resource-constrained devices, out-of-necessity many vendors developed proprietary protocols to run inside their sensor networks. Connectivity between the Internet and the sensor networks was achieved through the use of vendor-specific gateways or proxies. These gateways have to translate between protocols used in the Internet and proprietary protocols used in the sensor networks. Figure 1 displays two different sensor networks that are connected to the Internet by gateways. Users on the Internet have to connect to the gateways in order to obtain data from the corresponding sensor network. There are several ways how a gateway can handle such user requests. For example, the gateway from vendor 1 translates standard Internet protocols into proprietary sensor protocols and relays the requests to the sensors in its network. The gateway then receives the answers from the relevant sensors by means of the proprietary sensor protocols and sends back the appropriate reply to the user using standard Internet protocols. The gateway offers an API that applications should use in order to create requests that can be understood by the gateway. This approach has the benefit that direct (real-time) interaction with sensor nodes is possible, but only by using a vendor-specific interface. Alternatively, the gateway of vendor 2 contains a database with pre-collected sensor data. When it gets a request from a user on the Internet, it replies directly to the requester using the data in the database. In some cases, the gateway is simply running a web server that makes the data available to the outside world. In this case, existing database technologies can be reused, but the user does not know whether the returned data is coming in real-time from the sensors or whether it is coming from a value that has been previously stored in a database. The use of standardized solutions is mostly limited to the use of a standard for the physical layer and MAC layer, although tailored MAC protocols could be used as well. It is clear that such an approach hinders the integration of sensors into the Internet. Little flexibility is offered since users can query the sensors only in the way that is allowed by the gateway. Another disadvantage is the vendor lock-in: gateways and sensors often have to be from the same vendor in order to be compatible. In addition, creating and maintaining the gateway requires significant development effort: often even adding new sensor resources requires making (administrative) changes to the gateway. Finally, due to the lack of real end-to-end connectivity, no real-time interaction with the resource-constrained devices is supported. These limitations in combination with the general understanding that constrained devices will take up a prominent role in the future Internet, raised the need for standardized, open solutions for network communication with constrained devices. To ensure wide adoption, these new solutions have to be interoperable with the most widely used protocols in the Internet, initially IP and, in a later stage, HTTP. To address these needs, the IETF--responsible for the development of high-quality Internet standards--has formed several working groups: _IPv6 over Low Power WPAN_ (6 LoWPAN) [6], _Routing Over Low Power and Lossy Networks_ (ROLL) [3] and _Constrained Restful Environments_ (CORE) [7]. The 6 LoWPAN group tackles the transmission of IPv6 packets over IEEE 802.15.4 networks, the ROLL group develops IPv6 routing solutions for Low Power and Lossy Networks (LLNs) and the CoRE group aims at providing a framework for resource-oriented applications intended to run on constrained IP networks. Together, these protocols allow the IP-based integration of constrained devices into the Internet in a standardized way, as shown in Figure 2. Due to the popularity of IEEE 802.15.4, this standard is used at the physical layer and the medium access control layer.