doc.: ieee 802.11-10/0955r2 submission august 2010 bruce kraemer, marvellslide 1 smart grid...
TRANSCRIPT
August 2010
Bruce Kraemer, Marvell
Slide 1
doc.: IEEE 802.11-10/0955r2
Submission
Smart Grid Technology Summer 2010 Plans
Date: 2010-August-11Abstract: Discussion PAP#2 Report
Name Company Address Phone emailBruce Kraemer Marvell 5488 Marvell Lane,
Santa Clara, CA, 95054
+1-321-751-3988 [email protected]
Kaberi Banerjee
August 2010
Bruce Kraemer, Marvell
Slide 2
doc.: IEEE 802.11-10/0955r2
Submission
Call Agenda
• Comments on the content of the NIST PAP#2 report, r5.
• R5 was posted at:
• http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Action_Plan_2_r05.pdf
• Other items?
August 2010
Bruce Kraemer, Marvell
Slide 3
doc.: IEEE 802.11-10/0955r2
Submission
NIST Timeline
Release of draft 0.6
Release of Version 1
Draft 0.5July 28, 2010
Call for Input to Section 6August 4, 2010
End of draft 0.5 review periodSeptember 15, 2010
December 3, 2010
November 4, 2010
SGIP face-to-face, ChicagoPAP 2 meeting
OpenSG meeting, MiamiTentative PAP 2 meeting
SGIP face-to-face, St LouisTentative PAP 2 meeting
September 16, 2010
End of draft 0.6 review period
September 30, 2010
October 29, 2010
August 2010
Bruce Kraemer, Marvell
Slide 4
doc.: IEEE 802.11-10/0955r2
Submission
NIST Expectations
• Release 0.6 contains mature contents for all sections
• Minor changes are expected between release 0.6 and 1.0 to allow for NIST internal review process
• Technical contributions in the form comments to current draft and/or new material shall be posted on the twiki and made publicly available
• Technical contributions will be processed as they are received up to the end of the review period– Allow time to provide comment resolution and reach consensus
prior to the close of the review period.
August 2010
Bruce Kraemer, Marvell
Slide 5
doc.: IEEE 802.11-10/0955r2
Submission
Next NIST PAP 2 meetings
• SGIP meeting in St Louis, September 16, 2010?– Is there a need for a PAP 2 meeting?
• Co-located with OpenSG meeting, November 4, 2010, Miami FL.
• SGIP meeting, December 1-3, 2010, Chicago, IL
August 2010
Bruce Kraemer, Marvell
Slide 6
doc.: IEEE 802.11-10/0955r2
Submission
• Comments received during/following August 4
August 2010
Bruce Kraemer, Marvell
Slide 7
doc.: IEEE 802.11-10/0955r2
Submission
Availability - 1
• Hello all,• I wanted to start a discussion on Link Availability (Section 4.2.1.1 on p. 23) as a
continuation of our discussion on the call earlier today.• Currently the text mentions that Link Availability is affected by devices being in
sleep mode, or by propagation conditions and interference:• Sleep mode is generally configurable and optional (can be turned off), so one
technology is not going to offer less availability than another due to the presence of sleep mode capabilities because sleep mode can be configured appropriately or be turned off. Perhaps the availability of sleep mode should just be considered an energy efficiency mechanism and discussed in Section 4.2.2.3?
• Propagation conditions and interference affect availability of a link across all wireless technologies. What differs between different wireless technologies is how resilient they are to interference, multipath, etc., which is discussed in Section 4.2.2.1. Though these kinds of techniques can generally be employed across different technologies so it’s hard to say that they are specific to a given technology and can thus be used to compare different technologies.
• Are there additional dimensions to the Link Availability metric that are part of the intention behind this section but are not captured in the text?
• I look forward to your comments.• Jorjeta
August 2010
Bruce Kraemer, Marvell
Slide 8
doc.: IEEE 802.11-10/0955r2
Submission
Availability - 2
• Jorjeta and all,• Availability can be very focused or a rather expansive topic. I believe that sleep
mode and interference are potentially problematic in mixing concepts. • When designing an RF segment to be used by an application the duty cycle (sleep
mode) and RF link reliability are a couple of the factors that go into the availability of the link as seen by an application. For example, if one were to PING across a link from an NMS application other factors come into play. I am hitting on some of them below.
• If we are speaking to the RF link alone, availability is dependent upon, but not limited to:
• - link budget: the received signal level above the thermal noise floor necessary to receive a signal with the appropriate margin (different margins [dB] imply a different reliability [%]). NIST has produced a robust link budget calculator (available on the web) that covers the topic in much greater detail.
• - SNR margin: additional margin to account for harmful interference which is dependent on the technology in use and the permissible operational rules relating to the spectrum use/users
August 2010
Bruce Kraemer, Marvell
Slide 9
doc.: IEEE 802.11-10/0955r2
Submission
Availability - 3• Designed Availability:• However, when describing the that the radio link is needed by the application, it implies far more
than just the RF layer but also the availability of the connection (end-to-end). In many circles this is aligned more with site availability (the Uptime Institute has an excellent document covering the topic regarding Tier Classifications) and includes:
• - Hardware element availability (MTBF/MTTR)• - System component redundancy• - Distribution paths (this aligns well with the wireless topology [mesh, PTM, PTP, etc.)• - Power redundancy• - Fault tolerance• Duty Cycle: this is relative to the percentage of time the link is designed to be available for use and
tends to be dependent upon technology or operator settings (such as to conserve battery life or comply with MPE limits).
• In a single point of failure (no HW, backhaul, power redundancy design), one will find that ~99.5% is a designed system reliability. With redundancy in the systems (HW and/or power and/or distribution paths) 99.95 is achievable before RF availability is considered.
• Actual reliability will take into consideration the reliability of RF, the reliability of the system elements, the duty cycle and the operational practices of the system operator (change control, maintenance practices, etc.)
• Actual system reliability (as one would expect to see measured from a Network Management System report [i.e. an application]) must factor all these element in.
• Jake Rasweiler
August 2010
Bruce Kraemer, Marvell
Slide 10
doc.: IEEE 802.11-10/0955r2
Submission
Peter Ecclesine comments• == Preface v0.5 Hughes • (ignoring the fact that SG applications requirements evolve, yielding to experience rather than remain locked in 1989 or
1999 or 2009 economics)• Para 2 The decision to apply wireless for any given set of applications is a local decision that must be made by the system
designers. These decisions must take into account several important elements. Smart Grid applications requirements must be defined with enough specificity to quantitatively define communications traffic and levels of performance. Applications requirements must be combined with as complete a set of management and security requirements for the life-cycle of the equipment. Requirements are then used as a backdrop to assess the candidate wireless technologies.
• = changed to =• Para 2 Smart Grid applications requirements must be defined with enough specificity to quantitatively define
communications traffic and levels of performance over the lifetime of the applications. Applications requirements must be combined with as complete a set of management and security requirements for the life-cycle of the equipment. The decisions to apply wireless for any given set of applications can then be based on expected performance and costs over the projected useful lifetimes of the spectrum and equipment.
• == Prepared definitions• Definition of Packet Radio should be removed.• Rate adaptation should be replaced by Link adaptation, including changing Modulation, Coding Scheme, smart antennas,
hopping patterns, http://en.wikipedia.org/wiki/Link_adaptation • == 2_r04.pdf• Definitions to refine or remove: • (unused) Generally Accepted Privacy Principles – include Web accessed groups like Truste and Better Business Bureau.
(look at AT&T and Verizon Privacy Web pages)• (unused) Last Gasp – all are proprietary, none scale• Web Portal• Section 5.1.1 Indoor-indoor radio propagation models• There should be a 5.1.2 with indoor-indoor noise including basement/garage woodworking tools, sheetmetal shop, garage
door opener, washer/dryer, hair-dryer, etc. Let there be man-made noise or our models work in a vacuum.
August 2010
Bruce Kraemer, Marvell
Slide 11
doc.: IEEE 802.11-10/0955r2
Submission
Call for Contributions to Section 6
• Suggested Outline
• Factors affecting performance, i.e. reliability, delay, throughput– Channel conditions such as distance, transmitted power,
interference, propagation environment
– Traffic load
– Number of users
• Seeking volunteers?
August 2010
Bruce Kraemer, Marvell
Slide 12
doc.: IEEE 802.11-10/0955r2
Submission
Section 6 – Default Suggestions
• 6. Findings / Results• Does wireless technology X meet SG-Network requirements
– Performance Metrics– Reliability– Latency– Scalability– meets throughput needs– handles the number of devices needed– range– interference immunity– By actor to actor / Link by link which is the best to use– How does its work in urban, sub-urban, rural– How well does it propagate (e.g. walls, basements, vaults, clutter, hills)– scalability over a quantity of end points– Equipment required to operate– Include processing time between actor to actor