A Lightweight CoAP-based Software Defined

Networking for Resource Constrained AMI Devices

Jaebeom Kim12, Fethi Filali1, and Young-Bae Ko2

1Qatar Mobility Innovations Center (QMIC), Qatar Science and Technology Park (QSTP), Doha, Qatar

{jaebeomk, filali}@qmic.com 2Graduate School of Computer Engineering, Ajou University, 206 World Cup-ro, Suwon, Republic of Korea

{kimjaebum, youngko}@ajou.ac.kr

Abstract—Advanced Metering Infrastructure (AMI) network is

the capillary communication network for smart grid that does not

only provide the data collection from each household but also delivers

configuration requests from intelligent energy services. However, the

smart grid network challenges like heterogeneity, large-scale, and

distributed operation must be solved for reliable and stable smart

grid services. Software defined networking (SDN) can help

improving the network scalability and consistency issues by

separating control and data planes, but it needs to be optimized for

resource-constrained AMI devices. To solve this problem, we suggest

a new design for an SDN controller-client system based on the

constrained application protocol (CoAP). The proposed system is

completed with a message exchange procedure, a network policy

execution and a simplified routing strategy. The experiment and

simulation results of CoAP based SDN and its software defined

routing application outperforms traditional SDN and routing

protocols in terms of control message overhead, reliability, and QoS

in large-scale AMI environment.

Keywords—AMI network; CoAP; Software Defined Networking;

Resource Constrained Network;

I. INTRODUCTION

Smart grid realization depends on the combination of power grid and communication networks. Electrical grid systems have four elements: electricity generation plants, transmission substations, distribution substations, and end users [1]. The recent electrical grid system works as follows. First, power plants generate power in bulks from solar panel, wind energy, and/or nuclear ready for distribution. As the power approaches customer’s homes, it is stepped-down again to the voltage necessary for home use. Finally, home appliances access power through their electric smart meters. But they all share the common understanding that Smart Grid needs to be integrated with an information communication infrastructure in order to be ‘smarter’ without human interaction as internet connected Machine-to-Machine (M2M) communication [2]. In the Internet-of-Things (IoT) enabled M2M network, various types of network objects are embedded with Advanced Metering Infrastructure (AMI). By using IoT enabled M2M, the electronics, the software, and sensors can be simply connected using (web) internet protocol. Thus, comprehensive smart utility network services such as water, gas, electricity and public safety can be combined into a single service provider even though the hardware is exclusively designed for each service domain. However, the IoT enabled AMI network requires a reliable and autonomous network management solution [2].

Software-Defined Networking (SDN) is one of the solutions to provide a simplified network management and services that has been widely researched for high-bandwidth (e.g. Gigabit Ethernet) backbone network [3]. The SDN isolates control and data plane to provide simplified network management and flexible configuration. For example, the network information of the device such as link quality, link usage, neighbor information, and traffic volume are delivered to the centralized SDN controller. The SDN controller decides and publishes data forwarding policy to the SDN switches. Thus, the data forwarding strategy of the network can be simply processed without distributed decision method of the network device as switch, router and etc. However, in spite of these benefits, the SDN may not be directly utilized to the resource constrained AMI network due to the control message and end-to-end session management overhead. Not only the control overhead but also the interoperability among different vendor devices may not be guaranteed, because the SDN is implemented by vendor-neutral strategy depending on capability and business goal of the service domain without international agreement [4].

To enable efficient and interoperable Software Defined AMI network for resource constrained AMI device, we present the IETF Constrained Application Protocol (CoAP) [5] based Software-Defined AMI Networking (CoAP-SDAN). The proposed scheme consists of system architecture, CoAP based control message exchange procedure, control path construction, network graph construction and deductive based SDN routing. In the proposed scheme, CoAP-SDAN controller calculates data plane of the network using network declarative algorithm. The calculated data plane of the network is delivered to the network by using only GET (or Observe)/response message exchanging of the CoAP standard. The experiment and simulation results of the proposed CoAP-SDAN show low communication overhead, end-to-end delay and improved end-to-end data communication reliability compared to traditional SDN in large-scale AMI network environment. To the best of our knowledge, this work represents one of the few attempts (if not the only one) in combining the SDN concept with CoAP in a smart way to reduce resources usage in the AMI and at the same time deliver on the requirements of smart grid applications.

II. BACKGROUND AND RELATED WORK

The AMI network is last-mile entry point of the smart grid that delivers remote/report data between Head End System (HES) and households. Figure 1 shows the multi-tier based smart gird network architecture. The scattered electricity information from the home area network (HAN) is transported to the Neighbor Area Network

(NAN) and is further delivered to the operator and core power system via Wide Area Network. The HAN scale varies depending on the business goal of the service provider, but we can simply assume that the number of AMI meters in HAN is the same as the number of households in the region. To provide reliable services and autonomous networking, concepts related to M2M-IoT are considered in this work since they are, in general, capable of managing complex infrastructure and large-scale deployment. Furthermore, the wireless communication needs to be considered for HAN infrastructure as compared with wired network such as PLC, because the AMI in the region may not be directly connected to the network switch and service provider due to installation cost and network system limitations.

A. software-defined networking for smart grid.

To solve the network heterogeneity problem in large-scale and heterogeneous network, Software-Defined Networking (SDN) has been recommended by not only academics but also industry network researchers. The key concept of the SDN is the isolation of control and data plane by using network software with centralized network controller [3]. In SDN infrastructure, each device in the network periodically reports measured network information to the SDN controller. The SDN controller connected to each device decides and publishes network policies depending on the network situation. In the SDN, the network policy can be dynamically configured depending on the business domain and its service requirements such as electricity, gas (reliability), public safety (QoS), etc. Figure 2 shows an example of floodlight controller based SDN architecture. The controller decides the network rule such as network status monitoring interval, routing strategy, QoS depending on predefined business application. The network layer and controller application of the SDN can be connected by using API (such as REST API). The network policy and capability can be flexibly reprogrammed by service provider (i.e., administrator). The calculated network policy is delivered to the network devices by using Openflow protocol (de facto standard communications interface between control and forwarding layers) and each device can be dynamically configured with the received forwarding policy, network status reporting interval, etc.

Cahn, Adam, et al. proposed Software-Defined Energy Communication Networks (SDECN) in 2013, which applies SDN technology to the Grid [6]. The SDECN is designed for the self-managed substation network such as auto-configured, configurable

packet inspection, security, latency-aware, congestion avoidance and virtualization. However, storage, computational power, and network bandwidth of the device need to be enhanced, because the SDECN utilizes traditional software-defined architecture that is designed for next-generation network switch. Elias Molina, et al. proposed SDN for IEC 61850 system in 2014. In this proposal they suggested the interconnection interface design for Openflow and IEC 61850 [7]. Also they presented the SDN-based smart energy application that provides dynamic configuration of the data transmission and security management. However, the proposed SDN architecture is designed for Wide Area Network switch, which have in general medium-to-high computational resources. Thus, the proposed scheme is not suitable to enable resource-constrained smart meters.

B. IETF CoAP and Network management

The CoAP is standardized IoT protocol by IETF that aims to enable light weight message exchanging for resource constrained networks without HTTP [5]. HTTP is the standard web protocol, but it need to be optimized in terms of end-to-end session management overhead, and frame size for resource constrained M2M devices. The CoAP is designed to enable the IoT in resource constrained network that employs light-weight frame format, and message exchanging procedures. Ashish, Patro, et al. proposed a software-defined Home IEEE 802.11 wireless LAN management architecture by using CoAP in 2015 [5]. In the proposal architecture, channel assignment and interference management of the home devices are dynamically reconfigured by CoAP server. However, this architecture does not include multi-hop and routing protocols that must be considered to enable large-scale AMI network.

To enable the SDN based resource constrained AMI network, we propose the CoAP based Software-Defined AMI networking (CoAP-SDAN). In the CoAP-SDAN, the network management is processed by a centralized CoAP-SDAN controller and it enables the large-scale network management by using centralized network graph and forwarding rule construction. Also the multi-hop route between CoAP-controller and all clients can be established while CoAP message exchanging procedure.

III. PROPSOED ARCHITECTURE AND SCHEMES:

COAP BASED SOFTWARE-DEFINED AMI NETWORKING

In the proposed CoAP-SDAN, device can be categorized into two types; CoAP-SDAN server and CoAP-SDAN client. The

Figure 2. Overview of the Software-Defined Networking architecture

Figure 1. Multi-tier based smart grid network architecture

CoAP-SDAN server is operated in the AMI gateway (substation) that is directly connected to the WAN. This is mainly because the computational resource and network capacity of the AMI gateway are generally considered better than the AMI device in each household. To manage and make a network policy, CoAP-SDAN uses the Datalog [8]. The Datalog is a truly declarative and light-weight logic programming language that syntactically is a subset of Prolog. It is often used as a query language for simple deductive databases. By using this deductive and Datalog query, CoAP-SDAN can easily manage and generate the network policy.

A. System architecture and basic operation

Figure 3 shows the CoAP-SDAN architecture that consists of 2 type of devices; CoAP-SDAN controller and client. The CoAP-SDAN sever (controller) stores the received network status from all CoAP-SDAN clients and make the network policy by using received network status. The business application is updated by the service provider (or can be automatically updated by the IEC 61850 service profile). For example, the smart grid meter profile information can be shared by using IEC 61850 that defines the communication interface between smart grid profile and services [7]. By using deductive database and Datalog language, the controller calculates network policy such as routing, and MAC parameters. For example, the routing application calculates the optimal routing path by using received link status information of the network then it can be published to the network devices.

All of the control message exchange of the CoAP-SDAN is done by using standardized CoAP message [5]. The CoAP-SDAN defines two type of mandatory message: Neighbor Status Report (NSR), and Topology Information Announcement (TIA). The TIA message is the network graph information that is constructed by the received NSR from each device. The TIA message consists of device addresses, neighbor addresses, and link metrics. The CoAP-SDAN controller periodically sends TIA message to the network

with Non-confirmable Request (Multicast) of the CoAP [10]. The NSR message is generated by each device that includes neighbor address and link quality between its neighbors. This message is periodically delivered to the CoAP-SDAN controller by using GET:observe message of the CoAP. Figure 4 shows the basic operation of the CoAP-SDAN procedures. At the network initialization stag e, CoAP-SDAN controller multicasts the GET:observe to the network with NetGraph that is calculated by received NSR messages. The Uniform Resource Identifier (URI)-Path in the GET message defines the requested service name (Application layer) that is pre-defined value in the CoAP-SDAN controller and device. If the CoAP-SDAN device receives unknown URI-Path name then the TIA message is discarded. By using URI-Path name, each device can identify the request service type of the SDN. The code number is identification of the CoAP message that is defined in RFC 7252 CoAP standard (0.01: GET / 2.05: Content) [10]. The message id (MID) and Token are unique id for acknowledgement and response message identification.

B. Control path construction (for control plane)

The traditional SDN assumes that the controller and client are connected directly or connected through additional routing protocols [4]. But, direct connection between controller and client is restricted in large-scale metering network because the line installation cost and network scalability. Additional routing protocols can be utilized to construct end-to-end routing, but it may not suitable to resource constrained device due to the routing control message exchange overhead.

To construct end-to-end route between controller and clients, CoAP-SDAN utilizes the TIA message exchange procedures. By using the multicasting GET:Observe:TIA message of the CoAP-SDAN, the upstream route construction and neighbor information (link information) updating of the network is processed. The routing information is applied to IP routing table of the device. For example, at the network initialization stage, the TIA message is transmitted to the network by CoAP-SDAN controller. The device, which received GET:Observe:TIA stores the URI-path, observe option, network graph, transmitter address and hop distance. Also the neighbor table is updated by the transmitter address in the received TIA message. The stored transmitter address is utilized to the next-hop address of NSR message. The device address and hop

Figure 3. CoAP-SDAN architecture for resource constrained device

Figure 4. TIA and NSR message exchanges (control message) between

CoAP-SDAN controller and devices by using standard CoAP message.

distance in the TIA are updated by each forwarder, and finally all devices in the network can identify its hop distance, and URI-path of the CoAP-SDAN controller.

Algorithm 1 shows the server-client route construction by using TIA and neighbor update procedure of the CoAP-SDAN. When a device receives the code:0.01/NetStatus URI-path GET:observe message then device checks the message is new or not. If the message id is found to be new then the device stores MID, URI-path, and observe message option values (NSR report interval) in the CoAP frame. The Neighbor table of the device can be updated by received GET:observe:TIA. The received message is rebroadcasted to the network with updated transmitter address, hop count. Also the NSR message is transmitted to the CoAP-SDAN controller shown in Figure 4. If the device receives the duplicated message from the neighbor then, it updates its neighbor information. If the hop distance in the received TIA is shorter than own hop distance, then upstream address is changed to TransmitterAddress in the TIA message. Also the received GET:observe:TIA is rebroadcasted to the network. By using this algorithm, the CoAP-SDAN can construct the tree-path between controller and all devices in the network without additional routing protocol.

C. Deductive database and network grpah construction

The network graph is the shortest path topology information of a network that includes all device address, links, and link costs in the network. The controller constructs the network graph that consists of links (device, neighbor, link cost). This network graph is periodically published to the network devices using GET:observe message of the controller. The link cost can be calculated by each device by using link traditional metric values such as SNR, HOP (set to 1), ETX, ETT, etc. The network graph information format in the CoAP-SDAN as below: S(source address), D(destination address), and C (link cost). Deductive database of the CoAP-SDAN

controller maintains network graph table, which is updated by received NSR message from each device in the network. The network graph message in the TIA is as follow: <Device Address; Neighbor Address 1…n; link cost 1…n>. If the message size is very long due to the huge number of links in the network, then the TIA payload can be transmitted by using block-wise transfer of the CoAP standard [10]. The network graph size (TIA payload) can be calculated as below:

𝑁𝑒𝑡𝑤𝑜𝑟𝑘 𝑔𝑟𝑎𝑝ℎ 𝑠𝑖𝑧𝑒 = (∑ 2 × 𝐴𝑑𝑑𝑟𝑆𝑖𝑧𝑒𝑛𝑘=0 )/2 (1)

where the AddrSize is the byte size of the network address it defined by the address type of network as IPv6 or IPv4. If the network device uses the compressed IPv6 address, then it can be reduced [10]. n is the number of links in the network and 4 is link cost size. If the network graph size is bigger than allowed payload size, then the graph information is published by block-wise transmission. By using the received network graph, each device can update its routing path (forwarding table).

D. Datalog based CoAP-SDAN application

In the proposed architecture, CoAP-SDAN application can be programmed not only in the native programming language but also by using well-known Datalog query language [8]. The Datalog is the recursive query language that is designed to be processed using database operator with set semantics. The Datalog rule syntax as below, <result> :- <condition1>,<condition2>,… <conditaionN> where, the result is the output of the conditions, and conditional is the rule to derive header. This Datalog rule syntax is recursively operated until no new tuples generated. It is suitable to calculate the route selection among network links [8]. Not only the routing perspectives, Datalog based network serity, QoS control, and application property configuration can be derivded by using Datalog [8]. To derive the data plane (optimal routing) we suggests the shortest routing rules that is made by only four datalog program rules as Table 1. In this table, the source, destination and the nexthop can be derived from the IP address in the deductive database in CoAP-SDAN. The cost value is simply represents the hop count but it can be changed by using various link metrics [10].

Table 1. shortest-path-hop Datalog query program

r1 path(S,D,Z,C) :- link(S,D,C). r2 path(S,D,Z,C) :- link(S,Z,C1), path(Z,D,Z2,C2), C = C1 + C2. r3 pCost(S,D,min<C>) :- path(S,D,Z,C). r4 shortestPath(S,D,Z,C) :- pCost(S,D,C), path(S,D,Z,C). * S:source, D:destination, Z:Nexthop, and C:Cost.

In this table, the rule 1 and 2 are used to derive the routing path (S,D,Z,C). Rule r1 produces path directly from the stored link tuple in the deductive database in CoAP-SDAN. Rule r2 recursively constructs path tuples of adding cost by matching operation the destination of the links to the source field of previously path. For example, if the S and D can be connected through Z then it is stored to the path tuple. Given the path relation, r3 calculate the minimum cost C for each S and D for all input paths. Rule r4 computes the shortest path (S,D,Z,C) by using the minimum cost set of the path between S and D. This rule can be executed by the “Query shortestPathHop (S,D,Z,C)” and its output results are stored to the output table.

Algorithm1 : Multi-hop control path construction between Controller and

Clients

UPaddr = The next-hop (IPv4, or v6) address to the gateway

Hop = HOP distance between controller and current device (stored) hop = received HOP distance from the TIA message (in the packet)

Neighboraddr{n} = neighbor address list of the device

1: 2:

3:

4: 5:

7:

8: 9:

10:

11: 12:

13:

14: 15:

16:

17: 18:

19:

20: 21:

if Message ID (MID) in the GET (code:0.01/NetStatus) is new then

add observe information in GET to the observe table;

Hop = hop in the TIA + 1;

UPaddr = TransmitterAddress in TIA; Neighboraddr {} = TransmitterAddress in TIA;

rebroadcast GET:TIA (TransmitterAddress=DeviceAddr and hop=Hop);

store URI-Path; send NSR message by using UPaddr with service URI-Path name;

endif

elseif Message ID (MID) in the GET(:NetStatus) != new and TransmitterAddress in TIA is not listed in NeighborList{} then

Neighboraddr {} = TransmitterAddress in TIA;

temp = hop ; if temp> Hop -1 then

Hop = hop in the TIA + 1;

UPaddr = TransmitterAddress in TIA; rebroadcast GET:TIA (TransmitterAddress = deviceAddress

and hop=Hop);

endif

endelseif

IV. EXPERIMENT AND SIMULATION RESULTS

The performance evaluation is done by testbed and network simulator. Testbed and simulation setup are shown in Table 2. The CoAP-SDAN controller and devices are combined by using VMWARE, Ubuntu 14.4.2 with libCoAP and Datalog Education System (DES). The SDN controller can be configured by safari Copper web plugin and controller stores the neighbor link status information by using DES database [8]. The traditional SDN testbed is implemented by using debian linux, Openflow and floodlight controller. The floodlight is one of the famous SDN controller, which made by the Openflow and java. The service application and floodlight controller are connected through the REST API (HTTP-WEB browser). To evaluate the CoAP-SDAN in large-scale resource constrained AMI network scenario, we compare the routing performance between traditional MANET routing protocols (AODV, DSDV) and CoAP-SDAN routing application (shortest-path-hop Datalog query program) using ns-3 [10]. In this simulation each AMI meter sends the electricity monitoring result to the substation every 30 seconds.

A. Bandwidth requirements comparison by using testbed

experiments between CoAP-SDAN and tradtional SDN

Figure 5 shows the link stress (control traffic load) of the SDN controller. In this test scenario, a substation (controller) and 25 to 125 AMI meters (clients) are connected through 100 Mbps virtual Ethernet links. To analyze the traffic overhead, communication interface in the SDN controller is monitored by Wireshark traffic analyzer. In Figure 5, the average link stress of the Floodlight controller shows the 180 Kbps in 125 AMI devices environment. However, the proposed CoAP-SDAN only requires 20 Kbps in 125 AMI devices environment. This is because the average packet size and the number of the floodlight SDN controller are bigger than CoAP based SDN controller. The measured average packet size of CoAP-SDAN in this experiment shows the average 132 bytes, but the floodlight controller shows the 510 bytes. Not only the average packet size, the number of control packets of the floodlight SDN are increased compared to CoAP-SDAN. This is because the CoAP-SDAN does not maintain the end-to-end session such as TCP, and end-to-end acknowledgement.

Figure 6 shows the simulation result of end-to-end packet deliver ratio between CoAP-SDAN and Floodlight SDN controller. The

traffic patterns of each protocol are modeled by using captured packets in figure 5 and simulation environment is described in Table 2. Also the maximum hop distance of the 25 to 125 device scenarios are set to 1, 2, 3, 4 and 5 respectively. In Figure 6, packet deliver ratio of the TCP based SDN controller sharply degraded from 75 AMI meter scenario. The main reason of this simulation result is the TCP session management overhead and congestion. Thus the SDN control packet of the SDN controller is not transmitted to the client. However, the CoAP-SDAN shows the 96% packet deliver ratio in 5 hop simulation scenario (125 devices). This is because the SDN control packets between client and server can be exchanged without end-to-end session management.

B. Large-scale resource constrined AMI network scenario: SDN

routing vs. MANET routing protocols

Instead of traditional distributed multi-hop routing strategy, SDN employs centralized routing strategy by using SDN routing application. In this simulation, we simulate the 3 different types of routing protocols as AODV (on-demand), and DSDV (proactive) and CoAP-SDAN Shortest routing app. (Centralized). Figure 7 shows the reliability, delay and hop distance comparison result between different routing protocols. In Figure 7-(a), CoAP-SDAN shows the 99% packet delivery ratio. Also, the DSDV (proactive) routing protocol shows acceptable performance. This is because the routing information of each device is periodically updated by published network information without any route discovery message handshaking. However, the AODV (on-demand) shows the only 66% packet delivery ratio this because the 2-way

Table 2. Testbed and simulation setting

Testbed implementation by using VMware CoAP-SDAN Testbed Value

OS CoAP type Deductive Database CoAP-SDAN control.

Ubuntu 14.04.02 LTS LibCoAP ver. 4.1.1

Datalog Educational System ver. 3.10 Safari Copper UI (CoAP-REST API)

SDN Testbed Value

OS SDN type CoAP-SDAN control.

Ubuntu 14.04.02 LTS Openflow, Floodlight ver 1.1

Floodlight UI (HTTP-REST API)

ns-3 simulator setting for Large-scale AMI network Comm. Interface Propagation/Loss model # of devices and G/W Network size Average distance (Devices)

IEEE 802.11g 18Mbps (Rate control) Log distance, Nakagami distribution

25-125 AMI meters (Grid), and 1 Gateway 400m × 500m,

25m

Application model Value

Electricity monitoring 30 sec. interval, 100 bytes (Plain Text)

Figure 5. Average link stress comparison between CoAP-SDAN server

and Floodlight SDN controller (Network Monitoring APP)

Figure 6. End-to-end SDN control packet reception ratio comparison

between SDN controller (substation) and Clients (AMI devices) in

resource constrained environment.

handshake (route request- response) route discovery messages can be dropped in large-scale and resource constrained network.

Figure 7–(b) shows the average end-to-end delay comparison results. In this figure, the AODV shows the lowest delay performance due to the route discovery delay. The AODV does not use the routing table. Instead of routing table, ADOV uses the route cache that is periodically initialized when a route is not utilized. Thus, the end-to-end route discovery procedure is newly initiated by each metering data transmission and metering packet transmission is delayed. On-demand route discovery strategy is suitable to use for mobility and multimedia data transmission scenario, but it is not suitable for smart metering domain. However, the CoAP-SDAN routing application and DSDV periodically maintain its routing table and it provides direct data transmission.

Figure 7–(c) shows the average hop distance between routing protocols where the CoAP-SDAN routing shows the shortest average hop distance given that the routing information of the CoAP-SDAN is decided by CoAP-SDAN controller based on entire network link information that received from each device. Even if the DSDV can use the routing table but shortest routing path may not be constructed due to the multiple broadcasting link status message from all devices in the network. Thus, the link stat information may not be successfully delivered to all network devices. However, the CoAP-SDAN routing application uses a single link stat flooding message that is transmitted by CoAP-SDAN controller and each device just responses with its link status to CoAP server. The result of the AODV shows the longer hop distance, because the detour route can be established due to the route discovery message drop of the optimal path [10].

V. CONCLUSION

The software defined networking can help improving the scalability and reliability issues of the heterogeneous smart grid network services. However, the traditional SDN approaches may not be directly applied to the AMI network due to the resource limitation of the AMI devices and their network. To solve this problem, we proposed CoAP based SDN protocol. To the best of our knowledge this work is the first attempt to use CoAP for Software Defined Networking in the large-scale wireless AMI network domain. The proposed CoAP-SDAN and routing application outperform traditional SDN approach in terms of bandwidth requirements, control message overheads and control

message reliability. Also the proposed SDN routing application based AMI network shows the improved reliability, QoS, and route optimization performance compared to the traditional MANET routing protocol. However, our architecture cannot be directly interconnected to the de facto network layer SDN standard protocol (Openflow) that allows controlling the network interface flexibly. In the further work, we consider inter-operability between Openflow and the proposed CoAP-SDAN.

We believe that our work can be a helpful guideline for understanding how the CoAP and SDN can be utilized for large-scale resource constrained AMI network.

ACKNOWLEDGMENT

This publication was made possible by the NPRP award [NPRP 6 – 244 – 2 – 103] from the Qatar National Research Fund (a member of The Qatar Foundation). The statements made herein are solely the responsibility of the author[s].

REFERENCES

[1] H. Farhangi, “The path of the smart grid,” Power and Energy Magazine, IEEE, vol. 8, pp. 18-28, 2010.

[2] A. M. Alberti, et al., “Internet of Things: Perspectives, Challenges and Opportunities,” in International Workshop on Telecommunications, 2013.

[3] S. H. Yeganeh, et al., “On scalability of software-defined networking,” Communications Magazine, IEEE, vol. 51, pp. 136-141, 2013.

[4] S. Sezer, et al., “Are we ready for SDN? Implementation challenges for software-defined networks,” IEEE Communications Magazine, vol. 51, pp. 36-43, 2013.

[5] A. Patro, et al., “COAP: a software-defined approach for home WLAN management through an open API,” ACM SIGMOBILE Mobile Computing and Communications Review, vol. 18, pp. 32-40, 2015.

[6] A. Cahn, et al., “Software-defined energy communication networks: From substation automation to future smart grids,” in Smart Grid Communications (SmartGridComm), 2013 IEEE International Conference on, 2013.

[7] J. Zhang, et al., “Opportunities for software-defined networking in smart grid,” in Information, Communications and Signal Processing (ICICS) 2013 9th International Conference on, 2013.

[8] R. Caballero, et al., “A new proposal for debugging datalog programs,” Electronic Notes in Theoretical Computer Science, vol. 216, pp. 79-92, 2008.

[9] Z. Shelby, et al., “The constrained application protocol (CoAP),” 2014.

[10] J. Kim, et al., “Improving the reliability of IEEE 802.11 s based wireless mesh networks for smart grid systems,” Communications and Networks, Journal of, vol. 14, pp. 629-639, 2012.

(a) Packet delivery ratio (b) Delay (c) Average hop distance

Figure 7. Routing comparison between CoAP-SDAN routing application and multi-hop routing protocols (1 substation, 125 AMI devices).