Communication Services and Data Model for
Electrical Engineering and Computer Science Department
Colorado School of Mines
Golden, CO 80401 USA
Abstract—Demand response (DR) is becoming an integral part of
the modern power distribution systems. By partially reducing the
consumption level or shifting it from peak hours to off-peak
hours, DR can function as a tool for the utility to respond to
shortage of supply for a short duration of time. It helps stabilize
the electricity market, postpone capacity expansion projects for
building new power generation units, and can potentially lead to
mutual financial benefits for the utility as well as the customers.
DR is one of the enablers of the Smart Grid paradigm as it
promotes the interaction and responsiveness of the customers and
changes the grid from a vertically integrated structure to one that
is also affected by the behavior of the demand side. Essential to
successful implementation of demand response is an efficient
communication infrastructure capable of providing a secure two-
way data exchange means between the utility and the customers.
The focus of this paper is on the communication services and data
models that are needed for realization of DR at the residential
and commercial levels. The proposed model is platform
independent, promoting interoperability as one of the key
operational requirements of demand response implementation.
Keywords—demand response; distribution grid; distribution
management system; communication services; interoperability
Electric demand response (DR) refers to the changes in the
electricity usage by the end-use customers from their nominal
consumption patterns in response to changes in the price of
electricity over time, or to incentive payments designed to
induce lower electricity use at times of high wholesale market
prices or when the system reliability is jeopardized . In
addition to improving the reliability of the power system, and
causing short-term electricity market stability, DR can reduce
the system peak load in the long term and therefore postpone
the need for building new power plants, leading to considerable
environmental as well as financial benefits. For instance, the
capital cost required to build 1MW of DR capacity is of the
order of $240,000 versus $400,000 for a gas fired plant; while
at the same time DR capacity can potentially be dispatched in
less than 5 minutes, whereas a peaking power plant can take up
to 30 minutes to ramp up to full capacity . Successful
deployment of a DR program can lead to substantial financial
benefits. A Federal Energy Regulatory Commission (FERC)
commissioned study reported that a moderate amount of
demand response could save about $7.5 billion annually .
Even though demand reduction signals can be issued as a
system-wide event, not all consumers need to respond
simultaneously in order for markets to benefit from DR. Some
reports suggest that 20% of customers account for 80% of price
response, and that only as few as 5% of all customers are
needed to discipline electricity market prices .
Implementation of DR at the utility level, if performed in
conjunction with the knowledge of the power system model,
can result in additional benefits. Efficient congestion relief,
improvement of voltage profile, and reduction of utility
revenues lost are some of these benefits . In addition, DR
can be viewed as a type of distributed energy resource (DER),
i.e., a virtual power plant, which can be coordinated with other
energy resources such as non-dispatchable renewable resources
and energy storage systems . It can also be used as a tool for
relieving system capacity during the charging process of
electric vehicles when the system is under stress .
The objective of this paper is to provide an overview of
what DR means to the communication infrastructure of the
distribution system. Different communication services and data
models that can be used for implementing DR at the residential
and commercial levels are discussed. With the multitude of
manufacturers and services aimed at demand response at the
residential level, the issue of interoperability is gaining more
attraction. This calls for an abstract model, independent of
different underlying communication platforms.
Demand response programs can be roughly classified into
three groups according to the party that initiates the demand
reduction action. Depending on the average consumption size
and class of the end-use consumer, some of these programs
have natural precedence over the others for certain classes of
A. Incentive-Based DR
In this category of DR programs a set of demand reduction
signals (i.e., DR signals) are issued by the utility or the DR
Service Provider (aggregator) and are sent to the participating
customers in the form of voluntary demand reduction requests
or mandatory commands. Various types of resources can be
utilized under this program, namely, directly controllable loads
(mostly at the residential customer sites) and loads that can be
interrupted or reduced upon receipt of a signal from the utility
(mostly at the commercial and industrial customer sites).
Examples of programs in this category are Direct Load Control
(DLC) and Interruptible & Curtailable Load (I&C). DLC loads
can be remotely cycled or turned off by the utility, and can
normally be deployed within a relatively short period of time.
In more modern DR applications, these loads may be directly
dispatched by the utility based on the balance between the load
and generation . Typical household appliances and electric
vehicles may fit well in this approach. I&C loads, on the other
hand, are often larger scale and may include lighting, air
conditioning, process heating and cooling, and/or scheduling of
production. Notification time for this category of loads varies
from a few minutes to a few hours .
B. Rate-Based DR
In this program category, the price of electricity is changed
either at preset times or dynamically based on various times of
the day/week/year and the utility’s available reserve margin.
The customers would pay the highest prices for peak hours and
lowest prices for off-peak hours. The prices can be set a day in
advance on a daily or hourly basis, or in real-time. The
customers would receive electricity price updates on a regular
basis through internet or other media, and would accordingly
respond to the changes in prices by voluntary reduction of their
demand. Examples of price categories are time-of-use (TOU),
critical peak pricing (CPP) and real-time pricing (RTP).
C. Demand Reduction Bids
This is a more specialized program that better suits larger
customers that mostly own onsite distributed generation.
Customers participating in this category of programs initiate
and send demand reduction bids to the utility or the aggregator.
The bids would normally include the available demand
reduction capacity and the price asked for. This program
encourages mainly large customers to provide load reductions
at prices for which they are willing to be curtailed, or to
identify how much load they would be willing to curtail at the
posted price .
Depending on the types of programs the customers are
subscribed to, the output provided by the DR engine may
contain control commands for directly controllable loads,
demand reduction signals for interruptible loads and/or updated
electricity rates for voluntary demand reduction. Out of the
three programs mentioned in this section, only the incentive-
based DR is considered throughout the rest of this paper.
A. Overall Architecture
Figure 1 illustrates the schematic diagram of the demand
response architecture at the utility control center level, i.e., at
the distribution management system (DMS). The DR engine
operates as a semi-emergency application. It receives the meter
data from the Meter Data Management System (MDMS),
which in turn collects the data from individual customer meters
or aggregator(s), through different communication means. Data
on the expected demand of the system at the future intervals is
provided by the short-term load forecast (STLF) module, from
one hour to one week ahead. This data can be at the overall
system level, or a more granular level, e.g., at the service
transformer or customer meter levels. From an abstract point of
view, demand reduction is considered lost revenue by the
utility, which further denotes the importance of accurate load
forecast. Any over-prediction could, in principle, lead to
unnecessary demand reduction.
Figure 1. Schematic diagram of the demand response at the DMS level.
B. DR Trigger
If the forecasted system load level exceeds the total
capacity (or violates the required capacity margin) then the
shortage of supply would trigger the incentive-based DR for a
future time interval (Fig. 2).
Figure 2. Capacity margin is normally used to trigger demand response.
In addition, market data and electricity rates, provided to
the DR engine through external resources, can be used to
activate the rate-based DR. This information, for instance, can
be used to determine whether a DR event should be issued
instead of purchasing the required power from the spot market.
C. DR Timing
The North American Energy Standards Board (NAESB)
has defined the timing for a DR event (Fig. 3) . Due to the
dynamics of the loads, it takes a certain amount of time (ramp
period) until the consumer demand is reduced to the requested
levels. This period can take anywhere from a few seconds to a
few minutes for larger loads.
For most customers, it is only after the ramp period that the
utility can verify whether or not the requested demand
reduction actually took place. This can be done by sending
meter poll messages to provide meter readings at the start of
the sustained response period. A possible shortage of sufficient
compliance by the customers would then force the utility to
take drastic measures in short notice, for instance, send
emergency DR signals to the customers who can provide
ancillary services. The advance notice in this case would be
distinctly shorter (maybe in the range of a few minutes), which
justifies the higher incentives paid for participation. Emergency
DR programs often give the participants the option of not to
take part and in return forgo the incentive payment (with or
without a penalty). Failure to meet the required shortage of
supply through emergency DR may force the utility to turn to
the last resort option, i.e., load shedding, while having to accept
the significant damages to the reliability and continuity of
service in its service area.
Figure 3. Chronological steps of a demand response event.
The backbone of demand response is the communication
infrastructure linking the customer meters and (possibly)
appliances to the DR engine at the utility control center. Figure
4 illustrates the schematic view of the network infrastructure
needed for implementing DR command and control, which
consists of multiple interrelated domains. In practice, each of
the horizontal domains represents a zone of interoperation
where there may be competing and complementary standards
and technology, often focused on a specific technology or
partner technologies, and developed without consideration for
the requirements of any other domains .
A. Utility Control Center Domain
At the utility control center level, the operator would access
the billing system and MDMS, the network model/database, as
well as other DMS related functions that are required for
implementing DR. These, for instance, can be the voltage/VAR
optimization module, the service restoration module, Outage
Management System (OMS) or the general Load Management
System (LMS). This domain will also be communicating with
external systems such as the market regulators and the demand
response service providers. Communication protocols such as
internet protocols or Inter-Control Center Communication
Protocol (ICCP)  may be used. ICCP is based on
client/server models. All data transfers between the control
center and the external entities originate with a request by a
control center to the other entity that owns and manages the
Figure 4. Abstract view of the communication network infrastructure for DR.
B. Wide Area Network
This zone is the bridge between the utility and the field
networks, and provides communications links between the
control center and the substations, commonly referred to as the
‘backhaul’ communications . Various communication
media/technologies, e.g., satellite, microwave, Power Line
Carrier (PLC), can be used in this domain. Communication
protocols such as IEC 61850 , DNP3  and IEC 61968
 can be used here for the purpose of transmission of DR
signals. WAN combines the data received from the lower level
domains (LAN, WAN) and sends it to the utility. If distributed
energy resources are integrated with DR, the control and
command structure will be provided by the WAN.
C. Local/Neighborhood Area Networks
This domain connects the higher level WAN to the lower
level smart devices and smart homes, and essentially, creates a
point of contact to the smart meters. In smaller geographical
areas in can be a Local Area Network (LAN) connecting
multiple residential and commercial units, whereas in larger
areas, the system may be decomposed into multiple
Neighborhood Area Networks (NAN) each consisting of two or
more houses/buildings. In order to reduce the communication
bottleneck, often data from meters are stored in data
concentrators to be transmitted upstream.
WiMax, wireless mesh, ADSL, cable or cellular networks
can be used for establishing this. In selecting the proper
technology, factors such as the data rate, the bandwidth
required, data transport latency, power consumption, coverage,
interoperability aspects and security issues are taken into
account. However, from a utility's perspective, the installation
cost may be the biggest barrier for adopting any of these
D. Home Area Network
HAN is the local network of a particular household. It
creates a network linking smart appliances which are demand
responsive, such as smart thermostats and HVAC, controllable
washers/dryers, or even electric vehicle chargers, and forms the
backbone for Building Automation (BA) or Home Automation
(HA) systems. If applicable, it will also control the energy
resources such as rooftop photovoltaic (PV) panels or any other
small-scale distributed energy resource. Various network
protocols such as WiFi, RS485/RS232, OpenHAN, HomePlug,
Bluetooth and ZigBee may be used for establishing the
network. Installation cost, available data rates and coverage are
the main determining factors for selecting one over the other.
A successful DR infrastructure must be able to serve all
consumers, promote interoperability and open standards,
provide high quality services, create an efficient information
marketplace and protect the rights and privacy of its users .
A multi-layer scheme for DR information model is illustrated
in Fig. 5.
The bottom layer, physical device layer, consists of all
appliances that provide means for DR command, control and
metering. These devices are triggered through the
functionalities in the second layer, DR services layer, which is
responsible for linking the physical enablers of DR with the
applications processed at the utility control center. The
uppermost layer, the DR application layer, provides tools for
implementation of demand response. This layered structure
allows for clear and independent assignment of responsibilities,
in such a way that the overall infrastructure is flexible enough
to respond to changes in the underlying technologies.
Except for the physical device layer that forms the
foundation of the HAN, the other two layers defined above are
not necessarily bound to a specific part of communication
networks illustrated in Fig. 4. The DR application layer may
reside in a centralized fashion at the utility control center
network or, if performed by the demand response service
provider for example, may appear in a distributed manner at the
WAN or LAN level. Similarly, the DR services layer can
reside in any of the networks in Fig. 4, namely, it can be
activated at the control center level, at the distributed demand
response service provider level, or at the smart HAN level.
Figure 5. Layered model for DR information model.
With fast-paced advances in communication technologies
and smart appliances, it is no surprise if interoperability be
regarded as one of the most important operational objectives of
the DR infrastructure. In order to ensure that the overall system
is not sensitive to a change or modification in any one of its
underlying components, the model has to be platform
independent. Only such model can ensure that all devices and
applications can function properly without the need to know
much about the other entities they communicate with.
A data structure model then has to be developed for each
participating customer. To begin with, this model has to take
into account the entire DR related constraints and attributes
associated with each customer. These constraints and
parameters are often used by the utility or the aggregator in
order to choose a number of customers to send DR signals to.
Traditionally, the process of selection is achieved in a random
fashion where the customers whose constraints match those of
the DR event are shortlisted and prioritized based on a
predefined criteria, and contacted until the desired demand
reduction is achieved. Alternatively, it has been possible to
select the customers belonging to a specific feeder, substation
or geographical area of the power system.
The data model for DR customers should also include all
the controls and settings that can be accessed by the DR engine.
These would indicate the range of services that the utility can
Table 1 lists the data model for the DR customer that is
proposed in this paper. The data objects in the structure belong
to different classes of information. The operational constraints
are expected to be contained in the Customer Information
System (CIS), so that they can be accessed by the DR engine.
TABLE I. DR
Type Explanation M/O
CustID string Identification for the customer M
Description of the type of program the
customer is enrolled in M
MaxP real Maximum power delivered to the load
over a default period O
CoincPeak 1/0 Whether maximum demand of the
customer overlaps with that of system O
MinAdvNote int Minimum acceptable advance notice for
receiving the DR signal (min/hr) M
MaxAdvNote int Maximum acceptable advance notice for
receiving the DR signal (min/hr) O
MinDur int Minimum acceptable duration of DR
event (min) O
MaxDur int Maximum acceptable duration of DR
event (min) M
MaxEvDay int Maximum number of DR events that can
be received in one day O
MaxConDay int Maximum number of consecutive days
that a DR event can be received O
Minimum acceptable reduction request
(in kW) that can be received by the
Maximum acceptable reduction request
(in kW) that can be received by the
Indication whether the DR program that
the customer is enrolled in is mandatory
ExcFee real Exercise fee payable to the customer
upon compliance with the DR request O
LastDay date Last day when the customer had
received DR signal O
Number of DR events that the customer
had received on the last day it received
the DR signal
Number of consecutive days until and
including the last day when the customer
had received a DR signal
Watt real Total demand (kW) M
WattHr real Total energy (kWh) M
VAr real Reactive power consumption (kVar) O
DRsent 1/0 Indicates whether or not DR signal has
been sent to the customer M
DRreceived 1/0 Indicates whether or not DR signal has
been received by the customer O
Indicates whether or not a DR command
previously sent is implemented and is in
Loc 1/0 Indicates whether the DR control is done
locally or remotely M
Cont string DR command M
OpCntRs int Resettable operation counter indicating
number of past DR events O
LocSw 1/0 Switching the control from local to
MeterPoll 1/0 Polls the meter M
Mandatory or optional
A. Basic Services: Meter Read/Control
The DR engine and the meters communicate using a certain
set of messages/commands. For the DR event to be initiated,
the DR engine needs to send a command signal to the meters.
This can be a command for DLC (turn on/off) or I&C (reduce
demand). Once the command is sent, the DR engine needs to
validate the response of the customer (meter). This is necessary
to avoid a last minute shortage in demand reduction, i.e., lack
of sufficient participation. One way to achieve this is to send a
meter poll message to the meters selected for the DR event
before and shortly after the start time of the event. By
comparing these two values, the DR engine can determine
whether the required demand reduction is actually met. The
sequence diagram in Fig. 6 illustrates the order of these DR
Figure 6. Sequence of messages exchanged between DR and AMI.
The sequence of actions between the two modules is:
• The DR Engine sends the CreateEndDeviceControls
message with the meter id, the event start/end time, and
the reduction values (if applicable) to the meters.
• A few minutes before the event, the DR engine sends a
GetMeterReading request to the meters with the id of the
customers of interest (METER_NO), and the reading
time in the message payload. Consequently, the time-
tagged meter data are transmitted back to the DR engine.
• A few minutes after the event, the DR engine sends a
second GetMeterReading request to the customers of
interest (METER_NO), and the reading time in the
message payload. Consequently, the time-tagged meter
data are transmitted to the DR engine.
If the target reduction is not met the DR Engine sends the
second batch of CreateEndDeviceControls message with the
new set of customer id, the start time of the event, the end time
of the event and the reduction values (if applicable) to the
Demand response specific entities whose sole responsibility
is to maintain the 2-way DR data transmission with the
customers can certainly communicate with the smart meters of
the end use consumers directly. This, however, may turn out to
be a substantial burden on the DMS. In fact, this is one of the
reasons why demand response service providers (DRSP), also
known as aggregators, are becoming more common for DR
applications . Through contracts with aggregators, the utility
would enjoy dealing with a single resource –as opposed to
thousands of small scale customers, while it can receive a
guaranteed DR capacity upon need. However, performing
demand response through a DRSP deprives the utility of the
possibility of carrying out a more intelligent demand reduction
throughout the power system, as the DRSPs usually do not
have access to the network model in the same level of detail as
it is available at the DMS. Some of the benefits of performing a
network-model based DR at the DMS level have been
discussed in . This would require the DR engine to access
the meter data repository. In modern distribution grid, this is
the Advanced Meter Infrastructure (AMI) that consists of the
metering system recording consumer consumption. Integration
of the DMS and AMI can pose its own challenges since the two
systems have different goals and objectives. The authors in 
have proposed an integration solution which is essentially a
middleware between the two systems. In this case, the DR
engine would send the messages to this interface, which will
then transmit them to the corresponding meters.
B. DR Data Query
In order for the DR engine to select the most suitable set of
customers for a particular DR event, it has to have access to the
program attributes (operational constraints) of each one. This
can be done by a single query to the meter (customer). In
return, the meter would transmit the set of “Operational
Constraints” data objects back to the DR engine.
C. DR Status Query
The validation procedure through back-to-back meter polls
explained in the previous section is one way to ensure the
compliance with the DR event. In more advanced and
automated DR schemes implemented at the HAN, it is possible
for the DR engine to issue a DR status query message for
particular set of meters. In return, the meters could transmit the
data objects under the “Setting” group. This for instance would
indicate whether the DR signal has been received by the
customer, and if so, whether it has been implemented or not.
D. Miscellaneous Services
Other communication services can be envisioned for
automated DR. For instance, an important task for the DRSP or
the utility is to match individual customers (or classes of
customers) with DR programs that suit their consumption
patterns best. Data mining techniques can be used that look into
the history of DR events and the coincident behavior of each
customer, in order to customize DR program attributes for
individuals. Today, this seems unlikely as utilities often
promote a limited number of DR programs, but as DR becomes
more of a dependable energy resource in the future, it will be
plausible to have intelligently customized DR programs. For
this purpose, the DR engine might issue query messages on the
DR history at each customer location (or service point) on a
regular basis, collecting this raw data for the purpose of
Demand response is gaining more popularity among power
distribution utilities. Minimal customer participation during
peak demand can help the utility efficiently and economically
maintain the load balance, while improving the reliability of the
system. Environmental benefits are added bonuses that have
led to and continue to lead to higher acceptability of DR
programs in the advanced countries. While DR is in its early
stages, it is envisioned to become a pivotal part of the Smart
Grid. This would require a comprehensive and platform
independent model for DR and its communication services that
can function in an interoperable environment. Proposing such a
model is what this paper has attempted to achieve.
 “Assessment of demand response and advanced metering,” Staff Report,
Federal Energy Regulatory Commission, Aug. 2006.
 Thomas Weisel Partners, “A primer on demand response,” White Paper,
 S. Kiliccote, M.A. Piette and D. Hansen, “Advaned controls and
communications for demand response and energy efficiency in
commercial buildings,” in Proc. Carnegie Mellon Conference in Electric
Power Systems, Pittsburgh, PA, USA, Jan. 2006.
 S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li and H. Kazemzadeh,
“Demand response architecture – integration into the distribution
management system,” in Proc. IEEE SmartGridComm, Gaithersburg,
MD, USA, Oct. 2010.
 K. Dietrich, J.M. Latorre, L. Olmos and A. Ramos, “Demand response
in an isolated system with high wind integration,” IEEE Trans. ons on
Power Systems, vol. 27, no. 1, pp. 20-29, Feb. 2012.
 S. Shao, M. Pipattanasomporn and S. Rahman, “Demand response as a
load shaping tool in an intelligent grid with electric vehicles,” IEEE
Trans. on Smart Grid, vol. 2, no. 4, Dec. 2011, pp. 624-631.
 A. Brooks, E. Lu, D. Reicher, C. Spirakis and B. Weihl, “Demand
dispatch,” Power & Energy Magazine, vol. 8, no. 3, May/Jun. 2010, pp.
 “Demand response: design principles for creating customer and market
value,” Technical Report, Peak Load Management Alliance, Nov. 2002.
 J. Han and M.A. Piette, “Solutions for summer electric power shortages:
demand response and its applications in air conditioning and
refrigeration systems,” Journal of Refrigeration, Air Conditioning and
Electric Power Machinery, vol. 29, issue 1, pp. 1-4, Jan. 2008.
 S. Coe, A. Ott and D. Pratt, “Demanding standards,” Power & Energy
Magazine, vol. 8, no. 3, May/Jun. 2010, pp. 55-59.
 E.W. Gunther, A. Snyder, G. Gilchrist and D.R. Highfill, “Smart grid
standards assessment and recommendations for adoption and
development,” Technical Report, Feb. 2009.
 “IEC 60870-6- Telecontrol equipments and systems- Part 6: Telecontrol
protocols compatible with ISO standards and ITU-T recommendations”,
IEC Std. 2004.
 “IEC 61850- Communication networks and systems in substations”, IEC
 K. Curtis, “A DNP3 protocol primer,” DNP Users Group, March 2005,
pp. 1-8, [Online] available at http://www.dnp.org.
 “IEC 61968, Application integration at electric utilities – System
interfaces for distribution management”, IEC Std. 2003.
 “A strawman reference design for demand response information
exchange,” Technical Report, EnerNex Corporation, Oct. 2004.
 Z. Li, Z. Wang, J.C. Tournier, W. Peterson, W. Li and Y. Wang, “A
unified solution for advanced metering infrastructure integration with a
distribution management system,” in Proc. IEEE SmartGridComm,
Gaithersburg, MD, USA, Oct. 2010.