## 2 Background
### Overview of CoAP and Its Limitation  
The IETF CoRE WG [2] has designed CoAP for resource oriented applications intended to run on constrained IP networks. These networks and the nodes within them have severe limits on throughput, available power, and in particular, the amount of complexity that can be supported with a limited code size and limited RAM size per node [2]. For example, sensor nodes often have 8-bit microcontrollers with small amounts of ROM and RAM; while constrained networks, such as 6 LoWPAN often have high packet error rates (5%-10% is common) and a typical throughput of 10 kbit/s.  
CoAP, based on an asynchronous request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key Web concepts, such as Uniform Resource Identifiers (URIs) and Internet media types [2]. The server and client correspond to sensing nodes and Web clients, respectively. The resource information of the server such as the URI and IP address, is published at the Web Application Description Language (WADL) server [20]. The client can retrieve and access the measured data of the sensor node by referring to the resource information on the WADL server.  
Figure 1 shows CoAP architecture, which consists of two layers: message and request/response. The function of the CoAP message layer is to control message exchanges over UDP between two endpoints. There are four message types: _confirmable_ (CON), _non-confirmable_ (NON), _acknowledgement_ (ACK), and _reset_ (RST).  
At the request/response layer, CoAP request and response semantics are carried in a message, and include either a method code or a response code. The message also carries optional information, such as the URI and type of payload content. CoAP can match the requests and responses using a message ID, and a token option differentiates concurrent requests. The characteristics of CoAP are summarized below.  
Figure 1: CoAP architecture.  
* **Compact header**: CoAP includes a compact binary header with extensible options. The protocol has a base header size of only 4 bytes, and a total header of 10-20 bytes for a typical request.
* **Methods and URIs**: For a client to access server resources, CoAP supports the GET, PUT, POST, and DELETE request methods. These methods are answered using a subset of HTTP-compatible response codes. CoAP supports URIs, which are a key feature of the Web architecture.
* **Simple caching**: Caching for resource representations is supported to optimize performance in constrained network environment.
* **Asynchronous message exchanges:** The messages that are exchanged between the client and the server are operated asynchronously.  
These CoAP functional characteristics are implemented under the assumption that the IP address of the constrained sensing node is fixed. As the IP address of the server node may change because of node movement, the client may not find the location of the corresponding server node. As a result, the client may not retrieve the time-critical data from the server. To ensure timely data availability in a WoT environment, a simple and efficient mobility management function should be provided to handle server mobility.