Abstract
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.
1. 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–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.
In this situation, this paper proposes a service model in 6LoWPAN, and it has the following contributions.
We extend the IPv6-based k-Anycast communication model into 6LoWPAN service model so that the data-centric services can be achieved in address-centric 6LoWPAN efficiently. According to the characteristics of the IPv6-based k-Anycast communication model, we propose the 6LoWPAN network architecture and implement the IPv6-based k-Anycast communication model based on this architecture. 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. The proposed service model avoids the service failure caused by dormant sensor nodes. In the proposed service model, users can request the only network services they are interested in, so the redundant data transmission is avoided.
The remainder of the paper is organized as follows. In Section 2, we discuss the related work on the service models in 6LoWPAN. We describe and discuss the 6LoWPAN network service in Section 3 and the performance of the proposed service model in Section 4. We conclude the paper with a summary in Section 5.
2. Related Work
References [4–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 pair-based 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–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–19] were only for the data-centric WSN, and they were implemented based on the data-centric 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 k-Anycast communication model in ad hoc networks in [20–22] and have proposed the IPv6-based k-Anycast communication model [23] for the first time. In the model, multiple resource-limited sensor nodes, which are called k-Anycast members, can cooperate to complete data-centric tasks. From the perspectives of theory and practice, we have proven that the IPv6-based k-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 k-Anycast communication model to achieve the data-centric services in the address-centric 6LoWPAN.
3. 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.

Network architecture.
3.2. IPv6-Based k-Anycast Communication Model
The IPv6-based k-Anycast communication model is between anycast and multicast, and it allows n servers to cooperate with each another to accomplish a task. Anycast and multicast are two special examples of k-Anycast. If kis equivalent to 1, then k-nycast becomes anycast. If k is equivalent to the total number of k-Anycast members, then k-Anycast becomes multicast.
In the k-Anycast model, each k-Anycast address represents one kind of k-Anycast service which can be divided into multiple k-Anycast subservices, and one kind of k-Anycast service is performed by one k-Anycast group. The definition of a k-Anycast group is described as follows.
Each k-Anycast group is uniquely identified by a one k-Anycast address. Each member of one k-Anycast group can provide one k-Anycast subservice at least. All members of one k-Anycast group form a tree which is called the k-Anycast tree and whose root node is called the k-Anycast center node. Multiple members of one k-Anycast group can cooperate to perform one k-Anycast service. The unicast address space of the k-Anycast center node is the same as the k-Anycast address space of the k-Anycast group. One packet whose destination address is one k-Anycast address can be routed to the k-Anycast center node of the k-Anycast group identified by the k-Anycast address.
In the k-Anycast model, one k-Anycast address represents one k-Anycast service which corresponds to one k-Anycast group and one k-Anycast tree. The k-Anycast address of one k-Anycast group is the same as the unicast address of the corresponding k-Anycast center node.
In the k-Anycast model, the process of an IPv6 node acquiring one k-Anycast service is described as follows.
An IPv6 node sends a k-Anycast service-request packet whose destination address is the corresponding k-Anycast address. The packet is routed to the k-Anycast center node. The k-Anycast center node forwards the k-Anycast service-request packet to each k-Anycast member. After one k-Anycast member receives the k-Anycast service-request packet, it returns its k-Anycast subservice response data to the k-Anycast center node. The k-Anycast center node deals with all received k-Anycast subservice response data, encapsulates the complete k-Anycast service response data into one service-response packet, and returns the packet to the IPv6 node.
3.3. Extension of IPv6-Based k-Anycast Model into 6LoWPAN Service Model
The paper extends the IPv6-based k-Anycast model into the 6LoWPAN service model. In 6LoWPAN, a set of network services are considered as one k-Anycast service, one network service is one k-Anycast subservice, one cluster is one k-Anycast group, the cluster head and cluster members are the k-Anycast members of the k-Anycast group, the cluster head is the k-Anycast center node, the IPv6 address (unicast address) of the cluster head is the k-Anycast address of the k-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 k-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 k-Anycast service which provides 4 kinds of environmental k-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 k-Anycast service. Therefore, a k-Anycast service is divided into multiple k-Anycast subservices each of which is achieved by one k-Anycast member (one cluster member). In this way all cluster members (k -Anycast members) can work together to provide one k-Anycast service. The proposed 6LoWPAN service model defines that the type of one k-Anycast subservice is identified by an identifier in the application layer which is called sub-service ID. Therefore, the type of one k-Anycast subservice is uniquely identified by a port and a subservice ID; for example, the k-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 m-byte long. The value of m is a positive integer which is greater than or equivalent to 1 and can be adjusted according to the quantity of the k-Anycast subservices. In the subservice field, each bit corresponds to the state of a type of k-Anycast subservice which records the state of whether the k-Anycast subservice is achieved or not. The bit value 1 (achieved) means that the corresponding k-Anycast subservice is achieved, and the bit value 0 (nonachieved) means that the corresponding k-Anycast sub-service is not achieved. In the service model, the value of m is set to 1 that is, one k-Anycast service can contain a maximum of 8 k-Anycast sub-services (network services).
Through the sub-service field, users can request the only network services which they are interested in.
3.4. Generation of One Cluster (One k-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 k-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;
Join_C 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_C packet: the packet which one isolated node returns to one cluster head and which is one response packet to the Join_C packet sent by the cluster head;
Ack_C 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_C packet sent by the isolated node.
One isolated sensor node becomes a cluster head or a cluster member through the following steps.
One sensor node Y within one-hop communication area of one isolated node X receives one Adv packet sent by X. If Y is marked as a cluster member, then it abandons to process the packet and goes to step (6); otherwise, Y adds X into its neighbor node list. If Y is an isolated node, then it decreases its connectivity parameter by 1; otherwise if Y is marked as a cluster head, then it sends a Join_C packet to X and goes to step (3). If Y is an isolated node and its connectivity parameter is equivalent to zero, then it sends a Join_C packet to the isolated nodes in its neighbor node list; otherwise Y still keeps the isolated state and goes to step (6). After X (or one isolated node Z in Y's neighbor node list) receives the Join_C packet, if it is in the isolated state and does not return one Res_C packet to other nodes, then it returns to Y one Res_C packet. If Y is a cluster head and receives one Res_C packet returned by X, then it adds X into its neighbor list and its cluster member list and at the same time sends one Ack_C packet to X. If Y is an isolated node, then, in the predetermined time, Y checks if the total number of the isolated nodes returning one Res_C packet is equivalent to the threshold connectivity. If it is, then Y marks itself as a cluster head, sets its cluster member list to its neighbor node list, and sends one Ack_C packet to each cluster member in the cluster member list. Otherwise, Y deletes from its neighbor node list the nodes which do not return one Res_C, sets its connectivity parameter to the difference between the threshold connectivity and the total number of the nodes returning one Res_C, and still keeps the isolated state and goes to step (6). If one isolated node receives the Res_C 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. After X (or Z) receives one Ack_C packet sent by Y, it marks itself as a cluster member. A cluster's generation process ends.
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 k-Anycast service even if some cluster members are in the dormant state.
In this way, one k-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 k-Anycast tree whose k-Anycast center node is the cluster head, as shown in Figure 2.

Generation of one cluster (one k-Anycast group).
3.5. Implementation of 6LoWPAN Network Services
The process of one IPv6 node acquiring one k-Anycast service (a set of network services) is as follows.
One IPv6 node sends a k-Anycast service-request packet, the destination address of the packet is the k-Anycast address of the corresponding k-Anycast group, namely, the Unicast address of the cluster head H of the corresponding cluster, and the payload of the packet is the sub-service IDs of the requested k-Anycast sub-services. The k-Anycast service-request packet is routed to the cluster head H which broadcasts the k-Anycast service-request packet in the cluster. One cluster member X in the cluster receives the k-Anycast service-request packet. If X can provide the k-Anycast sub-services identified by the sub-service IDs in the packet, then it returns one k-Anycast sub-service response packet to H; otherwise, X abandons the packet. Within the predetermined time which is set to one dormant period of one sensor node, if the k-Anycast sub-service response packets returned by the cluster members can provide one complete k-Anycast service, then H encapsulates the complete k-Anycast service response data into one k-Anycast service-response packet and then returns it to the IPv6 node and goes to step (6); otherwise H waits for another predetermined time. In the second predetermined time, H encapsulates the received k-Anycast sub-service response data into one k-Anycast service-response packet and returns it to the IPv6 node. The process ends.
4. Performance Analysis
4.1. 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–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 6LoWPAN 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 C of the proposed service model can be calculated from formula (1), and the costs
In formulas (1) and (2),

Network service costs.
The network service delay time includes the delay time of transmitting packets and the delay time of processing packets. The network service delay time D in the proposed service model can be calculated from formula (3), and the network service delay time
In formula (3) and (4),

Network service delay time.
In the proposed service model, the k-Anycast members (the cluster members) deal with the k-Anycast service-request packet at the same time so the network service delay time is not associated with n if one k-Anycast service can provide n networks services through one request-response interaction, as shown in Figure 4.
4.2. Simulation Analysis
In ns-2 simulation environment, the simulation region is

Consumed power.

Delay time.
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.
In the proposed service model, an IPv6 node can obtain multiple network services through one request-response interaction based on the IPv6-based k-Anycast communication model, which reduces the consumed power and shortens the delay time. In the proposed service model, the k-Anycast members (the cluster members) can provide their respective network services at the same time, which shortens the delay time. The proposed service model avoids the service failure caused by dormant sensor nodes.
5. Conclusion
The paper proposes a 6LoWPAN service model based on the IPv6-based k-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.
Footnotes
Acknowledgment
This work is supported by the National Natural Science Foundation of China (61202440).
