About this Journal Submit a Manuscript Table of Contents
International Journal of Distributed Sensor Networks
Volume 2013 (2013), Article ID 692735, 8 pages
http://dx.doi.org/10.1155/2013/692735
Research Article

A Service Model for 6LoWPAN Wireless Sensor Networks

Changshu Institute of Technology, Changshu, Jiangsu 215500, China

Received 29 March 2013; Accepted 4 June 2013

Academic Editor: Yong Sun

Copyright © 2013 Xiaonan Wang and Haili Huang. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

This paper proposes a 6LoWPAN service model based on the IPv6-based -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 [13]. 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.(1)We extend the IPv6-based -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 -Anycast communication model, we propose the 6LoWPAN network architecture and implement the IPv6-based -Anycast communication model based on this architecture.(2)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.(3)The proposed service model avoids the service failure caused by dormant sensor nodes.(4)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 [46] 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 [1419] 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 [1419] 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 -Anycast communication model in ad hoc networks in [2022] 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.

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.

692735.fig.001
Figure 1: Network architecture.
3.2. IPv6-Based -Anycast Communication Model

The IPv6-based -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, then -nycast 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.

3.3. 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 sub-service 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.

3.4. 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;

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 .(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 .(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.(6)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 -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.

692735.fig.002
Figure 2: Generation of one cluster (one -Anycast group).
3.5. 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 sub-service 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 service-response packet and then returns it to the IPv6 node and goes to step (6); otherwise waits for another predetermined time.(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.

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 [46]. 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 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), 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; is the distance (hop) from the 6LoWPAN ingress node to the cluster head of the destination cluster (the -Anycast center node); is the distance (hop) from the gateway to the destination sensor node through the master node which the destination sensor node is associated with; 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; , , and 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], , , and in formula (1) and formula (2) are negligible. According to [25, 26], when the parameters are set to the following values: , , , , and , the network service costs is obtained, as shown in Figure 3.

692735.fig.003
Figure 3: 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 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), , , and 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; () 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); is the length of one (-Anycast) service-request packet, is the length of one (-Anycast) service-response packet, () is the length of one -Anycast sub-service packet, and their values are set to () bits; () 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.

692735.fig.004
Figure 4: Network service delay time.

In the proposed service model, the  -Anycast members (the cluster members) deal with the -Anycast service-request 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.

4.2. Simulation Analysis

In ns-2 simulation environment, the simulation region is 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 luminous-intensity 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 network-service 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 sub-service 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.

692735.fig.005
Figure 5: Consumed power.
692735.fig.006
Figure 6: 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.(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.

5. 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.

Acknowledgment

This work is supported by the National Natural Science Foundation of China (61202440).

References

  1. N. Kushalnagar, G. Montenegro, and C. Schumacher, “6LoWPAN: Overview, Assumptions, Problem Statement, and Goals,” IETF RFC 4919, 2007.
  2. K. Mayer and W. Fritsche, “IP-enabled wireless sensor networks and their integration into the internet,” in Proceedings of the 1st International Conference on Integrated Internet Ad hoc and Sensor Networks, ACM press, New York, NY, USA, May 2006, SESSION: Node implementation and integration into internet table of contents, article No. 5. View at Publisher · View at Google Scholar · View at Scopus
  3. G. Montenegro, N. Kushalnagar, and J. Hui, “Transmission of IPv6 Packets over IEEE802. 15. 4 Networks,” IETF RFC 4944, 2007.
  4. S. H. Chauhdary, M. Cui, J. H. Kim, A. K. Bashir, and M.-S. Park, “A context-aware service discovery consideration in 6LoWPAN,” in Proceedings of the 3rd International Conference on Convergence and Hybrid Information Technology (ICCIT '08), pp. 21–26, IEEE press, New York, NY, USA, November 2008. View at Publisher · View at Google Scholar · View at Scopus
  5. S. A. Chaudhry, W. D. Jung, and C. S. Hussain, “A proxy-enabled service discovery architecture to find proximity-based services in 6LoWPAN,” Embedded and Ubiquitous Computing, vol. 4096, pp. 956–965, 2006. View at Scopus
  6. S. A. Chaudhry, D. J. Won, and A. H. Akbar, “Proxy-based service discovery and network selection in 6LoWPAN,” High Performance Computing and Communications, vol. 4208, pp. 525–534, 2006. View at Scopus
  7. J. Ortiz, C. R. Baker, D. Moon, R. Fonseca, and I. Stoica, “Beacon location service: a location service for point-to-point routing in wireless sensor networks,” in Proceedings of the 6th International Symposium on Information Processing in Sensor Networks, pp. 166–175, IEEE press, New York, NY, USA, April 2007. View at Publisher · View at Google Scholar · View at Scopus
  8. R. Fonseca, S. Ratnasamy, J. Zhao, C. T. Ee, and D. Culler, “Beacon vector routing: scalable point-to-point in wireless sensornets,” in Proceedings of the 2nd Symposium on Networked Systems Design and Implementation, pp. 329–342, USENIX, 2005.
  9. K. Dongpil, L. Joongsoo, K. Seoungku, and L. Younghee, “A new address scheme for service discovery supporting active mobile sensor objects,” in Proceedings of the 10th International Conference on Advanced Communication Technology, pp. 765–768, IEEE press, New York, NY, USA, February 2008. View at Publisher · View at Google Scholar · View at Scopus
  10. K. Seungku, L. Joongsoo, K. Dongpil, and L. Younghee, “Effective service discovery in IP-based wireless sensor network,” in Proceedings of the 10th International Conference on Advanced Communication Technology, pp. 1112–1114, IEEE press, New York, NY, USA, February 2008. View at Publisher · View at Google Scholar · View at Scopus
  11. M. Harvan, Connecting Wireless Sensor Networks to the Internet-a 6lowpan Implementation for TinyOS 2. 0 [M.S. thesis], Jacobs University Bremen, 2007.
  12. R. Silva, V. R. Q. Leithardt, J. S. Silva, C. Geyer, J. Rodrigues, and F. Boavida, “A comparison of approaches to node and service discovery in 6lowPAN wireless sensor networks,” in Proceedings of the 5th ACM International Symposium on QoS and Security for Wireless and Mobile Networks (Q2SWinet '09), pp. 44–49, Canary Islands, Spain, October 2009. View at Publisher · View at Google Scholar · View at Scopus
  13. F. M. Anwar, M. T. Raza, S.-W. Yoo, and K.-H. Kim, “ENUM based service discovery architecture for 6LoWPAN,” in Proceedings of the IEEE Wireless Communications and Networking Conference 2010 (WCNC '10), Sydney, Australia, April 2010. View at Publisher · View at Google Scholar · View at Scopus
  14. R. Flury and R. Wattenhofer, “Routing, anycast, and multicast for mesh and sensor networks,” in Proceedings of the 26th IEEE International Conference on Computer Communications, pp. 946–954, IEEE press, New York, NY, USA, May 2007. View at Publisher · View at Google Scholar · View at Scopus
  15. C. Zhou, J. Luo, and R. F. Li, “An event aware anycast rooting protocol in wireless sensor networks,” in Proceedings of the International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM '07), pp. 2516–2518, IEEE press, New York, NY, USA, September 2007. View at Publisher · View at Google Scholar · View at Scopus
  16. H. Liu, Z. Zhang, and J. Srivastava, “PWave: a multi-source multi-sink anycast routing framework for wireless sensor networks,” in Proceedings of the 6th International IFIP-TC6 Networking Conference, pp. 179–190, Springer, Berlin, Germany, 2007.
  17. M. Koziuk and J. Domaszewicz, “Tree-based anycast for wireless sensor/actuator networks,” in Proceedings of the 9th International Conference on Distributed Computing and Networking, pp. 322–331, Springer, Berlin, Germany, 2008.
  18. N. Thepvilojanapong, Y. Tobe, and K. Sezaki, “HAR: hierarchy-based anycast routing protocol for wireless sensor networks,” in Proceedings of the 5th Symposium on Applications and the Internet (SAINT '05), pp. 204–212, IEEE press, New York, NY, USA, February 2005. View at Scopus
  19. X. Zhu and H. Gupta, “Fault-tolerant manycast to mobile destinations in sensor networks,” in Proceedings of the IEEE International Conference on Communications (ICC '07), pp. 3596–3603, IEEE press, New York, NY, USA, June 2007. View at Publisher · View at Google Scholar · View at Scopus
  20. W. Wang, X. Li, and O. Frieder, “k-anycast game in selfish networks,” in Proceedings of the 13th International Conference on Computer Communications and Networks, pp. 289–294, IEEE press, New York, NY, USA, 2004.
  21. B. Wu and J. Wu, “k-Anycast routing schemes for mobile Ad Hoc networks,” in Proceedings of the 20th International Parallel and Distributed Processing Symposium (IPDPS '06), April 2006.
  22. C. Carter, S. Yi, P. Ratanchandani, and R. Kravets, “Manycast: exploring the space between anycast and multicast in Ad Hoc networks,” in Proceedings of the 9th Annual International Conference on Mobile Computing and Networking (MobiCom '03), pp. 273–285, September 2003. View at Scopus
  23. X. Wang, “Analysis and design of a k-Anycast communication model in IPv6,” Computer Communications, vol. 31, no. 10, pp. 2071–2077, 2008. View at Publisher · View at Google Scholar · View at Scopus
  24. I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless sensor networks: a survey,” Computer Networks, vol. 38, no. 4, pp. 393–422, 2002. View at Publisher · View at Google Scholar · View at Scopus
  25. M. Woo, “Performance analysis of mobile IP regional registration,” IEICE Transactions on Communications, vol. E86-B, no. 2, pp. 472–478, 2003. View at Scopus
  26. X. Zhang, J. G. Castellanos, and A. T. Campbell, “P-MIP: paging extensions for mobile IP,” Mobile Networks and Applications, vol. 7, no. 2, pp. 127–141, 2002. View at Publisher · View at Google Scholar · View at Scopus
  27. T. T. Kwon, M. Gerla, S. Das, and S. Das, “Mobility management for VoIP service: mobile IP vs. SIP,” IEEE Wireless Communications, vol. 9, no. 5, pp. 66–75, 2002. View at Publisher · View at Google Scholar · View at Scopus
  28. S.-C. Lo, G. Lee, W.-T. Chen, and J.-C. Liu, “Architecture for mobility and QoS support in all-IP wireless networks,” IEEE Journal on Selected Areas in Communications, vol. 22, no. 4, pp. 691–705, 2004. View at Publisher · View at Google Scholar · View at Scopus