• No results found

LOADng Routing Protocol Evaluation for Bidirectional Data flow in AMI Mesh Networks

N/A
N/A
Protected

Academic year: 2021

Share "LOADng Routing Protocol Evaluation for Bidirectional Data flow in AMI Mesh Networks"

Copied!
7
0
0

Loading.... (view fulltext now)

Full text

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

37

LOADng Routing Protocol Evaluation for Bidirectional Data

flow in AMI Mesh Networks

Saida ELYENGUI

1

, Riadh BOUHOUCHI

2

, Tahar EZZEDINE

3 1.2.3

Communication System Laboratory Sys'Com, National Engineering School of Tunis, University Tunis El Manar

Abstract— This research work denotes a novel evaluation

of LOADng the routing protocol for Wireless Sensor Network. The LOADng protocol implementation is a part of ITU-T G.9903 recommendation based on the framework of the LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) proposed by IETF specified by the IETF Internet-Draft draft-clausen-lln-loadng-11 and currently still in its design phase. LOADng is a reactive on demand distance vector routing protocol derived from AODV the Ad hoc On-demand distance vector protocol proposed by IETF. This work was motivated by the need for a novel protocol implementation for smart metering applications providing better performance and less complexity than RPL the Routing Protocol for Low power and lossy networks and adapted to (LLNs) requirements and constraints.

Our implementation was successfully integrated into the communication layer of Contiki OS the Wireless Sensor Network operating system and evaluated through extensive simulations for AMI Mesh Networks.

KeywordsSmart Metering; LOADng; AODV; RPL;

Performance; Simulation; Contiki OS; Cooja.

I. INTRODUCTION

Smart metering is expected to be an integral part of the smart grid, since advanced metering infrastructure is the foundation of the power grid, providing the connection between customer’s premises and neighbor area networks (NAN) in order to transport metering and configuration data with bidirectional traffic flow to and from the information systems of energy providers.

The main purpose of automated metering is to enable real time access to metering data in order to improve management and production of energy and the configuration of smart meters in real time [12].

In this context, one of the prime challenges is providing scalable communication for bidirectional data flow to collect and manage large amount of data for distribution domain. Therefore the choice of a suitable routing protocol providing robust and scalable performance for different types of data traffic is mandatory.

This paper describe the evaluation of a novel routing protocol LOADng [1] which is still in the design phase by IETF to realize smart metering communications.

Results from extensive simulations carried out on cooja the contiki OS simulator on a realistic network topology are presented to demonstrate the efficiency of our proposed solution on the network latency, Packet delivery Ratio and control traffic overhead.

In this manuscript we make the following contributions: We evaluate our implementation of LOADng protocol and compare it to AODV protocol and RPL protocol for bidirectional scenarios in AMI mesh networks architecture.

We provide analytical results for the network end-to-end delay, PDR, overhead and show how our implemented LOADng solution can improve bidirectional data flow scalability.

The paper is organized as follows: Section II provides an overview about LOADng protocol for AMI mesh networks and highlights the prime issues raised that motivated us to its implementation.

Section III provides a detailed overview of LOADng protocol. Section IV presents detailed performance evaluation and analytical results, in section V we conclude.

II. LOADNG PROTOCOL

The LLN on-demand ad hoc distance vector routing protocol – next generation LOADng is a reactive routing protocol for Wireless Sensor Networks. It is a simplified version of ad hoc on-demand routing protocol AODV originally developed for use in IEEE 802.15.4 based devices in 6LoWPANs and LLNs [2]. This protocol may be used at layer 3 as a route-over routing protocol or at layer 2 as a mesh-under protocol. Therefore, LOADng algorithm is characterized by its simplicity and its low memory storage needs. Thus, it would be ideal and suitable solution for AMI mesh networks [9, 10, 11]. As it was originally developed to WSNs and Low Power and Lossy Networks (LLNs), it should be adapted to their requirements and constraints.

A. Motivation

Mesh network for smart metering application can be considered as trees of nodes rooted to different concentrators creating a neighbor area networks.

(2)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

38

Each concentrator is serving tree of smart meters in the same neighborhood collecting data and transmitting it threw different gateways to the utility information systems. Such scenario requires a bidirectional dataflow between nodes and concentrator in frequent way for real time metering and energy load management.

Different routing protocols were developed for LLNs [4] the most famous is RPL the routing protocol for low power and lossy networks standardized by IETF [5, 13, 14] supporting and optimized for most of LLNs traditional scenarios where MP2P and P2P communication traffic patterns are the most frequent and where traffic from concentrator to sensors are rare occurrence. Whereas, other P2MP scenarios should be also considered for study in AMI mesh networks. Where appropriate and predominant bidirectional dataflow scenarios are MP2P and P2MP traffic patterns. So our motivation for LOADng implementation came from the need for a novel protocol suitable for AMI.

B. LOADng Specification

LOADng describes four types of packets:

 Route Request (RREQ): The RREQ is generated by a router the <originator>, when a data packet in available to a destination, RREQ packet is with no valid route and with a specific destination address.

 Route Reply (RREP): The RREP is generated by a router, upon a RREQ reception and processing with destination address in its routing set.

 Route Reply Acknowledgement (RREP-ACK): The RREP-ACK is generated by a LOADng router after a reception of RREP, as an indication to the neighbor source of the RREP that the RREP was successfully received.

 Route Error (RERR): the RERR is generated by a router when the router detects a broken route to the destination.

LOADng inherited basic operations of AODV, including generation and forwarding of Route Request RREQs to discover a route to a specific destination as shown in Fig 1.

Fig. 1. RREQ forwarding in LOADng

Upon receiving this message, only the terminator (Node C) can reply by a RREP and forward it on unicast, hop-by-hop to the source as detailed in Fig 2.

Fig. 2. RREP unicast forwarding in LOADng.

When intermediate nodes receive the RREP, they will unicast a proper RREP–ACK to the neighbor from which they received the RREP, in order to notify that the link is bidirectional. If a route is detected broken, an error message can be returned to the source of that data packet.

(3)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

39

Compared to AODV, intermediate nodes are not allowed to generate RREPs. As a result, LOADng reduces the size of control messages which is demanded in LLNs

LOADng uses an alternative discovery scheme, denoted Smart RREQ; when receiving a RREQ, intermediate node looks in its routing table entries, if the demanded address exists and it is the next-hop, the RREQ is unicast to the next-hop instead of being broadcast.

In LOADng routing discovery process, only the destination is permitted to respond with a RREP when it receives RREQ message with the same IP address. So, there is no more need to the sequence Number included in AODV messages sent to requesting routers.

Also, there is no more Gratuitous RREP; when an intermediate node has a usable route to the destination the router responds with a RREP on unicast to the source and notify the destination with this Gratuitous message.

Thus, message size would be reduced which is definitely suitable to LLNs low-power and memory constraints [3].

In the other hand, nodes with LOADng protocol do not maintain a precursor list having the IP address for neighbors containing a next hop towards each destination – as it is done with AODV protocol –, but they only care about the next hop to forward current packet to its destination.

LOADng Control messages can include TLV (Type-Length-Value) elements, permitting protocol extensions to be developed [3].

C. Integration into the Contiki OS

As we work with Contiki OS [8] and the modular Rime stack, we have replaced its main modules which are route and route discovery.

When there is data to be sent, LOADng router discover a bi-directional route to any required destination in the network using the route discovery module. And maintain an active route as long as there is traffic to be sent with the protocol operations implemented in the route module. Each node that we call ―router‖ has a number of parameters, an information base and can generate process and forward a message.

D. Information Base

In order to maintain the protocol state, the following information base sets are required:

 The ―Routing Set‖: The Routing Set stores tuples for each reachable node.

 The ―Destination Address Set‖: Destination Address Set records address for which the current router must respond with a RREP message.

 The ―Blacklist Neighbor Set: Blacklist neighbor set stores neighbors to which connectivity is unidirectional.

 The ―Pending Acknowledgment Set‖: that Contains information about transmitted RREP with a RREP-requirement Set.

 Local Interface Set: Records local LOADng interfaces.

E. Route module : “route.c” & route.h

Route module is the core of the router; it governs the routing table by updating, removing, adding and maintaining routes. In this module, we modified two files; the route protocol route.c and the route protocol header route.h. This module was correctly compiled and integrated into the Contiki OS Rime Stack.

F. Route-discovery module: discovery.c & route-dicovery.h

Route-discovery module with route module permit to discover new routes and update routing sets, it uses mesh and uip-over-mesh libraries to enable routers to send and receive messages.

In our case, it deals especially with rime module -using rime address- in order to achieve these functions.

In this module, two files where modified; the route protocol code route-discovery.c and the route protocol header route-dicovery.h. The standard route discovery module of contiki OS was replaced by our modified module with respect to the specification in [1].

III. PERFORMANCE EVALUATION A. Simulations configuration

In order to understand both the performance of LOADng and the performance impact of our implementation we evaluate the LOADng routing protocol in terms of packet Delivery ratio (PDR), latency in order to predict how it behave in larger networks, and Overhead to describe its power consumption and memory management. Simulations were completed in a field of 1000 × 1000 meters, with variable amounts of routers positioned randomly as detailed in table 2.

(4)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

40

Table 1

CONTIKI OS AND COOJA SIMULATOR PARAMETER SETUP Settings Transport

layer UDP

Value

Wireless channel model UDGM Model with Distance Loss Communication range 150m

Distance to the Concentrator

Variable [20-250] Meters

Grid Size 1000*1000 m2

Number of routers Variable [25/50/75/100/125/150]

Mote type Tmote Sky

Network layer μIPv6 + 6LoWPAN

MAC layer CSMA + ContikiMAC

Radio interface CC2420 2.4 GHz IEEE 802.15.4 Simulation time 8h

The network scenarios are substance of two different traffic patterns: multipoint-to-point (MP2P), wherever all routers generate CBR traffic stream by periodic reporting of 512-byte data packet with 60 seconds interval and acknowledgment of each received frame in upward direction, for which the destination is always the sink.

TABLE 2

TRAFFIC PATTERN OF NODES

Node Type Traffic Pattern

Client MP2P traffic flow by periodic reporting with 5s interval and acknowledgment of each received frame in upward direction.

Sink P2MP traffic with two messages types :

Acknowledgment of data frames in downward direction every data arrival.

Configuration data sent with Poisson process with average of a single arrival per interval of 10 minutes in downward direction.

And point-to- multipoint (P2MP) traffic with two messages types, acknowledgment of data frames in downward direction every data arrival and configuration data sent with Poisson process through average of a single arrival per interval of 10 minutes in downward direction. We used two types; client’s nodes and a single router node.

B. Simulations Results

Point-to-multipoint (P2MP): Fig.4. shows the average packet delivery ratios function of variable distance to the concentrator and Fig.5. shows PDR function of variable nodes number, incurring from respectively AODV, LOADng and RPL.

Fig.6. depicts the delivery ratio for P2MP traffic flow of three protocols; the ratios are close to 100%, regardless of number of nodes. Whereas according to Fig.4. LOADng performance decrease when the node distance to the concentrator is higher than 150 meters. However LOADng yields 60% higher data delivery ratios than does AODV.

0 50 100 150 200 250 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Distance(m) P 2 M P P D R

P2MP PDR vs Distance to the Concentrator

AODV LOADng RPL

Fig. 3. Fig.4. P2MP PDR function of Distance

0 50 100 150 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of Nodes P 2 M P P D R P2MP PDR vs Nodes Number AODV LOADng RPL

(5)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

41

P2MP PDR function of Nodes Number

0 50 100 150 200 250 0 200 400 600 800 1000 1200 1400 1600 1800 Distance(m) E n d -t o -E n d D e la y P 2 M P (m s )

P2MP End-to-End Delay vs Distance to the Concentrator AODV

LOADng RPL

Fig. 4. P2MP End-to-End Delay function of Distance

0 50 100 150 0 500 1000 1500 2000 2500 3000 Number of Nodes P 2 M P E n d -T o -E n d D e la y

P2MP End-To-End Delay vs Nodes Number AODV

LOADng RPL

Fig. 5. P2MP End-to-End Delay function of Node Number Multipoint-to- Point (MP2P):

For downward traffic, the Fig.8 shows that LOADng is very efficient in terms of average latency which is equal to 286 ms compared to AODV 1680 ms when the network is subject to variable distance to the concentrator and when the network is with increasing number of nodes is variable latency is equal to 463 ms and 2586 ms for LOADng and AODV respectively. 0 50 100 150 200 250 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 Distance(m) M P 2 P P D R

MP2P PDR vs Distance to the Concentrator

AODV LOADng RPL

Fig. 6. MP2P PDR function of Distance

On the other hand, we observe a very low average latency in the case of standard RPL and it was equal to only 94 ms for both cases.

As LOADng’s control packets are significantly smaller than those of AODV, LOADng control traffic overhead is considerably lower than AODV.

Fig.9 shows that a packet delivery ratio is 100% for RPL and the degradation for the delivered packets for AODV protocol in accordance with the increase of number of nodes; it reaches only 55% lower than LOADng which is equal to 75%. Whereas degradation for the delivered packets for AODV protocol in accordance with the distance to the concentrator reaches only 65% lower than LOADng which is equal to 85%. 0 50 100 150 0.4 0.5 0.6 0.7 0.8 0.9 1 Number of Nodes M P 2 P P D R MP2P PDR vs Number of Nodes AODV LOADng RPL

Fig. 7. MP2P PDR function of Nodes Number

(6)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

42

For upward traffic, Fig.10 shows that LOADng is better than AODV in terms of average latency which is equal to 569 ms compared to AODV 2884 ms when the network is subject to variable distance to the concentrator and when the network is with increasing number of nodes is variable latency is up to 1062 ms and 3586 ms for LOADng and AODV respectively. On the other hand, we observe a very low average latency in the case of standard RPL is equal to only 96 ms for both cases.

0 50 100 150 200 250 0 500 1000 1500 2000 2500 3000 Distance(m) E n d -t o -E n d D e la y M P 2 P (m s )

MP2P End-to-End Delay vs Distance to the Concentrator AODV

LOADng RPL

Fig. 8. MP2P End-to-End Delay function of Distance

0 50 100 150 0 500 1000 1500 2000 2500 3000 3500 4000 Number of Nodes M P 2 P E n d -T o -E n d D e la y

MP2P End-To-End Delay vs Nodes Number AODV

LOADng RPL

Fig. 9. MP2P End-to-End Delay function of Node Number

Fig.12 shows the number of overhead packets conducted by each router and Fig.13 depicts the Overhead bytes per second in the network incurring from respectively AODV, LOADng and RPL. LOADng protocol shows better performance than AODV in both cases.

50 60 70 80 90 100 110 120 130 140 150 0 10 20 30 40 50 60 70 80 Number of Nodes N u m b e r o f O v e rh e a d P a c k e ts p e r R o u te r Overhead AODV LOADng RPL

Fig. 10.Number of overhead packets

50 60 70 80 90 100 110 120 130 140 150 0 500 1000 1500 2000 2500 Number of Nodes O v e rh e a d (B y te s /S e c ) Overhead AODV LOADng RPL

Fig. 11.Overhead bytes per second

Our study reveals that the LOADng implementation harvests better performance than AODV in all used metrics: higher data delivery ratios, lower delays and lower overhead.

In all cases RPL protocol performs better than our LOADng implementation but in other hand LOADng protocol represents a part of the ITU-T G.9903 recommendation for smart metering applications. Its strength came from its simple processing compared to RPL protocol, even though protocol extension should be developed to optimize its performance for AMI applications.

(7)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 6, June 2015)

43

IV. CONCLUSION

The results in simulations reveal that the LOADng protocol is better than AODV routing protocol in all cases. In AMI scenario, LOADng showed better memory management and power consumption. Also, it still has less implementation complexity compared to RPL which is a crucial point.

To sum up, many aspects remain interesting perspectives and future challenges: Evaluating LOADng performance in real experiment, testing its performance in other application domains in order to find how we can optimize flooding and route storage to maximize its performance.

REFERENCES

[1] T. Clausen, A Colin, J Yi, A. Niktash, Y Igarashi, H Satoh, and U Herberg. The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng), October, 2013, INTERNET-DRAFT draft-clausen-lln-loadng-10. K. Kim, S. Daniel Park, G. Montenegro, S. Yoo, and N Kushalnagar. 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD). Internet-Draft draft-daniel-6lowpan-load-adhoc-routing-03,Internet Engineering Task Force.

[2] C. Perkins, E. Belding-Royer, and S. Das, ―Ad hoc On-Demand Distance Vector (AODV) Routing,‖ Experimental RFC 3561, July 2003.

[3] T.Clausen, A.Colin, J.Yi, A.Niktash, Y.Igarashi, H Satoh, and U.Herberg, INTERNET-DRAFT draft-clausen-lln-loadng-01, ―The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)‖, January 2012.

[4] Sabbah, AI; El-Mougy, A; Ibnkahla, M., "A Survey of Networking Challenges and Routing Protocols in Smart Grids," Industrial Informatics, IEEE Transactions on, vol.10, no.1, pp.210,221, Feb. 2014.

[1] T. Winter, P. Thubert, A. Brandt, T. Clausen, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, and J. Vasseur, ―RPL: IPv6 routing protocol for low power and lossy networks,‖ IETF, RFC 6550, April 2012.

[2] P. Kulkarni, S. Gormus, Z. Fan, and B. Motz, ―A self-organising mesh networking solution based on enhanced RPL for smart metering communications,‖ in Proc. IEEE Hotmesh Workshop, Lucca, Italy, Jun.2011.

[3] T.Winter et al., RPL: IPv6 Routing Protocol for LowPower and Lossy Networks, IETF ROLL WG RFC 6550, 2012.

[4] ―Contiki: The operating system for connecting the next billion devices—The Internet of things,‖ Available: http://www.contiki-os.org/

[5] S. Subramani, Z. Fan, S. Gormus, P. Kulkarni, M. Sooriyabandara, andW. H. Chin, ―Wisemen: White space for smart metering,‖ in Proc.IEEE Innov. Smart Grid Technol. (ISGT) Conf., Washington, DC, Jan. 2012.

[6] I. Akyildiz, X. Wang, and W. Wang, ―Wireless mesh networks: A survey,‖ Comput. Netw., vol. 47, pp. 445–487, Mar. 2005.

[7] T. Iwao, K. Yamada, M. Yura, Y. Nakaya, A. Cardenas, S. Lee, and R. Masuoka, ―Dynamic data forwarding in wireless mesh networks,‖ in Proc. IEEE Smart Grid Commun. Conf., Gaithersburg, MD, Oct. 2010.

[8] B. Lichtensteiger, B. Bjelajac, C. Muller, and C. Wietfeld, ―RF mesh systems for smart metering: System architecture and performance,‖ in Proc. IEEE Smart Grid Commun. Conf., Gaithersburg, MD, Oct. 2010.

[9] D. Wang, Z. Tao, J. Zhang, and A. Abouzeid, ―RPL based routing for advanced metering infrastructure in smart grid,‖ in Proc. IEEE Int. Commun. Conf. (ICC), Cape Town, South Africa, May 2010. [10] J. Tripathi, J. Oliveira, and J. P. Vasseur, ―Performance evaluation of

routing protocol for low power and lossy networks (RPL), draft-tripathi-roll-rpl-simulation-04, IETF ROLL WG,‖ 2010.

AUTHORS

S. Elyengui: is a PhD student in the department of communication systems at Tunisian National School of Engineering, University of Tunis El Manar Tunisia. She is a researcher in the area of smart grid communication and networking, SG networks security, AMI applications and M2M communications. She received her Computer Networks Engineer Diploma and a Master degree in new Technologies of Communication and Networking in 2007 and 2011 respectively.

R. Bouhouchireceived the Master degrees in communication systems from ENIT, the MBA degree s from Mediterranean School of Business, T.E graduated in 2000 from ESPTT, and holds an engineering degree in computer sciences since 2006, as he holds more than eight international certificates in advanced programming and management as ITIL (Information Technologies I

References

Related documents

The Department, through its Office of Technology for Human Resources is issuing this CATS+ TORFP to provide information to Master Contractors interested in submitting proposals

Since 2008 (Class of 2010) the International Master Program in Biomedical Sciences is a joint program between the University of Freiburg and the Faculties of Medicine, and Pharmacy

The internal state of TCP congestion control mechanism is defined by three main parameters: size of congestion window (cwnd), threshold for switching between slow start and con-

Despite epididymal adipose tissue, significant changes were found in the weight and in the gene expression of different markers, both in subcutaneous and in brown adipose tissue,

Declines in the industry have been associated with declines in the provision and maintenance of site facilities, particularly social opportunities for on-site staff (Education

D1.12 HyLiner AKS HDPe Lining for ConCrete PiPe | | 17 oCtober 2013 | | PAge 3 HyLiner AKS HDPe is used as corrosion protection lining in HyLiner AKS HDPe is used as

impact potential. In 2014 they selected Atlanta Mission as their focus charity, providing loaned executives and key strategic services. This grant is allowing Atlanta Mission

Highway Engineerin Engineeringg C3010 / UNIT  C3010 / UNIT  6 6 The structure of the road mainly consists of the following layers.. The structure of the road mainly consists of