1218 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO.
4, APRIL 2011
End-to-End Communication Architecture
for Smart Grids
Thilo Sauter, Senior Member, IEEE, and Maksim Lobashov
Abstract—Smart grids heavily depend on communication in
order to coordinate the generation, distribution, and consumption
of energy–even more so if distributed power plants based on
renewable energies are taken into account. Given the variety of
communication partners, a heterogeneous network infrastructure
consisting of IP-based and suitable field-level networks is the
most appropriate solution. This paper investigates such a two-tier
infrastructure and possible field-level networks with particular
attention to metering and supervisory control and data acquisition
applications. For the problem of network integration, a combi-
nation of gateway and tunneling solutions is proposed which al-
lows a semitransparent end-to-end connection between application
servers and field nodes. The feasibility of the approach and imple-
mentation details are discussed at the example of powerline com-
munication and IP-based networks investigated in the European
research project on real-time energy management via powerlines
and internet. Nevertheless, it is shown that the communication
architecture is versatile enough to serve as a generic solution for
smart grids.
Index Terms—Communication network, metering, powerline
communication, protocol tunneling, smart grid.
I. I NTRODUCTION
I N AN increasingly deregulated and distributed energy
market, communication between the points of energy gen-
eration, distribution, and consumption becomes an essential
constituent of efficient grid control. The traditional approach of
controlling power production by means of a few large power
plants is less viable if a critical mass of small, distributed
power plants have to be taken into account, even more so when
renewable sources like solar and wind energy are considered
on a larger scale [1]. These latter depend on the availability
of natural resources that cannot be controlled. If renewable
energies are to play a bigger role—as intended by the Euro-
pean Union and other policy makers—rapid and unexpected
changes in power generation become problematic. Wind power,
for example, can vary between zero and rated power during
15 min, which can yield variations in the range of several
Manuscript received August 27, 2009; revised December 9, 2009 and
February 25, 2010; accepted April 20, 2010. Date of publication August 30,
2010; date of current version March 11, 2011. This work was supported in part
by the European Regional Development Fund, the province of Lower Austria,
and the European Commission under the DLC+VIT4IP project.
T. Sauter is with the Institute for Integrated Sensor Systems, Austrian Acad-
emy of Sciences, 2700 Wiener Neustadt, Austria, and also with the Institute of
Computer Technology, Vienna University of Technology, 1040 Vienna, Austria
(e-mail: thilo.sauter@oeaw.ac.at).
M. Lobashov is an independent consultant residing in Kaiserstraße 40, 1070
Wien, Austria (e-mail: maksim.lobashov@ibml.at).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TIE.2010.2070771
0278-0046/$26.00 © 2010 IEEE
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
Gigawatts depending on the installed capacity [2]. Such a
situation can be alleviated if many small, distributed power
plants can be combined to a virtual power plant. This, however,
necessitates appropriate control strategies on a local scale [3]
and suitable means of communication to exchange information
and coordinate the actions of the participants [2].
On the other side of the power distribution grid, the load
peaks generated by consumers during the day are a critical
issue because they demand the existence of quick and available
power reserves. One goal of energy management should
therefore be the utmost reduction of such peaks. This can be
achieved in various ways, such as real-time pricing where the
energy prices depend on the actual demand. Today, this is only
realized for large industries, which get their power directly
from the wholesale market. Smaller industries and households
are lagging behind.
The other possibility to reduce load peaks is demand side
management, where consumers regulate their consumption on
a relatively fine-grained appliance basis by appropriate schedul-
ing of run times or by exploiting (mostly thermal) energy stor-
age capabilities of individual application domains such as air
conditioning systems, heating, refrigerators, hot water genera-
tor systems, or–on a larger scale–heat stations. Combined with
load-dependent pricing strategies, such peak-avoiding energy
management will also be financially attractive for the customer.
All these concepts rely on a significant amount of commu-
nication in order to function properly [2], [4], [5]. Specifically,
energy consumption must be measured, energy provision must
be controlled, and the distribution grid must be monitored and
adjusted according to the power flows [6]. On the technical side,
this requires reliable communication between energy meters,
substation controllers, power plant control rooms, and data
acquisition centers for planning and billing. On the organi-
zational side, the communication partners are the customers,
utility companies providing the energy, and grid operators. The
communication relationships are not necessarily peer-to-peer
(this could be relevant for low-level demand side management).
Rather, a multiclient/multiserver scenario is realistic, where
a group of possibly unrelated server operators retrieves and
changes data on clients distributed in the field.
Communication architectures that can meet the needs of
smart grids are not straightforward, and the selection of suitable
communication technologies is subject to many technical, legal,
and strategic restrictions. It appears, however, that a two-tier
architecture consisting of an IP-based backbone technology and
an adequate field-level network can meet the needs fairly well.
The purpose of this paper is to investigate this further. Section II
will discuss the specific needs for communication infrastruc-
tures imposed by advanced grid and energy management
 SAUTER AND LOBASHOV: END-TO-END COMMUNICATION ARCHITECTURE FOR SMART GRIDS
concepts; whereas, Sections III and IV analyze possible so-
lutions for the general architecture and field-level networks,
respectively. The solution proposed in Sections V–VIII focuses
on powerline communication on the lower level and was de-
veloped within the scope of the EU-funded research project
on real-time energy management via powerlines and Internet
(REMPLI). Section IX presents some results from a field test,
and Section X provides conclusions.
II. R EQUIREMENTS FOR THE C OMMUNICATION S YSTEM
Communication networks suitable for energy management
applications—even in a loose sense—need to provide distinct
qualities and services which are closely related to application
requirements and distinguish them from other networks.
1) High reliability and availability are standard require-
ments for nearly every communication system. Nodes
should be reachable under all circumstances. While this
is normally not a problem in a wired network, it may
be challenging for wireless or powerline infrastructures
because communication channels can change during op-
eration. In the particular case of powerline systems, such
a change may be introduced by distribution network
management which balances the power consumption load
on the power grid, particularly on the medium-voltage
(MV) level. Switching actions are initiated via various
supervisory control and data acquisition (SCADA) and
controlling systems (or even manually) using specific
communication protocols that may not be modified.
Therefore, there is no straightforward way to simply
inform the communication system management about
topology changes that are about to occur. Rather, the com-
munication system itself must be designed for robustness.
If distribution network management switches a secondary
transformer station from primary station A to primary
station B, a request and response to and from the node
may have to go via primary station A, the confirmation
already via primary station B.
2) Automatic management of redundanciesis closely related
to the previous requirement. As some applications are
time critical, real-time properties of the network have to
be maintained even during topology changes. As stated
before, such changes must not be regarded as exceptional
situations due to error conditions but occur in normal
operation.
3) High coverage and distances. Evidently, the nodes to be
connected by the communication network are distributed
in a wide area. Network concepts based on telecommuni-
cation systems or powerlines have the potential to fulfill
this requirement.
4) Large number of communication nodes. If we assume
that only one energy meter per customer is connected,
a primary station can supply up to tens of thousands of
nodes, particularly in areas of large apartment block con-
centration. Even though the commands and data packets
are usually short, total data volume to be transferred in
the network is substantial, and communication overheads
can become an issue.
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
1219
5) Appropriate communication delay and system respon-
siveness. The Quality-of-Service (QoS) management
needs to take care of different data classes such as me-
tering, control, or alarm data. Even if the predominant
communication relationship is client/server (i.e., an ap-
plication server polls the meter data or issues control
commands), it may be necessary to foresee something
like a fast event channel to transmit, e.g., alarms from the
meters to the control room.
6) Communication security. Data related to energy distri-
bution are considered critical, in particular, when they
are relevant for billing purposes or grid control. Secure
communication is therefore important. Surveys among
utilities showed that integrity (no malicious modification)
and authenticity (origin and access rights are guaranteed)
are the most important security goals for energy distrib-
ution networks, whereas the confidentiality aspect is not
considered to be an issue [7], [8].
7) Ease of deployment and maintenance. For any distributed
communication system, mechanisms must be foreseen
which facilitate not only the initial installation but par-
ticularly the maintenance of the infrastructure during the
operation. Features like error mode analysis and error
localization, easy update of firm- and software and remote
configuration are essential.
III. N ETWORK T OPOLOGIES AND
C OMMUNICATION A RCHITECTURES
A communication system for a distribution network will
preferably have a generic two-tier architecture as depicted in
Fig. 1. The mostly centralized high-level equipment such as
back-office application servers used for metering and billing
purposes but also add-on services, possibly offered by third
parties, is exclusively used in an IP-based environment like
a company intranet or a wide area network, often based on
fiber optical networks [9]–[11]. The distributed communication
entities in the lower level of the communication system such
as energy meters, switch gears, or control equipment need
to be connected by an appropriate field-level network. The
interconnection of the two network domains is achieved by
network elements we denote in the following as Access Points
(APs). This term must not be mixed up with the APs used in
wireless networks; it just describes the fact that these network
elements permit the higher network level to access data and
services of the lower level.
While the basic communication architecture is rather
straightforward, the actual network topologies can be very
diverse and depend mostly on the field-level network. With
respect to the communication requirements, several options
are possible [1], [10]–[12] which are summarized in Table I.
Classical wired communication with dedicated data networks
connecting the field devices is one possibility. In such a sce-
nario, the APs would typically be located close to the field
devices in the last transformer station (provided that it can be
reached via the IP-based network), and the cable would bridge
the last mile. Dedicated wired data networks can be designed
to fulfill all requirements, but the installation costs do not
 1220
Fig. 1. Principle two-level communication architecture for energy distribution
networks.
TABLE I
F IELD -L EVEL N ETWORK T ECHNOLOGIES FOR S MART G RIDS
permit an intensive use [13]. A less expensive option is wireless
networks. Technologies for wireless local area networks or
personal area networks like IEEE 802.15.4 can, in principle, be
used as a replacement for wired links in the scenario mentioned
above [14], [15]. Their inherent problem is the limited range
which would require the AP to be very close to the end devices
(thus increasing the number of APs) or an additional network
level (sometimes called neighborhood area network) to bridge
the distance to more centralized APs.
A more promising wireless alternative is cellular networks
as used in telecommunications, like global system for mo-
bile communications (GSM) or general packet radio service
(GPRS), or worldwide interoperability for microwave access
(WiMAX). They have high coverage and low installation costs
for the end devices if the infrastructure already exists [13]. The
downside is the general dependency on the network provider
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO. 4, APRIL 2011
if public telecommunication networks are used–regarding both
costs for the communication channels and quality of service. In
this scenario, the AP would be located close to the application
servers in the IT infrastructure, e.g., the utility company.
The third possibility which is increasingly attracting interest
is powerline communication systems [15]–[19]. They use the
existing power cabling and need only moderate additional
network elements but require a more complex technology in
order to overcome the rather poor communication channel
characteristics. Regarding the network topology, the AP can be
located anywhere in the power grid, but a likely position is on
the MV level in the primary substation.
Technological aspects are just one criterion affecting the se-
lection of communication architectures. In deregulated markets,
ownership of equipment, infrastructure, and services is distrib-
uted among different business entities, which also affects the
communication system in a smart grid. Fig. 1 shows possible
ownership structures for the components of a communication
network. The end points of a communication channel, i.e.,
application servers and field devices, are usually in the hands of
one company. The communication channel as such, however,
may be provided by some third party. In the case of cellular
networks, this could be a telecommunication provider. In the
case of powerline networks, this could be the grid operator who
may be independent from the utility. Furthermore, there might
be add-on service providers needing access to communication
resources as well. The system architecture should therefore
allow for a clear separation of communication channels.
Having control over the communication system can also be a
strategic issue for a grid operator. This speaks against public
telecommunication networks because the required quality of
service, e.g., in the case of emergencies, may not be avail-
able or associated with high costs [20]. To cope with such
reliability problems, grid operators can establish their own
cellular network infrastructure [12] (apart from GSM/GPRS,
WiMAX or terrestrial trunked radio could be an option) or
use the resources they have at hand, anyway. This is why
powerline communication (PLC) systems are an interesting
though challenging possibility and have been employed in the
investigation discussed subsequently.
Fig. 2 shows the communication network architecture de-
veloped in the European research project REMPLI [16] that
will be described in detail in the following sections. The main
goal of the communication system is to interconnect application
servers on the one side and field-level equipment on the other,
with the constraint of supporting already existing standardized
SCADA or metering protocols such as IEC 60870, IEC 62056
(formerly known as IEC 1107), and EN 1434-3 [known as
Message Bus (Meter-Bus)].
Since many of these protocols expect simple serial interfaces,
a particular challenge lies in mimicking serial communication
links across a network. The characteristics of the powerline
network do not allow implementing a general purpose “byte-
transparent” virtual serial link over the PLC efficiently (cf.
Section IV-B). However, given the knowledge of protocols used
by the application servers, the system can emulate the behavior
of the serial line such that neither protocols nor application
servers need to be modified.
 SAUTER AND LOBASHOV: END-TO-END COMMUNICATION ARCHITECTURE FOR SMART GRIDS
Fig. 2. Powerline- and IP-based communication architecture for smart grids
used in the REMPLI project. The dotted lines indicate possible communication
paths through the grid.
As discussed before, the application servers are linked via
a private IP-based network to a layer of APs. They form the
interface to the powerline at the MV grid level and may also
exploit the fact that there might be several possibilities to reach
a given node via the power grid. In this case, they can relay a
message between each other in order to use the best route to the
field level.
From the APs onward, the messages are transferred via
the powerline communication system, which in itself is a
complex network using specialized protocols. Long messages
are being fragmented and routed via intermediate network
components–Bridges and Repeaters. Bridges at the medium-to-
low voltage (MV/LV) transformer stations provide transparent
data connection between the LV and MV powerlines. From
there, the data are transmitted over the LV powerline network
to the Nodes. If distances are too long, Repeaters (not shown
in Fig. 2) may be employed to ensure signal quality and
connectivity. The Nodes ultimately connect various field-level
equipment such as utility meters or SCADA equipment and,
thus, make them accessible to the application servers.
IV. ACHIEVING E ND - TO -E ND C OMMUNICATION
As outlined in the introduction, the predominant communi-
cation relationship in smart grids is the multiclient/ multiserver
scenario, where communication channels are needed between
applications (primarily SCADA and metering software) and
corresponding field hardware (sensors, switch gear, energy me-
ters) in an end-to-end fashion. In many installations, application
server and field hardware, software, and protocols already exist
as standards that should be reused. Therefore, the network
must be able to handle several applications and, respectively,
communication protocols in parallel. Naturally, not all of these
protocols can be directly considered during the design phase.
Rather, the communication architecture must be open to allow
for an easy integration of further protocols in the future.
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
1221
Fig. 3. Protocol transitions in a gateway.
A common approach advocated by many authors today is to
use TCP/IP (usually based on IPv6 to cope with the address
space limitation problem) as a consistent network layer in order
to achieve end-to-end communication [10], [14], [19]. This is
appealing in theory but requires sufficient performance in all
parts of the network because the nature of TCP and some
common application protocols above it impose a number of
requirements on the lower layers of the protocol stack. In par-
ticular, TCP implicitly assumes that IP packets can be emitted
at arbitrary points in time in a peer-to-peer fashion without
any adherence to the properties of the underlying medium.
This behavior is difficult to support in large-scale narrowband
powerline networks, where often a master/slave communication
style is adopted (this is also the case in the example considered
here). Transmitting IP packets from the master to the slave is
not overly problematic because the master can, in principle,
initiate data transmission at any time. The reverse direction (i.e.,
when the slave wants to initiate a data transfer) is, however,
more difficult. With a large number of slaves, it may take very
long until the slave is ultimately polled by the master for its data
[18]. The resulting timing characteristics of the network may be
unacceptable for applications needing fast responses.
Furthermore, most of the currently used metering and
SCADA protocols are not based on user datagram protocol
(UDP)/TCP/IP but on a simple request/response scheme with
own addressing, originally designed to run over raw serial com-
munication channels often operating in a master/slave mode.
Encapsulating such protocols in TCP/IP, though possible in
principle, generates an overhead without additional benefit and,
thus, was deliberately not considered.
A. Pros and Cons of a Gateway Approach
If a common and transparent network layer is not feasible,
interconnection could be based on the gateway approach which
is widely used in vertical integration of automation networks
[21], [22]. In this case, the AP would convert the backbone
protocol into one which could be designed to ideally match the
properties of the lower PLC layers in terms of packet sizes,
timings, and communication services of the PLC stack. The
Node would need to convert the protocol back to the original
one to get the end-to-end connectivity on the application level
(Fig. 3). Alternatively, an asymmetric conversion would be
possible, such that, for instance, a single IEC 1107 (IEC 62056)
metering application can be used to retrieve data from all meters
in the field- not only IEC 1107 but also M-Bus, device language
message specification (DLMS), and others. In the SCADA
 1222
domain, one could use, e.g., object linking and embedding for
process control [23] to control all field devices.
The most essential problem with the gateway approach is that
although metering and SCADA applications use standardized
protocols, standardization is rather loose. General frame for-
mats, command and response codes and protocol procedures
(handshakes etc.) are usually well defined in the respective
standards and implemented by the equipment vendors in the
same way. The format and semantics of data, transmitted within
these frames are, however, often manufacturer-specific. The
IEC 1107 presents an obvious example: At the basic level
(reading the current billing list), a metering application from
one manufacturer is able to communicate with meters from
another. More sophisticated transactions (meter configuration,
load profile read-out) require using a software application from
the same vendor as the meter itself. Under these circumstances,
it would be necessary to implement a protocol conversion
module not just for every supported protocol but for every
manufacturer or even hardware model. This raises also certi-
fication difficulties. For certain applications, such as billing,
manipulation of data is allowed only with certified modules.
This would mean that each new protocol conversion module for
the gateway needed to be certified anew, which is economically
infeasible. These problems ultimately make the gateway ap-
proach unsuitable for smart grid communication architectures,
and the tunneling concept must be the method of choice.
B. Semitransparent Tunneling
As stated above, many, if not most, protocols currently used
in the metering and SCADA domains were originally designed
to run over a serial line—either in the point-to-point (RS-232)
or in the multidrop (RS-485) mode. The natural solution to
tunnel these protocols is to offer a “virtual serial cable” between
the application and the field hardware. This is comparatively
straightforward if circuit-switching networks (like plain old
telephone service or GSM) are used which establish an indi-
vidual communication channel per field device. With packet-
oriented networks using shared media—such as PLC—things
are different from the serial cable.
1) The field-level network introduces its own addressing
scheme. Different application protocols use their own
way of addressing devices on the bus. These addresses
cannot be used directly to address field devices like
PLC Nodes. Establishing virtual connections between the
application and the target device similar to telecommuni-
cation channels is undesired due to the large number of
devices resulting in very high overhead.
2) Timings in field-level networks are very different from
those of a direct serial line and—as discussed before—
likely asymmetric (in particular, in master/slave PLC
systems like the one used in REMPLI). Unless the system
dynamically adapts to currently ongoing protocol trans-
actions, or “hides” the timing issue from applications by
other means, this latency can break the communication.
In some cases, it is also necessary to emulate the keep-
alive service (if one is used by the application proto-
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO. 4, APRIL 2011
col), as the required timings cannot always be achieved
through the actual communication network.
3) Several application-layer protocols need to be supported
at the same time, with minimum or no coordination
between the applications. With dedicated RS-485 or
RS-232 lines, applications assume an ownership of the
bus. In case of a shared medium, this is no longer true. All
nonessential traffic, such as background link-layer polling
of remote terminal units in SCADA protocols, needs to
be suppressed in order to avoid wasting the available
bandwidth.
4) Serial line properties for RS-232 or RS-485, such as baud
rate, parity, flow control, etc., have no equivalent in case
of advanced field-level networks, including PLC. If an
application protocol depends on the correspondence of
these parameters above and below the field-level network,
their support needs to be emulated as well.
The above considerations do not make the provision of a
“clean” serial tunnel over the PLC network infeasible. How-
ever, as far as network efficiency with large number of devices
and multiple parallel applications is concerned, simple byte
forwarding is not sufficient.
C. Protocol Driver Concept
The approach adopted in REMPLI is a compromise between
a tunnel and a gateway [24]. Without attempting to modify or
analyze the semantics of the application-layer data, the system
still splits every transmitted protocol into individual protocol
data units (PDUs) and, knowing standard properties of each
protocol (frame formats at its different layers), converts, and
optimizes the protocol for transmission over the PLC network.
This is achieved by introducing special protocol-specific mod-
ules, called protocol drivers, into the system. One such driver
runs on the application side (at the AP); another one runs on
the field side (at every Node). Both AP and Nodes can run mul-
tiple drivers for different protocols in parallel. Communication
between different sets of drivers is isolated by the underlying
protocol stack.
The process of protocol conversion/optimization is fully
transparent to both applications and field devices. For instance,
large data sets (e.g., metering load profiles) can be compressed
by the Node driver and decompressed back before being passed
to the application at the AP.
Apart from the already mentioned emulation of the keepalive
service, a number of other measures have to be taken by the
protocol drivers to adapt different application protocols for
transmission over the PLC which go beyond pure protocol
encapsulation.
1) Address rewriting. A PLC network implements its own
application-independent addressing scheme. In case of
REMPLI, end devices are addressed by unique unstruc-
tured 32-bit integers. Application- or transport-layer ad-
dresses of the specific protocol are then translated into
the PLC addresses by protocol drivers. Depending on
the protocol, the actual transport and/or application layer
headers can be stripped before transmission and recon-
structed on the opposite side, as illustrated in Fig. 4. The
 SAUTER AND LOBASHOV: END-TO-END COMMUNICATION ARCHITECTURE FOR SMART GRIDS
Fig. 4. Protocol transitions in the “semitransparent tunnel” approach.
address translation does not need to be exactly symmetric
on the two sides of the network. For example, if only one
energy meter is connected to each PLC Node, all meters
can be preconfigured by the system integrator to have the
same metering protocol address. Address translation on
the AP side can, nevertheless, present all meters under
different metering protocol addresses to the application,
translating these into unique (PLC Node address, meter
address) pairs. This simplifies network commissioning.
2) QoS mapping. If the transmitted application protocol em-
beds quality of service parameters (e.g., PDU priorities),
these can be mapped onto packet priorities supported
by the PLC network (the REMPLI system allows up
to 127 priority levels). If the protocol does not support
QoS, priorities can be configured on a per-protocol or
per-PDU-type basis. For instance, one can configure the
system such that any SCADA traffic is transmitted ahead
of metering.
3) Communication service mapping. The basic transmission
services needed for the field level are “request” (trans-
mission from AP to Node) and “response” (Node to AP,
including the transmission of alarms). If the field-level
network, like in the case of PLC, has a master/slave na-
ture, transmitting request/response-based protocols over
these services can result in large response latencies,
particularly in networks with many slaves. In order to
improve system responsiveness, it is possible to exploit
knowledge of the fact that a response is expected (and,
in some cases, even the anticipated time of the response)
to adapt the polling cycle and deliver the response sig-
nificantly faster. Therefore, instead of implementing only
“request” and “response” services, the PLC system offers
a set of higher-level primitives for transmitting PDUs, like
request/response, request/no-response, alarm, or urgent
alarm. Each has a different behavior and is subject to
different timing-related optimizations. The task of the
driver is to choose a service appropriate for transmission
of a particular PDU, given the driver’s knowledge of the
application protocol and of the current application’s state.
4) Emulation of protocol features and further timing op-
timizations. Some protocol features, such as serial line
control or emulation of timing-critical handshake proce-
dures separately on the AP and Node sides, may require
additional out-of-band communication between protocol
drivers at the AP and Nodes. Such messages are never
passed to applications and devices and are used only for
internal signaling.
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
1223
V. REMPLI P ROTOCOL S TACK
The structure of the communication protocol stack, imple-
mented by APs and Nodes, is illustrated in Fig. 5. It must
be noted that the distribution of functionalities between dif-
ferent layers of the stack does not always match the standard
International Standards Organization/Open Systems Intercon-
nection model. This is mainly due to performance reasons:
combining certain functions within one layer allows achiev-
ing a higher degree of optimization. Specific properties of
the powerline network–such as complicated medium access
control spanning across several layers—have also affected the
model.
The powerline physical and data-link layers implement
the actual powerline coupling [25]. The network layer (NL)
provides a simple datagram-oriented communication in a
master/slave fashion with reliable delivery [26], [27]. In a PLC
network spanning multiple segments (LV, MV), the network
layer communication runs between devices in the same seg-
ment, handling dynamic routing between the master and slaves
over Repeaters. Each transmitted NL fragment is acknowledged
by the receiver. Bridges terminate the network layer from
both sides, thus the NL acknowledgement mechanism runs
separately on the AP-Bridge and Bridge-Node sides. The back-
ground polling of slaves for data, as well as the login/logout
procedures, is handled by the network layer as well.
The transport layer (TL) adds end-to-end communication
capability: from an AP through Bridges to the target Nodes
and backwards. In a meshed PLC network, this layer handles
the routing of messages through all available communication
paths, considering channel qualities reported by the network
layer [28]. While the network layer is only capable of transmit-
ting short packets (up to approximately 200 B), the transport
layer implements fragmentation and reassembly, significantly
increasing the maximum PDU length (up to 32 MB). It also
abstracts the communication system functionality at a higher
level than the NL, offering data transmission services such
as request/response, request/no-response, alarm, urgent alarm,
multicast, broadcast, etc. Finally, it handles most of the QoS
support in the stack. A deliberate decision in REMPLI was to
keep the communication services offered by the transport layer
datagram-oriented and not the connection-oriented services
since this solution provides a better efficiency for the tunneling
of SCADA and metering protocols.
The communication multiplexer/demultiplexer (de/mux)
module is the central component in the tunneling process. Its
upper interface is similar to that of the transport layer but
with one important difference: At the transport layer interface,
no distinction between different kinds of PDUs (and, respec-
tively, application protocols) is made. The de/mux actually
multiplexes streams of PDUs from different protocol drivers on
one side and separates them again on the other, isolating the
communication between different driver sets.
Every kind of protocol driver is associated with its own
unique identifier (driver ID) denoting the supported protocol
type. Drivers on the opposite sides of the network, responsible
for tunneling of the same protocol, register with their de/mux
instances using the same IDs. The de/mux ensures that a
 1224
Fig. 5. Communication structure for transmitting metering and SCADA protocols.
message sent by the driver with an ID N on the AP is delivered
to the driver with the same ID N on the Node and the other way
around. This concept is similar to the port numbers in TCP/IP
(or considering the datagram-oriented nature of communication
to UDP/IP ports).
Another function of the de/mux is the top-level routing
of messages in systems with several APs. Multiple APs are
required for redundancy reasons and, in switched PLC net-
works, to cover all possible communication paths in the upper
(MV) segment. A typical application connects to only one
AP (with the notable exception of those applications that can
handle redundant communication paths on their own, like many
SCADA systems do).
Finally, the de/mux implements cryptographic security ser-
vices (message authentication, encryption, and integrity verifi-
cation). Usage of these is optional; sending protocol drivers can
decide on a per-PDU basis, whether a particular security service
is to be applied.
Apart from the top-level routing performed by the de/mux,
error recovery in REMPLI is primarily covered by the PLC
layers. Using the acknowledgement mechanism mentioned be-
fore, the NL supports retries for fragment transmission, with an
upper limit for the number of retries in order to preserve latency
and bandwidth QoS. The TL adds end-to-end confirmations
for complete PDUs between senders and receivers on opposite
sides of the PLC network (APs and Nodes). Irresolvable errors
are forwarded to the protocol drivers to be dealt with at appli-
cation level.
Finally, the upper level of the stack is comprised of pro-
tocol driver modules, responsible for adapting particular pro-
tocols for the transmission over the PLC and providing a
semitransparent tunnel between the application and the field
hardware.
It is worth mentioning here that not all drivers in the system
are actually used to tunnel third-party application protocols.
On the one hand, applications designed to run exclusively on
top of the REMPLI network can extend their “protocol driver”
modules to handle the application logic, especially on the Node
side. For example, a Node driver within a dedicated PLC energy
meter would implement the complete metering functionality
instead of interfacing with external hardware. On the other
hand, special kinds of drivers exist that are not involved in the
transmission of application data. A “management driver,” for
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO. 4, APRIL 2011
example, is used to configure and monitor Nodes and to update
their software and firmware [29].
VI. M ESSAGE ROUTING AND D ELIVERY
The powerline network consists of a number of master/slave
segments (see also Fig. 2). Each AP is a master for a segment
with one or more Nodes and/or Bridges in it being slaves.
Every bridge—a device installed at the border between different
voltage levels—is also a master to the segment on the other
side of the transformer. With these linking devices, the pow-
erline communication is, therefore, mostly independent of the
energy flow in the grid. For redundancy, a segment can also
contain more than one master. Slaves can communicate with
all these masters in parallel, so that we have a meshed network
with multiple possible communication paths between any AP
and Node.
Routing and delivery of PDUs in this meshed network be-
tween the application and the Node consists of several steps,
each handled by a different layer of the protocol stack. Fig. 6
schematically illustrates the most common PDU transaction
type: the request/response service, consisting of a request PDU,
sent downwards (from application to a field device), and a
response PDU in the opposite direction.
The transaction starts with the application sending a PDU
to an AP driver (left side of the figure). The driver performs
necessary conversions of the PDU, as described in the above
sections, determines PLC addresses of the destination Nodes,
and submits the PDU to the de/multiplexer running at the
same AP.
The de/multiplexer verifies whether the target Node is known
to the local TL (this information is periodically made available
to the de/mux by the TL). It also checks whether the target Node
can be reached via another AP in the system (the information
on Node availability and the associated channel qualities is
periodically exchanged over TCP/IP between de/mux instances
running at different APs). The de/mux ultimately submits the
PDU either to the local TL or a TL running at another AP; such
rerouting is also implemented via IP and is transparent to the
applications which mostly connect to just one AP (see Fig. 2
for an example). A decision to route via another AP is made
if the destination Node cannot be reached from the given AP
directly, or if another AP provides a significantly better overall
 SAUTER AND LOBASHOV: END-TO-END COMMUNICATION ARCHITECTURE FOR SMART GRIDS 1225

Fig. 6. Request/response transaction.

channel quality to the Node. The channel quality is given by

the latency and packet loss of the respective powerline segment;
these parameters are continuously monitored.
The PDU is split into fragments and sent via the determined
route through the powerline to the target Node. Routing of
fragments within one PLC segment is a task of the NL. Noise
and transient disturbances on the PLC may prohibit direct
communication between the master and slave over large dis-
tances. Thus, the NL has to internally route the fragment
through one or more Repeaters. Above the NL, the segment is
still represented as a transparent master/slave network.
Once the request PDU is fully delivered to the Node, the TL
at the AP notifies the de/mux about this fact. The acknowl-
edgement includes a request/response ID (RRID), which can
be later used to identify the matching response. The de/mux
delivers this acknowledgement to the protocol driver that ini-
tiated the transaction (either locally or to another AP via IP).
Drivers at different sides of the network can open multiple
request/response transactions in parallel, provided that the field
device supports such mode of operation.
As PDU fragments reach the destination Node, they are
reassembled by the TL and passed to the target protocol driver
by the de/mux. Here, the request PDU is also associated with
Fig. 7. AP and Node architecture.
an RRID. Processing of the request is performed in a protocol-
and driver-specific manner; typically, the PDU is sent to the
field device, and a response is awaited. on the same device, TCP/IP allows unifying this interface with
Once the processing of the request is complete, the response others in the system and, if necessary, to easily distribute the
is sent backwards, along with the RRID previously received system load across different hosts. One channel (driver-de/mux
with the request. Routing of the PDU in the opposite direction and de/mux-transport layer) is always reserved for delivering
(from Node to AP) is similar to the above described, except that alarms and other spontaneous messages, including network
de/multiplexers at Nodes are not linked via IP and thus never management notifications (Node logged in/out, channel quality
reroute PDUs through each other. Ultimately, the response changed, and the like). In addition, multiple other channels can
with the original AP-side RRID is delivered to the originating be opened at the same time to handle regular request/response
protocol driver and sent to the application. transactions initiated by drivers (transmission of request and
response messages between AP and Nodes). For each channel
opened by a driver, the de/mux allocates a separate channel
VII. AP S AND N ODES
from a connection pool on its opposite side (to the transport
The internal design of APs and Nodes is shown in Fig. 7. layer). Therefore, PDUs from/to drivers are sent and received
Bridges have a similar architecture but without the upper two in parallel; the serialization of the data stream occurs only at
layers (de/mux and drivers): The interconnection between the the lowest level inside the transport layer—immediately before
master and slave segments of the PLC is accomplished by the the network layer interface. At this point, QoS parameters are
transport layer alone. As can be seen from the figure, the archi- considered: A PDU sent by a driver is split into individual parts
tecture closely corresponds to the protocol stack. Each layer of (fragments) by the fragmentation and reassembly mechanism;
the stack is a separate component (process) with an interface those related to PDUs with higher priorities are passed to the
offering services of the respective layer to the upper one. network layer ahead of others. The interface between the trans-
Technically, the interface of the transport layer and the port and network layers is not TCP/IP-based and consists of
de/mux is TCP/IP-based and involves multiple parallel commu- simple in-memory queues of fragments (separately for sending
nication channels. Although both layer components usually run and receiving directions). Overall, the PDU transmission path

Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
 1226
through different layers and the PLC network is designed to
avoid store-and-forward of PDUs, or even large parts thereof.
The starting portion of a PDU might reach the destination
protocol driver on the other side of the network even before the
end of the PDU is issued by the driver at the source. This, on the
one hand, allows lowering memory requirements at individual
devices (especially Bridges) and, on the other hand, minimizes
transmission latencies.
In case the driver requests transmission of a certain PDU to
be secured, this PDU is processed by the security module inside
the de/mux. REMPLI devices use smart-card-based authentica-
tion, encryption, and integrity verification of PDUs [30]. Since
the processing time can be quite significant, particularly for
large PDUs, and the smart card is a shared resource for all
secure PDUs sent and received at a given time, the de/mux
has to temporarily split PDUs into separate packets (still, much
larger than the network layer fragments) and “feed” them into
the cryptographic engine in a round-robin fashion, considering
the QoS in the same way as the transport layer does when
submitting fragments into the send queue of the network layer.
The PDUs are reassembled before they are passed to the upper
or lower layer of the stack. For nonsecure PDUs, this is not nec-
essary. After the control information (internal protocol headers)
is received and processed, simple byte forwarding between the
driver and the transport layer takes place.
The top-level rerouting of PDUs via other APs is also based
on TCP/IP. All de/multiplexers in the network communicate to
each other to send/receive commands and responses, choosing
the best possible communication paths for PDU transmissions.
In the opposite direction, alarms, received by one AP, are
redistributed to all other APs in the system and delivered,
respectively, to all drivers with the target ID.
VIII. “L AST M ILE ”
The communication system, naturally, needs to be linked
with the field hardware on one side and with the applications
on the other, so that the desired end-to-end communication
becomes possible. On the field side, the situation is straightfor-
ward: The PLC Node is installed in direct vicinity of the device
(energy meter, SCADA gear) and is linked to it by a dedicated
interface, such as RS-232.
In contrast, the application server is unlikely to be installed
anywhere near the AP (the latter needs to be located in a pri-
mary transformer station coupled with the physical powerlines).
The communication channel between the application and the
AP is IP-based. Therefore, another round of protocol tunneling
is needed.
Many applications support the encapsulation of their pro-
tocol into TCP/IP natively. Some protocols even define a
dedicated mode of operation over the TCP/IP (such as the
IEC 60870-5-104 variation of the IEC 60870-5-101 SCADA
protocol). If the application does not support TCP/IP natively,
it might still be possible to implement the encapsulation by
providing a special communication driver for this application.
This driver would be developed particularly for the REMPLI
system, as it is a counterpart of the protocol driver running at
the REMPLI AP.
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO. 4, APRIL 2011
TABLE II
SCADA P ERFORMANCE E VALUATION
Finally, if the application hard-codes its protocol-related
routines and is not extendible through communication drivers,
it is usually possible to intercept the protocol at the serial
bus level and wrap it into TCP/IP for transmission to the AP.
This can be accomplished with the help of a virtual serial port
proxy that transmits the payload over TCP/IP and supports line
control (RFC 2217). No modifications of the application itself
are necessary.
IX. T EST R ESULTS
The described communication system was successfully
implemented within the REMPLI project, including the support
for the IEC 1107, M-Bus, and the IEC 60870-5-101/104
protocols and subsequently extended to handle several other
protocols in the automated metering domain (over ten different
protocols are already supported at the time of this publication).
The evaluation of the system was made during two parallel
field tests at the end of the project. The performance figures,
quoted below, correspond to the application layer—i.e., the
measured performance of actual applications—in a test bed in-
stalled in an urban residential environment. The communication
system comprised of two APs, four Bridges (installed at two
different LV transformer stations), and 34 Nodes–four dedi-
cated SCADA Nodes at the LV transformers and 30 Nodes for
metering, installed near the electric meters in apartment blocks.
The results of the SCADA performance tests (IEC 60870-5-
101 protocol, four Nodes) are presented in Table II. Measured
in each case was the time of a response or alarm transmission
(corresponding to the SCADA protocol transaction type) with
security disabled. The system was configured to transmit IEC
60870-5-101 at a priority higher than any other protocol in the
network; thus, any parallel traffic was suspended by the QoS
mechanism during the transmission of SCADA PDUs. Multiple
measurements for each protocol transaction type were made to
obtain minimum and maximum timing figures.
The metering performance tests (IEC 1107 protocol) con-
sisted of reading out billing lists from single-phase meters
(266 B) and three-phase meters (10 355 B) with frame com-
pression disabled in the protocol driver. Each of the 30 metering
Nodes was attached, on average, to ten energy meters (296
energy meters were covered in the whole system). In the test,
altogether 357 989 B of 296 billing lists were read out within
17 min. These figures correspond to the worst-case scenario:
1) Meters were configured to use low baud rates on their
serial link to the Nodes (2400 b/s for single-phase
 SAUTER AND LOBASHOV: END-TO-END COMMUNICATION ARCHITECTURE FOR SMART GRIDS
meters; 4800 b/s for three-phase meters) due to issues
with their firmware, which had a significant impact on
the total response latency.
2) The metering application used in the test was not able to
perform parallel billing list read-outs; thus, the powerline
network remained idle most of the time, waiting for
an application request or meter response. No parallel
transmissions in one direction occurred; downlink and
uplink were not used in parallel either.
The net data throughput was measured with the help of a
special test application capable of saturating the available PLC
network bandwidth to a higher extent than the above metering
and SCADA applications. This application was supported by a
dedicated pair of protocol drivers (“test drivers”).
With conservative PLC parameter settings [utilizing only a
part of the European Committee for Electrotechnical Standard-
ization (CENELEC) A band in both MV and LV, resulting
in a slower network than in the field test] and a single test
application instance running (no parallel requests; no parallel
uplink/downlink traffic), a relatively moderate average payload
data rate of 1328 b/s was achieved. With two test applications
running in parallel, the average payload data rate was 2500 b/s.
With a further increase of the available PLC bandwidth (full
CENELEC A band) and four instances of the test application,
an average payload data rate of 17 536 b/s was achieved. All
tests were performed in a two-layer network (MV/LV) with
intermediate Bridges between the APs and Nodes.
During tests in a laboratory setup with an improved PLC
modem hardware and settings according to the United States
Federal Communications Commission low-band specification,
data rates of up to 139.7 kb/s were achieved with a network
layer fragment size of 64 B. For larger fragment sizes, a
throughput of 250 kb/s can be estimated from the test results,
which promises a performance improvement of two orders of
magnitude compared to the results obtained in the field tests.
Independent tests of the upper protocol stack layers with
PLC replaced by Ethernet (de/mux-to-de/mux over UDP, thus
bypassing the PLC stack in Fig. 5) were conducted in order
to verify the scalability of the stack in high-throughput field
networks. The performance has been shown to exceed the max-
imum performance of the PLC by far. Using a given hardware
(a 32-b microcontroller which the REMPLI AP is based on),
a 10-Mbit Ethernet bandwidth was fully saturated. For a real-
world application on top of high-bandwidth networks, it might,
however, be simpler to use a homogeneous IP layer instead of
the de/mux concept.
X. C ONCLUSION AND O UTLOOK
Smart grids rely to a large extent on communication, and the
respective infrastructure comprises heterogeneous networks.
In order to interconnect them, pure tunneling and gateway
approaches are too simple for real-world scenarios. This paper
showed that, in reality, a combination of the two, plus—for
some protocols—further tricks are necessary.
The communication system, described and evaluated in this
paper, was tailored to smart grid environments (therefore being
somewhat more sophisticated than, e.g., industrial automation
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
1227
networking concepts) and based on PLC technology. Neverthe-
less, the presented architecture and protocol stack is, largely,
not specific to powerline and allows abstracting from the actual
communication technology. All that is needed is to replace
the transport layer with an appropriate equivalent for another
network technology suitable for smart grids. Upper layers,
including drivers and applications, may remain unaffected. Se-
curity services, isolation of driver pairs, protocol optimizations,
etc., will be provided just as before.
The proposed approach will be most beneficial for
low-bandwidth and high-latency field-level networks using
point-to-multipoint communication. In addition, the top-level
routing mechanism over IP (at the de/mux layer) even allows
integrating different field-level networks at the same time.
Thus, there might be dedicated APs, for e.g., nodes reach-
able over PLC and over GSM, respectively. For the drivers
and applications on the higher levels, this would make no
difference, so that heterogeneous network structures can be
supported.
R EFERENCES
[1] A. Ipakchi and F. Albuyeh, “Grid of the future,” IEEE Power Energy
Mag., vol. 7, no. 2, pp. 52–62, Mar./Apr. 2009.
[2] T. J. Hammons, “Integrating renewable energy sources into European
grids,” Int. J. Elect. Power Energy Syst., vol. 30, no. 8, pp. 462–475,
Oct. 2008.
[3] M. Liserre, T. Sauter, and J. Y. Hung, “Future energy systems:
Integrating renewable energy sources into the smart power grid through
industrial electronics,” IEEE Ind. Electron. Mag., vol. 4, no. 1, pp. 18–37,
Mar. 2010.
[4] C. H. Hauser, D. E. Bakken, and A. Bose, “A failure to communicate: Next
generation communication requirements, technologies, and architecture
for the electric power grid,” IEEE Power Energy Mag., vol. 3, no. 2,
pp. 47–55, Mar./Apr. 2005.
[5] C. W. Potter, A. Archambault, and K. Westrick, “Building a smarter smart
grid through better renewable energy information,” in Proc. Power Syst.
Conf. Expo., Seattle, WA, 2009, pp. 1–5.
[6] G. Chicco and P. Mancarella, “Distributed multi-generation: A
comprehensive view,” Renew. Sustainable Energy Rev., vol. 13, no. 3,
pp. 535–551, Apr. 2009.
[7] A. Treytl, P. Palensky, and T. Sauter, “Security considerations for energy
automation networks,” in Proc. IFAC Int. Conf. Fieldbus Syst. Their Appl.
(FeT), Puebla, Mexico, 2005, pp. 158–165.
[8] SELMA—Project for Secure Electronic Metering Data Interchange, 2003.
[Online]. Available: http://www.selma-project.de
[9] K. Rajamani and R. Vaishnav, “Automation and information management
for a large urban power distribution network,” in Proc. Power Energy Soc.
Gen. Meeting—Conversion and Delivery of Electrical Energy in the 21st
Century, Pittsburgh, PA, 2008, pp. 1–7.
[10] F. Lobo, A. Cabello, A. Lopez, D. Mora, and R. Mora, “Distribution Net-
work as communication system,” in Proc. SmartGrids Distrib., CIRED
Semin., Frankfurt, Germany, 2008, pp. 1–4.
[11] M. McGranaghan, D. von Dollen, P. Myrda, and E. Gunther, “Utility
experience with developing a smart grid roadmap,” in Proc. Power Energy
Soc. Gen. Meeting—Conversion and Delivery of Electrical Energy in the
21st Century, Pittsburgh, PA, 2008, pp. 1–5.
[12] S. E. Collier, “Ten steps to a smarter grid,” in Proc. REPC, Fort Collins,
CO, 2009, pp. B2-1–B2-7.
[13] A. Mahmood, M. Aamir, and M. I. Anis, “Design and implementation
of AMR Smart Grid System,” in Proc. EPEC, Vancouver, BC, Canada,
2008, pp. 1–6.
[14] C. Bennett and D. Highfill, “Networking AMI smart meters,” in Proc.
Energy 2030 Conf. (ENERGY), Atlanta, GA, 2008, pp. 1–8.
[15] A. Sarafi, G. Tsiropoulos, and P. Cottis, “Hybrid wireless-broadband
over power lines: A promising broadband solution in rural areas,” IEEE
Commun. Mag., vol. 47, no. 11, pp. 140–147, Nov. 2009.
[16] T. Sauter, G. Pratl, A. Treytl, and G. Bumiller, “Secure and reliable wide-
area power-line communication for soft-real-time applications within
REMPLI,” in Proc. ISPLC, Vancouver, BC, Canada, 2005, pp. 57–60.
 1228 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 58, NO. 4, APRIL 2011
[17] G. N. Srinivasa Prasanna, A. Lakshmi, S. Sumanth, V. Simha, J. Bapat,
and G. Koomullil, “Data communication over the smart grid,” in Proc.
ISPLC, Dresden, Germany, 2009, pp. 273–279.
[18] M. Bauer, W. Plappert, C. Wang, and K. Dostert, “Packet-oriented com-
munication protocols for Smart Grid Services over low-speed PLC,” in
Proc. ISPLC, Dresden, Germany, 2009, pp. 89–94.
[19] F. Lobo, A. Lopez, A. Cabello, D. Mora, R. Mora, F. Carmona, J. Moreno,
D. Roman, A. Sendin, and I. Berganza, “How to design a communication
network over distribution networks,” in Proc. 20th Int. Conf. Exhib. Elect.
Distrib., Prague, Czech Republic, 2009, pp. 1–4.
[20] C. Pavlovski, “Smart grids and the telecommunications network,” pre-
sented at the CommsDay Melbourne Congr., Melbourne, Australia,
Oct. 13–14, 2009. [Online]. Available: http://www.greentelecomlive.com/
?p=1262
[21] M. Kunes and T. Sauter, “Fieldbus-Internet connectivity: The SNMP
approach,” IEEE Trans. Ind. Electron., vol. 48, no. 6, pp. 1248–1256,
Dec. 2001.
[22] M. Lobashov and T. Sauter, “Vertical communication from the enter-
prise level to the factory floor—Integrating fieldbus and IP-based
networks,” in Proc. IEEE Int. Conf. ETFA, Prague, Czech Republic, 2006,
pp. 1214–1221.
[23] P. Bhatt and R. P. Baldevia, “Integrate IEDS with OPC technology,” in
Proc. Power Syst. Conf.: Adv. Metering, Protection, Control, Commun.,
Distrib. Resour. (PS), Clemson, SC, 2006, pp. 391–407.
[24] G. Pratl and M. Lobashov, “Remote access to power-line networked
nodes: Digging the tunnel,” in Proc. IEEE Int. WFCS, Vienna, Austria,
2004, pp. 323–332.
[25] G. Bumiller, “Influence of single frequency network transmission on the
physical layer of a multi carrier modulation system,” in Proc. ISPLC,
Vancouver, BC, Canada, 2005, pp. 80–84.
[26] R. Brito and Y. Q. Song, “A dispatching mechanism providing REMPLI
applications with QoS,” in Proc. IEEE Int. Conf. ETFA, Catania, Italy,
2005, pp. 67–74.
[27] L. P. Lu, G. Y. Li, and Y. Q. Song, “Powerline communication system
for monitoring and supervision of feeder equipments for MV substation
automation,” in Proc. IEEE SIES, Antibes Juan-Les-Pins, France, 2006,
pp. 1–8.
[28] F. Pacheco, L. M. Pinho, and E. Tovar, “Queuing and routing in a hierar-
chical powerline communication system,” in Proc. IEEE Int. Conf. ETFA,
Catania, Italy, 2005, pp. 59–66.
[29] A. Bratukhin and G. Pratl, “A management system for a distributed power-
line based communication infrastructure,” in Proc. IEEE Int. Conf. ETFA,
Catania, Italy, 2005, pp. 75–81.
[30] A. Treytl and T. Sauter, “Security concept for a wide-area low-bandwidth
power-line communication system,” in Proc. ISPLC, Vancouver, BC,
Canada, 2005, pp. 66–70.
Authorized licensed use limited to: Velalar College of Engineering and Technology. Downloaded on February 17,2020 at 08:53:16 UTC from IEEE Xplore. Restrictions apply.
Thilo Sauter (M’93–SM’09) received the Dipl.-Ing.
and Ph.D. degrees in electrical engineering from the
Vienna University of Technology, Vienna, Austria, in
1992 and 1999, respectively.
From 1992 to 1996, he was a Research Assistant at
the Institute of General Electrical Engineering, work-
ing in the area of programmable logic and analog
application-specific integrated circuit design. Since
1996, he has been with the Institute of Computer
Technology (since 2006 as a tenure Assistant Pro-
fessor), where he has been the Head of the center of
excellence for fieldbus systems and leading the factory communications group.
Since 2004, he has also been the Director of the Institute for Integrated Sensor
Systems of the Austrian Academy of Sciences, Wiener Neustadt, Austria. His
current research interests are on integrated sensor systems and communication
networks in automation, with a focus on interconnection issues of fieldbus
systems and IP-based networks as well as industrial Ethernet.
Dr. Sauter is a member of the Austrian Technical Committee OVE MR65SC
and a delegate in the European Committee for Electrotechnical Standardization
committee TC65CX, both concerned with fieldbus standardization. Further-
more, he is the Chair of the Institute of Electrical and Electronics Engineers
Industrial Electronics Society Technical Committee (IEEE IES TC) on factory
automation, IES representative in the administrative committee of the IEEE
Sensors Council, and Treasurer of the IEEE Austria section.
Maksim Lobashov received the B.S. degree in con-
trol engineering and computer science from the Perm
State Technical University, Perm, Russia, in 1997,
and the Ph.D. degree from the Institute of Com-
puter Technology, Vienna University of Technology,
Vienna, Austria.
During his postgraduate studies, he worked as a
Research Assistant and participated in several re-
search projects in the areas of industrial and home
automation, fieldbus networks, powerline commu-
nication systems, and energy management. One of
these projects was real-time energy management via powerlines and Internet
(REMPLI), where he worked on the upper layers of the PLC-based commu-
nication system. Currently, he is self-employed, specializing on the design
of embedded systems and communication software for remote metering and
supervisory control and data acquisition. Amongst other activities in the last
years, he continued working on the REMPLI system.