Communication of Energy Price Information

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. 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. 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. This specification defines a simple JSONmedia 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. 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. 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. 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. 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. 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. 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). 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. 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

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.

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.

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. Time at which this data series will become invalid. UTC time in RFC 3339 format. Optional. Specify currency in ISO 4217 [REF] currency code. 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. Each price time object contains several attributes, some of which are optional and some of which are mandatory. Time this price becomes effective. UTC time in RFC 3339 format. 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. Open Issue: What is the best representation for time? Open Issue: Is it OK that currency is optional? Open Issue: How many entries can the array have? It would be nice to have some maximum size. 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. 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? Open Issue: should we be able to represent both buy and sell prices?

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.

Open Issues: Is DHCP the best approach to discovery or would something else be better?

Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification.

IANA will make the following "Well Known URI" registration as described in RFC 5785: URI suffix: electricity-price.json Change controller: IETF <iesg@ietf.org> Specification document(s): [RFC-AAAA] Related information: None

TBD

The following registrations are done following the procedure specified in and . Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification.

TBD

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. 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 (then EI would reference and build implementation models, for e.g., XML schemas). 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). 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. 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. 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. 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:

2009-06-02T17:15:00.0 2009-06-03T00:00:00.0 2009-06-03T23:59:00.0 PRICE_ABSOLUTE Price 0.0 0 0.0 3600 ... 0.0 82800 ]]> TBD - define a simple mapping to and from OpenADR.

TBD Further discussion of security proprieties for media types can be found in .

TBD

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>.