One document matched: draft-jennings-energy-pricing-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="no"?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-jennings-energy-pricing-01"
ipr="trust200902">
<front>
<title abbrev="Energy Pricing">Communication of Energy Price
Information</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Bruce Nordman" initials="B." surname="Nordman">
<organization>Lawrence Berkeley National Laboratory</organization>
<address>
<postal>
<street>1 Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>USA</country>
</postal>
<email>BNordman@LBL.gov</email>
</address>
</author>
<date day="10" month="July" year="2011" />
<abstract>
<t>This specification defines media types for representing the future
price of energy in JSON. It also defines a way for a client device, such
as a car, refrigerator, air conditioner, water heater, or
display to discover a web server that can provide the future price for
local electrical energy. This will allow the client device to make
intelligent decisions about when to use energy, and enable price
distribution when the building is off-grid. It enables obtaining price
from a local or non-local price server.</t>
<t>This draft is an early skeleton of a draft to start discussion around
this idea.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>Many uses of energy can be shifted in time, or changed in quantity,
based on price. Consider charging an electric car. For users that plug
in cars at 9pm, they may not care when it actually charges, as long as
it is ready at 8am when they need to go to work. This is a classic real
time problem and can be optimized as long as the charger for the car has
relevant information about how long it will take to charge and the cost
of electricity between the current time and the time when the task needs
to be complete.</t>
<t>Other devices such as refrigerators, air conditioners, and washers
can similarly shift load. For their primary temperature regulation
function, they can lower their setpoint (for cooling devices) when costs
are low, and increase it when costs are high. The amount of deviation
from the base target is keyed to the value of the price, operational
considerations (e.g. not letting food freeze or spoil), or other
non-price information available (e.g. occupancy). Devices such as
displays (TV or computer) or lights can dim in some proportion to the
electricity price, to balance cost and functionality. Devices with
user-oriented time-outs (e.g. when an occupancy sensor's lack of seeing
anyone in a space leads to a light going off) can adjust the length of
such time-outs in proportion to price. Periodic functions (e.g. a
refrigerator defrost cycle) can be shifted to the lowest cost time in
the relevant time horizon. In general, the end-use device itself usually
has the most knowledge about how best to act, and the the best access to
internal actuators to accomplish the change.</t>
<t>Development around “Demand Response (DR)” has been
advancing since around 2000. Most work in that area involves sending
signals from the grid (DR-service provider) to a large building
(commercial/industrial) or large device within it, to request load
shedding or load shifting. There are then financial arrangements to pay
the building owner for the service. More recently, the DR community and
regulators have turned to enabling dynamic pricing so that the price
customers actually pay at the meter more closely corresponds to the
actual costs that the utility faces. Prices can be sent from the grid to
an end use device, or from the grid to a gateway device (could be the
meter) that then sends the prices to end use devices.</t>
<t>This specification defines a simple JSON<xref
target="RFC4627"></xref>media type to provide the cost of energy at
future points of time. It is an array of objects in which each object
contains the time a new price will come into effect and the price at
that time. JSON also defines a well known URL on a web server so that an
HTTP client can retrieve this data. Finally as a way to automatically
discover the web server, this specification defines a DHCP option to
provide the host name of the web server.</t>
<t>At this time, only electricity is contemplated, but other resources
do plausibly have time-varying prices, such as centrally provided steam
or hot/cold water. Any resource (e.g. water) could use this mechanism to
have a local price to distribute. Resources with a local supply constraint
will then have a local price to ensure a balance with demand.</t>
<t>The base usage case for this specification is a time-varying
electricity price with the current price and a set of future prices
(confirmed or estimates), usually for a 24 hour period. This price comes
from the electric utility. The price can be fetched directly from the
utility. However, many alternate cases are also expected and supported.
The building may have one entity (likely a piece of network equipment
since it is always on already) that gets prices from the grid and all
others get it from this building-local 'price server'. Both transactions
use this mechanism.</t>
<t>The operator of the building may choose to present a higher price to
devices in the building to take into account carbon emissions or other
pollution from generating electricity. The building may also have local
generation and/or storage, whose state and operation may indicate
changes in price. For example, a building with an excess of solar power
on-site may sell marginal electricity back to the grid at a low price.
This would suggest lowering the price until supply and demand in the
building were approximately in balance.</t>
<t>Some buildings operate off-grid, either all the time or
intermittently. A building is a structure that uses resources and
provides services. Common examples are homes, office, retail, and
institutional buildings. Other building types include vehicles such as
cars, ships, and airplanes. All these building types have electricity
systems that would benefit from a price mechanism.</t>
<t>There are other protocols designed to get prices from the grid to a
building, particularly to a building control system. One example of
these is OpenADR. This mechanism complements rather than replaces these
other mechanisms.</t>
<t>Electricity pricing has other aspects that complicate pricing. For
example, in many places electricity use over a monthly billing period is
sold in blocks, with the price increasing or decreasing with larger
blocks depending on what the utility is trying to accomplish with the
price. For example, the first five hundred kWh could be $0.10/kWh, the
second 500 kWh $0.15, and so on. Thus, the monthly marginal price (what
is paid if the consumption goes up or down modestly) is the last block
used. This could be substantially different from an average price. There
are many options for how utilities could combine blocks with dynamic
prices. This specification is not attempting to provide a set of prices
that are legally binding. Rather, it is intended to provide a simple and
reasonably reliable set of prices that devices can use (when the
alternative may be in fact no information at all).</t>
<t>Consider a typical residence with broadband Internet and a
residential gateway that gets its IP address via DHCP from the service
provider. The service provider would provide the domain of the local
power provider via DHCP. The residential gateway would get this and
provide it in DHCP requests sent to the residential gateway. The
residential gateway would also be able to override this, so if the
consumer had arranged power from an alternative power provider, the name
of that provider could be configured in the device.</t>
<t>A device on the residential network, such as a dishwasher, could find
the energy provider name via DHCP. The dishwasher would then make an
HTTP GET request to the well known URI defined in this specification. In
other words, it would do an HTTP GET to the
/.well_known/electricity-price.json and would receive back an
energyprice+json media type. For example</t>
<figure>
<artwork><![CDATA[
{
"currency" : "USD",
"prices":[
{ "time": "2011-04-12T23:20:00.00Z", "price": "0.028" },
{ "time": "2011-04-12T23:21:00.00Z", "price": "0.025" },
{ "time": "2011-04-12T23:22:00.00Z", "price": "0.021" }
]}]]></artwork>
</figure>
<t>The above example shows a case where at 21:00 UTC, the price falls
from 2.8 cents per KWh to 2.5 cents per kWh. Using kWh is fixed.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Semantics">
<t>Each media type carries a single JSON object that represents a set of
prices and times. This object contains optional attributes described
below and a mandatory array of one or more measurements.</t>
<t><list style="hanging">
<t hangText="validTill:">Time at which this data series will become
invalid. UTC time in RFC 3339 format.</t>
<t hangText="currency:">Optional. Specify currency in ISO 4217 [REF]
currency code.</t>
<t hangText="prices:">Array of price objects. Mandatory and there
must be at least one object in the array. Objects MUST be ordered in
this array by time.</t>
</list></t>
<t>Each price time object contains several attributes, some of which are
optional and some of which are mandatory.</t>
<t><list style="hanging">
<t hangText="time:">Time this price becomes effective. UTC time in
RFC 3339 format.</t>
<t hangText="price:">Price per kWh. The cost of energy changes to
this price at the time in this object and remains at this price
until the time of the next object in the prices array.</t>
</list></t>
<t>Open Issue: What is the best representation for time?</t>
<t>Open Issue: Is it OK that currency is optional?</t>
<t>Open Issue: How many entries can the array have? It would be nice to
have some maximum size.</t>
<t>The price in the last entry in the series is ignored. That is, the
purpose of the last entry is to close the time of the last period. While
24 hours will be a typical time horizon, it could be shorter or
longer.</t>
<t>Question: Can the request have a start time (zero for the present),
so that if there is a limit on array size, one can get the rest?</t>
<t>Open Issue: should we be able to represent both buy and sell
prices?</t>
</section>
<section title="Well Known URL ">
<t>A client that implements this specification uses the path
"//.well-known/electricity-price.json" for the resource name unless the
client has been configured with an alternative path.</t>
</section>
<section title="DHCP">
<t>Open Issues: Is DHCP the best approach to discovery or would
something else be better?</t>
</section>
<section title="IANA Considerations">
<t>Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with
the RFC number of this specification.</t>
<section title="Well-Known URI Registration">
<t>IANA will make the following "Well Known URI" registration as
described in RFC 5785:</t>
<texttable>
<ttcol></ttcol>
<ttcol></ttcol>
<c>URI suffix:</c>
<c>electricity-price.json</c>
<c>Change controller:</c>
<c>IETF <iesg@ietf.org></c>
<c>Specification document(s):</c>
<c>[RFC-AAAA]</c>
<c>Related information:</c>
<c>None</c>
</texttable>
</section>
<section anchor="sec-dhcp" title="DHCP Options">
<t>TBD</t>
</section>
<section anchor="sec-iana-media" title="Media Type Registration">
<t>The following registrations are done following the procedure
specified in <xref target="RFC4288"></xref> and <xref
target="RFC3023"></xref>.</t>
<t>Note to RFC Editor: Please replace all occurrences of "RFC-AAAA"
with the RFC number of this specification.</t>
<section title="energyprice+json Media Type Registration">
<t>TBD</t>
</section>
</section>
</section>
<section title="Mapping to OpenADR">
<t>Lawrence Berkeley National Laboratory led the development of OpenADR
initially (OpenADR v1.0), and it is now being formalized as an open
standard through OASIS and national Smart Grid activity (OpenADR v2.0).
At present, there are two relevant OASIS technical committees (TCs) that
are relevant to the dynamic pricing (includes real-time prices)
discussion: the Energy Interoperation TC (EI) and the Energy Market
Information Exchange TC (EMIX). Each committee has a draft standard of
the same name as the technical committee.</t>
<t>The OpenADR v2.0 standard will become a subset of what EI produces.
EMIX is charged with defining a standard abstract form of price
signaling. The details of how to represent a price product is defined in
EMIX<xref target="EMIX"></xref> (then EI<xref target="EI"></xref> would
reference and build implementation models, for e.g., XML schemas).</t>
<t>Both committees cover much more than just price (and price forecast)
information. The discussion below focuses only on features relevant to
this IETF specification. The OpenADR model uses XML as the data
description language. OpenADR v1.0 and v2.0 can specify prices in
different terms - absolute, multiple, or in relative terms to a base
price (either additive or multiplicative).</t>
<t>Pricing can be a very complicated topic, but for the discussion here,
we limit it to what this specification does- a schedule of time periods
and a price for each period.</t>
<t>To represent time, EI and EMIX use WS-Calendar (also an OASIS
standard), which provides for complex scheduling; simple price sequences
use only a small part of this. Sequences are represented as a start time
and a sequence of interval durations. As WS-Calendar builds on iCalendar
(see RFC 5545) it uses the same date/time format as this draft.</t>
<t>A related issue is how to specify the current time to assure that the
price source and user of the price have consistent time (or know how to
adjust the schedule for a difference in time). This discussion does not
consider this topic. So long as prices do not vary significantly from
one time period to the next, and the time differences are not large, this
issue is not of great concern.</t>
<t>EMIX can encode prices in several ways, including relative prices.
For absolute prices, the price is simply a numeric value in cents/kWh
for the U.S. Other additional attributes relevant to price
representations are under consideration (e.g., currency). The following
is a sample excerpt of an OpenADR v1.0 price schedule:</t>
<figure>
<artwork><![CDATA[
<p:drEventData>
<p:notificationTime>2009-06-02T17:15:00.0</p:notificationTime>
<p:startTime>2009-06-03T00:00:00.0</p:startTime>
<p:endTime>2009-06-03T23:59:00.0</p:endTime>
<p:eventInfoInstances>
<p:eventInfoTypeID>PRICE_ABSOLUTE</p:eventInfoTypeID>
<p:eventInfoName>Price</p:eventInfoName>
<p:eventInfoValues>
<p:value>0.0</p:value>
<p:timeOffset>0</p:timeOffset>
</p:eventInfoValues>
<p:eventInfoValues>
<p:value>0.0</p:value>
<p:timeOffset>3600</p:timeOffset>
</p:eventInfoValues>
...
<p:eventInfoValues>
<p:value>0.0</p:value>
<p:timeOffset>82800</p:timeOffset>
</p:eventInfoValues>
</p:eventInfoInstances>
</p:drEventData>
]]></artwork>
</figure>
<t></t>
<t>TBD - define a simple mapping to and from OpenADR.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
<t>Further discussion of security proprieties for media types can be
found in <xref target="sec-iana-media"></xref>.</t>
</section>
<section title="Privacy Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgement">
<t>We would like to thank Girish Ghatikar at LBNL for information and
text about OpenADR. Thanks for helpful comments from many people
including Scott Brim, <get your name here>. </t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object
Notation (JSON)</title>
<author fullname="D. Crockford" initials="D." surname="Crockford">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from
the ECMAScript Programming Language Standard. JSON defines a small
set of formatting rules for the portable representation of
structured data. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4627" />
<format octets="16319"
target="http://www.rfc-editor.org/rfc/rfc4627.txt" type="TXT" />
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author fullname="M. Murata" initials="M." surname="Murata">
<organization></organization>
</author>
<author fullname="S. St. Laurent" initials="S."
surname="St. Laurent">
<organization></organization>
</author>
<author fullname="D. Kohn" initials="D." surname="Kohn">
<organization></organization>
</author>
<date month="January" year="2001" />
<abstract>
<t>This document standardizes five new media types -- text/xml,
application/xml, text/xml-external-parsed-entity, application/xml-
external-parsed-entity, and application/xml-dtd -- for use in
exchanging network entities that are related to the Extensible
Markup Language (XML). This document also standardizes a
convention (using the suffix '+xml') for naming media types
outside of these five types when those media types represent XML
MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3023" />
<format octets="86011"
target="http://www.rfc-editor.org/rfc/rfc3023.txt" type="TXT" />
</reference>
<reference anchor="RFC4288">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization></organization>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization></organization>
</author>
<date month="December" year="2005" />
<abstract>
<t>This document defines procedures for the specification and
registration of media types for use in MIME and other Internet
protocols. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and
suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13" />
<seriesInfo name="RFC" value="4288" />
<format octets="52667"
target="http://www.rfc-editor.org/rfc/rfc4288.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list style="empty">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="EMIX"
target="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emix">
<front>
<title>Energy Market Information Exchange (EMIX) Version 1.0,
Committee Specification Draft 02 / Public Review Draft</title>
<author>
<organization>OASIS</organization>
<address></address>
</author>
<date day="28" month="April" year="2011" />
</front>
</reference>
<reference anchor="EI"
target="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop">
<front>
<title>Energy Interoperation Version 1.0, Committee Specification
Draft 01</title>
<author>
<organization>OASIS</organization>
<address></address>
</author>
<date day="26" month="November" year="2010" />
</front>
</reference>
<!--
<reference anchor="OpenADR" target="http://drrc.lbl.gov/publications/open-automated-demand-response-dynamic-pricing-technologies-and-demonstration">
<front>
<title>
Ghatikar, Girish; Mathieu, Johanna; Piette, Mary Ann; Koch, Ed; Hennage, Dan; 'Open Automated Demand Response Dynamic Pricing Technologies and Demonstration', LBNL-3921E
</title>
<author >
<address> </address>
</author>
<date year="2010" />
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:07 |