## 5 Test-Bed  
As previously mentioned, in this paper we compare and discuss the performance obtained in a real 6 LoWPAN network by TinyCoAP, CoapBlip and HTTP. Our experiments involve different solutions for the transport layer used by HTTP. We consider HTTP/TCP, HTTP/UDP and HTTP persistent. The third solution refers to the use of a persistent TCP connection. The HTTP and TCP protocols that we use to implement the server are included in Blip. The HTTP version it implements is the 1.0. The TCP version used by the client is one the most widely adopted, which is the TCP Reno. The congestion window size (CWND) of client and server is fixed to 1. A larger CWND could overload the wireless link with too many transmissions, and thereby increasing the probability of collision. The need to have more than one TCP packet pending in the network could be justified in a multi-hop scenario. In a one-hop network there is not such a need, and client and server would avoid competing for the radio channel. The MSS of both sides always corresponds to the length of the TCP payload sent in each experiment. Thus, each HTTP single packet is sent in one TCP segment. This setting allows maximizing the throughput by reducing the interchange of control messages and avoiding fragmentation. \begin{table}
\begin{tabular}{l l} \hline
**CoapBlip** & **TinyCoAP** \\ \hline typedef struct \{ & typedef struct \{ \\ coap\_hdr\_t *hdr; & uint\_t timestamp; \\ unsigned short length; & coap\_hdr\_thdr; \\ coap\_list\_t *options; & struct sockaddr\_in6 addr; \\ unsigned char *data; & uint\_t payload [MAX]; \\ \{} coap\_pdu\_t; & uint\_16\_t payload\_len; \\  & coap\_list\_t opt\_list; \\  & \} coap pdu t; \\ \hline \end{tabular}
\end{table} 
Table 1: CoAP PDU structures. CoapBlip stores the PDU in the UDP buffer and uses a pointer to provide access. TinyCoAP saves it in the memory allocated with PoolC. The tests involve client/server transactions where a client sends requests to a server in order to retrieve information. All the requests are sent using the GET method. When receiving a request with test as URI, the CoAP or HTTP server replies with a payload composed of a sequence of bits of fixed size. In this way, the more performs no sensing operation that might influence the results. Therefore, the experiments account only for the performance of each technique in processing and replying to the received messages. The CoAP CON request messages sent by the client have a total length of 14 bytes. The HTTP GET requests carry the same information of that sent in CoAP. However, the verbose format of HTTP implies a growth in size of up to 37 bytes. Table 2 shows the composition of the GET requests for CoAP and HTTP. All the tests are performed in a real WSN implementation. Crossbow's TelosB motes are used as a hardware platform to develop our test-bed network. TelosB [45] is a typical example of a low-cost wireless sensor used in constrained sensor networks. It features 16-bit RISC MCU at 8 MHz and 16 registers. The platform offers 10 kB of RAM, 48 kB of flash memory and 16 kB of EEPROM. Since our experiments are focused on evaluating single client/server transactions, we can keep our test-bed network simple and avoid deploying complex architectures. The test-bed network used in all the experiments is shown in Figure 5. The CoAP and HTTP clients as well as the proxy server are located in a PC. Each request is sent through a 6 LoWPAN base station attached to the USB port of the PC. The server is embedded in a TelosB mote located one-hop away from the 6 LoWPAN base station. \begin{table}
\begin{tabular}{l c} \hline \hline
**CoAP** & **HTTP** \\ \hline _CoAP HEADER: 5 bytes_ & _GET /test HTTP/1.0\(|\)v\(|\)n_ \\ _COAP URI PATH: 6 bytes_ & _Host: fec0::2\(|\)v\(|\)n\(|\)v\(|\)n_ \\ _COAP TOKEN: 3 bytes_ & \\ _PAYLOAD: 0 bytes_ & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Composition of the HTTP and CoAP Confirmable (CON) requests. In both cases the requests are sent using the GET method. Figure 5: Test-bed network.