These are very relevant and important observations.
As the low level wireless guy (as in lowly PHY/MAC dude) I can add a few bits to
this (finally!). Not sure if it helps, but maybe at least it's a chance to
share something I actually know :-).
I agree (enthusiastically) that upper layer
protocols should be as lean as possible, always. Overhead creep has a way
of happening in each layer, and we must remain aware that at limited speed
transports will be used in some parts of our SG network. Heck, that's
just as wise as when Granma said not to put more on your plate than you will
actually eat.
With 6loWPAN, the underlying constraint from
802.15.4 is the limited frame payload size, not so much the data rate, in our
context. The expected data volume per end-point is modest, and most
end-points are idle most of the time (low duty cycle). In 802.15.4 today
the payload limit per 'over the air' frame is 127 octets, which is not ideal for
packaging and transporting IP packets (the header of which can be longer than
that). As everyone here probably knows, that is why 6loWPAN was
initiated. Even with the great efforts that have gone into it, efficient
movement of IP traffic is challenging (and uses up more of the modest data
rate). Fixing this limit is one key goal of the current "Smart Utility Networking"
(SUN) task group in 802.15.4 (TG4g for short); support for a PHY payload of 1500
octets. With this change and a modest 100kbps data rate, support for IP
based upper layer protocols is easier. This allows more the available
capacity to be used for moving the application's data.
GPRS has been used in end points which forms
an experience base. An issue brought to the 802.15.4 effort from
this (and other) experience is the operational complexity of using licensed
spectrum and depending on regional service providers. Utilities and
vendors want a solution that can be deployed the
same nation-wide. The equipment vendors would like to have one
solution globally, and that is even more constrained. In the US
there are successful systems using the 902-928 ISM band, and this is a
popular approach in proposals heard so far in TG4g.
-Ben
----- Original Message -----
From:
Michel Kohanim
To:
Cc: 'Toby Considine'
Sent: Tuesday, March 31, 2009 9:24
AM
Subject: RE: [smartgrid-interest] Draft
Charter - Energy Market Information Exchange
Hi
Bill, thank you. It does make sense but I was specifically talking about GPRS
and 6LoWPAN systems. GPRS would become too expensive for XML and 6LoWPAN might
not [yet] have capabilities to process pure SOAP messages.
Ed,
I agree with your statements. Although the document talks about XML
Vocabularies (which is OK), there is no specific mention of the message
formats/encondings. I think we should either make it clear that
everything is XML – and as Bill suggests – and specific systems are in charge
of serialization/compression/binary translation OR we should allow for other
encodings possibly something close to what Brian suggested (thanks
Toby).
With
kind regards,
********************************
Michel Kohanim,
C.E.O
Universal Devices,
Inc.
(p)
818.631.0333
(f)
818.708.0755
http://www.universal-devices.com
********************************
From:
William Cox [mailto:]
Sent: Tuesday,
March 31, 2009 9:08 AM
To:
Cc:
; 'Toby Considine'
Subject:
Re: [smartgrid-interest] Draft Charter - Energy Market Information
Exchange
Michel --
Good point for discussion.
My view
is that the key interactions are the home/business/internet side, and that for
bandwidth-limited devices/networks the important thing is to have a consistent
information model of what is exchanged, whether it's the messages (which may
or may not have additional content) or more information.
So if the
information model as expressed in the XML is consistent with smaller/slower
connections, the information can be communicated and acted on in a consistent
way across homes, buildings (in general, suggesting non-homes), industrial
facilities, and so forth.
There are a number of alternate
serializations of XML that take less bandwidth, and a communications
aggregator/gateway could do a variety of things with the information streams.
Small embedded devices can implement an entire web services stack, and may be
usable in the future in home control/gateway environments -- the lesson from
the DMTF (Distributed Management Task Force) is that a fairly complex
management stack is now implemented in every NIC/ethernet card at a cost
differential of roughly $1.
The full information model may be
(initially) of less use in the Home to Grid space, but some of my talks and
papers discuss use of forward price information and bids for homes, so
additional information from the EMIX model will be useful in the
future.
(see, for instance, my presentation (and paper with Toby
Considine) from Grid-Interop 2008 on the page at http://www.grid-interop.com/2008/default.asp#session_712
. The presentation PDF seems messed up, at least on a Macintosh - font
issues - but can be found from http://www.coxsoftwarearchitects.com/Pages/C_Energy.html
and directly at http://www.coxsoftwarearchitects.com/Resources/Grid-Interop2008/Cox%2BConsidine%20Grid-Interop%202008%20Slides.pdf
)
Thanks!
bill
cox
Michel Kohanim wrote:
Hi
Bill,
This
is an excellent start and one which I truly believe in.
One
comment though: this document assumes that all transactions will be done using
XML/SOAP/Web Services (I understand the connection to OASIS). In this respect,
we are already assuming that each actor has enough bandwidth to support such
transactions, right? What are the provisions for bandwidth constrained
actors?
Again,
this is an excellent start and thanks for putting the document
together.
With
kind regards,
********************************
Michel Kohanim,
C.E.O
Universal Devices,
Inc.
(p)
818.631.0333
(f)
818.708.0755
http://www.universal-devices.com
********************************
From:
William Cox [mailto:]
Sent: Monday, March 30, 2009 7:43 PM
To:
Cc:
Toby Considine
Subject: [smartgrid-interest] Draft Charter - Energy
Market Information Exchange
I've attached a draft charter for the proposed OASIS Energy
Market Information Exchange (eMIX) Technical Committee.
This TC is
intended to address the prices, market characteristics, and other information
for energy trading, buying, and selling. I was inspired to start working on
this from discussions in and around the NIST Building-to-Grid and
Industry-to-Grid Domain Expert Working Groups, and continued interest from
first round reviewers and from people attending GridEcon 2009 in Chicago (http://www.gridecon.com -- slides are
available on line at the agenda link).
>From my perspective as an
enterprise software architect, this fits into a simple three layer stack with
interoperation protocols (how to communicate) as the fundamental
layer. I put the Energy Interoperation TC/OpenADR work here, with parts of the
message payload in the next layer.
The middle layer is what
is communicated -- for markets, things like price, quantity, units,
time (of use), and characteristics of the energy sold -- from source (e.g.
gas-fired plants, coal, solar, coal plant with scrubbers, wind) to derived
information (e.g. carbon data), and also trading information (is this a bid, a
price quote, an accepted transaction?).
The goal is to create an XML
vocabulary that can be used in a broad range of market exchanges with minimal
differences (and where there are differences, arranged in a simple way) for
the various consumers of the information.
The third layer is the market
design and definition; since markets have varying degrees of complexity I'm
leaving this alone for now :-). This is a potentially complex area, and an
interesting one. Accordingly, I'd like to carefully define the EMIX work to
focus on layer two.
I invite you to participate in a discussion on how
to improve this charter, as well as the sorts of characteristics that are
important to energy markets.
If you would like to be listed on the
charter when submitted as a supporter, please contact me or Toby
Considine.
Comments to me or (preferably) to the list. Please reference
line numbers where appropriate.
Thanks!
--
William Cox
Email:
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
