Smart Grid Discussions – November 2010

1. Smart Grid Discussions – November 2010 Date: 2010-November-10 Abstract: NIST PAP#2 Report r6 recommended changes Other Smart Grid activities Bruce Kraemer, Marvell

2. Call Topics • Agenda Topics • IEEE • SGIP news • Catalog • AMI Security • PAP2 Report Status • UK Consultation Status • FG-Smart in ITU Bruce Kraemer, Marvell

3. IEEE LAUNCHES SMART GRID WORLD FORUM VIRTUAL CONFERENCE • IEEE LAUNCHES SMART GRID WORLD FORUM VIRTUAL CONFERENCE • Videos of Smart Grid Sessions and Exclusive Speaker Interviews Available Online • PISCATAWAY, N.J., USA, November 22, 2010 – IEEE, the world's largest professional association advancing technology for humanity, today announced that full-length videos of panel discussions and other activities that are part of the first  IEEE Smart Grid World Forum will be available for online viewing. The IEEE Smart Grid World Forum Virtual Conference will provide coverage of the event, taking place in Brussels, Belgium on December 2-3, 2010. With in-person registrations at capacity, the videos will provide anytime, anywhere access to expert viewpoints for individuals unable to attend the event. WHAT: The first IEEE Smart Grid World Forum Virtual Conference will focus on state-of-the-art Smart Grid developments in Europe. The Forum series is a global platform for collaboration to support and promote the Evolution of Smart Grid, and help develop a clear road map towards accelerating Smart Grid advancements worldwide. WHEN: The fully indexed, easy to navigate video sessions will be available as soon as: ·        Day One: December 3rd (from Dec 2 sessions) ·        Day Two: December 4th (from Dec 3 sessions) Bruce Kraemer, Marvell

4. SGIP Catalog of Standards • The catalog is a compendium of standards and practices considered to be appropriate for the development and deployment of a robust and interoperable Smart Grid. The catalog may contain multiple entries that may accomplish the goals and are functionality equivalent; similarly a single standards entry may contain optional elements that need not be implemented by all implementations. In general, compliance with a standard does not guarantee interoperability due to the above reasons or due to vagueness or under-specification in the base document. The SGIP as a part of its work program is defining a testing and certification program that may be applied to the standards listed in the catalog and that, if applied, will substantiate that implementations claiming compliance with the respective standards are also interoperable. Where test profiles have been defined for a particular standard this will be indicated in the catalog entry. http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/SGIPCatalogOfStandards Bruce Kraemer, Marvell

5. Smart Grid Standards Information • Version 1.8 • Thursday, November 18, 2010 http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGIPCatalogOfStandards/SmartGridStandardsInformationTemplate.docx Bruce Kraemer, Marvell

6. NIST PAPZZ – AMI Security Subgroup • Abstract • This priority action plan will lead to development of a standardized of a set of advanced metering infrastructure (AMI) security requirements by a formally recognized Standards Development Organization (SDO) or a selected Standards Setting Organization (SSO). In performing each of its tasks, members of this priority action plan will liaison with the NIST CSWG Testing and Certification Subgroup to ensure standardized requirements facilitate the goals and objectives for testing and certification. • To ensure the result does not become quickly obsolete and avoid inhibiting market creativity, members of this priority action plan will endeavor to find a sufficiently detailed level of specificity to make controls actionable such as specifying criteria for selection of mechanisms, protocols, and techniques; however the desired standard shall avoid prescribing sub-system design or identifying specific products or vendor names. For example, specifying criteria for identification of acceptable encryption algorithms and key sizes is appropriate, as is delineating requirements for handling of key material within a device; however dictating chip layout or code structure is below the level of specificity appropriate for this activity. • Members of this priority action plan shall also ensure documentation developed extends the architecture and view presented in the NIST Interagency Report 7628 (“NISTIR”). Members of this priority action plan shall communicate any and all gaps between source documentation and the NISTIR identified during the development process to the relevant parent organization. http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/AMISecurityRequirements Bruce Kraemer, Marvell

7. Results of Dallas Discussions • Package to NIST • https://mentor.ieee.org/802.11/dcn/10/11-10-1396-02-0000-smart-grid-summary-input-to-pap-2-report-nov-2010.ppt • The intent of the Section 4 comments was to improve the technical precision of the document and provide a better basis for evaluation and comparison of wireless technologies that might be used in the Smart Grid. • However, the IEEE 802 Smart Grid committee recognized that addition of new or revised definitions or insertion of additional rows, after receiving the technology characteristics populating the V5 matrix columns, would cause some concern for NIST and the SDO respondents. • The recommended solutions are as follow: • Create  an updated  matrix with a new designation (V6-proposed was the chosen designation) • Retain the previous (V5) matrix to ensure that the matrix rows and columns are archived in the form supplied • Add disclaimers to the V6-proposed matrix indicating that some blank or omitted responses could indicate questions or clarifications which were added to this matrix after the responses were received from the particular SDO who supplied input to the original matrix. • The recommended disclaimers are included in this document. • The recommended definition additions for Section 2.2 are included in this document. • The recommended matrix (V6-proposed) is included in this document. • It is recommended that the revised matrix be used as the basis for comparison going forward and that SDOs could be encouraged by NIST to update their supplied information. Bruce Kraemer, Marvell

8. NIST Response Thank you for the input. I think that Matrix V6 still needs more work to correctly point to and use the new notes. 1) In the version_history sheet, Missing entry that includes what was done to create this version V6 (or draft 16m?). 2) In the Characteristics sheet  Group 7 has nothing to do with Note B.  Might be Note A Group 11 has nothing to do with Note A, but rather NOTEs B and C NOTE C should be on Group 11 item d. The terms in Note B do not match those in e, f,g, and g (or what should be h)  Alignment is required to avoid confusion. Since the new items appear to be further clarifications on mesh, then perhaps they should be indicated that way such as d:mesh; d1 single-hop; d2multi-hop; d3 ; d4.   Do these apply to all wireless technologies or just to IEEE 802 wireless technologies? “It is recommended that the revised matrix be used as the basis for comparison going forward and that SDOs could be encouraged by NIST to update their supplied information .” The comment here is to drop the word " comparison" from the last sentence since PAP#2 is about evaluating whether a wireless technology satisfies the requirements of the smart grid. David Cypher Bruce Kraemer, Marvell

9. UK Smart Metering Consultation • Still listed as closed – awaiting Government response • (1 of 21 consultations in similar state) Bruce Kraemer, Marvell

10. ITU FG Smart • ITU-T Focus Group on Smart Grid (FG Smart) • Started May 2010 • The Terms of Reference of the Focus Group are available here. • The Focus Group will, • identify potential impacts on standards development • investigate future ITU-T study items and related actions • familiarize ITU-T and standardization communities with emerging attributes of smart grid • encourage collaboration between ITU-T and smart grid communities • The Focus Group will collaborate with worldwide smart grid communities (e.g., research institutes, forums, academia) including other SDOs and consortia. http://www.itu.int/en/ITU-T/focusgroups/smart/Pages/Default.aspx Bruce Kraemer, Marvell

11. ITU FG Smart Fourth meetingChicago, USA, 29 November – 3 December 2010 • Registration form • Meeting Announcement • Meeting documentsDeadline for Contributions: 25 November 2010 Fifth meetingYokohama, Japan, 10-14 January 2011 • Registration form • Meeting Announcement • Meeting documents http://www.itu.int/en/ITU-T/focusgroups/smart/Pages/Default.aspx Bruce Kraemer, Marvell

12. ITU FG Smart FG Management • Chairman: Les Brown (Lantiq, Germany) • Vice-Chairman: Li Haihua (MIIT, China) • Vice-Chairman: Hyung-Soo (Hans) Kim (Korea Telecom, Korea) • Vice-Chairman: Yoshito Sakurai (Hitachi, Japan) • Vice-Chairman: David Su (NIST/USA) Bruce Kraemer, Marvell

13. FG –Smart Structure • Writing a Document • Working Groups • 1 – Uses Cases • 2 – Requirements • 3 – Architecture Bruce Kraemer, Marvell

14. Previous information follows Bruce Kraemer, Marvell

15. Agenda Topics for the Dallas Week Action Item • Finalize change suggestions for the NIST PAP#2 Report Information Items • SGIP update • ITU Focus Group • UK Consultation • March Tutorial topics/speakers Bruce Kraemer, Marvell

16. Report Changes Bruce Kraemer, Marvell

17. July 28, 2010 Draft 0.5 August 4, 2010 Call for Input to Section 6 September 15, 2010 End of draft 0.5 review period September 16, 2010 SGIP face-to-face, St Louis Tentative PAP 2 meeting NIST Timeline re-confirmed Nov 4 September 30, 2010 Release of draft 0.6 October 29, 2010 End of draft 0.6 review period November 4, 2010 OpenSG meeting, Miami Tentative PAP 2 meeting SGIP face-to-face, Chicago PAP 2 meeting December 3, 2010 Release of Version 1 Bruce Kraemer, Marvell

18. PAP#2 Report was updated Oct 1 • http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Action_Plan_2_r06.pdf Bruce Kraemer, Marvell

19. NIST PAP#2 Report v6 – Section 4 4.1 Technology Descriptor Headings To be able to describe wireless technology a set of characteristics were identified and organized into logical groups. The group titles are listed below. • 1. Link Availability • 2. Data/Media Type Supported • 3. Coverage Area • 4. Mobility • 5. Data Rates • 6. RF Utilization • 7. Data Frames & Packets • 8. Link Quality Optimization • 9. Radio Performance Measurement & Management • 10. Power Management • 11. Connection Topologies • 12. Connection Management • 13. QoS & Traffic Prioritization • 14. Location Characterization • 15. Security & Security Management • 16. Radio Environment • 17. Intra-technology Coexistence • 18. Inter-technology Coexistence • 19. Unique Device Identification • 20. Technology Specification Source • 21. Deployment Domain Characterization • 22. Exclusions Bruce Kraemer, Marvell

20. IEEE 802 contributed a number of suggestions on how to change the NIST PAP#2 Report r6. These were contained in documents 1210 and 1209 and 1316.https://mentor.ieee.org/802.11/dcn/10/11-10-1209-00-0000-comment-set-1-on-pap-2-report-r6.dochttps://mentor.ieee.org/802.11/dcn/10/11-10-1210-01-0000-comment-set-2-on-pap-2-report-r6.ppt Bruce Kraemer, Marvell

21. Material for this meeting Section 4 edited Section 4 edited Bruce Kraemer, Marvell

22. Comment #01 • Section 4.2.1.3 talks about Coverage Area. It is important to discuss coverage in conjunction with data rates and link margin for example, in order to avoid associations between inconsistent pieces of information, e.g., citing the largest coverage area achievable by a given technology along with the highest data rate achievable by the technology is incorrect – generally the two have a reverse relationship and the highest coverage is achievable at the lowest data rate. • Agreed to text change: • Add the following text at the end of Section 4.2.1.3: When comparing coverage areas between different technologies, it is important to take into account the link budgets used in the coverage computation. Note that the largest coverage area achievable by a specific technology typically requires transmission at the lowest data rate used by that technology. Bruce Kraemer, Marvell

23. Comment #02a • Section 4.2.1.4 talks about Mobility. It would be useful to mention the data rates achievable at various mobility levels to avoid assumptions that mobile devices can communicate at the highest data rates used by a specific technology. • Agreed to text change: • Add the following text at the end of Section 4.2.1.4: Comparisons between the capabilities of different mobile technologies have to take into account the maximum data rate achievable at each mobility level -- mobile devices may not be able to communicate at the highest available data rates when moving at high speeds. Bruce Kraemer, Marvell

24. Comment #03 • Section 4.2.1.5 talks about Data Rates. • Agreed text change: • Add the following text at the end of Section 4.2.1.5: Additional factors to consider when discussing data rates: • Throughput must be considered in conjunction with packet size, coverage range and rate of mobility (if any). • It is important to distinguish between unicast, multicast and broadcast rates, as they may not be the same for a given wireless technology. • Throughput depends on medium access scheduling, including the capability to provide block transmissions (whereby multiple data packets can be sent in succession with minimum or no individual medium access operations per packet except before the first packet is sent), and/or block acknowledgements (whereby a single acknowledgement packet can acknowledge multiple preceding data packets). The capability and flexibility to optimize block transmissions and acknowledgements can have a significant effect on GoodPut. • The use of rate adaptation mechanisms, where the data rate on a link is modified when the quality of the link changes. Bruce Kraemer, Marvell

25. Add these definitions to Section 2.2 Broadcast • Broadcast is a form of message transmission where a message is sent from a single source to all potential receiving nodes. Multicast • Multicast is a form of message transmission where a message is sent from a single source to a subset of all potential receiving nodes. (The mechanism for selecting the members of the subset is not part of this definition.) Unicast • Unicast is a form of message transmission where a message is sent from a single source is sent to a single receiving node. Bruce Kraemer, Marvell

26. Comment #04 • Section 4.2.1.6 talks about RF utilization. • Agreed text change: • Add the following text at the end of Section 4.2.1.6: • Consider the power level regulations for the different channels used by a particular technology. • Consider the impact of Dynamic Frequency Selection (DFS) regulations on the channels used by a particular technology, e.g., certain UNII channels are subject to DFS regulation which requires wireless devices to change channel when they detect the use of radar on their current channel. Bruce Kraemer, Marvell

27. Comment #05 • Section 4.2.1.7 talks about Data Frames and Packets. It is important to consider frame duration in conjunction with data rate and size of the frame. Also, we need to consider multicast and broadcast frames in addition to unicast frames. • Agreed text change: • Modify item “a)” in Section 4.2.1.7 as follows: • What is the maximum frame duration for a unicast, multicast and broadcast frame respectively, and what are the corresponding frame size and data rate at which each type of frame was sent? • Modify item “b)” in Section 4.2.1.7 as follows: • What is the maximum packet size that can be sent in one unicast, multicast and broadcast radio frame respectively? • Modify item “c)” in Section 4.2.1.7 as follows: • Does the radio system support segmentation of unicast, multicast and broadcast packets respectively, when the payload size exceeds the capacity of one radio frame? Bruce Kraemer, Marvell

28. Comment #06 • Section 4.2.2.4 talks about Connection Topologies. The Bus and Ring topology need to be removed, they are not wireless topologies. One way to characterize wireless topologies is as single hop and multi-hop (statically configured or mesh), and wireless links as point-to-point, point-to-multipoint, and omnidirectional. We need to add figures that correspond to the text we end up with. • Agreed text change: • Remove the Bus and Ring figures • Replace the current text in Section 4.2.2.4 with the following: Wireless network topologies can be divided into single hop and multi-hop, where a multi-hop topology can be statically configured, or can be dynamic and self-forming, e.g., a mesh. A wireless link can be point-to-point, point-to-multipoint, or broadcast. • Add the definitions on the following 4 slides to Section 2.2 Bruce Kraemer, Marvell

29. Hop Definitions • Proposed PAP2 Guidelines Document Definitions • Hop: The term hop is used to signify a link between a pair of devices that a frame or packet needs to traverse to reach one device from the other. • Single-Hop Network: A single-hop network is one in which devices can only communicate with each other directly, e.g., over a single link (hop), and do not have the capability to forward traffic on each other’s behalf. • Multi-Hop Network: A multi-hop network is one in which devices have the capability to forward traffic on each other’s behalf and can thus communicate along paths composed of multiple links (hops). Bruce Kraemer, Marvell

30. Configuring Definition • Statically Configured Multi-Hop Network: A multi-hop network can be statically configured, such that each node’s forwarding decisions are dictated by configuration. • Dynamic and Self-Configuring Multi-Hop Network: A multi-hop network can be dynamic and self-configuring, such that network devices have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre-configured constraints and requirements, e.g., lowest delay or highest throughput. Bruce Kraemer, Marvell

31. MESH Definition • Mesh Network: A mesh network is a dynamic self-configuring network composed of devices that can forward traffic on each other’s behalf, have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre-configured constraints and requirements, e.g., lowest delay or highest throughput. Bruce Kraemer, Marvell

32. Comment #07 • Section 4.2.2.5 talks about Connection Management. The section needs to mention what aspects of “connection management” can be used to compare different wireless technologies. For example, we can evaluate the latency to join a network, available security mechanisms employed when joining a network, and overhead to join the network (number of control packets exchanged). Perhaps section titles such as “Network Participation Mechanisms” or “Joining the Network” are more descriptive of the content of this section. Bruce Kraemer, Marvell

33. Comment 07b Add the following text at the end of Section 4.2.2.5: • It is important to evaluate: • the time it takes for a device to join a particular network, and the overhead required to do so • the time and overhead required to rejoin the network when a device becomes disconnected from the network • the overhead required to maintain membership in the network after the initial admission into the network • the overhead associated with optimizing connectivity, e.g., in mesh-based topologies. Bruce Kraemer, Marvell

34. Comment #08 • Section 4.2.3.2 talks about Location Characterization. It seems like many of the techniques applicable to this section are not technology-specific but implementation-specific and as such can be incorporated across different wireless technologies even if they are not currently incorporated into the products of a specific wireless technology. It would be helpful to make the distinction between technology-specific properties and product-specific properties in the text. • Agreed text change: • Add the following text at the end of Section 4.2.3.2: • It is important to distinguish between technology-specific mechanisms for location characterization and mechanisms that are applicable across technologies or communication topologies, which can easily be added to products that may not currently support them. Bruce Kraemer, Marvell

35. Comment #09 • A category that is missing from Section 4 is one that characterizes the deployment complexity of each technology. • Agreed text change: Add the following text after Section 4.2.4.1: • 4.2.5 Group 22: Deployment Complexity • It is important to evaluate the complexity of: • installation and maintenance of a given wireless system • integration with other, possibly existing, networks • expansion of the wireless network coverage over time. Bruce Kraemer, Marvell

36. General Comment #10 • It would be helpful to have some tables and text summarizing the information in Section 5, and to move a lot of the discussions/derivations to an appendix. Otherwise, the message/conclusions/recommendations get lost in the text. Bruce Kraemer, Marvell

37. General Comment #11 Section 4.2.1.2 (p. 24) talks about voice and video traffic over the smart grid. We need more use cases motivating why we would want to have voice and video traffic over the smart grid network. The current set of use cases supplied by OpenSG does not currently contain this service. The only video example given in the text is one of surveillance of affected outage areas. It would seem that voice and video might be of lower priority during outages, e.g., caused by disasters or weather-related events, since the network would require a high degree of availability for its regular functions. In addition, surveillance is generally part of the public safety infrastructure and there is spectrum allocated for such use so I am not convinced that we should be discussing this kind of application in the context of the smart grid. • Applications such as voice and video have requirements that even broadband network providers are struggling with (wireless and landline) and making them part of the smart grid infrastructure requires significant justification. Bruce Kraemer, Marvell

38. General Comment #12 • Link Availability in Section 4.2.1.1 does not appear to be consistently calculated for the various candidate various radio technologies, nor did majority of the technology candidates describe the method used to calculate availability. • The current description of the characteristic does not match the calculation. • Both of these issues need to be resolved before progressing to completion of Sections 6 & 7. • “The technology “Operating Point” chosen is presumably chosen recognizing that achieving a low failure rate is desirable.” • Agreed text change: Change this sentence to • “The technology “Operating Point” is chosen to achieve a low failure rate and is an outcome of deployment flexibility & strategy.” Bruce Kraemer, Marvell

39. Comment #13 Para 2 Recommended change • Reword the preface to incorporate the idea that SG application requirements evolve over time, yielding to experience rather than remain locked in 1989 or 1999 or 2009 economics. • Smart Grid application 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.  Bruce Kraemer, Marvell

40. Matrix Disclaimer text – Robert Russell • Blank or omitted responses could indicate questions or clarifications which were added to this matrix after the responses were received from the particular SDO to the original matrix. • Additional questions or points of clarification developed through the course of completing this document which may result in a blank or non- response from a particular respondent and do not reflect on the respondent's ability or lack of ability to support the item. • Blank responses reflect clarifications to question asked in this document made after information was already received from earlier versions. • A blank response indicates a question or clarification ammended to this document to which the respondent has not had the opportunity to respond to. Bruce Kraemer, Marvell

41. Matrix Disclaimer text • Blanks in rows marked with # indicate technology questions which were added to this matrix after the responses were received from the particular SDO to the original matrix. Bruce Kraemer, Marvell

42. MESH Disclaimer text • After the responses were received from the SDO to the original mesh question the following definition for mesh was added. Bruce Kraemer, Marvell

43. Add these definitions to Section 2.2 Broadcast • Broadcast is a form of message transmission where a message is sent from a single source to all potential receiving nodes. Multicast • Multicast is a form of message transmission where a message is sent from a single source to a subset of all potential receiving nodes. (The mechanism for selecting the members of the subset is not part of this definition.) Unicast • Unicast is a form of message transmission where a message is sent from a single source to a single receiving node. Bruce Kraemer, Marvell

44. Hop Definitions • Proposed PAP2 Guidelines Document Definitions • Hop: The term hop is used to signify a link between a pair of devices that a frame or packet needs to traverse to reach one device from the other. • Single-Hop Network: A single-hop network is one in which devices can only communicate with each other directly, e.g., over a single link (hop), and do not have the capability to forward traffic on each other’s behalf. • Multi-Hop Network: A multi-hop network is one in which devices have the capability to forward traffic on each other’s behalf and can thus communicate along paths composed of multiple links (hops). Bruce Kraemer, Marvell

45. Configuring Definition • Statically Configured Multi-Hop Network: A multi-hop network can be statically configured, such that each node’s forwarding decisions are dictated by configuration. • Dynamic and Self-Configuring Multi-Hop Network: A multi-hop network can be dynamic and self-configuring, such that network devices have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre-configured constraints and requirements, e.g., lowest delay or highest throughput. Bruce Kraemer, Marvell

46. MESH Definition • Mesh Network: A mesh network is a dynamic self-configuring network composed of devices that can forward traffic on each other’s behalf, have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre-configured constraints and requirements, e.g., lowest delay or highest throughput. X Bruce Kraemer, Marvell

47. MESH Definition • Mesh Network: A mesh network is a network composed of devices that can forward traffic on each other’s behalf, have the ability to discover (multi-hop) forwarding paths in the network and make their own forwarding decisions based on various pre-configured constraints and requirements, e.g., lowest delay or highest throughput. option Bruce Kraemer, Marvell

48. Matrix Disclaimer text • Blanks in rows marked with # indicate technology questions which were added to this matrix after the responses to the original matrix were received from the particular SDO. X Bruce Kraemer, Marvell

49. Completely inter-connected via nearest neighbor • Star topology Bruce Kraemer, Marvell

50. Completely inter-connected via nearest neighbor • Representation of mesh network • Partially complete example of fully inter-connected network Bruce Kraemer, Marvell