Doc.: IEEE 802.11-10/1385r0 Submission November 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid...

November 2010

Bruce Kraemer, Marvell

Slide 1

doc.: IEEE 802.11-10/1385r0

Submission

Smart Grid Discussions – November 2010

Date: 2010-November-10

Abstract: NIST PAP#2 Report r6 recommended changesOther Smart Grid activities

Name Company Address Phone emailBruce Kraemer Marvell 5488 Marvell Lane,

Santa Clara, CA, 95054

+1-321-751-3988 [email protected]

Jorjeta Jetcheva Itron

November 2010


Slide 2

doc.: IEEE 802.11-10/1385r0

Submission

Agenda Topics for the 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

November 2010


Slide 3

doc.: IEEE 802.11-10/1385r0

Submission

Report Changes

November 2010


Slide 4

doc.: IEEE 802.11-10/1385r0

Submission

NIST Timeline

Release of draft 0.6

Release of Version 1

Draft 0.5July 28, 2010

Call for Input to Section 6August 4, 2010

End of draft 0.5 review periodSeptember 15, 2010

December 3, 2010

November 4, 2010

SGIP face-to-face, ChicagoPAP 2 meeting

OpenSG meeting, MiamiTentative PAP 2 meeting

SGIP face-to-face, St LouisTentative PAP 2 meeting

September 16, 2010

End of draft 0.6 review period

September 30, 2010

October 29, 2010

November 2010


Slide 5

doc.: IEEE 802.11-10/1385r0

Submission

PAP#2 Report was updated Oct 1

• http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP02Wireless/NIST_Priority_Action_Plan_2_r06.pdf

November 2010


Slide 6

doc.: IEEE 802.11-10/1385r0

Submission

NIST PAP#2 Report v6 – Section 44.1 Technology Descriptor HeadingsTo be able to describe wireless technology a set of characteristics were identified andorganized 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

November 2010


Slide 7

doc.: IEEE 802.11-10/1385r0

Submission

•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

November 2010


Slide 8

doc.: IEEE 802.11-10/1385r0

Submission

Material for this meeting

r6+change suggestions

Section 4 edited

Matrix v5+changes

Section 4 edited

November 2010


Slide 9

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 10

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 11

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 12

doc.: IEEE 802.11-10/1385r0

Submission

Add these definitions to Section 2.2Broadcast• 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.

November 2010


Slide 13

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 14

doc.: IEEE 802.11-10/1385r0

Submission

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?

November 2010


Slide 15

doc.: IEEE 802.11-10/1385r0

Submission

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

November 2010


Slide 16

doc.: IEEE 802.11-10/1385r0

Submission

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

November 2010


Slide 17

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 18

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 19

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 20

doc.: IEEE 802.11-10/1385r0

Submission

Comment 07bAdd 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.

November 2010


Slide 21

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 22

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 23

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 24

doc.: IEEE 802.11-10/1385r0

Submission

General Comment #11Section 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.

November 2010


Slide 25

doc.: IEEE 802.11-10/1385r0

Submission

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

November 2010


Slide 26

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 27

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 28

doc.: IEEE 802.11-10/1385r0

Submission

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.

November 2010


Slide 29

doc.: IEEE 802.11-10/1385r0

Submission

MESH Disclaimer text

• After the responses were received from the SDO to the original mesh question the following definition for mesh was added.

November 2010


Slide 30

doc.: IEEE 802.11-10/1316r2

Submission

Add these definitions to Section 2.2Broadcast• 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.

November 2010


Slide 31

doc.: IEEE 802.11-10/1316r2

Submission

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.



November 2010


Slide 32

doc.: IEEE 802.11-10/1316r2

Submission

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.


November 2010


Slide 33

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 34

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 35

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 36

doc.: IEEE 802.11-10/1316r2

Submission

• Completely inter-connected via nearest neighbor

• Star topology

November 2010


Slide 37

doc.: IEEE 802.11-10/1316r2

Submission


• Representation of mesh network

• Partially complete example of fully inter-connected network

November 2010


Slide 38

doc.: IEEE 802.11-10/1316r2

Submission


• 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

November 2010


Slide 39

doc.: IEEE 802.11-10/1316r2

Submission

• 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

November 2010


Slide 40

doc.: IEEE 802.11-10/1316r2

Submission

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.

November 2010


Slide 41

doc.: IEEE 802.11-10/1316r2

Submission

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.

November 2010


Slide 42

doc.: IEEE 802.11-10/1316r2

Submission

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.

November 2010


Slide 43

doc.: IEEE 802.11-10/1316r2

Submission

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.



• Statically Configured Multi-Hop Network: A multi-hop network can be statically configured, such that each node’s forwarding decisions are dictated by configuration.


November 2010


Slide 44

doc.: IEEE 802.11-10/1316r2

Submission

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.

November 2010


Slide 45

doc.: IEEE 802.11-10/1316r2

Submission

16m matrix revision

draft 16m revision

November 2010


Slide 46

doc.: IEEE 802.11-10/1316r2

Submission

July 2010 Smart Grid TutorialIntroductions

1 Introduction to Information Event2 Introduction to Smart Grid - What is it?

3 Other Multi-national & InternationalJTC1

Special Working GroupIEEE

IEEE project list15.4gP2030 seriesP19011547 series

4 EuropeIEC

Global Standards for the Smart Grid SG3 – Smart Grid Standardization Roadmap

ITUSmart Grid Standards InitiativeG.hn

ECDirective 2006/32/EC Smart Grids Task ForceM/441 European Open Meter Mandate

CENStandardisation Mandate concerning the charging of electric vehicles

CENELECETSI

Primarily US CentricNIST SGIP – Mark

PAPsSGACSGTCCCyber Security

SAE – Mark standards that can be used now to support Smart Grid development:

SAE J1772 Electrical Connector between PEV and EVSE SAE J2293 Communications between PEVs and EVSE for DC Energy SAE J2836/1-3 Use Cases for PEV Interactions (in development) SAE J2847/1-3 Communications for PEV Interactions (in development

Open SG

Energy STAREPRI – Unified Metrics – Slide from EPRIGWAC – Grid Wise Architecture Council

IETF - Joseph Reddy (TI)6LoWPAN (RFCs: 4944, 4919)Roll (RFCs: 5867, 5826, 5673, 5548)

ZigBee SEP

AHAM – Association of Home Appliance ManufacturersThe Future for Appliances in the Smart Grid

Japan and AsiaJapan, Other

November 2010


Slide 47

doc.: IEEE 802.11-10/1316r2

Submission

• Other activities

November 2010


Slide 48

doc.: IEEE 802.11-10/1316r2

Submission


Action Item


• Information Items

• SGIP update

• OpenSG update

• P2030 update

• ITU Focus Group


November 2010


Slide 49

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 50

doc.: IEEE 802.11-10/1316r2

Submission


Action Item


• Information Items

• SGIP update

• OpenSG update

• P2030 update

• ITU Focus Group


51November 20106/8/2010

Bruce Kraemer, MarvellFooter for this presentation

CATALOG OF STANDARDSCATALOG OF STANDARDS

04/20/23

Mark KlererSGIP Plenary Vice Chair

5252

CATALOG OF STANDARDS (STATUS OF WORK IN CATALOG OF STANDARDS (STATUS OF WORK IN PROGRESS)PROGRESS)

5353

• 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

CATALOG OF STANDARDS: PROCESS & CATALOG OF STANDARDS: PROCESS & STRUCTURESTRUCTURE

54November 20106/8/2010

Bruce Kraemer, MarvellFooter for this presentation

TESTING & CERTIFICATION COMMITTEETESTING & CERTIFICATION COMMITTEE

04/20/23

Rik DrummondSGTCC Chair

55November 2010 Bruce Kraemer, Marvell 55

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

November 20106/8/2010

Bruce Kraemer, MarvellFooter for this presentation 56

56

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 1st 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 MONTHLY QUAD CHARTSGTCC MONTHLY QUAD CHART


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

November 20106/8/2010

Bruce Kraemer, MarvellFooter for this presentation 58

58

GENERAL STRUCTURE OF THE FRAMEWORK GENERAL STRUCTURE OF THE FRAMEWORK MANUALMANUAL

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


• 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 GUIDE 65 OVERVIEWISO GUIDE 65 OVERVIEW

6060

• 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 (1st, 2nd or 3rd party), with many 3rd 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 OVERVIEWISO 17025 OVERVIEW


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

BEST PRACTICES FOR IOP TEST CONSTRUCTION BEST PRACTICES FOR IOP TEST CONSTRUCTION EXAMPLESEXAMPLES


2011 TRANSITION BOOTSTRAP YEAR2011 TRANSITION BOOTSTRAP 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.


2012 AND BEYOND2012 AND BEYOND• 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.


NEXT STEPS AND YOUR RESPONSENEXT STEPS AND YOUR RESPONSE• 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.


GB Election Timeline – Even Stakeholders, 2010


UPCOMING 2010 PLENARY EVENTSUPCOMING 2010 PLENARY EVENTS• 30 Nov – 3 Dec: Grid-Interop, Chicago

– See http://www.grid-interop.com/2010/#agenda for detailed 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 PAPs & WGs

12.00 pm

LUNCH

1.00 pmOptional Meetings

Opening Plenary

Closing Plenary

3.30 pmDEWGs &

CommitteesPAPs & WGs PAPs & WGs

Optional Meetings

5.00 pm Candidate Interviews

andOptional Meetings

7.00 pm PAPs & WGs

9.00 pm


2011 Plenary Meeting Schedule

Month Date Time Detail

Jan 21 1 – 3 p.m. Virtual Meeting/Conf. Call

Feb

Mar 29-31 All Day F2F: Nashville likely

Apr

May 26 1 – 3 p.m. Virtual Meeting/Conf. Call hosted @ ConnectivityWeek

Jun

Jul 12-14 All Day F2F: Montreal, Canada – International theme

Aug

Sep 15 1 – 3 p.m. Virtual Meeting/Conf. Call hosted @ GridWeek

Oct

Nov

Dec 5-8 All Day F2F: Grid-Interop, Phoenix

November 2010


Slide 69

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 70

doc.: IEEE 802.11-10/1316r2

Submission

ITU FG SmartFourth meeting

Chicago, USA, 29 November – 3 December 2010

• Registration form

• Meeting Announcement

• Meeting documents

Deadline 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

November 2010


Slide 71

doc.: IEEE 802.11-10/1316r2

Submission

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)

November 2010


Slide 72

doc.: IEEE 802.11-10/1316r2

Submission

UK Smart Metering - Introduction

• Reference Number: 10D/732Open Date: 2010-07-27Close 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

November 2010


Slide 73

doc.: IEEE 802.11-10/1316r2

Submission

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

November 2010


Slide 74

doc.: IEEE 802.11-10/1316r2

Submission

DECC & Ofgem supporting documents

DECC & Ofgem supporting documentsImpact 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 sites Size: [296 KB] File Type: [.pdf]Disablement / enablement functionality for smart gas meters Size: [99 KB] File Type: [.pdf]Analysis on disablement/ enablement functionality for smart gas meters Size: [656 KB] File Type: [.pdf]Smart Metering implementation programme: statement of design requirements Size: [713 KB] File Type: [.pdf]Smart Metering implementation programme: communications business model Size: [1,011 KB] File Type: [.pdf]Smart Metering implementation programme: implementation strategy Size: [560 KB] File Type: [.pdf]Smart Metering implementation programme: rollout strategy Size: [608 KB] File Type: [.pdf]Smart Metering implementation programme: regulatory and commercial framework Size: [650 KB] File Type: [.pdf]Smart Metering implementation programme: non-domestic sector Size: [419 KB] File Type: [.pdf]Smart Metering implementation programme: consumer protection Size: [411 KB] File Type: [.pdf]Smart Metering implementation programme: data privacy and security Size: [303 KB] File Type: [.pdf]Smart Metering implementation programme: in-home display Size: [392 KB] File Type: [.pdf]Consumers’ views of Smart Metering: report by FDS International Size: [948 KB] File Type: [.pdf]


November 2010


Slide 75

doc.: IEEE 802.11-10/1316r2

Submissionhttp://www.decc.gov.uk/assets/decc/Consultations/smart-meter-imp-prospectus/225-smart-metering-imp-programme-design.pdf

November 2010


Slide 76

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 77

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 78

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 79

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 80

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 81

doc.: IEEE 802.11-10/1316r2

Submission

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?

November 2010


Slide 82

doc.: IEEE 802.11-10/1316r2

Submission

Doc 226 – Communications Business Model

CHAPTER 2Question 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 3Question 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 bein a position to provide its services and the likely timescales involved?Question 8: Do you have any comments on the proposed approach to cost recoveryand incentivisation for DCC?

November 2010


Slide 83

doc.: IEEE 802.11-10/1316r2

Submission

Doc 225 – Design Requirements

CHAPTER 3Question 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 5Question 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?

November 2010


Slide 84

doc.: IEEE 802.11-10/1316r2

Submission

Doc 220 - ProspectusCHAPTER 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?

November 2010


Slide 85

doc.: IEEE 802.11-10/1316r2

Submission

Doc 231 – Consumer ProtectionCHAPTER 2Question 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 3Question 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 beforeswitching 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 4Question 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: FiveQuestion 17: Do you have any comments on our proposals to prevent upfront charging for the basic model of smart meters and IHDs?

November 2010


Slide 86

doc.: IEEE 802.11-10/1316r2

Submission

UK Consultation documents

• Consultation documents

• Smart Metering implementation programme: prospectus - letter to consultees Size: [50 KB] File Type: [.doc]

• Smart Metering implementation programme: prospectus document Size: [786 KB] File Type: [.pdf]


November 2010


Slide 87

doc.: IEEE 802.11-10/1316r2

Submission

Doc.: IEEE 802.11-10/1385r0 Submission November 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid...

Documents

Transcript of Doc.: IEEE 802.11-10/1385r0 Submission November 2010 Bruce Kraemer, MarvellSlide 1 Smart Grid...