A Service Model for 6LoWPAN Wireless Sensor Networks

This paper proposes a 6LoWPAN service model based on the IPv6-based k-Anycast communication model. This model is extended into 6LoWPAN service model so that the data-centric services of WSN can be achieved efficiently in the address-centric 6LoWPAN. In the proposed service model, an IPv6 node can obtain multiple network services through one request-response interaction where multiple sensor nodes cooperate to complete all requested network services and they provide their respective network services at the same time. As a result, the delay time is shortened. In addition, the proposed service model avoids the service failure caused by dormant sensor nodes. Since users can only request the network services they are interested in, the redundant data transmission is avoided. The performance parameters of the proposed service model are analyzed, and the data results show that the performance of the proposed service model is better.


Introduction
With the rapid development of the IPv6 Internet and the extensive application of wireless sensor networks (WSN), all-IP communication between WSN and the IPv6 Internet has become an inevitable future trend [1][2][3]. In this situation, IETF proposes 6LoWPAN [1] where each sensor node has a unique IPv6 address.
The IPv6 network adopts the address-centric working mechanism, while WSN utilizes the data-centric working mechanism. Therefore, achieving the data-centric network services in the address-centric 6LoWPAN gives rise to some issues, such as work inefficiency. For example, in general, a sensor node only collects a particular type of data (e.g., temperature). When an IPv6 node requests several types of data (e.g., temperature, humidity, luminous intensity, etc.) collected by several sensor nodes at the same time, in a traditional way it has to repeatedly send the service-request packet to obtain the required data. Therefore, the traditional service model not only increases service response time but also reduces the network service performance. Hence, the issue of how to integrate the data-centric mechanism and the address-centric mechanism to increase network service performance in 6LoWPAN needs urgently a solution.

Related Work
References [4][5][6] proposed a discovery scheme of WSN network service based on the directory proxy agent (DPA). In the scheme, a sensor node registered the network services provided by it with the DPA in the local region. If a user wanted to acquire network services, then the user had to search the DPA in the local region for the information on the sensor nodes which could provide the required network services and then communicated with the sensor nodes in a unicast way to acquire the required network services. However, a DPA in the scheme needed to maintain a great deal of registration information on sensor nodes and to communicate frequently with the sensor nodes in order to ensure the accuracy and correctness of the registration information, which consumed a lot of storage and computing resources. If a DPA failed, then the network services in the corresponding local region would fall into collapse. In addition, the scheme was built on the data-centric working mechanism and did not take into account the integration of the address-centric working mechanism and the data-centric working mechanism.
Reference [7] proposed a location-based service discovery scheme for WSN based on the WSN point-to-point routing scheme [8]. Since the routing scheme [8] was not based on IPv6 address, it was not suitable for 6LoWPAN service model. In [9,10], network service types were embedded into IPv6 addresses in order to quickly achieve network service discovery and inquiry, but one IPv6 address including network service types could not be compressed. In addition, network service types being embedded in IPv6 addresses are not in line with IPv6 layer design principles.
Reference [11] adopted the 6LoWPAN network architecture [3] to achieve WSN service, but the experimental data showed that network services achieved through the traditional Internet network service model consumed a lot of power and their performance was neither good nor efficient. Reference [12] proposed three kinds of service discovery mechanisms: YouCatchMe, ICatchYou, and Some1CatchMe and analyzed their energy consumption, and the performance of Some1CatchMe was the best. However, Some1CatchMe was based on RFID tags so its application was limited.
Reference [13] proposed a service discovery scheme where the electronic number mapping was employed to perform the service discovery in 6LoWPAN. In the scheme, a sensor node was associated with a master node which was assigned a unique E.164 number. The gateway of the network performed the task of converting attribute-value pair-based human readable queries into E.164 numbers so that services destined for sensor nodes first reached the master node with which they were associated by using the E.164 number of the master node. In the scheme, translating attribute-value pairbased human readable queries into E.164 numbers increased the service discovery delay and also made a gateway become a bottleneck. If a gateway or a master node failed, then the corresponding service discovery process also collapsed. In addition, the more the number of service requests was, the worse the performance of the scheme was.
References [14][15][16][17][18][19] introduced the (m) anycast communication model into the data-centric WSN to improve the network service performance. The research results showed that the introduction of the (m) anycast communication model enhanced the cooperation ability of sensor nodes, shortened the delay time of data transmission, and effectively saved network resources. However, the (m) anycast communication models in [14][15][16][17][18][19] were only for the datacentric WSN, and they were implemented based on the datacentric routing mechanism of WSN, so it was difficult to apply the research results into the address-centric 6LoWPAN. Therefore, it needs to introduce an (m) anycast model based on the address-centric mechanism into 6LoWPAN so that the data-centric tasks can be implemented efficiently in 6LoWPAN. For this purpose, we have studied the concept of the -Anycast communication model in ad hoc networks in [20][21][22] and have proposed the IPv6-based -Anycast communication model [23] for the first time. In the model, multiple resource-limited sensor nodes, which are called -Anycast members, can cooperate to complete data-centric tasks. From the perspectives of theory and practice, we have proven that the IPv6-based -Anycast communication model can achieve the data-centric tasks in the address-centric networks efficiently [23].
Therefore, the paper proposes to utilize the IPv6-based -Anycast communication model to achieve the data-centric services in the address-centric 6LoWPAN.

6LoWPAN Service Model
3.1. Network Architecture. 6LoWPAN includes 3 types of nodes: 6LoWPAN ingress node, cluster head, and cluster member. A 6LoWPAN ingress node connects 6LoWPAN to the IPv6 networks. 6LoWPAN is divided into multiple clusters, and each cluster has only one cluster head, as shown in Figure 1. Cluster heads are responsible for routing and forwarding, while cluster members provide 6LoWPAN services.

IPv6-Based -Anycast Communication
Model. The IPv6based -Anycast communication model is between anycast and multicast, and it allows servers to cooperate with each another to accomplish a task. Anycast and multicast are two special examples of -Anycast. If is equivalent to 1, thennycast becomes anycast. If is equivalent to the total number of -Anycast members, then -Anycast becomes multicast.
In the -Anycast model, each -Anycast address represents one kind of -Anycast service which can be divided into multiple -Anycast subservices, and one kind of -Anycast service is performed by one -Anycast group. The definition of a -Anycast group is described as follows. (1) Each -Anycast group is uniquely identified by a one -Anycast address.
(2) Each member of one -Anycast group can provide one -Anycast subservice at least.
(3) All members of one -Anycast group form a tree which is called the -Anycast tree and whose root node is called the -Anycast center node. Multiple members of one -Anycast group can cooperate to perform one -Anycast service.
(4) The unicast address space of the -Anycast center node is the same as the -Anycast address space of the -Anycast group. One packet whose destination address is one -Anycast address can be routed to the -Anycast center node of the -Anycast group identified by the -Anycast address.
In the -Anycast model, one -Anycast address represents one -Anycast service which corresponds to one -Anycast group and one -Anycast tree. The -Anycast address of one -Anycast group is the same as the unicast address of the corresponding -Anycast center node.
In the -Anycast model, the process of an IPv6 node acquiring one -Anycast service is described as follows.
(1) An IPv6 node sends a -Anycast service-request packet whose destination address is the corresponding -Anycast address.
(2) The packet is routed to the -Anycast center node.
(3) The -Anycast center node forwards the -Anycast service-request packet to each -Anycast member.
(4) After one -Anycast member receives the -Anycast service-request packet, it returns its -Anycast subservice response data to the -Anycast center node.
(5) The -Anycast center node deals with all received -Anycast subservice response data, encapsulates the complete -Anycast service response data into one service-response packet, and returns the packet to the IPv6 node.

Extension of IPv6-Based -Anycast Model into 6LoWPAN
Service Model. The paper extends the IPv6-based -Anycast model into the 6LoWPAN service model. In 6LoWPAN, a set of network services are considered as one -Anycast service, one network service is one -Anycast subservice, one cluster is one -Anycast group, the cluster head and cluster members are the -Anycast members of the -Anycast group, the cluster head is the -Anycast center node, the IPv6 address (unicast address) of the cluster head is the -Anycast address of the -Anycast group, and each cluster member can provide one network service at least. In this way, a set of network services can be achieved by one cluster.
In the proposed service model, the type of one -Anycast service is uniquely identified by one fixed port, which is similar to a well-known port in IPv6. For example, in IPv6 the port 80 refers to the web service, and similarly in the proposed service model the port 1200 represents the environmental -Anycast service which provides 4 kinds of environmental -Anycast subservices (network services): temperature network service, humidity network service, carbon dioxide concentration network service, and luminous intensity network service. Due to resource constraint, it is difficult for a sensor node to independently provide a complete -Anycast service. Therefore, a -Anycast service is divided into multiple -Anycast subservices each of which is achieved by one -Anycast member (one cluster member). In this way all cluster members ( -Anycast members) can work together to provide one -Anycast service. The proposed 6LoWPAN service model defines that the type of one -Anycast subservice is identified by an identifier in the application layer which is called sub-service ID. Therefore, the type of one -Anycast subservice is uniquely identified by a port and a subservice ID; for example, the -Anycast sub-service of providing the temperature is identified by port 1200 and sub-service ID 1. Subservice ID is described by one subservice field in the application layer which is -byte long. The value of is a positive integer which is greater than or equivalent to 1 and can be adjusted according to the quantity of the -Anycast subservices. In the subservice field, each bit corresponds to the state of a type of -Anycast subservice which records the state of whether the -Anycast subservice is achieved or not. The bit value 1 (achieved) means that the corresponding -Anycast subservice is achieved, and the bit value 0 (nonachieved) means that the corresponding -Anycast subservice is not achieved. In the service model, the value of is set to 1 that is, one -Anycast service can contain a maximum of 8 -Anycast sub-services (network services).
Through the sub-service field, users can request the only network services which they are interested in.

Generation of One Cluster (One -Anycast Group).
In the initial state, all sensor nodes except 6LoWPAN ingress nodes in WSN are in the isolated state and have one connectivity parameter with the same initial value which defines the threshold connectivity with which one isolated sensor node can be marked as a cluster head. In the service model, one isolated sensor node periodically broadcasts an Adv packet within one-hop communication area.
During the generation of one cluster (one -Anycast group), the following data structures are defined: Adv packet: the packet which an isolated node broadcasts to its neighbor nodes within one-hop scope in order to show its existence; 4 International Journal of Distributed Sensor Networks Join packet: the packet which a cluster head sends to its neighbor isolated nodes within one-hop scope in order to invite the isolated nodes to join the cluster identified by the cluster head; Res packet: the packet which one isolated node returns to one cluster head and which is one response packet to the Join packet sent by the cluster head; Ack packet: the packet which one cluster head returns to one cluster member to confirm that the cluster member joins the cluster identified by the cluster head and which is one response packet to the Res packet sent by the isolated node.
One isolated sensor node becomes a cluster head or a cluster member through the following steps.
(1) One sensor node within one-hop communication area of one isolated node receives one Adv packet sent by . If is marked as a cluster member, then it abandons to process the packet and goes to step (6); otherwise, adds into its neighbor node list. If is an isolated node, then it decreases its connectivity parameter by 1; otherwise if is marked as a cluster head, then it sends a Join packet to and goes to step (3).
(2) If is an isolated node and its connectivity parameter is equivalent to zero, then it sends a Join packet to the isolated nodes in its neighbor node list; otherwise still keeps the isolated state and goes to step (6).
(3) After (or one isolated node in 's neighbor node list) receives the Join packet, if it is in the isolated state and does not return one Res packet to other nodes, then it returns to one Res packet.
(4) If is a cluster head and receives one Res packet returned by , then it adds into its neighbor list and its cluster member list and at the same time sends one Ack packet to . If is an isolated node, then, in the predetermined time, checks if the total number of the isolated nodes returning one Res packet is equivalent to the threshold connectivity. If it is, then marks itself as a cluster head, sets its cluster member list to its neighbor node list, and sends one Ack packet to each cluster member in the cluster member list. Otherwise, deletes from its neighbor node list the nodes which do not return one Res , sets its connectivity parameter to the difference between the threshold connectivity and the total number of the nodes returning one Res , and still keeps the isolated state and goes to step (6). If one isolated node receives the Res packet sent by one isolated node which is in its neighbor node list, then it deletes the isolated node from its neighbor node list and at the same time increases its connectivity parameter by 1.
(5) After (or ) receives one Ack packet sent by , it marks itself as a cluster member.
From the above process, it can be inferred that only the isolated node whose connectivity is not less than the  threshold connectivity can be marked as a cluster head. The goal of the generation algorithm of a cluster is to ensure that the total number of cluster members in one cluster is not less than the threshold connectivity so that one cluster can provide a complete -Anycast service even if some cluster members are in the dormant state.
In this way, one -Anycast group (one cluster) is generated, and it is uniquely identified by the unicast address of the cluster head, and the cluster members and the cluster head form a -Anycast tree whose -Anycast center node is the cluster head, as shown in Figure 2.

Implementation of 6LoWPAN Network Services.
The process of one IPv6 node acquiring one -Anycast service (a set of network services) is as follows.
(1) One IPv6 node sends a -Anycast service-request packet, the destination address of the packet is the -Anycast address of the corresponding -Anycast group, namely, the Unicast address of the cluster head of the corresponding cluster, and the payload of the packet is the sub-service IDs of the requested -Anycast sub-services.
(2) The -Anycast service-request packet is routed to the cluster head which broadcasts the -Anycast service-request packet in the cluster.
(3) One cluster member in the cluster receives the -Anycast service-request packet. If can provide the -Anycast sub-services identified by the sub-service IDs in the packet, then it returns one -Anycast subservice response packet to ; otherwise, abandons the packet.
(4) Within the predetermined time which is set to one dormant period of one sensor node, if the -Anycast sub-service response packets returned by the cluster members can provide one complete -Anycast service, then encapsulates the complete -Anycast service response data into one -Anycast serviceresponse packet and then returns it to the IPv6 node and goes to step (6); otherwise waits for another predetermined time.
International Journal of Distributed Sensor Networks 5 (5) In the second predetermined time, encapsulates the received -Anycast sub-service response data into one -Anycast service-response packet and returns it to the IPv6 node. (6) The process ends.

Cost and Delay Analysis.
In order to evaluate the performance of the proposed service model, we compare the proposed service model with the existing service model. As we know, not much work has been done in the field of service discovery for 6LoWPAN, so few existing service models were available for comparison. Reference [13] has proved that the performance of the service model in [13] has been better than that of the service models proposed in [4][5][6]. Therefore, we compare the proposed service model with the existing service model in [13]. Reference [13] proposed a service discovery scheme where the electronic number mapping was employed to perform the service discovery in 6LoWPAN. In the scheme, each sensor node was associated with a master node which was assigned a unique E.164 number. The gateway of the network performed the task of converting attribute-value pair-based human readable queries into E.164 numbers so that services destined for sensor nodes first reached the master node with which they were associated by using the E.164 number of the master node [13].
We adopt the analytical method in [13] to compare the performance of the proposed service model and the existing service model [13].
The paper analyzes the performance parameters of the proposed service model and the existing service model [13]. The performance parameters include the network service costs and the network service delay time. The network service costs include the transmission cost of the packets in IPv6 networks and WSN, the cost of the gateway (or 6LoW-PAN ingress node which connects WSN to IPv6 networks) processing packets, and the cost of the destination node processing the packets. In the proposed service model, the sub-service field is 1-byte long.
The costs of the proposed service model can be calculated from formula (1), and the costs of the existing service models [13] can be done from formula (2): In formulas (1) and (2), SR-GW is the distance (hop) from the source IPv6 node, which sends a service-request packet, to the gateway (or 6LoWPAN ingress node) which connects the destination WSN to the IPv6 network; GW-DES is the distance (hop) from the 6LoWPAN ingress node to the cluster head of the destination cluster (the -Anycast center node); GW-MA-GM is the distance (hop) from the gateway to the destination sensor node through the master node which the destination sensor node is associated with; DES-GM is the distance from the cluster head of the destination cluster (the -Anycast center node) to the cluster members in the same cluster (the -Anycast members), and its value is 1; GW , DES , and GM are, respectively, the cost of the gateway (or 6LoWPAN ingress node) processing one packet, the cost of the -Anycast center node processing one packet, and the cost of one -Anycast member (or the destination sensor node) processing one packet; is the number of the network services contained in one -Anycast service; and are, respectively, the transmission cost of a unit of data in WSN and the transmission cost of a unit of data in IPv6 networks. Since the cost consumed by data transmission between sensor nodes is larger than the one consumed by data processing by several orders of magnitude [24], GW , DES , and GM in formula (1) and formula (2) are negligible. According to [25,26], when the parameters are set to the following values: = 1, = 2, SR-GW = 6, GW-MA-GM = 4, GW-DES = 3 and DES-GM = 1, the network service costs is obtained, as shown in Figure 3.
The network service delay time includes the delay time of transmitting packets and the delay time of processing packets. The network service delay time in the proposed service model can be calculated from formula (3), and the network service delay time in the existing service model [13] can be done from formula (4): In formula (3) and (4), GW , DES , and GM are, respectively, the delay time of the gateway (or 6LoWPAN ingress node) processing one packet, the delay time of the -Anycast center node (or master node) processing one packet, and the delay time of one -Anycast member (or destination sensor node) processing one packet, and their values are set to 1 ms [27,28]; is the delay time of one intermediate node processing one packet's routing, and its value is set to 0.001 ms; wireless ( wired ) is the delay time of one packet's transmission on the wireless (wired) network plus the link delay time on the wireless (wired) network, and its value is set to 2 ms (0.5 ms); request is the length of one ( -Anycast) service-request packet, response is the length of one ( -Anycast) service-response packet, ( sub response ) is the length of one -Anycast sub-service packet, and their values are set to (127 × 8) bits; BW wireless (BW wired ) is the bandwidth of WSN (IPv6 networks), and its value is set to 250 Kbps (100 Mbps). The network service delay time is obtained, as shown in Figure 4.
In the proposed service model, the -Anycast members (the cluster members) deal with the -Anycast servicerequest packet at the same time so the network service delay time is not associated with if one -Anycast service can provide networks services through one request-response interaction, as shown in Figure 4.

Simulation Analysis.
In ns-2 simulation environment, the simulation region is 100 × 100 m 2 and includes one 6LoWPAN ingress node and 200 sensor nodes including 40 temperature sensor nodes, 40 humidity sensor nodes, 40 carbon-dioxide-concentration sensor nodes, 40 luminousintensity sensor nodes, and 40 soil-moisture sensor nodes. The sensor nodes form multiple clusters according to the proposed algorithm of one cluster generation. When one sensor node is in the idle state, it switches into the dormant state. In one dormant period, the sensor node is awakened automatically to check if there are the networkservice requests, and one dormant period is set to 1 ms. The communication range of one sensor node can range from 10 m to 100 m. The bandwidth in IPv6 networks is 100 Mbps, and the one in 6LoWPAN is 250 Kbps. The link protocol is IEEE 802.15.4. In the proposed service model, the fixed port 1200 refers to the environmental -Anycast service which includes 5 networks services ( -Anycast sub-services): the temperature network service whose sub-service ID is 1, the humidity network service whose sub-service ID is 2, the carbon-dioxide-concentration network service whose subservice ID is 3, the luminous-intensity network service whose sub-service ID is 4, and the soil-moisture network service whose sub-service ID is 5. The sub-service field is 1-byte long. When the above 5 network services are requested in sequence, the consumed power comparison and the delay time comparison of the proposed service model and the existing service model [13] are shown in Figures 5 and 6. Figures 5 and 6 show that the performance of the proposed service model is better than the one of the existing service model [13], and the analytical reasons are as follows.
(1) In the proposed service model, an IPv6 node can obtain multiple network services through one request-response interaction based on the IPv6-based -Anycast communication model, which reduces the consumed power and shortens the delay time.
(2) In the proposed service model, the -Anycast members (the cluster members) can provide their respective network services at the same time, which shortens the delay time.
(3) The proposed service model avoids the service failure caused by dormant sensor nodes.

Conclusion
The paper proposes a 6LoWPAN service model based on the IPv6-based -Anycast communication model. In the proposed service model, an IPv6 node can obtain multiple network services through one request-response interaction where multiple sensor nodes cooperate to complete all requested network services and provide their respective network services at the same time. In addition, the proposed service model also avoids the service failure caused by dormant sensor nodes. The paper analyzes the performance of the proposed service model and the existing service models, and the analytical results show that the proposed service model can greatly improve the service performance in 6LoWPAN.
International Journal of Distributed Sensor Networks