1. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid Discussions – November 2010 Date: 2010-November-10 Abstract: NIST PAP#2 Report r6 recommended changes Other Smart Grid activities NameCompanyAddressPhoneemail Bruce KraemerMarvell5488 Marvell Lane, Santa Clara, CA, 95054 +1-321-751-3988bkraemer@marvell.com Jorjeta JetchevaItron

2. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 2 Call Topics Agenda Topics IEEE SGIP news –Catalog –AMI Security PAP2 Report Status UK Consultation Status FG-Smart in ITU

3. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 3 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)

4. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.SGIP http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/SGIPCatalogOfStandards

5. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 5 Smart Grid Standards Information Version 1.8 Thursday, November 18, 2010 http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGIPCatalogOfStandards/SmartGridStandardsInformationTemplate.docx

6. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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. CSWG 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

7. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.ppthttps://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.

8. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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

9. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 9 UK Smart Metering Consultation Still listed as closed – awaiting Government response (1 of 21 consultations in similar state)

10. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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. 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

11. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 11 ITU FG Smart Fourth meeting Chicago, USA, 29 November – 3 December 2010 Registration form Meeting Announcement Meeting documents Deadline for Contributions: 25 November 2010Meeting documents Fifth meeting Yokohama, Japan, 10-14 January 2011 Registration form Meeting Announcement Meeting documents http://www.itu.int/en/ITU-T/focusgroups/smart/Pages/Default.aspx

12. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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)

13. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 13 FG –Smart Structure Writing a Document Working Groups 1 – Uses Cases 2 – Requirements 3 – Architecture

14. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 14 Previous information follows

15. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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

16. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 16 Report Changes

17. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 17 NIST Timeline Release of draft 0.6 Release of Version 1 Draft 0.5 July 28, 2010 Call for Input to Section 6 August 4, 2010 End of draft 0.5 review period September 15, 2010 December 3, 2010 November 4, 2010 SGIP face-to-face, Chicago PAP 2 meeting OpenSG meeting, Miami Tentative PAP 2 meeting SGIP face-to-face, St Louis Tentative PAP 2 meeting September 16, 2010 End of draft 0.6 review period September 30, 2010 October 29, 2010

18. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 18 PAP#2 Report was updated Oct 1 http://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Actio n_Plan_2_r06.pdfhttp://collaborate.nist.gov/twiki- sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Actio n_Plan_2_r06.pdf

19. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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

20. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.doc https://mentor.ieee.org/802.11/dcn/10/11-10-1210-01-0000-comment-set-2-on-pap-2-report-r6.ppt https://mentor.ieee.org/802.11/dcn/10/11-10-1209-00-0000-comment-set-1-on-pap-2-report-r6.doc https://mentor.ieee.org/802.11/dcn/10/11-10-1210-01-0000-comment-set-2-on-pap-2-report-r6.ppt

21. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 21 Material for this meeting Section 4 edited

22. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

23. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

24. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

25. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

26. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

27. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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?

28. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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

29. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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).

30. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

31. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

32. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

33. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

34. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

35. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

36. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

37. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

38. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.”

39. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

40. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

41. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

42. doc.: IEEE 802.11-10/1316r4 Submission November 2010 Bruce Kraemer, MarvellSlide 42 MESH Disclaimer text After the responses were received from the SDO to the original mesh question the following definition for mesh was added.

43. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

44. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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).

45. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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.

46. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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

47. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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

48. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 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

49. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 49 Completely inter- connected via nearest neighbor Star topology

50. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 50 Completely inter- connected via nearest neighbor Representation of mesh network Partially complete example of fully inter-connected network

51. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 51 Completely inter- connected via nearest neighbor Representation of mesh network Partially complete example of fully inter-connected network X Y Nodes A,B,C capable of forwarding or relay A B C

52. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 52 Path reduced Representation of mesh network Symmetric, Partially complete example of fully inter-connected network (Acyclic diagraph?) Distorted, Partially complete example of fully inter-connected network

53. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 53 MESH Definition Mesh Topolgy: A mesh topology is a multi-hop network that contains multiple connection paths between some or all nodes. Mesh Topology: A mesh topology is a set of nodes that contains multiple connection paths between some or all nodes.

54. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 54 Updated Definitions 4.2.2.4 Group 11: Connection Topologies Radio systems may be designed to use one or more connection topology. Wireless network topologies can be characterized as being single hop or multi-hop. Multi-hop topology can be statically configured, or can be dynamically configured and self-forming. A mesh network is a multi-hop network that contains multiple connection paths between nodes.

55. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 55 Mesh Disclaimer text The original question in the Group 11 “Connection Topologies” portion of the matrix to which SDOs responded asked if “mesh” was supported. There was no definition of “mesh” provided. After the responses were received it was determined that a definition should have been provided to normalize responses. The following definition for mesh was added. Mesh Network: A mesh network is a multi-hop network that contains multiple connection paths between nodes.

56. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 56 Hop Disclaimer text The original question in the Group 11 “Connection Topologies” portion of the matrix to which SDOs responded did not ask if hop connections were supported. After the responses were received the following definition for hop connections were added. 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). 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.

57. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 57 xcast Disclaimer text The original question in the Group 7 “Data Frames and Packets” portion of the matrix to which SDOs responded assumed a unicast mode was used and did not ask for characterization using unicast, multicast and broadcast modes nor did it ask if these modes were supported. After the responses were received the following definitions for casting modes were added. 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.

58. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 58 16m matrix revision

59. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 59 July 2010 Smart Grid Tutorial

60. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 60 Other activities

61. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 61 Agenda Topics for the Week Action Item Finalize change suggestions for the NIST PAP#2 Report Information Items SGIP update OpenSG update P2030 update ITU Focus Group March Tutorial topics/speakers

62. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 62 Smart Energy Projects Bluetooth Smart Energy CEN, CENELEC, ETSI Focus Group on standards for the Smart Grid European Commission Task Force on Smart Grids EUTC, ICT4SDG (European Utilities Telecom Council, ICT for Smart Distributed Generation) GMC (Grid Modernization Collaborative) GWAC (GridWise Architecture Council) IEC, Strategic Group 3 on Smart Grid IEEE Smart Grid Initiative IETF ISO/IEC JTC 1 SWG Smart Grid ITU-T FG Smart (Focus Group Smart Grid) ITU-T Study Groups 5 and 15 KSGA (Korea Smart Grid Association) KSGI (Korea Smart Grid Institute) Next Generation Energy Study Group, Japan NIST Smart Grid Interoperability Standards Project OASIS Blue Initiative SEESGEN-ICT (Supporting Energy Efficiency in Smart GENeration grids through ICT) SGA (Smart Grid Australia) SGCC (State Grid Corporation of China) SIP Forum Smart Grid Special Interest Group UCA IUG OpenSG (UCA International Users Group, Open Smart Grid) U.S. Department of Energy, OE ZigBee Alliance Smart Energy

63. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 63 Agenda Topics for the Week Action Item Finalize change suggestions for the NIST PAP#2 Report Information Items SGIP update OpenSG update P2030 update ITU Focus Group March Tutorial topics/speakers

64. 64 November 20106/8/2010 Bruce Kraemer, MarvellFooter for this presentation CATALOG OF STANDARDS 6/2/2015 Mark Klerer SGIP Plenary Vice Chair

65. 65 Plenary leadership team working in conjunction with SGAC and other SGIP working groups Proposed Scope of the Standards Catalog – Standards and guides recognized as relevant for enabling SG capabilities Proposed Objectives of the Standards Catalog – Explain value & purpose of the catalog for SG community – Influential, but independent of NIST/FERC decision-making – Characterize the various specification organizations with respect to their processes in developing their specifications – Provide an annotated resource that identifies standards created by recognized SSOs and/or industry consortia that are relevant to Smart Grid applications – Identify functional areas of smart grid where each standard is appropriate (draw on SGAC work) C ATALOG OF S TANDARDS (S TATUS OF W ORK IN P ROGRESS )

66. 66 Process – NIST Framework and Roadmap for SG Interoperability v1.0 identifies many standards to consider – Additional standards can be identified to the SGIP Administrator by any SGIP member for potential inclusion in catalog – Relevance and importance evaluated by appropriate SGIP working group (e.g. DEWG, PAP, etc) and consensus developed – 75% approval by SGIP membership required prior to SGIPGB approval for inclusion in the catalog – Standards included in the catalog may be deprecated from further use to changes in technology or needs by following the same process. Catalog Structure – Entries in catalog to be structured based on application domain defined in the Framework and further classified by GWAC stack Relationship to NIST and FERC lists – Standards Catalog strives for accurate characterization and relevance to the smart grid community, and avoids recommendation – Standards Catalog expected to be a larger compilation which can inform NIST and FERC in their decision processes C ATALOG OF S TANDARDS : P ROCESS & S TRUCTURE CATALOG OF STANDARDS: PROCESS & STRUCTURE

67. 67 November 20106/8/2010 Bruce Kraemer, MarvellFooter for this presentation TESTING & CERTIFICATION COMMITTEE 6/2/2015 Rik Drummond SGTCC Chair

68. 68 November 2010 Bruce Kraemer, Marvell 68 P URPOSE Establish a Testing and Certification Framework for the Smart Grid Establish a brand called ‘Interoperability’ that has a consistent meaning across the Smart Grid for the buyers of interoperable products. – At this time a set of products deemed interoperable may be interoperable with a 80%, 95%, 99%, or 100% confidence level. Thus to say a product is interoperable has little current meaning in the market place as many purchasing organizations have found.

69. 69 November 20106/8/2010 Bruce Kraemer, MarvellFooter for this presentation 69 Deliverables  D3 – Interoperability Process Reference Manual (IPRM) is being finalized for SGIP review.  Interoperability Maturity Assessment Tool completed Activities and Accomplishments  D3 – Interoperability Process Reference Manual (IPRM) completed 1 st review and comment period during St. Louis meetings; comment resolution and final editing remains in progress  Began piloting IPRM with several Interoperability Testing and Certification Authorities (ITCA) who have expressed willingness to cooperate and participate in assessing their organizations against the IPRM recommendations.  Prepared draft ITCA audit process document and checklist in preparation for ITCA reviews  Launched discussion with accreditation bodies for future independent ITCA reviews Upcoming Key Milestones and Activities  Presentation on SGTCC framework and plan to the SGIP on October 29 to build awareness and support for the process  Completing 2-3 ITCA reviews by late November  Updates to the IPRM based on experience gathered during the ITCA review process, and revision/release in early January  Engaging with the CSWG testing sub-team to coordinate security related testing issues Issues, Concerns, and Help Needed  Obtaining timely cooperation from the ITCAs to participate in the review process with the TCC, and accelerating their commitment to adopt and enact the SGTCC recommendations in their operations  Engaging end users to gain their commitment towards requiring IPRM conformance for ITCAs certifying the products that they purchase October 2010 Activities - PMO Monthly Report SGTCC M ONTHLY Q UAD C HART SGTCC MONTHLY QUAD CHART

70. 70 November 2010 Bruce Kraemer, Marvell 70 D EFINITIONS ITCA – Interoperability Testing and Certification Authority Framework Manual - IPRM – Interoperability Program Reference Manual ISO 65 - General Requirements for Bodies Operating Product Certification Systems ISO 17025 – General Requirements for the Competence of Testing and Calibration Laboratories SGTCC Interoperability Test Construction Best Practices – Lists of best practices not covered in ISO 65 and ISO 17025 SGTCC/CSWG Cyber Security Testing Best/Standard Practices –List of best practices not covered in ISO 65 and ISO 17025 Interoperability Maturity Assessment Model – looking for IOP products based on standards NOW.

71. 71 November 20106/8/2010 Bruce Kraemer, MarvellFooter for this presentation 71 G ENERAL S TRUCTURE OF THE F RAMEWORK M ANUAL GENERAL STRUCTURE OF THE FRAMEWORK MANUAL ISO Guide 17025 ISO Guide 65 Best Practices for IOP Test Construction Best/Standard Practices for Cyber Security Test Construction Introduction, Responsibilities, Rationale, Usage and Checklists 2011 Transition Bootstrap Support Plan for ITCAs Evaluation Checklist for ITCA Delta to Manual Framework Manual

72. 72 November 2010 Bruce Kraemer, Marvell 72 ISO Guide 65 contains the requirements necessary for an organization to demonstrate competence to perform certification activities related to the standards or specifications stated in the certification ISO Guide 65 criteria include: – Technical competence Certifying personnel criteria; accessibility of certification test processes; assessment fairness and integrity and others – Management systems Quality management processes, technical dispute resolution processes Lab qualification criteria, lists of certified products, record control, ongoing certification maintenance and withdrawal process ISO Guide 65 conformance demonstrates a robust, thorough and meaningful certification program Implements a monitoring program for IOP products in the field to ensure IOP remains ISO G UIDE 65 O VERVIEW

73. 73 ISO 17025 contains all requirements that laboratories need to demonstrate that they – operate a management system, – are technically competent, – are able to generate technically valid results. ISO 17025 is the most widely accepted and used standard for the operation of test laboratories ISO 17025 applies to any testing laboratory operation (1 st, 2 nd or 3 rd party), with many 3 rd party labs formally accredited It facilitates acceptance of test results from accredited laboratories and serves as the requirements that formal accreditation bodies apply in assessing laboratories. ISO 17025 O VERVIEW ISO 17025 OVERVIEW

74. 74 November 2010 Bruce Kraemer, Marvell 74 – Test Suite Specification of a standard used for interoperability or conformance testing shall be managed in the same way as the standard they are derived from. – IOP Certification test reports shall fully describe the test methodology used including the justification for statistical or deterministic testing. – A certified interoperable product set shall also be conformant to the standard or profile of the standard. – The only means to ensure interoperability among products is to perform a full matrix test. B EST P RACTICES FOR IOP TEST CONSTRUCTION EXAMPLES

75. 75 November 2010 Bruce Kraemer, Marvell 75 2011 T RANSITION B OOTSTRAP YEAR SGTCC, with NIST will help bootstrap the process by offering tutorial help in 2011 to the first few committed ITCAs. – Preliminary review of implementation of ISO 65 and ISO 17025 implemented processes. – Review and analysis of interoperability test construction best practices. – Other general guidance. Maintain a list for the industry showing ITCAs in the process of implementing the Manual.

76. 76 November 2010 Bruce Kraemer, Marvell 76 2011 T RANSITION B OOTSTRAP YEAR SGTCC, with NIST will help bootstrap the process by offering tutorial help in 2011 to the first few committed ITCAs. – Preliminary review of implementation of ISO 65 and ISO 17025 implemented processes. – Review and analysis of interoperability test construction best practices. – Other general guidance. Maintain a list for the industry showing ITCAs in the process of implementing the Manual.

77. 77 November 2010 Bruce Kraemer, Marvell 77 2012 AND B EYOND ITCAs will be using Test Labs using ISO 17025, and ISO 65 standards and be accredited by the existing formal accreditation organizations. SGTCC will maintain lists of SGIP Approved ITCAs (those implementing the Manual) for a standard and demonstrating the production of interoperable products. The products of the standard will be monitored for interoperability in the field by ITCA and secondarily by SGTCC Accreditation Bodies (e.g., NVLAP and ANSI) will periodically audit test labs and certification bodies using the Manual as guidance and re-accredit them. SGTCC will subsequently update the ‘SGIP ITCA Approved List ’. Note many Test lab now use ISO 17025, but not the IOP best practices. Also many ITCAs do not use ISO 65.

78. 78 November 2010 Bruce Kraemer, Marvell 78 N EXT S TEPS AND Y OUR R ESPONSE Receive SGIP consensus for Manual / Framework Each SGIP member MUST REQUIRE the purchase of interoperable products to initiate the monetary incentive for many of the ITCAs to upgrade to the Manual / Framework. – Note: this is an issue about wide scale interoperability across the smart grid. Having only a percentage requiring interop products will in many ways leave us in our current state. SGTCC will offer two Webinars in late November and early December to address questions and concerns. To be announced.

79. 79 November 2010 Bruce Kraemer, Marvell 79 GB Election Timeline – Even Stakeholders, 2010

80. 80 November 2010 Bruce Kraemer, Marvell 80 UPCOMING 2010 PLENARY EVENTS 30 Nov – 3 Dec: Grid-Interop, Chicago – See http://www.grid-interop.com/2010/#agenda for detailed agendahttp://www.grid-interop.com/2010/#agenda Mon. 11/29 Tue. 11/30 Wed. 12/1 Thu. 12/2 Fri. 12/3 8.00 am GB Meeting 10.30 am PAPs & WGs 12.00 pmLUNCH 1.00 pm Optional Meetings Opening Plenary Closing Plenary 3.30 pm DEWGs & Committees PAPs & WGs Optional Meetings 5.00 pm Candidate Interviews and Optional Meetings 7.00 pm PAPs & WGs 9.00 pm

81. 81 November 2010 Bruce Kraemer, Marvell 81 2011 Plenary Meeting Schedule MonthDateTimeDetail Jan211 – 3 p.m.Virtual Meeting/Conf. Call Feb Mar29-31All DayF2F: Nashville likely Apr May261 – 3 p.m.Virtual Meeting/Conf. Call hosted @ ConnectivityWeek Jun Jul12-14All DayF2F: Montreal, Canada – International theme Aug Sep151 – 3 p.m.Virtual Meeting/Conf. Call hosted @ GridWeek Oct Nov Dec5-8All DayF2F: Grid-Interop, Phoenix

82. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 82 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. 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

83. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 83 ITU FG Smart Fourth meeting Chicago, USA, 29 November – 3 December 2010 Registration form Meeting Announcement Meeting documents Deadline for Contributions: 25 November 2010Meeting documents Fifth meeting Yokohama, Japan, 10-14 January 2011 Registration form Meeting Announcement Meeting documents http://www.itu.int/en/ITU-T/focusgroups/smart/Pages/Default.aspx

84. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 84 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)

85. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 85 UK Smart Metering - Introduction Reference Number: 10D/732 Open Date: 2010-07-27 Close Date: On 27 July 2010, the Government with Ofgem published a Prospectus containing proposals for the delivery of electricity and gas smart metering in Great Britain. This covers both domestic households and small and medium non-domestic sites. The Prospectus document, which represents the joint views of the Department of Energy and Climate Change (DECC) and the Gas and Electricity Markets Authority (GEMA), sets out proposals for and asks for views on how smart metering will be delivered, including on issues relating to: –the minimum requirements for meters and displays –the establishment of central communications and data services –data privacy and security issues –the regulatory and commercial framework –the approach to small and medium sites in the non-domestic sector –consumer protection –the approach to rollout and –the implementation strategy http://www.decc.gov.uk/en/content/cms/consultations/smart_mtr_imp/smart_mtr_imp.aspx

86. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 86 Ofgem, DECC, GEMA Ofgem is the Office of the Gas and Electricity Markets. Protecting consumers is our first priority. We do this by promoting competition, wherever appropriate, and regulating the monopoly companies which run the gas and electricity networks. The interests of gas and electricity consumers are their interests taken as a whole, including their interests in the reduction of greenhouse gases and in the security of the supply of gas and electricity to them. Ofgem is governed by GEMA, which consists of non-executive and executive members and a non-executive chair. GEMA is the Gas and Electricity Markets Authority (DECC) The Department of Energy and Climate Change was created in October 2008

87. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 87 DECC & Ofgem supporting documents Impact assessment: GB-wide smart meter roll out for the domestic sectorImpact assessment: GB-wide smart meter roll out for the domestic sector Size: [516 KB] File Type: [.pdf] Impact assessment: GB-wide advanced/smart meter roll out to small and medium non-domestic sitesImpact assessment: GB-wide advanced/smart meter roll out to small and medium non-domestic sites Size: [296 KB] File Type: [.pdf] Disablement / enablement functionality for smart gas metersDisablement / enablement functionality for smart gas meters Size: [99 KB] File Type: [.pdf] Analysis on disablement/ enablement functionality for smart gas metersAnalysis on disablement/ enablement functionality for smart gas meters Size: [656 KB] File Type: [.pdf] Smart Metering implementation programme: statement of design requirementsSmart Metering implementation programme: statement of design requirements Size: [713 KB] File Type: [.pdf] Smart Metering implementation programme: communications business modelSmart Metering implementation programme: communications business model Size: [1,011 KB] File Type: [.pdf] Smart Metering implementation programme: implementation strategySmart Metering implementation programme: implementation strategy Size: [560 KB] File Type: [.pdf] Smart Metering implementation programme: rollout strategySmart Metering implementation programme: rollout strategy Size: [608 KB] File Type: [.pdf] Smart Metering implementation programme: regulatory and commercial frameworkSmart Metering implementation programme: regulatory and commercial framework Size: [650 KB] File Type: [.pdf] Smart Metering implementation programme: non-domestic sectorSmart Metering implementation programme: non-domestic sector Size: [419 KB] File Type: [.pdf] Smart Metering implementation programme: consumer protectionSmart Metering implementation programme: consumer protection Size: [411 KB] File Type: [.pdf] Smart Metering implementation programme: data privacy and securitySmart Metering implementation programme: data privacy and security Size: [303 KB] File Type: [.pdf] Smart Metering implementation programme: in-home displaySmart Metering implementation programme: in-home display Size: [392 KB] File Type: [.pdf] Consumers’ views of Smart Metering: report by FDS InternationalConsumers’ views of Smart Metering: report by FDS International Size: [948 KB] File Type: [.pdf] http://www.decc.gov.uk/en/content/cms/consultations/smart_mtr_imp/smart_mtr_imp.aspx

88. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 88 http://www.decc.gov.uk/assets/decc/Consultations/smart-meter-imp-prospectus/225-smart-metering-imp-programme-design.pdf

89. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 89 Doc 233 – In Home Display Question 1: We welcome views on the level of accuracy which can be achieved and which customers would expect, in particular in relation to consumption in pounds and pence. Question 2: We welcome evidence on whether information on carbon dioxide emissions is a useful indicator in encouraging behaviour change, and if so, how it might be best represented to consumers. Question 3: We welcome views on the issues with establishing the settings for ambient feedback. Question 4: Do you think that there is a case for a supply licence obligation around the need for appropriately designed IHDs to be provided to customers with special requirements, and/or for best practice to be identified and shared once suppliers start to roll out IHDs? Question 5: We welcome evidence on whether portability of IHDs has a significant impact on consumer behavioural change. Question 6: Do you agree with the proposed minimum functional requirements for the IHD? Question 7: Do you have any views or evidence relating to whether innovation could be hampered by requiring all displays to be capable of displaying the minimum information set for both fuels? Question 8: Do you agree with the proposals covering the roles of and obligations on suppliers in relation to the IHD?

90. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 90 Doc 232 - Privacy and Security CHAPTER 3 Question 1: Do you have any comments on our overall approach to data privacy? Question 2: We seek views from stakeholders on what level of data aggregation and frequency of access to smart metering data is necessary in order for industry to fulfil regulated duties. Question 3: Do you support the proposal to develop a privacy charter? Question 4: What issues should be covered in a privacy charter? CHAPTER 4 Question 5: Do you agree with our approach for ensuring the end- to-end smart metering system is appropriately secure?

91. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 91 Doc 230 – Non-Domestic Sector CHAPTER 3 Question 1: Are there any technical circumstances where only advanced rather than smart metering would be technically feasible? How many smaller non-domestic customers have U16 or CT meters and what scope is there for full smart meter functionality to be added in these cases? Question 2: Do you agree with our proposed approach to exceptions in the smaller non-domestic sector? Question 3: Are there technical circumstances that we have not considered that would justify further flexibility around installation of either smart or advanced meters? CHAPTER 4 Question 4: Do you agree with the proposed approach that use of DCC should be optional for non- domestic participants in the sector? Question 5: If use of DCC is not mandated for non-domestic customers, do you agree with the proposed approach as to how it offers its services and the controls around such offers? Question 6 To what extent does our proposed approach to the use of DCC for non-domestic customers present any significant potential limitations for smart grids? Question 7: Is a specific licence condition required to ensure that metering data for non-domestic customers can be provided to network operators or DCC, and should any provision be made for charging network operators for the costs of delivering such data? Question 8: How can interoperability best be secured in the smaller non-domestic sector? CHAPTER 5 Question 9: What steps are needed to ensure that customers can access their data, and should the level of data provision and the means through which it is provided to individual customers or premises be a matter for contract between the customer and the supplier or should minimum requirements be put in place? Question 10: Do you agree with our approach to data privacy and security for non-domestic customers? Question 11: Is the proposed approach to rollout (for example in terms of targets and a requirement for an installation code of practice) appropriate for the non-domestic sector?

92. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 92 Doc 229 – Regulatory & Commercial Framework CHAPTER 2 Question 1: Have we identified all of the key elements that you would expect to see as part of the Smart Metering Regulatory Regime? CHAPTER 3 Question 2: Do you agree with the proposal to establish a Smart Energy Code? Question 3: Do you have any comments on the indicative table of contents for the Smart Energy Code as set out in Appendix 3? Question 4: Do you have any comments on the most appropriate governance arrangements for the Smart Energy Code? CHAPTER 4 Question 5: Do you agree with the proposals concerning the roles and obligations of suppliers in relation to the WAN communications module? Question 6: We welcome views as to which other additional data items should be included in the mandated HAN data set beyond the list for the IHD. Question 7: Do you agree with the proposal that the WAN and the HAN in customer premises should be shared infrastructure, with the installing supplier retaining responsibility for ongoing maintenance? If not, would you prefer to have an arrangement by which if the gas supplier is the first to install, responsibilities for the common equipment is transferred to the electricity supplier when the electricity smart meter is installed? CHAPTER 5 Question 8: Are there additional measures that should be put in place to reduce the risks to the programme generated by early movers? Question 9: What is needed to help ensure commercial interoperability? Question 10: Can current arrangements for delivering technical assurance be developed to gain cost effective technical assurance for the smart metering system? If so, how would these procedures be developed and governed? Question 11: Are there any other regulatory and commercial issues that the programme should be addressing? CHAPTER 6 Question 12: What evolution do you expect in the development of innovative time-of-use tariffs? Are there any barriers to their introduction that need to be addressed? Question 13: Are there changes to settlement arrangements in the electricity or gas sectors that are needed to realise the benefits of smart metering? Question 14: What arrangements would need to be put in place to ensure that customers located on independent networks have access to the same benefits of smart metering as all other customers? Question 15: Are there any other industry processes that will be affected by smart metering and which the programme needs to take into account?

93. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 93 Doc 228 – Rollout Strategy CHAPTER 2 Question 1: Do you believe that the proposed approach provides the right balance between supplier certainty and flexibility to ensure the successful rollout of smart meters? If not, how should this balance be addressed? Question 2: Would the same approach be appropriate for the non-domestic sector as for the domestic sector? Question 3: Is there a case for special arrangements for smaller suppliers? CHAPTER 3 Question 4: What is the best way to promote consumer engagement in smart metering? As part of broader efforts, do you believe that a national awareness campaign should be established for smart metering? If so, what do you believe should be its scope and what would be the best way to deliver it? Question 5: How should a code of practice on providing customer information and support be developed and what mechanisms should be in place for updating it over time? CHAPTER 4 Question 6: Do you agree with the proposed obligation on suppliers to take all reasonable steps to install smart meters for their customers? How should a completed installation be defined? Question 7: Do you think that there is a need for interim targets and, if so, at what frequency should they be set? Question 8: Do you have any views on the form these targets should take and whether they should apply to all suppliers? Question 9: What rate of installation of smart meters is achievable and what implications would this have? CHAPTER 5 Question 10: Do you have any evidence to show that there are benefits or challenges in prioritising particular consumer groups or meter types? CHAPTER 6 Question 11: Do you agree with our proposed approach to requiring suppliers to report on progress with the smart meter rollout? What information should suppliers be obliged to report and how frequently? CHAPTER 7 Question 12: Do you agree that there is already adequate protection in place dealing with onsite security or are there specific aspects that are not adequately addressed? Question 13: Do you agree with our proposal to require suppliers to develop a code of practice around the installation process? Are there any other aspects that should be included in this code of practice?

94. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 94 Doc 234 – Implementation Strategy CHAPTER 2 Question 1: Do you have any comments on our proposed governance and management principles or on how they can best be delivered in the context of this programme? CHAPTER 3 Question 2: Are there other cross-cutting activities that the programme should undertake and, if so, why? CHAPTER 5 Question 3: Do you agree with our proposal for a staged approach to implementation, with the mandated rollout of smart meters starting before the mandated use of DCC for the domestic sector? Question 4: Do you have any comments on the risks we have identified for staged implementation and our proposals on how these could best be managed? Question 5: Do you have any other suggestions as to how the rollout could be brought forward, including the work to define technical specifications, which relies on industry input? Question 6: Do you agree with our planning assumption that a period of six months will be needed between the date when supply licence obligations mandating rollout are implemented and the date when they take effect? Question 7: Do you have any comments on the activities, assumptions, timings and dependencies presented in the high-level implementation plan? Question 8: Do you have any comments on the outputs identified for each of the phases of the programme?

95. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 95 Doc 226 – Communications Business Model CHAPTER 2 Question 1: Do you agree that access control to secure centrally-coordinated communications, translation services and scheduled data retrieval are essential as part of the initial scope of DCC? Question 2: Do you agree that meter registration should be included within DCC’s scope and, if so, when? Question 3: Should data processing, aggregation and storage be included in DCC’s scope and, if so, when? Question 4: Do any measures need to be put in place to facilitate rollout in the period before DCC service availability and the transition to provision of services by DCC, for example requiring DCC to take on communications contracts meeting certain pre-defined criteria? CHAPTER 3 Question 5: Do you agree that the licensable activity for DCC should cover procurement and management of contracts for the provision of central services for the communication and management of smart metering data? Question 6: Do you consider that DCC should be an independent company from energy suppliers and/or other users of its services and, if so, how should this be defined? Question 7: Do you have any comments on the steps DCC would need to take to be in a position to provide its services and the likely timescales involved? Question 8: Do you have any comments on the proposed approach to cost recovery and incentivisation for DCC?

96. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 96 Doc 225 – Design Requirements CHAPTER 3 Question 1: Should the HAN hardware be exchangeable without the need to exchange the meter? Question 2: Are suitable HAN technologies available that meet the functional requirements? Question 3: How can the costs of switching between different mobile networks be minimised particularly in relation to the use of SIM cards and avoiding the need change out SIMs? Question 4: Do you believe that the Catalogue is complete and at the required level of detail to develop the technical specification? Question 5: Do you agree that the additional functionalities beyond the high-level list of functional requirements are justified on a cost benefit basis? Question 6: Is there additional or new evidence that should cause those functional requirements that have been included or omitted to be further considered? CHAPTER 5 Question 7: Do you agree that the proposed approach to developing technical specifications will deliver the necessary technical certainty and interoperability? Question 8: Do you agree it is necessary for the programme to facilitate and provide leadership through the specification development process? Is there a need for an obligation on suppliers to co-operate with this process? Question 9: Are there any particular technical issues (e.g. associated with the HAN) that could add delay to the timescales? Question 10: Are there steps that could be taken which would enable the functional requirements and technical specifications to be agreed more quickly than the plan currently assumes?

97. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 97 Doc 220 - Prospectus CHAPTER 2 (responses requested by 28 October except for asterisked questions, where responses are requested by 28 September) Question 1: Do you have any comments on the proposed minimum functional requirements and arrangements for provision of the in-home display device? Question 2: Do you have any comments on our overall approach to data privacy? Question 3*: Do you have any comments on the proposed approach to ensuring customers have a positive experience of the smart meter rollout (including the required code of practice on installation and preventing unwelcome sales activity and upfront charging)? Question 4: Have we identified the full range of consumer protection issues related to remote disconnection and switching to prepayment? Question 5: Do you have any comments on the proposed approach to smaller non-domestic consumers (in particular on exceptions and access to data)? CHAPTER 3 (responses requested by 28 October except for asterisked questions, where responses are requested by 28 September) Question 6*: Do you have any comments on the functional requirements for the smart metering system we have set out in the Functional Requirements Catalogue? Question 7*: Do you see any issues with the proposed approach to developing technical specifications for the smart metering system? Question 8: Do you have any comments on the proposals that energy suppliers should be responsible for purchasing, installing and, where appropriate, maintaining all customer premises equipment? Question 9: Do you have any comments on the proposal that the scope of activities of the central data and communications function should be limited initially to those functions that are essential for the effective transfer of smart metering data, such as data access and scheduled data retrieval? Question 10: Do you have any comments on the proposal to establish DCC as a procurement and contract management entity that will procure communications and data services competitively? Question 11: Do you have any comments on the proposed approach for establishing DCC (through a licence awarded through a competitive licence application process with DCC then subject also to the new Smart Energy Code)? Question 12: Does the proposal that suppliers of smaller non-domestic customers should not be obliged to use DCC services but may elect to use them cause any substantive problems? Question 13: Do you agree with the proposal for a Smart Energy Code to govern the operation of smart metering? Question 14: Have we identified all the wider impacts of smart metering on the energy sector? Question 15: Is there anything further we need to be doing in terms of our ensuring the security of the smart metering system? Question 16*: Do you have any comments on the proposals for requiring suppliers to deliver the rollout of smart meters (including the use of targets and potential future obligations on local coordination)? CHAPTER 4 (responses requested by 28 September) Question 17*: Do you have any comments on our implementation strategy? In particular, do you have any comments on the staged approach, with rollout starting before DCC services are available? Question 18*: Do you have any other suggestions on how the rollout could be brought forward? If so, do you have any evidence on how such measures would impact on the time, cost and risk associated with the programme? Question 19*: The proposed timeline set out for agreement of the technical specifications is very dependent on industry expertise. Do you think that the technical specifications can be agreed more quickly than the plan currently assumes and, if so, how? Question 20*: Do you have any comments on our proposed governance and management principles or on how they can best be delivered in the context of this programme?

98. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 98 Doc 231 – Consumer Protection CHAPTER 2 Question 1: Do you have any views on our proposed approach for addressing potential tariff confusion? What specific steps can be taken to safeguard the consumer from tariff confusion while maintaining the benefit of tariff choices? Question 2: Do you agree with our proposed approach for addressing unwelcome sales activities during visits for meter installation? Question 3: What do you consider as acceptable and unacceptable uses of the installation visit and why? Question 4: Do you agree with our proposed approach to ensuring that the IHD is not used to transmit unwelcome marketing messages? Question 5: Do you agree that consumers should be able to obtain consumption information free of charge at a useful level of detail and format? How could this be achieved in practice? CHAPTER 3 Question 6: Do you consider that existing protections in the licence are sufficient to ensure that consumers are not remotely switched to prepayment mode inappropriately? Question 7: Could provision of an appropriate IHD help overcome meter accessibility issues to facilitate prepayment usage? Question 8: What notification should suppliers be required to provide before switching a customer to prepayment mode? Question 9: Do you believe that suppliers should be required to provide emergency credit and ‘friendly credit’ periods to prepayment customers or whether, as now, this can be left to suppliers? Question 10: Do you consider that an obligation similar to Prepayment Meter Infrastructure Provision (PPMIP) may be required? Question 11: Is the obligation which Ofgem is proposing to introduce on suppliers to take all reasonable steps to check whether the customer is vulnerable ahead of disconnection sufficient? If not, what else is needed? Question 12: What notification should suppliers be required to provide before disconnecting a customer? Question 13: Do you have any views on the acceptability of new approaches to partial disconnection and how they might be used as an incentive to pay bills? Question 14: Do you agree with our approach for addressing issues related to remote disconnection and switching to prepayment? Question 15: Have we identified the full range of consumer protection issues associated with the capability to conduct remote disconnection or switching from credit to prepayment terms? If not, please identify any additional such issues. CHAPTER 4 Question 16: What information, advice and support might be provided for vulnerable consumers (e.g. a dedicated help scheme)? Who should it be provided to? CHAPTER: Five Question 17: Do you have any comments on our proposals to prevent upfront charging for the basic model of smart meters and IHDs?

99. doc.: IEEE 802.11-10/1316r3 Submission November 2010 Bruce Kraemer, MarvellSlide 99 UK Consultation documents Consultation documents Smart Metering implementation programme: prospectus - letter to consultees Size: [50 KB] File Type: [.doc]Smart Metering implementation programme: prospectus - letter to consultees Smart Metering implementation programme: prospectus document Size: [786 KB] File Type: [.pdf]Smart Metering implementation programme: prospectus document http://www.decc.gov.uk/en/content/cms/consultations/smart_mtr_imp/smart_mtr_imp.aspx