## 1 Introduction  
The Internet of Things (IoT) enables real world objects to be integrated into a virtual world, where sensors, actuators, and other devices interact not only with human users, but also with each other and software agents on the Internet. One approach for making IoT data available to users is the use of Web service technologies, which can directly integrate IoT data and Web functionalities through the Internet. This integration of Web services with IoT has been defined as the Web of Things (WoT) [1]. Furthermore, sensors in IoT environment have been miniaturized, integrating various communication functions, such as Bluetooth, ZigBee, Low-power WiFi, and GPS. The Internet Engineering Task Force (IETF) has undertaken much standardization work related to WoT. For example, the IETF Constrained RESTful Environments (CoRE) Working Group (WG) has been creating standardizations for introducing the Web service paradigm into networks of smart objects. The CoRE WG has defined a REST-based Web transfer protocol, the Constrained Application Protocol (CoAP) [2]. CoAP can make it easy to integrate physical devices with contents on the Web, while satisfying requirements, such as multicast support, low signaling overhead, and simplicity for constrained network environments. The devices in a constrained network environment generally tend to be embedded, and to require considerably less CPU processing, memory, and power supply capabilities than Internet devices. More specifically, the constrained node often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6 LoWPANs) often have high packet error rates and a typical throughput of 10 s of kbit/s. Therefore, the requirements of multicast support, low signaling overhead, and simplicity are extremely important in a WoT environment. In addition, the constrained networks in a WoT environment usually have a limitation in packet size, may exhibit a high degree of packet loss, and may have a substantial number of devices in sleep mode operation [2]. In a duty-cycled network, sensor nodes perform four distinct operational states: transmit, receive, idle, and sleep. In sleep states, the sensor is shut down and a low-power timer is on to wake up the sensor at a later time [3]. Therefore, it can consume only a tiny fraction of the energy consumed in the active mode. The interaction model of CoAP is similar to the client/server model of HTTP. However, unlike HTTP, the end-points of the CoAP may act as both clients and servers [2,4]. The architecture of CoAP is divided into two layers: message and request/response. CoAP supports reliable message transmissions by using stop-and-wait retransmissions with an exponential back-off mechanism to correct the order of packets and check duplicates [1]. CoAP can benefit various IoT applications, such as ubiquitous healthcare services, V2I/V2V automatic vehicle networks, home networks, automotive networks, automatic systems, industrial networks, interactive toys, and remote meters. One limitation of CoAP is that it does not directly address the mobility requirements for mobile constrained nodes in WoT environments. CoAP has been designed for Machine to Machine (M2M) applications, such as smart energy and building automation [5]. In previous WoT applications, WoTresearchers assumed that most sensor nodes do not have movement. Therefore, the sensor mobility has not been considered in a WoT network environment. A sensor node, however, can have mobility. For example, in a vehicle monitoring system, the vehicle can move into different IP domains. In the ubiquitous network, the characteristics of the wireless network or sensor movement can change the wireless connection between the sensor and wireless access router. In WoT environment, the sensor provides the sensing resource and acts as Web server.