8.2.1.1 The Existing AMI Organization

Energy distribution networks have a tree topology with large production units on top producing most of the required energy, which is then transported via a widespread distribution network toward consumers (called the end points). Figure 8.1 illustrates this top‐down configuration in which consumers can be reached after passing through different aggregating nodes, i.e., transformers. Utilities forecast the consumption of end points based on their historical consumption and adjust these forecasts based on automated metering. These forecasts are therefore very sensitive to any modification of end‐points behavior.

Currently there are several notable trends taking place in the energy market. Some examples are the shift away from fossil to renewable energy, the steadily increasing number and heterogeneity of electrical appliances and devices, and the decreasing price of various distributed energy production technologies.

DSOs require a bidirectional communication with smart meters in order to efficiently manage their networks and face these trends. In fact, one consequence of these upcoming changes is the growing demand at the consumer side. Therefore, utilities have to plan such growth, increase the amount of electricity produced, and transport this electricity toward the end points. However, as the distribution network capacity is limited, a question that arises is what will happen when reaching this limit. Utilities should encourage end points to balance their consumption during a 24 h period; hence the bidirectional communication with smart meters. In addition, consumers are getting more and more equipped with micro‐generation systems. As a consequence, the grid evolves toward a system in which large energy production facilities – dams, nuclear power plants, etc. – must coexist with a myriad of smaller, less reliable systems in the same network. Therefore, and without more information from these “prosumers” – at the same time consumer and producer – it will become more and more difficult for DSOs to estimate consumption of such end points. The ideal solution in order to take into consideration these trends would be to modify the whole distribution network. First, by increasing its capacity and secondly, by allowing prosumers to re‐inject their production excess into the network – and have smart meters metering it. However, these modifications are very costly and so inconceivable for now or should be planned and spread over several years. For these reasons, DSOs prefer to first set up means to efficiently meter as well as send signals to individuals to balance their consumption.

Therefore, initial smart grid efforts, mainly directed by DSOs, use the AMI in order to offer better management of a distributed energy production. And the smart meter is thus a central piece of the needed communication framework. On the one hand, it allows real‐time monitoring in order to collect accurate data about the consumption (and possibly the production). On the other hand, it allows receiving real‐time electricity pricing signals, which trigger a certain period of time where the energy is cheaper. Relays can be used in user premises to activate or deactivate devices that are plugged into a specific circuit (e.g., hot water tank, which could be switched on during the night).

As illustrated in Figure 8.2, the AMI consists of a tree of smart meters, placed at different positions of the network. Data from all these meters are collected, stored, processed, and analyzed by the utility center. Routing protocols are thus required from the smart meters (i.e., nodes of the tree) to the utility center (i.e., root of the tree) in order to forward the data hop by hop. Basic commands issued by the utility center to announce the price in real time are actually broadcast to the whole network and do not require unicast transmission.

8.2.1.2 Communication Technologies used in the AMI

Currently, the communication taking place within the core system is based on Internet technologies with IP above a variety of underlying technologies such as optical fiber, cellular network, or power line communication (PLC). With some of them, one aggregating node or a relay node can transfer data on behalf of hundreds of smart meters behind it. To reach the core of the AMI, data issued by (or intended to) the smart meters typically have different “hops” distance to perform. The distance to cover in one hop will vary depending on the network configuration. The technology used to communicate depends on this distance and the environment characteristics. In particular, the technologies used for the last‐hop heavily depend on a) the meter capabilities in terms of communication and processing power, b) the energy requirements for this communication, and c) the relative performance of the available options – such as the distance with a wireless base station, the quality of PLC transmission, etc. A non‐exhaustive list of commonly used technologies is given in Table 8.1, along with their advantages and drawbacks [8–10]. For wireless technologies, the “energy cost” column refers to the energy consumption associated with the technologies: it includes the transmission power, as well as the processing cost of the corresponding protocol stack and the specific medium access control procedures. The “monetary cost” reflects the cost of the hardware components needed to implement a technology, including SIM cards, as well as potential spectrum license fees.

Technology	Range	Throughput	Energy cost	Monetary cost
802.15.4 [11, 12]	up to 100 m	up to 250	cheap	cheap
802.11ah [8]	up to	Tens of	expensive	cheap
LoRaWAN [9]	(urban) to (rural)	Tens of	cheap	cheap
LTE‐Cat M [10]	(urban) to (rural)		medium	expensive
Narrowband PLC [13]	several	up to	cheap	cheap
Wired Internet	–	up to	cheap	expensive

We need to bear in mind that all technologies listed in Table 8.1 are not always available: due to hardware limitations and/or environmental constraints, the choice can be limited.

8.2.1.3 AMI Limitations

Up to now, on the demand side, the smart grid is mostly limited to the smart meters. Their deployment within the AMI is mapped onto the distribution structure. Furthermore, the intelligence in meters or in intermediate nodes is very limited, leaving all the intelligence in the network core, i.e., the utility center. As a consequence, the AMI lies into a centralized system as previously illustrated: all the data transit through data centers controlled by a DSOs, where all storage and analysis actions are performed; in other words, the AMI is fully operated and controlled by utilities.

With respect to this status, we see three kinds of limitations, all in favor of the use of alternative communication systems.

First, we see issues in terms of incentives. Indeed, DSOs will not expect significant gains from improving the communication capabilities, since those gains will go to the entities exploiting them, such as flexibility operators. Conveying the data is not the core mission of DSOs, and they will probably be reluctant to invest in communication improvements if they do not get a return on investment.

Second, the current situation raises some privacy concerns: indeed, DSOs have now access to a precise electricity consumption over time, which may raise some privacy concerns. And, if the infrastructure evolves in a way that even more information is transferred to the DSO, e.g., with a per‐device monitoring, such a situation is unlikely to be accepted by users. On the contrary, they should decide which entity (if any) to trust with those data and at which granularity level.

Third, we envision some interoperability issues:

all the gathered data, which we recall are mainly used for billing and planning purposes, are very sensitive. Therefore, DSOs will not likely let users, other organizations, or entities manipulate them. Consequently, the AMI is currently a closed network where there is no interconnection with other systems and architectures – resulting in a situation where users can only visualize their data. This missing interconnection limits the possibilities to cross‐reference or use information coming from other systems. For instance, senior monitoring systems would be more accurate if health information could be crossed with electric information, and DSOs could benefit from having external information to better plan consumption or production.

Nevertheless, smart meters will probably embed more functionalities in the future, such as data storage and decision / management mechanisms. However, adding such capabilities will increase the cost to produce and deploy such meters. Therefore, DSOs will have to determine a business model that will push them into deploying such a costly new system. Although, this suggestion appears to be innovative, if there is not a significant gain for DSOs, these “smarter” smart meters will never be deployed.

8.2.2.1 IP‐Based Architecture Limitations

Energy and smart grids are potential application domains for IoT among others such as transportation, health care, or environmental monitoring. One issue of such an Internet‐based solution is that there are several ways to implement an architecture for an enhanced smart grid. In addition, there is not only one standard architecture, leading the standardization efforts to be scattered [15, 16]. Furthermore, energy‐related information is fragmented toward several standards and metrics, leading almost all smart appliances to be manufacturer specific. This diversity leads to a fragmented landscape of architecture models and isolated “silos” implementation . Interconnection of these silos is very difficult, if not impossible, as they often use their own architecture, models, and mechanisms – sometimes even between silos belonging to the same application domain.

Another concern with this type of solution is the lack of security around the deployed devices. Everything and everybody is now connected on the Internet, but not all of them are benevolent. In fact, as most IoT architectures are not mature enough, they do not include strong security mechanisms to protect underlying networks. As a result, connected devices are more and more targeted in order to break in private networks and user privacy².

Last but not least, there is no actual interconnections with utilities networks apart from a potential interaction with the centralized management system in order to realize demand response (DR) mechanisms. Nevertheless, enabling crossed information from both smart meters and smart appliances could greatly enhance smart grid systems.

8.2.3.1 Technical Issues for Next‐Generation Smart Grids

The number of smart objects is expected to explode in the near future [17]. Many of them will be electrical appliances, leveraging connectivity to provide daily‐life services to their owners and possibly to the grid (through load shedding or storage for instance). This plethora of smart devices will use different types of access technologies, protocols, and information formats. As a consequence, this next‐generation system should be flexible, adaptable, and dynamic and will enable automation.

In order to support scalability, this diversity of devices has to be handled locally. It will first lower the complexity of such system and then enable local management. However, smart meters currently deployed in the AMI have not been designed for managing and aggregating data on behalf of several appliances, nor for enabling such elaborated services – i.e., collecting input from users and from other devices/services in order to analyze data and control appliances.

8.2.3.2 Handing Back the Keys to the User: Energy Management Should Be Separated from the Smart Meter

We insist here on the distinction between the devices interacting with the user (to make decisions within its area) and the devices used by the utility to monitor and bill the area consumption, as well as inform about the grid demands.

In order to enable a more effective energy management, end users have to be more involved with respect to their data as well as to make decisions about energy usage. Their involvement should not anymore only be on a monitoring basis. They have to understand how they consume (and produce) and at the same time how they can act for both their own and the grid benefits. Therefore, they will be part of local decision making regarding the balance of their own consumption and production, and/or at the same time they could participate in the balance optimization of the whole grid by shifting, postponing, or switching off their appliances upon request. Therefore, the next‐generation smart grid architecture should provide users with the proper tools to control both their data and energy usage.

In order to realize all these actions, a dedicated management equipment is required. The smart meter could play this role if it can be equipped with new functionalities (storage, analysis, and user interactions). However, as previously mentioned, this will initially be more costly for the DSO and also implies that the user could possibly alter the functioning of the smart meter through interactions. Let us recall that the main purpose of smart meters is to ensure billing and planning for utilities; it is therefore not acceptable to affect the communications with the utility management center. For these reasons, it is very unlikely that the smart meter would act as a local EMS in the future.

On the contrary, it is more probable to see users acquiring an independent EMS in order to have access to energy services. Smart meters would still be in use, first by the DSO to monitor, bill, and send grid‐related requests (consumption reduction or increase, load shifting) and furthermore, by the EMS in order to be aware of the site global consumption and possibly to share certain data with the DSO (e.g., consumption forecast). In any case, the per‐device decisions should be left to the EMS, either directly operated by the user or by a specific service provider.

This may enable new open markets for energy management in which the users should be able to choose who will get access to their detailed energy data as well as control of their smart appliances. Similarly, the users should be free to decide whether to let a third party manage their consumption/production and if positive, to select one. Switching among “energy management service providers” should be simple enough so that market competition would lead to a desirable outcome.

8.2.3.3 To Build an Open Market, Use an Open Network

As previously stated, the communication network used for energy management should be adaptive, dynamic, flexible, and easily accessible to allow fair competition. The Internet naturally appears as a good candidate as it is built on open standards that provide almost all these features while adapting to smart grid applications through various IoT standardization efforts. The openness of the Internet and its standards seem preferable than letting energy operators define proprietary networks and protocols. The latter approach might potentially lead to several isolated platforms with few potential interconnections. With the use of the right tools, the Internet will provide all the required flexibility to handle a large volume of distributed consumption and production points.

As a result, the next‐generation smart grid core network should be decentralized and mainly focus on ensuring the interconnection of these end points, while the intelligence should be distributed toward appliances, equipment, systems, and aggregating units, as we will detail in the following subsection.

8.2.3.4 Multi‐Level Aggregation

In this next‐generation model, an EMS can aggregate data from different devices of a given site. Communications between EMS and appliances are based on the IoT concept, which specified that all devices must be uniquely identified. An EMS can therefore analyze and process collected data, which results in making decisions and controlling corresponding devices . The same principle could be performed at different levels (a set of EMSs could be managed by another one). Actually, using Internet‐based technologies (such as peer‐to‐peer tools) simplifies the communication between different EMSs. As a result, it allows to define several types of aggregation levels, corresponding to different scales for the appliance management grain as well as for global energy balance and economic relationships.

For instance, a hierarchical and geographical aggregation can be defined, where several individual users from the same area gather to form a microgrid. At the individual site level, a fine‐grained management can be parameterized, along with an EMS, and accordingly to each individual's preferences. These different sites – with potential storage and/or production capabilities – coordinate themselves and simultaneously provide their general energy information to an EMS taking care of this microgrid. At the end, this smaller grid is seen as a single entity to the rest of the grid. The microgrid EMS manages lower‐level EMSs. It might receive demands from the grid and determine if and how it can satisfy them, using available storages within the microgrid or in turn sending demands to lower EMSs. Nevertheless, the shedding potential of this sites' gathering is more important than each individual site.

Another example is to define an aggregation of appliances belonging to different sites. In fact, controlling one appliance may not be significant at the grid level. However, remotely aggregating the flexibility supply from many appliances offers a great potential – e.g., with a fleet of EVs.

The IoT paradigm is therefore allowing to gather all devices, from different areas but with similar behavior. These aggregation mechanisms offer more significant potential than what each individual could offer. Such next‐generation grid communication systems are encouraging the emergence of FOs that sell negative energy (also called “negawatts”) – i.e., selling flexibility in consumption, load shedding capacity, or vehicle‐to‐grid transfer system [5]. Additionally, an open network simplifies the operation of new markets, since the layered structure of the Internet allows to create new services upon existing ones. Actually, the proper incentives can be computed based on the available data and transmitted to actors at each envisioned scale.

Therefore, the main elements for such model are the EMSs that have data storage, analysis, and management capabilities as well as decision and control functionalities. They rely on available smart appliances and smart meter data in order to efficiently optimize the energy balance of their managed group. The same communication technologies listed in Table 8.1 can still be implemented. However, peer‐to‐peer communication as well as shared directories will be required to ensure an efficient coordination of these elements while reducing the risks of a single point of failure affecting the system.

8.2.3.5 Security Concerns

We also stress the importance of security required in such smart grid systems. While we still regularly observe new attacks occurring on the Internet, and recently targeting connected objects, the redundancy and resilience of the Internet, together with various improvements in Internet security, still make it the best candidate for smart grid applications. In fact, the Internet, and in particular the IoT, benefits from the efforts of many specialists as regards security issues [18].

In any case, this next‐generation system will be required to use the following building blocks for providing security:

• Authentication: identifying a node before letting it access the system;
• Authorization: process to determine if a node has the authorization to perform certain tasks;
• Access control: ensuring that a node can access certain resources (data and/or devices).

For instance, these mechanisms should help the system ensure that a given third party is really who it claims to be, that it can interconnect with other parties of the system, and perhaps, that it can access data from a given EMS.

8.2.3.6 Ongoing Research Efforts

Research efforts are required in order to study, standardize and test such next‐generation smart grid communication systems. Before being adopted, they have to demonstrate their benefits and above all that they are considered secure for both the end users and utilities.

In the IoT paradigm, several groups are trying to standardize a common IoT architecture. Standardization and uniformity are required in order to be able to collect information from different application domains and cross them in order to enhance the system. For instance, machine learning can be used to determine predictive information based on gathered data. But, as aforementioned, the IoT landscape is currently fragmented, and standardization efforts are scattered. As a matter of fact, most of the IoT architectures currently used are deployment‐specific and do not enable simple interconnection. In the following, we cite certain IoT architectures:

• oneM2M: A global organization composed of standardization bodies as well as industries. It was created to provide technical specifications addressing the need for a common architecture to connect the myriad of machine‐to‐machine (M2M) devices. oneM2M Functional Architecture [19] mainly focuses on the collection of data from field nodes and interconnection of M2M systems. This group is still active and have ongoing research on semantics, which should provide automation to their Functional Architecture. However, it does not plan to have end users interacting with end nodes.
• Internet of Things ‐ Architecture (IoT‐A): A European research project that aims at providing a reference architecture model for IoT applications and business. This project develops guidelines (common understanding, common grounding, standardized interfaces, and best practices) and a reference model for building compliant IoT solutions. The resulting Architecture Reference Model (ARM) [20] helps to build and interconnect systems. However, it carries on the silos model.
• Industrial Internet Consortium (IIC): An organization composed of several companies created to promote open standards and interoperability for technologies used in industrial and M2M environments. They designed an architecture, Industrial Internet Reference Architecture (IIRA) [21], enabling the set up of industrial IoT systems, which will be compatible and interoperable with other industrial systems. It is based on specific publish‐subscribe mechanisms that help the interconnection ensure reliability, performance, and scalability. However, IIRA supposes that all deployments have a centralized management domain.
• Smart Energy Aware Systems (SEAS): A European project aiming to provide the ICT tools to interconnect energy actors in order to better manage, coordinate, and optimize energy consumption, production, and storage. The proposed SEAS reference architecture model (S‐RAM) [22] derives from oneM2M and is based on distributed core services to interconnect both energy actors and management systems. These core services should take care of the following:
  1. – finding other parties in a simple way;
  2. – automatically learn from them using semantics;
  3. – ensuring security of the system;
  4. – ensuring monetary compensation for compliance to commitments.

  This model defines a way to divide the system in various groups, which therefore provides different management levels.

• Alliance for Internet of Things Innovation (AIOTI): An alliance initiated by the European Commission based on the observation that there was no common European IoT market. The aim of this alliance is to strengthen interaction among IoT players in Europe and to contribute to the creation of a dynamic European IoT ecosystem. In order to meet this target, they suggest to define a High Level Architecture ³, providing minimal requirements, using semantics, and compatible with previous architectures.

All the above approaches attempt to provide a common reference model for IoT‐related solutions, apart from SEAS, which is dedicated to the energy domain – but S‐RAM could be used for other application domains.

The next‐generation smart grid systems that would interconnect AMI with an Internet‐based communication network might probably rely on one of these architectures. The most promising solutions from the ones cited previously would be a) IoT‐A, but it will not provide the openness required to support open energy market; and b) SEAS, as it appears to provide all the required building blocks.

No matter which solution is chosen to support such next‐generation smart grid systems, it would have to demonstrate the advantages of such a complex system through research and test‐bed implementations. In the next part, we give more details on the communication framework and especially the routing part that nowadays allows smart meters to communicate with the utility center in an efficient and reliable way.

8.3.1.1 Proactive Routing Protocol

In proactive routing protocols, routes are built a priori, and as a result, all nodes in a network are aware of the routes to any destination at any time. Thus, a node may transmit a data packet to any destination with no delay, since all routes are stored in the routing tables. However, periodic routing‐related control packets need to be transmitted to maintain the routing table updated. Furthermore, to control the network overload, the periodicity of these control packets must be accurately defined.

RPL[26] is today the main protocol in the proactive family of routing protocols chosen in LLN. It is actually a distance vector routing protocol specified by the Internet Engineering Task Force (IETF) ROLL working group [27]. RPL is defined as link‐layer agnostic, so it can operate over wireless or PLC networks for example.

8.3.1.2 Topology Management under RPL

In a LLN, the topology is not predefined and, thus, RPL is in charge of discovering and carefully selecting nodes in order to construct optimal routes. The topology is organized based on a directed acyclic graphs (DAG), a graph where the connections between nodes have a direction and a non‐circular property. Based on the ”acyclic” nature of the DAG, the graph comprises at least one root, a node with no outgoing edge. In Figure 8.4 (a), a DAG composed of ten nodes and three DAG roots is illustrated. To construct a routing topology, RPL employs an extension of DAG: the destination oriented DAG (DODAG), which is similar to DAG with a single DAG root. In a smart grid scenario, the root of a RPL network could be the data concentrator that gathers the metering information. Figure 8.4 (b) depicts a DODAG topology that consists of eight nodes with one root.

To establish and maintain routes, RPL uses three different types of ICMPv6 control packets:

• DAG information object (DIO)
• DAG information solicitation (DIS)
• destination advertisement object (DAO)

The upward route construction, the one used between smart meters and the core network, is managed by transmitting DIO messages in multicast. DIO messages contain information that allows discovering a RPL instance, calculating its own rank and choosing parents in the DODAG. The rank contained in the DIO message is the rank of the node sending the DIO message and determines the relative position of a node in the DODAG. The rank is computed by the objective function using routing metrics, and its purpose is to avoid loops. The downward route construction, which is optional in RPL, is managed by the DAO messages to propagate information about the destination in the upward direction. To construct the downward routes, there are storing and non‐storing modes. Finally, DIS control packets are utilized to solicit a DIO message from a RPL node.

8.3.1.3 Routing Table Maintenance under RPL

As previously stated, DIO messages are periodically transmitted to build and maintain the RPL DODAG. However, if the network is stable, the DIO message frequency is decreased to reduce the overhead of signaling messages. On the contrary, if the condition of the network is not stable, more DIO messages have to be transmitted. This timing function is called trickle timer [28]. If a received DIO message does not imply any change on the receiver in terms of rank, parent set, or preferred parent, the DIO is considered consistent. As long as consistent messages are received, the interval between DIO messages is exponentially doubled to reduce the overhead of periodic messages. Conversely, when the network is not stable and DIO messages are inconsistent with the known topology, more DIS and DIO messages are needed to update the node routing tables. Messages such as multicast DIS without a solicited information option or DIO messages containing infinite rank are considered inconsistent and cause the trickle timer to reset, and the interval time is set to its minimum value. The trickle algorithm allows to be reactive in case of a change or failure in the network while minimizing the overhead when the network is stable.

For the downward route construction, a DelayDAO is sent to govern the emission of the DAO messages. At each transmission of a DAO message, a random interval is chosen before the actual transmission.

8.3.1.4 Routing Strategy: Metrics and Constraints

A metric in RPL is a quantitative value, and it is used to evaluate the path cost. Vasseur et al. (2012) [29] define two kinds of metrics that can be used for path calculation:

• the link metric, which concerns the link's attributes, e.g., link quality level (LQL), ETX, latency, and throughput; and
• the node metric, which takes into account the node state and attribute (NSA) such as energy (remaining energy, power source) or min‐hop (number of hops to the root).

RPL supports also a constraint‐based routing where the constraint may be applied on both link and nodes. If a link or a node does not satisfy a constraint, it is discarded from the parent set.

This constraint is used to include or eliminate a link or a node that does not meet a specific criterion. For instance, the objective function will not choose a path that traverses a node that is battery powered or a link with low ETX. The RPL objective function could combine metrics and constraints to compute the best path.

8.3.1.5 Path Computation under RPL

To compute the optimal path, the objective function plays a major role in the RPL protocol. To this aim, the two following algorithms have to be defined:

• the computation of the node's rank according to one or several metrics; and
• the parent selection operation according to metrics and constraints.

Two objective functions have been defined by the ROLL working group: objective function zero (OF0) and minimum rank with hysteresis objective function (MRHOF) and are presented next.

The Objective Function Zero

The OF0 [30] works by computing the rank based on the addition of a scalar, representing the link properties to the rank of the preferred parent. The scalar value is normalized between 1 and 9 for expressing the link properties, with 1 for excellent, and 9 for very poor. Note that any kind of metric could be used for the scalar value. This objective function allows to find the closest grounded root (a root that offers connectivity to the application goal) by selecting a preferred parent and a backup successor if available.

The rank computation is given by the algorithm below:

(8.1)

(8.2)

where:

• R(P) is the preferred parent's rank
• Sp (the step_of_rank), Sr (stretch_of_rank), and Rf (rank_factor) are respectively the expression of the link properties normalized between 1 and 9, the maximum augmentation to the step_of_rank of a preferred parent to allow the selection of an additional feasible successor and a value used to increase the importance of the link properties.
• MinHopRankIncrease is a multiplying factor that plays a major role in the rank computation by reflecting the impact of the metric on the rank increase. The default value is 256, as it is described in[26].

OF0 parent selection is governed by several rules (see Section of [30]), but the most important is that the selected parent must be the one that causes the lesser resulting rank for the node. This selected parent becomes the “preferred” parent.

The Minimum Rank Hysteresis Objective Function

MRHOF [31] optimizes the path to the root that minimizes a defined metric. However, it avoids changing this path frequently. Light metrics variations cause changes in the network that are decreased by introducing a hysteresis. MRHOF works with additive metrics and introduces the path cost for the rank computation, which specifies the property of the path to the root regarding the employed metric. The path cost is calculated by the sum of the path cost advertised by the parent and the link metric cost to the parent.

The rank computation for MRHOF is given by the algorithm below:

(8.3)

(8.4)

where:

• is advertised by the parent and represents the pathcost of the parent; and
• link_cost is the cost associated with the parent's link regarding the selected metric.

MRHOF parent selection is governed by a hysteresis function given by the equation below where and are respectively the path cost to parent 1 and parent 2. PP is the selected parent designated as Preferred Parent, P1 is the current best parent, and P2 is a candidate parent.

(8.5)

where Threshold is the hysteresis function, i.e., the minimum difference between the cost of the path through the preferred parent and the cost path of a candidate parent to trigger the selection of a new preferred parent. This objective function allows for selection of the route toward the root with the lowest path cost, e.g., minimum hop counts if the hop‐count metric is used.

8.3.1.6 Summary of the RPL DODAG construction

Figure 8.5 shows an example of the upward route construction using the hop‐count metric. Once the trickle timer is expired, RPL root will broadcast a DIO message containing its rank. Nodes in the coverage area of the root (i.e., yellow circles) will receive the DIO message and process it. If the DIO message had been corrupted, it would have been discarded. Since the root is the sink of the network, nodes 1 and 2 can not be closer to the root, so they will add the root as their preferred parent and compute their rank. To test if a candidate neighbor is eligible to be a preferred parent, a node will verify if the rank contained in the received DIO message added to a RPL parametric value (min_hop_rank_increase) is less than its rank. Then node 1 and 2 will broadcast their own DIO message with their new computed rank. Note that since the root has a smaller rank than the one advertised in nodes 1 and 2 DIO messages, nodes 1 and 2 will not be considered as potential parents for the root. It is worth mentioning that ranks shown under node names in this example depend on the objective function, and values shown beside edges represent the link quality (i.e., ETX). The arrows between nodes represent the upward route, and when a node installed at least one of them, it is considered to have joined the DODAG. It has to be noted that a node may either stay silent and wait for a DIO message or it may send a DIS message during the initialization process.

8.3.1.7 Reactive Routing Protocol

In a reactive‐based routing protocol, routes are built and maintained only when they are requested, which means that there is no need to maintain a route if there is no traffic. Thus, a delay is added before transmitting a data packet due to the route construction. Contrary to proactive protocols, reactive protocols do not need to send routing information periodically and, thus, will require less energy or CPU resources. However, the quantity of routing messages will greatly depend on the frequency of the traffic in the network.

8.3.1.8 Topology Management under AODV

AODV [32] is a well‐known reactive routing protocol designed for use in mobile ad hoc networks (MANET). It floods the network with broadcast route‐request messages when a needed route that does not exist.

To establish and maintain routes, AODV uses five types of messages:

• RREQ: route request
• RREP: route reply
• RERR: route error
• RREP‐ACK: route reply acknowledgment
• HELLO: link status monitoring

When a source node expects to establish a route to a destination, it broadcasts a RREQ packet. Once the destination is reached (or an intermediate node that knows the route to the destination is reached), a RREP message is sent back to the RREQ sender, which ends the route discovery process. If a RREP message is received, the route discovery operation is over. Otherwise, after certain period, it repeats the RREQ message and increases the waiting period. If there is no RREP message, this process can be repeated several times (by default, RREQ_RETRIES = 2). If there is still no response after three attempts, the route search process is aborted. Consequently, a new route request will be initiated after ten seconds. A node receiving a RREQ packet will send a RREP (route reply) packet if it is the destination or if it has a route to the destination with a sequence number greater or equal to the RREQ packet; otherwise, it rebroadcasts the RREQ packet. Each node keeps a trace of the source IPs and the identifiers of the RREQ packets. In case of receiving a RREQ packet that they have already processed, they delete it.

Once the source has received the RREP packets, it can start sending data packets to the destination. If the source subsequently receives a RREP containing a higher or equal sequence number but with a smaller number of hops, it will update its routing information to that destination and start using the best route. A route is maintained as long as it continues to be active, in other words, as long as data traverse between the source and the destination. The link expires when there is no more data in transit on the link and after a predefined delay. If the link is cut, the end node sends a RERR (route error) packet to the source node to warn that the destination is currently unreachable. If the source node still wants to get a route to that destination, it must start the route discovery process again.

Concerning the routing table, each entry contains nine fields. In addition to IP address of the destination node, the fields contain routing information and information related to the qualitative state of the route for maintenance purposes. Unlike other protocols, AODV only maintains information about the next hop in the route, not the entire routing list. This saves memory and decreases overhead for route maintenance. The routing table also contains information enabling the host to share information with other nodes when link states change. To ensure the information is the latest one available in the route table entry, a sequence number for the IP address is included in the message. This sequence number is called the “destination sequence number.” It is updated each time a node receives a RRER, RREP, or RREQ message.

To offer connectivity information, nodes that are part of an active route can broadcast local Hello messages. Every HELLO_INTERVAL, the node will check if it has sent a broadcast message during the last interval, and if it has not, it will broadcast a RREP message with a TTL set to 1. Within a dedicated period, if a node that has received a Hello message from a neighbor does not receive any packet from that neighbor, the node will assume the link is lost and will send a RRER route error message. Figure 8.6 shows a route search on the initiative of the node A in the direction of J. The RREQ message is broadcast from node A to all its neighbors. When node G receives the message, it returns a RREP message to node A through node E.

• The RREQ route request message is sent to search for available routes; it is made of frame size in length.
• The RREP route response to demand message is sent to indicate available routes to the originator of the demand; the frame consists of .
• The RRER is sent to report routes with potential errors to the originator of the demand; it consists of .

A route reply acknowledgment (RREP‐ACK) message is sent in response to a RREP message with the ‘A’ bit set to 1 when there is danger of unidirectional links preventing the completion of a route discovery cycle. It indicates that another available route is already used.

8.3.2.1 Performance Evaluation

As LOAD and RPL are both specifically designed for LLN, hereafter, we will present a performance evaluation comparison of these two protocols, Table 8.2 summarize their specificities.

Comparing RPL and LOAD will mainly depend on the topology (e.g., density). In a stable network, the round‐trip time for a data request (i.e., end‐to‐end delay) will tend to be better with RPL, due to the time needed to build the path using the LOAD RREQ message. Thus, thanks to the trickle timer, RPL will decrease significantly the control traffic as long as the network stays stable. When the condition of the network evolves unexpectedly (i.e., a node loses its parent, a path cost changes), RPL will reset the trickle timer and send more DIO messages to recompute the DODAG. This explains the additional control traffic in RPL, and may result in a broadcast storm, caused by the issue of DIO messages with increased DODAG version number (global repair). A global repair of the DODAG is triggered by the root. It re‐computes the DODAG and increases the end‐to‐end delay where LOAD will be less affected by the network variation. In smart grid applications, end‐to‐end delay tolerance could vary from below 10 to more than two seconds (e.g., smart meter reading). On the other hand, a teleprotection, for instance, which ensures the protection of network equipment from severe damage by managing the grid load, requires fast signals to pilot protective relays: no more than 10 [33]. Figure 8.8 shows the end-to-end delay comparison between LOAD and RPL under different smart grid scenarios.

Since in LLNs, nodes have constrained memory, smart meters will only store a dozen entries, whereas the routing table usually contains hundred of thousands of routes in IP core routers. As a consequence of flooding, each smart meter in a LOAD network receiving a RREQ message will install a route toward the sender, resulting in a large number of unnecessary routing entries. The same issue occurs when a node is situated on a route of a RREP message. On the contrary, most routers in RPL network have the default entry toward the preferred parent. However, when RPL operates in storing‐mode, nodes that are chosen as preferred parent have to store the downward route and may cause critical issues such as loops, in case a node runs out of energy.

Concerning the path efficiency, since RPL computes a DODAG from a sub‐topology of the physical network, the traffic has to follow paths along the DODAG even if a more optimal path exists in the physical world. Those protocols produce a sub‐optimal solution, which can be improved by carefully selecting parameters for the metrics used to arbitrate the chosen links. For instance, LOAD uses the LQI (link quality indicator) of the 6LoWPAN physical layer in addition to the Hop distance.

Figure 8.9 shows the root data delivery ratio of a 100‐node topology for RPL and LOAD, respectively, after two hours of simulation. As the traffic is set to start when the simulation initiates, RPL demonstrates additional delay before the actual data packet reception. However, RPL attains high performance once the DODAG is established. Concerning LOAD, results indicate that data is received quickly once the network is initiated; however, it takes time for LOAD to reach the same DDR as RPL.

In RPL, packets are sent only after the DODAG is constructed. Thus, if the metric chosen for constructing the DODAG is hop count, then RPL will compute a DODAG with minimum hops. Due to the flooding mechanism of LOAD, nodes construct the path using the first RREP message arrived, which is not necessarily the optimal one in terms of hops. The packet will follow a non‐optimal route until subsequent RREP message reception to update the path.

In terms of overhead, differences between the protocols will mainly depend on the implementation and employed parameters. The stability of the network has a significant impact on RPL protocol, since its parameters should be carefully selected to handle specific network circumstances. In LOAD, route hold time (RHT) will greatly impact the frequency of the flooding and, consequently, will increase the overhead. The number of nodes in the network is also critical in LOAD since high density in the network will increase the overall overhead. In RPL, we expect the maximum overhead at the beginning of the DODAG construction and then a reduction as the network becomes stable, due to the behavior of the trickle algorithm.

8.3.2.2 Summary on Routing Protocols

Choosing between reactive and proactive routing protocols in a smart grid network depends on multiple factors. The application, which identifies the type of traffic, has a major role in choosing the routing protocol and its corresponding parameters. Several parameters will also depend on the density of smart meters and the type of topology, i.e., number of maximum hops to the root. Furthermore, the priority of the traffic has an impact on the routing strategy as well, i.e., if the application is tolerant to high end‐to‐end delay. However, each protocol has different implementation issues attaining, thus, different performances. As a result, several parameters need to be properly configured in order to satisfy the requirements of the considered network and application.

RPL, for instance, is known to work well in multi‐point‐to‐point applications, a typical scenario in smart grid network, where data concentrators will receive the data from a large amount of smart meters in the NANs. LOADng address 6LoWPAN ad hoc on‐demand distance vector routing (LOAD) multi‐point‐to‐point issue and offer a similar performance to RPL at the cost of delay for the route discovery process. In a smart grid scenario, for typical monthly readings, the delay could not be a critical issue, so both protocols could be chosen depending on the acceptable overhead. The frequency of the traffic is also a major issue in smart grid networks, where a stable routing graph, such as RPL constantly maintained DODAG will greatly impact the delay at the cost of energy consumption. On the other hand, if the smart grid traffic is sparse, the need of maintaining a routing graph at the cost of high control traffic is not essential. For example, millions of smart meters using RPL have been installed in California mandated by the California Public Utilities Commission (CPUC) while French Enedis has chosen LOADng for the widely deployed Linky smart meters in France.

Furthermore, today smart grid devices have multiple heterogeneous communication interfaces, which leads to hybrid networks. Such a feature allows to enhance reliability and robustness by taking advantages of all available technologies (i.e., PLC and 802.15.4) [34].