High-level Smart Meter Data Traffic Analysis

High-level Smart Meter Data Traffic Analysis For: ENA May 2010 Engage Consulting Limited Document Ref: ENA-CR008-001-1.4 Restriction: ENA Authorised Parties Engage Consulting Limited Page 1 of 62

Document Control Authorities Version Issue Date Author Comments 0.1 01 st April 2010 Viktorija Namavira First draft 0.2 06 th April 2010 Viktorija Namavira Tom Hainey comments implemented 0.3-0.6 08 th April 2010 Jane Eccles/ James Boraston General check of the report 0.7 12 th April 2010 Tom Hainey Clarifications added 0.8 12 th April 2010 Simon Harrison Comments regarding protocols 0.9 14 th April 2010 Tom Hainey Update following QA of model & ENA ICT Group feedback 1.0 28 th April 2010 Viktorija Namavira / Tom Hainey Update following ENA members responses. Provides insight into potential Peak data traffic requirements. 1.1 5 th May 2010 Tom Hainey Updated with ENA comments on V1.0 1.2 7 th May 2010 Tom Hainey / Viktorija Namavira Updated with ENA comments on V1.1 1.3 10 th May 2010 Tom Hainey Update with some comments on V1.2 1.4 12 th May 2010 Tom Hainey Update of Executive Summary Version Issue Date Reviewer Comments 0.8 12 h April 2010 Tom Hainey Review of First draft 1.0 29 th April 2010 Tom Hainey Review of Updated Draft 1.1 5 th May 2010 Tom Hainey Review of ENA suggested changes 1.2 7 th May 2010 Craig Handford Quality Review 1.3 10 th May 2010 Tom Hainey Updated with some comments on V1.2 1.4 12 th May 2010 Tom Hainey Updated of Executive Summary Version Issue Date Authorisation Comments 0.8 12 th April 2010 Tom Hainey Issue to ENA for Distribution together with Excel based ENA data traffic analysis. Engage Consulting Limited Page 2 of 62

1.0 29 th April 2010 Tom Hainey Issued to ENA. 1.1 5 th May 2010 Tom Hainey Issued to ENA 1.2 7 th May 2010 Craig Handford Issued to ENA 1.3 10 th May 2010 Tom Hainey Issued to ENA 1.4 12 th May 2010 Tom Hainey Issued to ENA Related Documents Reference 1 Reference 2 Reference 3 Reference 4 Smart Metering Updated Requirements (ENACR006-002-1.1) Smart Metering Use Cases (ENA-CR007-001-1.1) Smart Metering Data Traffic Analysis Workbook (ENA-CR008-001-1.4.xls) Smart Metering Security Assessment (ENA-CR009-002-1.0) Distribution Recipient 1: Alan Claxton Recipient 2: ENA Members Engage Consulting Limited Page 3 of 62

Table of Contents Document Control...2 Authorities... 2 Related Documents... 3 Distribution... 3 Table of Contents...4 Executive Summary...5 1 Introduction... 14 1.2 Background... 14 1.3 Purpose... 14 1.4 Scope... 15 1.5 Copyright and Disclaimer... 15 2 Data Traffic Analysis approach... 16 2.1 Annual Data Traffic Level v Potential Peak values... 16 2.2 Use Case Scenarios - Assumptions... 16 2.3 Data Size Assumptions Used... 24 3 Data Traffic Analysis... 31 4 Summary of the Data Traffic Analysis... 33 4.1 Summary of Data Traffic Analysis Approach... 33 4.2 Annual Data Traffic per meter assessment... 33 4.3 Assessment of some potential Peak Data Traffic Scenarios... 36 5 Conclusions... 45 Appendix 1 Electricity & Gas Use Case Data Traffic Analysis Detail... 54 Engage Consulting Limited Page 4 of 62

Executive Summary This data traffic evaluation is based on a set of assumptions related to the raw data being transferred across the smart metering system and the overheads on that process typically introduced by security and the selected communication protocols being used. This evaluation has assumed that the transport protocol used will be TCP/IP. The reason for choosing TCP/IP protocols is that they are commonly used in smart grids and smart metering communications in pilot projects in Europe, USA, Australia and other regions and because TCP/IP creates a relatively high overhead in data transmission messages. TCP/IP protocols will therefore represent the higher end of requirements of the communications infrastructure in terms of packet sizes associated with data transmission. It follows that assuming TCP/IP will provide a robust indicative estimate of the data packet sizes that each meter and the wider metering system will need to deal with on both an individual activity and annual basis. These assumptions would need to be refined if different protocols were assumed to apply. The approach uses Use Case scenarios (Reference 2) to define the detail surrounding the data that will need to be exchanged to enable network operators to undertake certain activities in support of network planning and also, to an increasing extent over, in the active management of smart grids. This includes data storage, data transmission and response granularity assumptions, which facilitate the understanding of the amount of data stored at the meter, the size the transmitted data packets will need to be, and how often and how quickly they will need to be sent. To support their requirements, network operators envisage that certain data will need to be stored within the meter for a minimum of 3 months; this aligns with ENA s understanding of suppliers requirements for data storage at the meter. The meter will therefore need to have sufficient memory capacity to accommodate both these requirements. Based on the set of assumptions described in this report, the data flow volumes that will be generated by network operators business processes, both on a per meter and total meter population per annum basis, are shown below (assuming a population of 27 million electricity meters and 20 million gas meters): Meter Type Single Meter p.a. Total Meter Population p.a. Electricity Less than 1.5 MB 1 30 40 TB 2 Gas Less Than 1 MB 15 20 TB TOTAL - 45 60 TB Table E.1 below summarises for a single electricity or gas meter the following: Data granularity registered at the meter period covered by the data; Data Transmission granularity frequency data will be transferred; Latency required maximum acceptable transfer for data; 1 1 Megabyte = 10 6 bytes 2 1 Terabyte = 10 12 bytes Engage Consulting Limited Page 5 of 62

Cumulative per activity data volume in bytes; Cumulative data volume per activity per year. Engage Consulting Limited Page 6 of 62

Table E.1 Details of Electricity & Gas assumptions and Use Case data requirements (per meter) ELECTRICITY USE CASES Assessment of network performance Data granularity registered at the meter Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom Basic Flow Data Periodically HH average 3 months on availability 145,888 583,552 Basic Flow DNO Requests data On event (assumed once Once every 3 months every 3 months) (1 month of ½ hour data) 41,489 165,956 HH average Use Case 02 - Determine network impact of proposed new demand / generation connections Basic Flow on event (assumed once 3 months every 3 months) (1 month of ½ hour data) 41,489 165,956 HH Average Use Case 03 - Determine network impact of proposed increase in demand / generation at existing connection points Basic Flow on event (assumed once every 3 months) HH Average 3 months (1 month of ½ hour data) Use Case 04 - Monitor demand and generation profiles for network load forecasting See Use Case 01 Use Case 05 - Determine Latent Demand due to Embedded Generation See Use Case 01 Use Case 06 - Identify Voltage Quality Issues Basic Flow Actively manage network / System Balancing on event (assumed once a month) Assumed send Reports every 6 months) 41,489 165,956 656 1,312 Use Case 07 - Collect data for active management Basic Flow As in Use Case 01 but with a lower latency HH average As Required Lower Latency required than UC 01 As UC 01 As UC 01 Use Case 08 - Active network management of network voltage Uses Voltage information captured to instigate actions on DNO Assets to control voltage, as well as having the same data flows as Use Case 09 to undertake actions in the household to address voltage issues via ToU/Peak tariffs, control household equipment etc. 09 Use Case - Perform Active Management of Network Power Flow 1. Operation of (Distribution Use of System) Time of Use tariff (Scenario 1) 2. Operation of (Distribution Use of System) Real Time Pricing (Scenario 2) on occurrence (assumed to happen every 3 months) on occurrence (assumed to happen every 3 months) 3 months Up to 5-15 min. to configure. TOU Readings 12 hours 3 months Up to 5-15 min. to configure. RTP Readings 12 hours 2,006 8,024 1,194 4,776 Engage Consulting Limited Page 7 of 62

ELECTRICITY USE CASES Data granularity registered at the meter 3. Power Sharing by Maximum Thresholds (Scenario 3) on occurrence (assumed to happen every 3 months) 4. Direct Control, by DNOs, of appliance or microgeneration (Scenario 4) System Balancing 10 Use Case - Perform System Balancing Same data flow as in Use Case 09 on occurrence (assumed to happen every 3 months) On occurrence (assumed to happen every 3 months) Data transmission granularity ENA Latency req. (command execution ) 3 months Between Metering System and IHD via HAN no DNO related data traffic 3 months 5-15 min. for up to 1,000 meters (may need to be repeated across the country) On event (assumed to happen once every 3 months) 11 Use Case - Check effectiveness of active network management / system balancing measures 1. The Smart Metering System measures power flow and HH Average voltage data (as in Use Case 01) 2. DNO requests data 3. Smart System sends data on occurrence (assumed to happen once every 3 months) 3 months (1 month of ½ hour data) Actively manage network during planned and unplanned outage Use Case 12 - Notify consumer of planned outage 1. Consumer notification of planned / emergency outage 2. Consumer notified that outage is over on occurrence of the event (assumed one planned outage per Use Case 13 - Query Meter Energisation Status to determine outage source and location 1. False Outage Report (DNO checks meter energisation On occurrence of the event status: supply on) (assumed to happen once per once per year 5 15 min latency (On localised basis, which is constraining factor, only small subset of meters involved assume 1,000. However at national level could be millions) Cumulative per activity (bytes) Not related to DNO Cumulative Data volume per year (bytes) Data flows between Meter & IHD, nothing to DNO 1,194 4,776 See UC 09 See UC 09 5-15min. 41,489 165,956 Message confirmation within. 5-10 min. (within Hour) once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of 1,791 1,791 1,791 1,791 Engage Consulting Limited Page 8 of 62

ELECTRICITY USE CASES Data granularity registered at the meter 2. Confirmed network outage On occurrence of the event (assumed to happen once per Use Case 14 - Send Alarm to DNO during network outage 1. Outage alarm sent to the Distribution Network On occurrence of the event Operator (assumed to happen once per Use Case 15 - Verify restoration of supplies after outage 1. Meter notifies DNOs of power restoration On occurrence of the event (assumed to happen once every 6 months) Use Case 16 - Regulatory Reporting of outages 1. DNO requests stored outage information on event (assumed once 2. Meter sends outage report every 3 months) Use Case 17 - Restore and maintain supply during outages 1. Smart Metering System sends "power restored" message to the DNO 2. DNO activates the maximum power consumption threshold 3. Smart Metering confirms activation of the maximum On occurrence of the event (assumed to happen once every 6 months) On occurrence of the event (assumed to happen once every 6 months) Data transmission granularity ENA Latency req. (command execution ) extreme weather events. 30 sec per single meter once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of extreme weather events. 30 sec per single meter once a year For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 6 months For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 3 months (Reporting period) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) 1,194 1,194 597 597 597 1,194 1,161 4,644 6 months 5 min. 597 1,194 6 months 15 min. 1,194 2,388 Engage Consulting Limited Page 9 of 62

ELECTRICITY USE CASES Data granularity registered at the meter power consumption threshold Manage safety issues Use Case 18 - Manage meter safety alarm 1. Smart Metering System sends alarm to DNOs on event (assumed once a 2. DNO remotely disconnects the supply through the Smart Metering System (where necessary) 3. The Smart Metering sends the confirmation message to the DNO Use Case 19 - Manage extreme voltage at meter 1.The Smart Metering System sends alarm of a voltage level outside its configured tolerance levels 2.(Optionally) the Smart Metering System autodisconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO 3.Supply is enabled by DNO after emergency/safety action on event (assumed once a On occurrence of the event (assumed to happen once every 6 months) on event (assumed once a Support network activities Use Case 20 - Configure Smart Metering System 1. DNO configures meter reading registers on event (assumed every 3 years) 2. DNO configures meter alarms on event (assumed every 3 years) 3. DNO configures meter load threshold on event (assumed every 3 years) Basic Flow Total (Everything works as required) Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) once a year 15 min 597 597 once a year 15 min. 1,194 1,194 6 months once a year Alarm in up to 15 min. 5 min. 1,791 2,388 every 3 years Assumed 15 minutes up to 12 hours (i.e. confirming meter changes) 1,194 1,194 every 3 years As Above 1,194 1,194 every 3 years As Above 1,194 1,194 332,980 1,288,818 Engage Consulting Limited Page 10 of 62

GAS USE CASES Use Case 1 - Gather information for planning 1.The Smart Metering System sends the recorded gas demand data to the GDNO (6min) Data granularity registered at the meter 2.The Smart Metering System sends the recorded gas demand data to the GDNO (daily) Use Case 02 - Configure Smart Metering System 1. GDN configures meter reading registers on event (assumed to happen every 3 years) Use Case 03 - Disable Supply of Gas 1. Gas is disabled by GDNs on event (assumed once every 3 years) Use Case 04 - Display Messages from Gas Distribution Network 1.GDN sends notification to IHD Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) Every 6 minutes all day for once a year 5 days the winter period (Was 351,544 351,544 November-March) - 6 months every day at 6 am every 6 months 5 days 1,302 2,604 on occurrence to happen once every 10 years every 3 years every 3 years every 10 years confirmation almost real Up to 1 hour (was almost real ) Up to 1 hour (was almost real ) Use Case 05 - Measure and Store Calorific Values at the meter Update CV daily daily Up to 1 hour (was almost real ) (Optionally) GDN update the message Tampering Notification send to GDNs meter sends tampering notification to GDNs Basic Flow Total (Everything works as required) on occurrence (assumed to happen once a month) on occurrence (assumed once a monthly Up to 1 hour (was almost real ) 2,388 2,388 1,791 1,791 1,194 1,194 1,177 429,605 1,177 14,124 once a year almost real 597 597 361,170 803,847 Engage Consulting Limited Page 11 of 62

Currently, Network Operators are able to rely on Radio Teleswitching, which has the capability to address large populations of meters in a matter of seconds, for control of offpeak appliances such as electric storage (space) and water heating. However, this service is due to be withdrawn in 2014. Network Businesses also have the capability, through their SCADA systems, to identify major disruptions to their network that affect many thousands of their customers. In both these examples, the communications system is able to transmit the data at the necessary transmission granularity and latency. With regard to the smart metering communications system, one concern for network operators will be to ensure that where required to do so, it will be able to simultaneously transmit data to or from a few hundred, or perhaps up to a thousand, meters that are geographically closely located (e.g. covering one or more 11kV feeders over a small geographical area e.g. less than 1 km 2 ). Some communication technologies that could be deployed would support fast response s for several hundred meters. For example an LV network Power Line Carrier system acting through a local concentrator could provide a dedicated communication path for perhaps 100 meters at premises served from a given distribution substation. However, with some communication technologies, such as GPRS where a local transmitter might serve an area covered by perhaps hundreds of distribution substations, the communication infrastructure might be put under considerable strain should it be called upon to handle simultaneous data flows to or from all meters associated with the networks served by those substations. The risk is that if the communication infrastructure is not sufficiently sized to deal with these peak activities within the required response s (latency), this could result in the local communications infrastructure becoming overloaded and unable to provide the functionality required by network operators. In a worst case scenario this could conceivably result in the network operating outside its thermal and voltage capabilities. Clearly the required response s for processes supporting planning activities tend not to be too onerous; for example is a typical latency figure used for these activities in the Assess Network Performance Use Cases. However, where there is a need to actively manage parts of the network, the latency will need to align with network operators requirements to receive, assess and act on the information within a given critical scale. In general terms, the active management of networks will require that the communications infrastructure is able to support a higher speed of data transfer. How quickly and widely active network management will need to become commonplace will depend on the speed of uptake of new sources of electricity demand and production such as electric vehicles (EVs), heat pumps and micro-generation. However, it is anticipated that there will be some early clustering of these sources of demand and generation that will require pockets of the network to be actively managed in the very near future. To gain an insight into these peak activities Section 4.3 of the report considers a number of Use Case examples for a varying number of meters and different potential requirements for latency. An example is illustrated in Section 4.3.1.2 (Use Case 01 Request latest month s data for all relevant electricity parameters). This data capture process supports the assessment of the network s performance (planning activities) initially assuming relatively high acceptable latency, but it will also form a key part of the active management of the network in the future (Use Case 07) with the deployment of new sources of demand such as EVs and heat pumps etc. The latency in this active management stage will then need to be much lower e.g. 15 minutes. If the network operator needed to acquire data from 600-1,000 meters from a localised part of their network to support planning processes, and this needed a response only within 12 Engage Consulting Limited Page 12 of 62

hours, then the local communication infrastructure covering these meters would only need to support a speed of 5 8 kbps 3. However, once new types of demand have been connected to the network and there is an increasing need for network operators to proactively manage their networks, they will need to capture certain data in a much shorter frame to facilitate the necessary speed of operational response. If this resulted in a requirement for a response of 15 minutes rather than, then the local communication infrastructure would need to deal with data traffic in the 0.2 0.4 Mbps range (Million bits per second). These figures assume no group addressing or broadcast capability in place, so represent what could be considered as a worst case response requirement. In conclusion the key points to note from this work are as follows: Initially network operators only need data for network planning purposes which will normally be collected on a rolling 3 month basis. The volume of this data and the required latency should be easily managed by any communication solution deployed; The required latency for communicating with the smart metering system will reduce as new demand and production are deployed and this will require any communication infrastructure to be able to deal with these potential local peaks within the operational scales that network operators can respond. This report and analysis supports the conclusions stated above and describes how network operators requirements of the smart metering system will evolve over to support the needs of a smart grid. 3 Kbps = Kilo bits per second = 1,000 bits per second Engage Consulting Limited Page 13 of 62

1 Introduction For Great Britain (GB) smart metering, we now know the high level structure of the Central Communications model. We are therefore able to make some key assumptions on the structure and scope of services within that model. The particular data traffic scenarios that have been used within this analysis reflect the smart meter related data flows associated with domestic and small-tomedium enterprise smart meters and the use of the communications infrastructure to support smart grid functionality. The scenarios are aligned with specifically developed Use Cases. This approach has enabled a structured and easy to understand analysis of the data traffic to be performed. By applying the Use Case approach, the GB smart metering requirements will remain solution and technology agnostic, supporting innovation and communication technology interoperability in the future. The use of Use Cases will also provide the basis for assessment of data volumes and traffic, which will be critical in selecting the communications service options and subsequent solutions. 1.1.1 Smart Metering Scenarios To fully inform the Ofgem E-serve process it is important to assess the key Use Cases using relevant data exchange flows. The scenarios highlight the level and detail of data traffic incurred by the specific activity from the meter, or network operator side that the communications infrastructure will need to support. This helps to estimate more detailed data traffic volumes which in turn will highlight the minimum data size requirements that will need to be handled by a smart meter, including data storage requirements at the meter and the data volumes that meter might need to handle at one point in. The analysis also helps to identify the data communication speed requirements at the meter depending on the activities carried out, which will give some idea of the communication solutions needed for smart meters. Such analysis additionally provides some facts that will allow the appropriate Cost Benefit Analysis to be undertaken. This will inform the development of the Ofgem Smart Metering Prospectus. 1.2 Background 1.3 Purpose Use of smart meters will cause significant data traffic flow as meters will be configured, set and read remotely using the communication network for smart meters over different periods e.g. weekly, daily, hourly, etc. In order to optimise network requirements for smart meters, and develop appropriate standards, it is important to keep in mind the data traffic flow requirements to ensure reliable and secure smart metering system data exchange. The objective of this report is to construct scenarios aligned with each Use Case (Reference 2), identify the information flow and data to be exchanged, and estimate the amount of data that will be flowing from the meter to the network Engage Consulting Limited Page 14 of 62

1.4 Scope operator and other authorised parties and vice versa. This will help the assessment of smart meter communication requirements for dealing with the smart grid related data requirements. Such analysis provides an overview of the system requirements to ensure a reliable and effective exchange of data and provide the necessary ability to regulate demand, optimise the grid, and allow further innovation. The scope of this report includes the analysis of data traffic between the meter and the network operators. This report does not include network traffic analysis between independent service providers, suppliers or linked entities such as smart home appliances and other utility meters (water, heat). 1.5 Copyright and Disclaimer The copyright and other intellectual property rights in this document are vested in ENA. Engage Consulting Limited has an unlimited licence to use any techniques or know-how developed by it under this Agreement on its future work. No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Engage Consulting Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it. Engage Consulting Limited Page 15 of 62

2 Data Traffic Analysis approach This data traffic analysis should be considered as a starting point to gain some insight into the potential level of data traffic that any communication network would need to support for each smart meter type over any period of interest. The analysis is based on a number of assumptions stated below for the typical activities that will underpin the Use Cases provided in Reference 2. The assumptions used were considered reasonable for this type of analysis based on feedback from ENA members. However, the assumptions can be modified later to meet any further developments within the sector thus allowing a reassessment of the requirements at a later stage. A Workbook (Reference 3) that forms the basis of this work is also provided as a companion to this report for use by interested parties. 2.1 Annual Data Traffic Level v Potential Peak values The focus of the evaluation has been on identifying: 1. The overall data traffic for each meter over a year. (See Section 4.2) 2. The potential requirement of needing to notify or receive data from a group of meters at periods of stress on the system (proxy for peak activity). (See Section 4.3). 2.2 Use Case Scenarios - Assumptions The project has outlined several Use Cases (Reference 2) that are relevant to network business requirements for smart metering to support smart grids. Each Use Case consists of various scenarios, which describe an occurrence, or a general process of data exchange. Use of scenarios helps to identify various data exchange flows depending on the process and trigger event that caused the data to be exchanged, thus making sure that the basic data flow is identified and presented in the analysis. Table 1 (electricity) and Table 2 (gas) summarise the potential data exchange scenarios relevant to the network operator s smart grid activities and the planning of smart grid activities based on the required interval data requirements. The scenarios will be used in presenting Raw Data Analysis and TCP/IP protocol based analysis later in the report. The column Data granularity at meter indicates how often the data is being recorded at the meter, but is not being sent immediately. This helps to estimate how many values the meter collects before actually transmitting it to the central data depository. The column data transmission granularity shows how often it is estimated that the data will actually be transmitted between the meter and the end party i.e. the Central Data Repository System or network operators. Where it is stated on occurrence this means that the data is transmitted as soon as the meter registers the event as occurring. The assumption of how often the scenario is likely to occur is given in brackets and will be used purely for data traffic estimation in the potential smart grid operation scenario. Engage Consulting Limited Page 16 of 62

The column Time represents how quickly the network operators would generally require the metering system to execute the commands, or to submit the requested data. Table 1 Summary of Electricity Scenarios used for data traffic analysis per each Use Case Assessment of network performance Use Cases 01_Monitor Power Flows and Voltage Levels to Identify Thermal Capacity and Statutory Voltage Headroom Potential data exchange scenarios: 1. Data is periodically sent from the Smart Metering System (import/export; real/reactive flow and voltage as specified by DNOs) Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO (latency) required by ENA Every HH average Every 3 months Assumed that DNO s would be able to access the data by being able to log into the Central data Repository (assumption) 4 2. DNO requests data (in cases where the data is needed earlier then the configured data submission ) On event (assumed to happen once every 3 months) Every 3 months 3. The Smart Metering System sends the requested data (assumed one month of HH real/reactive import/export, microgeneration real/reactive flow and voltage) (in cases where the data is needed earlier then the configured data submission) Alternative Flows: Metering system failure: (1 month of ½ hour data) 1. Smart Metering System rejects the message as invalid On event (assumed to happen once a Once a year 2. The Smart Metering System does not have any measured data stored 02_Determine network impact of proposed new demand / generation connections 3. The DNO does not receive the data from the Smart Metering System (in case of scenario 1 and 2) 1. DNO requests stored HH power flow and voltage data (and microgeneration data where available) is considered reasonable for an error report to reach DNO s in this case If data is requested with an expectation that it arrives within, it seems reasonable for a fail alarm to be delivered in the same scale as above On event (assumed to happened once every 3 months) On event (assumed to happen once every 3 months) 2. Smart Metering system retrieves the requested data (assumed one month of HH real and reactive energy import and export, real/reactive generation energy and (1 month of ½ hour data) 4 It is assumed that the DNO s are able to access data from the Central Data Depository. The data is for planning purposes thus a 3 months delay is acceptable. Engage Consulting Limited Page 17 of 62

Use Cases Potential data exchange scenarios: voltage data) Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO (latency) required by ENA Alternative flow: 03_Determine network impact of proposed increases in demand / generation at existing connection points 04_Monitor demand and generation profiles for network load forecasting 05_Determine Latent Demand due to Embedded generation 06_Identify Voltage Quality Issues 1. The DNO does not receive the data On event ( assumed to happen once a 1. DNO requests stored HH power flow and voltage data (and microgeneration data where available) 2. Smart Metering system retrieves the requested data (assumed one month of HH real and reactive energy import and export, real/reactive generation energy and voltage data) Alternative flow: 1. The DNO does not receive the data 1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01) 1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01) 1. The Smart Metering System accumulates and date stamped voltage quality events (assumed 6 events) 1. Meter fails to send the message On event (assumed to happen once every 3 months) On event ( assumed to happen once a On event ( assumed to happen once a Every 3 months (1 month of ½ hour data) On event ( assumed to happen once a Every HH average Every 3 months As per UC 01 Every HH average Every 3 months As per UC 01 On event (assumed to happen once a month) On event (assumed to happen once a On event (assumed every 6 months) On event (assumed to happen once a Actively manage network / System Balancing Use Cases 07_Collect data for active management Potential data exchange scenarios: 1. Data is periodically sent from the Smart Metering System (import/export; real/reactive flow, real/reactive generation flow and voltage as specified by DNOs) as in Use Case 01 Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO (latency) required by ENA As Use Case 01 As required Once EVs, heat pumps etc. are common, this may need to happen more often and faster than for UC 01 e.g. 5-15 minutes Alternative flow: 1. Meter fails to send the message On event (assumed to happen once a On event (assumed to happen once a 08_Active Management of network voltage Uses Voltage information captured to instigate actions on DNO Assets to control voltage, as well as having the same data flows as Use Case 09 to undertake actions in As for UC 09 Engage Consulting Limited Page 18 of 62

Use Cases 09_Perform Active Management of Network Power Flow Potential data exchange scenarios: the household to address voltage issues via ToU/Peak tariffs, control household equipment etc. 1. Operation of (Distribution Use of System) Time of Use Tariff 2. Operation of (Distribution Use of System) Real Time Pricing Estimated ENA related Data granularity at meter (registered at the meter) On event (assumed to happen once every 3 months) Estimated ENA Data transmission granularity to Central Data Repository/DNO On event (assumed to happen once every 3 months ) (latency) required by ENA Up to 5-15 min. to configure, send to up to 1,000 meters TOU readings 12 hours 3. Power Sharing by Maximum Thresholds 4. Direct Control, by DNOs, of appliances or micro-generation Related to Metering system and IHD, nothing to DNO 5-15 min for command execution to up to 1,000 meters (may need to be repeated across country) 1. Power Sharing by Maximum Power Thresholds consumer does not turn off appliances 5-15 min. 2. Power Sharing by Maximum Power Thresholds consumer turns off some of the appliances 5-15 min. System Balancing Use Cases 10_Perform System Balancing 11_Check effectiveness of network management / system balancing measures Possible data exchange scenarios: The same data flow as in Use Case 09 1. The Smart Metering System measures power flow and voltage data (as in Use Case 01) 2. DNO requests data (in cases where the data is needed earlier then the configured data submission ) 3. The Smart Metering System sends the requested data (assumed last real import/export and voltage data read) Estimated ENA related Data granularity at meter (registered at the meter) On occurrence (assumed every 3 months) HH Average On event (assumed to happen once a. This may have low localised impact, but high concurrence. Potentially millions of meters. Estimated ENA Data transmission (latency) required granularity to by ENA Central Data Repository/DNO On event (assumed once every 3 months) On event (assumed to happen once every 3 months) 5-15 minutes (On localised basis, which is constraining factor, only small subset of meters involved assume 1,000. However at national level could be millions). Within 15 min. (1 month of ½ hour Engage Consulting Limited Page 19 of 62

Use Cases Possible data exchange scenarios: Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission (latency) required granularity to by ENA Central Data Repository/DNO data) Alternative flow: 1. Meter fails to send the message On event (assumed to happen once a On event (assumed to happen once a Actively manage network during Planned & Unplanned Outages Use Cases 12 Notify consumer of planned outage Potential data exchange scenarios: 1. Consumer notification of planned / emergency outage 2. Consumer notified that outage is over 1. Smart metering system deems the request invalid for step 1 Estimated ENA related Data granularity at meter (registered at the meter) On occurrence of the event (assumed to happen once per Estimated ENA Data transmission (latency) required granularity to by ENA Central Data Repository/DNO On occurrence of the event (assumed to happen once per On event (assumed to happen once a On event (assumed to happen once a Notification of outage to be sent within 10 days to IHD before the outage; message confirmation within 12 hours. 5-10 mins if within hour. 2. DNOs do not receive acknowledgement message for step 1 13_Query Meter Energisation Status to determine Outage Source and Location 3. Smart metering system deems the request invalid for step 2 4. DNOs do not receive acknowledgement message for step 2 1. False Outage Report (DNO checks meter energisation status: supply on) On occurrence of the event (assumed to happen once per On occurrence of the event (assumed to happen once a Ability to send energisation queries to 1,000 meters in 15 minutes or 100,000 meters in 1 hour in the example of an extreme weather related event. 30secs for one meter 2. Confirmed network outage 30sec for one meter Alternative flow: 1. Smart Metering system deems the request invalid (for step 1) 2. The Distribution Network Operator does not receive the message (for step 1) 14 Send Alarm during Network Outage to Identify Loss of Supply 1. Outage alarm sent to the Distribution Network Operator (Note: Need to control number of outage alarms to avoid swamping communication infrastructure e.g. say only first 1,000 meters in any localised region). On occurrence of the event (assumed to happen once a On occurrence of the event (assumed to happen once a Receive alarm within 5 mins for LV faults (1,000 max); up to 15 min for HV faults. Engage Consulting Limited Page 20 of 62

Use Cases 15 Verify restoration of supplies after outage Potential data exchange scenarios: Alternative flow: 1. Smart Metering System is unable to send the outage alarm message 2. DNOs do not receive notification 1. Meter notifies DNOs of power restoration Estimated ENA related Data granularity at meter (registered at the meter) On occurrence of the event (assumed to happen once every 6 months) Estimated ENA Data transmission (latency) required granularity to by ENA Central Data Repository/DNO On occurrence of the event (assumed to happen once every 6 months) Receive alarm within 5 mins for LV faults (1,000 max); up to 15 min for HV faults. 1. Smart Metering System fails to detect power restoration 2. DNOs do not receive message On event (assumed to happen once a On event (assumed to happen once a 16 Regulatory Reporting on outages 1. DNO requests stored outage information On occurrence (assumed every 3 months) 3 months (Reporting period) 2. Meter sends outage report As Above 1. Smart Metering System rejects the message as invalid On event (assumed to happen once a On event (assumed to happen once a 17 Restore and maintain supply during outages 2. Smart Metering System does not have any of the requested information stored 3. DNOs do not receive notification 1. Smart Metering System sends power restored message to the DNO 2. DNO activates the maximum power consumption threshold 3. Smart Metering confirms activation of the maximum power consumption threshold On occurrence of the event (assumed to happen once every 6 months) On occurrence of the event (assumed to happen once every 6 months) 15 min 15 min Approx. 5 min for command execution 1. DNOs do not receive power restored message 2. Smart Metering System deems the request invalid 3. DNOs do not receive the confirmation response On event (assumed to happen once a On event (assumed to happen once a Engage Consulting Limited Page 21 of 62

Manage Safety Issues Use Cases 18 Manage meter safety alarm Potential data exchange scenarios: 1. Smart Metering System sends alarm to DNOs Estimated ENA related Data granularity at meter (registered at the meter) On occurrence (assumed once a Estimated ENA Data transmission granularity to Central Data Repository/DNO On occurrence (assumed once a (latency) required by ENA 15 min 2. DNOs remotely disconnect the supply through the Smart Metering System (where deemed necessary) 3. The Smart Metering sends the confirmation message to the DNO 15 mins 15 mins 1. DNOs do not receive the alarm 2. Smart Metering System deems the request invalid On event (assumed to happen once a On event (assumed to happen once a 3. DNO does not receive confirmation of the supply switch activating to cut-off supply 19 Manage extreme voltage at meter 1. The Smart Metering System sends alarm of a voltage level outside its configured tolerance levels On occurrence (assumed once every 6 months) On occurrence (assumed once every 6 months) Alarm in 15 min 2. (Optionally) the Smart Metering System auto-disconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO On occurrence (Assumed to happen once a On occurrence (Assumed to happen once a Alarm in 5min (Possibly require 30 secs to 2 mins) 3. Supply is enabled by DNO after emergency/safety action 1. The Smart Metering System fails to send the extreme voltage alarm 2. The Smart Metering System fails to auto disconnect Alarm in 5 min (Possibly require 30 secs to 2 mins) Support Network activities Use Cases 20 Configure Smart Metering System Potential data exchange scenarios: 1. DNO configures meter reading registers (this is confirmed by the metering system) 2. DNO configures meter alarms (this is confirmed by the metering system) 3. DNO configures meter load threshold (this is confirmed by the metering system) Data granularity at meter (registered at the meter) On occurrence assumed to happen every 3 years Data transmission granularity to Central Data Repository/DNOs On occurrence assumed to happen every 3 years (latency) required by ENA Assumed 15 mins up to (i.e. confirming meter changes) Engage Consulting Limited Page 22 of 62

Use Cases Potential data exchange scenarios: 1. Smart Metering System deems the request invalid 2. DNOs do not receive notification Data granularity at meter (registered at the meter) On occurrence Data transmission granularity to Central Data Repository/DNOs On occurrence (latency) required by ENA Table 2 Summary of Gas Scenarios used for data traffic analysis per each Use Case Use Cases 01 Gather information for Planning Potential data exchange scenarios: 1. The Smart Metering System sends the recorded gas demand data to the Gas Distribution Network Operator ( assumed 6min interval data) 2. The Smart Metering System sends the recorded gas demand data to the Gas Distribution Network Operator ( assumed Daily registered data) Estimated ENA related Data granularity at meter (registered at the meter) Every 6 minutes every day Estimated ENA Data transmission granularity to Central Data Repository/DNO Every year (latency) required by ENA 5 days Every day at 6am Every 6 months 5 days Use Case 02 Configure Smart Metering System 1. Meter does not communicate requested data to the authorised GDN party 2. Meter data reads are missing / corrupted 1. GDN configures meter reading registers (this is confirmed by the metering system) (frequency of readings detail) Alternative flow: On occurrence of event (assumed to happen once a On occurrence assumed to happen every 3 years On occurrence of event (assumed to happen once a On occurrence assumed to happen every 3 years Confirmation almost real 1. Smart Metering deems the request invalid 2. GDNs do not receive confirmation On event (assumed to happen every 3 years) On event (assumed to happen every 3 years) Use Case 03 Disable Supply of gas 1. Gas is disabled by GDNs, meter sends acknowledgment. Assumed every 3 years Assumed every 3 years Updated to 1 hour (previously assumed real- for smart grid needs) 1. Smart Metering deems the request invalid 2. GDN does not receive confirmation On event assumed to happen once every 3 years On event assumed once every 3 years Use Case 04 Display Messages from Gas Distribution Network 1. Meter displays message from GDNs to customer display On occurrence assumed to happen once every 10 years On occurrence Updated to 1 hour (previously assumed real- for smart grid needs) 1. Meter fails to send confirmation message On occurrence Engage Consulting Limited Page 23 of 62

Use Cases Use Case 05 Measure and Store Calorific Values at the meter Potential data exchange scenarios: In cases where meter does not measure CV at the meter: 1. GDN s send Calorific Value to the meter Estimated ENA related Data granularity at meter (registered at the meter) Every day Estimated ENA Data transmission (latency) required granularity to by ENA Central Data Repository/DNO Updated to 1 hour (previously assumed Daily real- for smart grid needs) 2. Meter confirms the data has been updated successfully to GDNs and suppliers Every day Daily Updated to 1 hour (previously assumed real- for smart grid needs) 3. (optionally) GDN update the message Assumed once per month Monthly 4. Meter confirms the message As Above 1. The Smart Metering System rejects the message as invalid On event assumed to happen once a year Once a year Tampering notification to GDNs Meter Sends tampering notification to GDNs On event assumed to happen once a year Once a year Almost real. Each scenario presents a data exchange between the smart metering system and the central data communication party, and/or network operators. 2.3 Data Size Assumptions Used The analysis is structured to give an overview of the processes associated around the data exchange in a day to day situation using certain assumptions, which could be updated later to fit a more specific metering system set-up. First of all a Raw Data analysis is provided, which provides an overview of the size of each data item as registered at the meter. It is assumed that the data will be stored at the meter for at least 3 months (in line with ERA assumptions for Suppliers). Then, while giving consideration to the different protocols used for data communication, the TCP/IP protocol based data traffic analysis will be provided. The reason for choosing TCP/IP protocols is that they are commonly used in smart grids and smart metering communications in pilot projects in Europe, USA, Australia and other regions while being able to create some of the highest overheads in a data transmission message. 2.3.1 Raw Data Analysis - size assumption Command/Request for data request is usually a one byte request code and can contain commands such as the identification request, read request, write, negotiate, wait and terminate request. In order to assess the minimum data size requirements, the payload of the message can increase the command to up to 25 bytes; therefore this size is used in the analysis. Engage Consulting Limited Page 24 of 62

The size of the response can vary significantly, depending on the activity, it can be 4 bytes when only one meter read is requested, for instance, the latest voltage read, or it can be over 100 bytes when asking for a meter performance report or a range of interval reads for the last 3 weeks. Below is a table summarising assumptions made when considering the size of basic data exchanges. Table 3 Summary of Raw Data Size Assumptions (Please note the bold numbers represent a summary of non bold numbers) Data Total size (bytes) Breakdown Command / Request (data flow to the The request can be made to schedule reads, to update meter, to request reads on demand, to meter) request from the Authorised control load, to change tariff etc. Party for a certain data 25 Meter Periodic Data read 4 Real Power (import) (kw) 4 Reactive Power (import) (kvar) 4 Real Power (export) (kw) 4 Reactive Energy (export) (kvar) 4 Micro-generation Real Power (kw) 4 Micro-generation Reactive Power (kvar) 4 Voltage 4 Power Factor Confirmation / Notification message Meter sends Error Report 4 GAS-per read* Includes: Failure notifications, messages, etc. 25 18 This report is automatically produced when failure occurs within the system 2 Error Id 1 Switch Status 4 Timestamp 4 read voltage 4 read frequency 1 Report type 1 Check sum Meter sends Performance Report 1 Closing flag 150 This report is produced on occurrence of the failure or as scheduled to determine meter performance. 1 Status 4 Timestamp 2 Diagnostics 1 Report type Engage Consulting Limited Page 25 of 62

140 Event Log (14 bytes per event) - assumed 10 events 1 Check sum Meter sends Outage Report (1 outage registered) 1 Closing flag 14 Outage report is sent after the supply has been restored 4 Outage detected stamp 4 Supply restored stamp 2 Event id 4 Data Weekly read submission 28 7*8 (for electricity) One month of data (assumed to include Meter sends one month of HH real/reactive import/export, microgeneration real/reactive and voltage data) 28 7*4 (for gas) 40320 (4*48*30)*7 Last day HH import data summary 192 48*4 CV value for gas 8 2.3.2 Data Exchange Protocols and Communication Review When data is sent from, or to, the Smart Metering System, the size of the data will increase depending on the protocols used within the end-to-end communication. In European projects a range of protocols and communication types are currently used for smart metering and smart grid purposes. Thus, for instance, a combination of Power Line Carrier (PLC) (in most cases between the meter and data concentrator) and GPRS (mostly between the concentrator and data administration) communication based on IEC 61334 S-FSK, DLMS/COSEM, TCP/IP protocols is used in Dutch DSMR, French ERDF, Spain s and Italy s smart metering projects. M-bus and SML protocols are widely used in German projects. Meanwhile, the recent announcement on smart metering roll out by British Gas includes GPRS and DLMS for WAN communication and alternative technologies where GPRS has no coverage and ZigBee for HAN communication. Each protocol has certain data size overheads that can increase the size of the data substantially. Data size overheads include a certain data packet frame, which means that for every packet of data sent there will be a frame which includes meter id, equipment status, type of message, etc. The size of the packet frame depends on the communication protocol used. It can add from 10 to 50 bytes per packet of data sent. Table 4 below provides an overview of the most commonly used protocols for Smart Metering System Data Exchanges in Europe and other regions and provides data size overhead per packet depending on the protocol. Please note that the table includes both carrier protocols (e.g. TCP/IP, PLC FSK, PRIME) and the data encoding protocols (e.g. FLAG, DLMS, SML, ZSE). Data Engage Consulting Limited Page 26 of 62

encoding protocols would need a carrier protocol to actually move the data around. Table 4 Summary of characteristics of main protocols used for Data Exchange in Smart Metering Systems 5 Transport Protocols Protocols: Estimated Protocol frame size (bytes) Remote AMR Used For AMI PSTN GSM GPRS Physical Carriers Low Power RF PLC PLC Broadba Narrowb nd 6 and IEC 61334 (S FSK, FSK, OFDM) 45 bytes 7 Y Y Y Y 8 IEC 62056 31 Euridis 9 45 bytes 10 Y EN 13757 M Bus 11 27 bytes Y 12 Y TCP/IP protocol 13 50 bytes Y Y Y Y Y Y Y SITRED 14 45 bytes 15 Y Y Y Y PRIME 8 bytes 16 Y Y Y EverBlu unknown 17 Y Y Y Y OPERA/UPA 18 24 bytes 19 Y Y Y Y ZigBee 20 15 bytes Y Y Y Mesh radio 5 http://www.openmeter.com/files/deliverables/open-meter%20wp2%20d2.1%20part4%20v1.0.pdf 6 PLC Broadband is still in development. IEEE P1901 (data rate expected: >100Mbits/s) is working towards standardisation of this network. It is expected that it will take approximately another 4 years, before the standard will be confirmed. Other associations are also working on further PLC broadband developments, including: G.hn (data rate expected: 1Gbit/s) and OPERA (<205Mbps) http://www.openmeter.com/files/deliverables/open-meter%20wp2%20d2.1%20part2%20v2.3.pdf 7 http://www.openmeter.com/files/deliverables/open-meter%20wp2%20d2.1%20part2%20v2.3.pdf 8 http://www.openmeter.com/files/deliverables/open-meter%20wp2%20d2.1%20part4%20v1.0.pdf AMI system is supported when used with DLMS/COSEM 9 Euridis supports twisted pair local bus with carrier signalling. It is widely used in France. Work under progress to adapt it to new needs with higher speed and use with DLMS/COSEM. 10 http://www.erdfdistribution.fr/fichiers/fckeditor/file/erdf/2009/doc_linky/specification_linky/erdf- CPT-Linky-SPEC-FONC-CPL_Linky%20PLC%20profile%20functional%20specifications.pdf 11 M-bus is mainly used with heat, gas and water meters. It supports twisted pair local bus with base band signalling and wireless in the unlicensed 868-980 MHz SRD 12 AMI supported when used in conjunction with DLMS/COSEM 13 TCP/IP profile with GPRS is used in smart metering project in Netherlands. 14 SITRED (Integrated System for data Transmission on Electricity Distribution network) is Enel s proprietary solution. It includes its own data exchange and encoding application layers. It is being standardised as the Meters and More protocol see press release: http://www.enel.com/ewcm/salastampa/comunicati_eng/1629732-1_pdf-1.pdf.dl 15 The frame extracted from IEC 61334 FSK protocol, which is a Physical Layer of SITRED. 16 http://www.iberdrola.es/webibd/gc/prod/en/doc/mac_spec_white_paper_1_0_080721.pdf 17 This protocol is proprietary, therefore no information is available. It uses proprietary data formats 18 Open PLC European Research Alliance 19 http://www.ist-opera.org/opera1/downloads/d18/op_wp2_deliverable_d18_v1.01.pdf 20 The ZigBee protocol stack includes lower layers consistent with IEEE 802.15.4 radio specifications. It supports a variety of upper application layers the typical AMI solution is the ZigBee Smart Energy profile. Engage Consulting Limited Page 27 of 62

Data Exchange Protocols Protocols: Estimated Protocol frame size (bytes) Remote AMR IEC 62056 21 FLAG 22 bytes 21 Y Y 22 IEC 62056 DLMS/COSEM 23 14 bytes 24 Y Y SML 25 14 bytes 26 Y Y Zigbee SmartEnergy 25 bytes 27 Y OPERA/UPA 28 24 bytes 29 Y Y AMI Dependent on the protocol used when the data is transmitted the data is protected by additional verification and checks to ensure that the data is correct. Transmitted data can also include a pause after the data packet to avoid collision with other transmitted data in order to guarantee the delivery of the message and command. An example of a typical communication session would consist of the following data transmissions, identification, negotiation (reconfigure the communication channel 30 for communication parameters differing from the default values), log-on, security, read, write, and terminate. In order to clarify how the data overheads are created, the example of a typical communication process taken from EPRI (Electric Power Research Institute) and based on TCP/IP mode of operation is shown in Table 5 below. This example assumes that the requested data is sent within various packets, with each packet usually taking between 50 and 66 bytes. The size of the data will depend on the data that was requested. In the example below, the descriptor <ACK> acknowledges the receipt of the package bit and valid CRC3231 is used to detect errors in the message. The assumptions on data traffic message size vary considerably. For instance, in Flanders 32 advanced metering data size requirement assessment ( An evaluation of 21 http://www.mayor.de/lian98/doc.en/html/u_iec62056.htm 22 AMI supported when used in Mode E with DLMS/COSEM and remote two-way communication. 23 DLMS/COSEM has been selected as a basis of the Dutch and the French projects 24 Open Metering System Specification (OMS) https://www.zvei.org/fileadmin/user_upload/fachverbaende/energietechnik/brancheninformationen/om S/OMS-Spec_Vol2_Primary_v200.pdf 25 SML (Smart Message Language) is applied by RWE, E.ON, EnBW, Vattenfall, also by Landis&Gyr, Hager, etc. 26 Open Metering System Specification (OMS) https://www.zvei.org/fileadmin/user_upload/fachverbaende/energietechnik/brancheninformationen/om S/OMS-Spec_Vol2_Primary_v200.pdf 27 http://www.jennic.com/files/support_files/jn-an-1035%20calculating%20802-15- 4%20Data%20Rates-1v0.pdf 28 Open PLC European Research Alliance 29 http://www.ist-opera.org/opera1/downloads/d18/op_wp2_deliverable_d18_v1.01.pdf 30 http://intelligrid.epri.com/smart_grid_information_sharing_calls/2009/ami_han_mtg._materials_6.16.09/nist_vendor_webinar_2.pdf 31 Toggle bit is used to reject duplicate packets thus retransmitted packets keep the same state as the original packet sent. CRC stands for Cyclical Redundancy Checking and is used to verify the integrity of a data communication. A CRC character is generated at the end of transmission. 32 Flanders is the northern region of Belgium and represents 60% of its population with population density reaching 440 inhabitants/km 2 Engage Consulting Limited Page 28 of 62

two-way communication means for advanced metering in Flanders (Belgium) ), which provided an analysis of advanced meter requirements, although it was recognised that typical data size is 32 bytes, the data size requirements per transaction type per meter was required to be a minimum of 512 bytes for commands, parameter adjustments and alarms, and 1024 bytes for meter registers (periodically and on demand). 33 Some recent articles speculate that 14 byte data reads are more likely to be in the range of 4k to 16k bytes per reading. 34 Table 5 TCP/IP based message transaction overheads The data throughput differs significantly depending on the protocol and communication used. 2.3.3 Data size calculation assumptions based on TCP/IP protocol With data being actually transmitted the characteristics of protocols used through end-to-end communication will need to be used to carry out data traffic analysis. As was stated above, the overhead per packet of data sent through the TCP/IP protocol amounts to up to 50 bytes. Therefore each raw data transaction will contain an additional 50 bytes. Additionally, the message negotiation and verification needs to be taken into account which adds further packet transactions. As was previously mentioned TCP/IP data transmission can easily add around 10 further transactions. Therefore it will be assumed that each data transmission will add a further 500 bytes. 33 http://www.vreg.be/vreg/documenten/rapporten/rapp-2007-8.pdf 34 http://www.smartgridnews.com/artman/publish/technologies_security_news/that-smart-grid-data- Surge-We-Mentioned-Earlier-You-Can-t-Ignore-It-1351.html Engage Consulting Limited Page 29 of 62

2.3.4 Security In this data traffic analysis a basic level of security is assumed, namely when a command is sent to a meter (whether it is a data request, a schedule of reads or a configuration) each command and request is verified by the meter. The security checks are assumed to be 22 bytes per packet of data sent, which includes DES (Data Encryption Standard) and AES (Advanced Encryption Standard) for the detection and prevention of unauthenticated access and modification 35. Please note that in the future it could be possible that smart metering activities could also include such high security operations as RSA (Rivest Shamir Adleman chipper) which could add over 300 bytes per data packet, however due to large data overheads they are currently not too popular. The analysis below also includes request verification, which is the authentication and check for errors in the request. Such verification is assumed to add 4 bytes to each request transmission going to the meter. Engage has prepared a report on security issues related to smart metering deployment (Reference 4), which further highlights the main threats and security measures that would need to be considered when rolling out smart meters. 35 http://www.rempli.org/download.php?doc=29&phpsessid=859e10189e665ece80f54e096ff08764 Engage Consulting Limited Page 30 of 62

3 Data Traffic Analysis An Excel Workbook (Reference 3 ENA-CR008-001-1.3) was created to underpin the analysis, which is provided as a companion to this report. Summary output from this spreadsheet is provided in Section 4 below. The spreadsheet allows the assumptions of the overheads per packet and the network to be modified (the cells that can be modified are shown in red in Reference 3) in order to see the immediate results in the data traffic flow. It also allows adjustments of the data sizes and the granularity of data transmissions, thus meeting other additional needs that the network operators might need to incur. Reference 3 contains several Worksheets, namely: - The first Worksheet DataSizeAssumptions contains the assumptions of the electricity and gas data size in bytes, overhead size per packet and overhead per message transmission. The assumptions can be modified for different smart metering system solutions. - The second Worksheet EleTransferFrequencyAssumptions contains the assumptions of electricity data registration occurrence at the meter, and how long it will be stored before transmission. This helps to understand how large the volume of data is that will be transmitted and how often. The last column contains an element to calculate the data volumes per year. The assumptions can be modified for different smart metering system solutions. - The third Worksheet Gas_TransferFreqAssumptions contains the same as the above spreadsheet for gas. The assumptions can be modified for different smart metering system solutions. - The fourth Worksheet Electricity_DataTraffic represents electricity related data flow volumes based on the assumptions in the previous Worksheet. The last 2 columns give the provision made for the data traffic during the year. - The fifth Worksheet Gas_DataTraffic represents gas related data flow volumes based on the assumptions in the above mentioned spreadsheet tabs. - The sixth Worksheet Ele_DataTrafficSpeed provides an overview of the electricity data speed requirements giving values in bits per second needed to receive a response, or data with varying latency levels assumed of 5 seconds, 30 seconds, 3 minutes, 5 minutes, 15 minutes, 1 hour and.. These cells can be modified to identify the change in speed resulting from these changes. - The seventh Worksheet Gas_DataTrafficSpeed gives an overview of gas data speed requirements similar to the electricity data. The last two Worksheets have been provided to allow a user to derive a view of the potential impact of specific data traffic instances being triggered for a number of meters. This is viewed as a way to highlight a potential peak data traffic estimate for some transactions that may become critical, especially when it is necessary to undertake an active management of the network. - The eighth Worksheet Ele_DataSpeedMultpMeterers provides an overview of the electricity data speed requirements for a specified number of meters in bits Engage Consulting Limited Page 31 of 62

per second needed to receive a response or data with various latency levels assumed of 5 seconds, 30 seconds, 3 minutes, 5 minutes, 15 minutes, 1 hour and. A single figure for the number of meters can be entered and applied to all data traffic for each Use case, or alternatively, each individual data flow can be updated to reflect views regarding the number of meters that could be involved in that specific data flow requirement. The areas that can be changed are highlighted in red. - The ninth Worksheet Gas_DataSpeedMultpMeterers provides an overview of the gas data speed requirements for a specified number of meters in bits per second needed to receive a response or data with various latency levels assumed of 5 seconds, 15 minutes or 1 hour. A single figure for the number of meters can be entered and applied to all data traffic for each Use Case, or alternatively, each individual data flow can be updated to reflect views regarding the number of meters that could be involved in that specific data flow requirement. The areas that can be changed are highlighted in red. Further details from the full analysis can be found in Section 4 and the detail is contained in Reference 3 ENA-CR008-001-1.3 Data Traffic Workbook. Engage Consulting Limited Page 32 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential 4 Summary of the Data Traffic Analysis 4.1 Summary of Data Traffic Analysis Approach The analysis assessed the ENA requirements for smart metering system related data to support smart grid activities. The requirements included: - Two way communication; - Remote disabling and enabling of supply; - Power quality reads; - Half Hourly Import and export data reads or 6 min. interval reads for gas; - Half Hourly Active and Reactive power reads; - Micro-Generation data reads; - Data on request; - Alarm configuration; - Change of tariffs; - Load management controls and feedback; - Customer notifications of power/gas outages or other activities; and - Management of outages. The data traffic discussed in Section 4.2 is provided on a per meter basis in order to identify the data size requirements that each meter would need to handle as a minimum. The analysis also provides an overview of data traffic in cases of alternative flows when the smart metering system fails, assuming that it would be corrected after one attempt. To provide a complete picture for data traffic it is necessary to provide an insight into the potential peak data traffic that might occur due to specific aspects of key Use Cases, that may require messages being sent to a number of meters, or data received from a number of meters. If the meters in question are geographically spread across the country, it is likely they will not provide added strain on the associated communications infrastructure. However, when events are localised and this data needs to be sent to or obtained from a concentrated area, it is possible that this might create added pressure on the associated aspect of the localised communication infrastructure. Section 4.3 will provide some insight into this. 4.2 Annual Data Traffic per meter assessment Using the assumptions detailed above, the Data Traffic Analysis showed that as a minimum, the metering system should be capable of dealing with the following levels of data per annum: ELECTRICITY: 1.2 1.3 MBytes per meter per annum; GAS: c. 0.8 MBytes per meter per annum. Engage Consulting Limited Page 33 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Based on the ENA requirement for electricity smart meters to store data in the meter for 3 months (as per ERA stated requirements) and then transmit it to the central data repository, this would result in a transmission of over 18 kbytes every 3 months of half-hourly data for each data item such as voltage, or electricity consumption etc. This amounts to c. 140-145 kbytes to transfer 3 month s worth of electricity related half hour data. For gas, where GDN s required up to 6 minute interval data collection, the data can reach over c.170-175 kbytes for transmission solely of interval data (6 months of data). Within the assumed periods (3 months for electricity and 6 months for gas) the likely data transfer will be of the order of: Meter Type All Operations work as expected (Use Case Basic Flow) All Operations encounter each problem highlighted in Use Case Basic + Alternative Flows ELECTRICITY c.325 kbytes c.410 kbytes GAS c.355 kbytes c.375 kbytes Appendix 1 provides a detailed breakdown of the required bytes of data and the associated speed to provide a response within 5 seconds, 30 seconds, 3 minutes, 5 minutes, 15 minutes, 1 hour and for electricity and 5 seconds, 15 minutes and 1 hour for gas. Table 6 provides an extract from Appendix 1 for Use Case 1 for both electricity and gas. Engage Consulting Limited Page 34 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Table 6 Extract for Electricity and Gas Use Cases 1 from Appendix 1. Electricity Use Cases Bytes 5sec Assessment of network performance Speed on cumulative volumes depending on response required (bps) 30 sec 3min 5min 15min 1 hour Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom 1. Data is periodically sent from the 145888 233421 38903 6,484 3890 1297 324 27 Smart Metering System (All Data) 2. DNO requests data Included in step 3 below 3. The Smart Metering System sends 41489 66382 11064 1,844 1106 369 92 8 the requested data 1. Smart Metering System rejects the message as invalid 1187 1899 317 53 32 11 3 0 2. The Smart Metering System does not have any measured data stored 4300 6880 1147 191 115 38 10 1 3.1 The DNO does not receive the data from the Smart Metering System (scenario 1) 3103 4965 827 138 83 28 7 1 3.2 The DNO does not receive the data from the Smart Metering System (scenario 2) 3103 4965 827 138 83 28 7 1 Gas Use Cases Speed on cumulative volumes depending on response required (bps) Bytes 5sec (min) 15min 1 hour Use Case 1 - Gather information for planning 1. The Smart Metering System sends the recorded gas demand data to the GDNO Included in Step 2 below (6min) 2. The Smart Metering System sends the recorded gas demand data to the GDNO 352846 564554 3136 784 (daily) 1. Meter does not communicate requested data to the authorised GDN party 3103 4965 28 7 2. Meter data reads are missing / corrupted 4300 6880 38 10 Engage Consulting Limited Page 35 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential 4.3 Assessment of some potential Peak Data Traffic Scenarios The previous section has highlighted the data traffic associated with one meter per annum. The discussion that follows will select some data traffic outcomes resulting from some of the key Use Cases (Reference 2) and provide an insight into the required data transfer speed needed under a number of latency assumptions for a varying number of meters. Some examples of situations where data traffic could be at a peak are as follows: Under storm conditions the power outage data traffic (via alarms or checking energisation status) could be relatively heavy, but only for those parts of the country experiencing storm conditions and only on predominantly Overhead Line networks. Depending on the communication technology deployed this could lead to high volumes of data traffic on local communication infrastructure. Major disruptions will be identified by SCADA systems and the purpose of the use of the alarm notification and/or energisation checks will be to ensure that all supplies are restored appropriately; For Demand Side Management (DSM) when third parties will be able to control specific household equipment. This will be extremely important with the growth of new technology such as Electric Vehicles (EVs), heat pumps etc. It is assumed that these households will have undertaken contractual agreement with these third parties, allowing them to control certain equipment within pre-agreed limits. Problem parts of the network will be known to network businesses through the capture of planning data and it will be necessary to instigate swift action once problems are identified on that part of the network; and There might be a need to capture the latest half-hourly data from a number of metering systems to undertake an assessment of how problems may have been adversely impacted by recent changes. This may not require second based response, but it may need a response within minutes with linked assessment tools leading to action needing to be taken quickly to avoid major problems. This is likely to be necessary when the network operators need to actively manage the network. 4.3.1 Assessment of some potential Peak Data Traffic Scenarios Some of these potentially Peak activities will occur immediately the smart meters have been rolled out in specific areas, whereas others may be as a consequence of the growth of new technologies such as EVs, heat pumps etc., which will require electricity network businesses to actively monitor their networks and respond to problems in fairly short scales. 4.3.1.1 Electricity Use Case 14 Outage Alarm Sent (Similar data traffic volume is associated with Use Case 15 - Verify Restoration of Supplies after Outage) Use Case 14 reflects the process of a smart metering system sending an outage alarm to the Distribution Network Operator when an Outage has been detected. Outages can impact a large number of meters depending on the cause of the Engage Consulting Limited Page 36 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential outage and Figure 1 below indicates the required communication speed necessary to deliver an alarm from a varying number of meters. As stated earlier, the larger the outage the more likely the DNO s SCADA systems will have detected the extent of the problem. The challenge for the DNO will be to capture this alarm related information and use it to ensure that supplies have been restored to all customers. Figure 1 Outage Alarm - Require Communication speed per packet for varying numbers of meters and assumed latency (response s) kbps 12,000 10,000 8,000 6,000 4,000 2,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5000 meters 10000 meters 5 secs 30 secs 3 mins 5 mins 15 mins 1 hour Latency periods No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps kbps kbps kbps kbps 200 191 32 5 3 1 0 0 400 382 64 11 6 2 1 0 600 573 96 16 10 3 1 0 800 764 127 21 13 4 1 0 1000 955 159 27 16 5 1 0 5000 4,776 796 133 80 27 7 1 10000 9,552 1,592 265 159 53 13 1 If we assume that the incident is fairly localised then all of these alarm signals will create data traffic on specific nodes of the communication infrastructure. Based on the data above, if the DNO requires a response from 1,000 meters within a 3 minute period, then this implies that this part of the communication infrastructure needs to deliver data at c. 27,000 bits per second (27kbps). However as the number of meters involved increases (if they were still part of the same nodes of the communication infrastructure), then this would increase the Engage Consulting Limited Page 37 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential required speed as shown above to c. 133kbps for 5,000 meters and c. 265kbps for 10,000 meters. As the required response (latency) for these activities reduces, then the required speed increases very quickly from 27kbps for 3 minute latency for 1,000 meters to almost 1 Mbps for a 5 second response. 4.3.1.2 Electricity Use Case 01 Request latest month s data for all relevant electricity parameters Similar data traffic volume is associated with Use Case 02 Determine network impact of proposed new demand / generation connections; Use Case 03 Determine network impact of proposed increases in demand / generation at existing connection points; Use Case 04 Monitor demand and generation profiles for network load forecasting same data, but may be for up to 3 months, rather than 1 month; Use Case 05 Determine Latent Demand due to Embedded Generation same data, but may be for up to 3 months, rather than 1 month; Use Case 07 Collect data for active network management same data, but latency will need to be shorter; and Use Case 11 - Check effectiveness of active network management / system balancing measures. This example spans both the System Planning aspects of DNOs operation (UC 01 05) and the active management of the network when the uptake of new technologies such as EVs and heat pumps etc. is much more prevalent and the DNO needs to manage the network much more actively and respond within much tighter scales. Figure 2 (shown on the next page) illustrates the required communication speeds in kbps that would be needed for varying levels of latency (response s). Engage Consulting Limited Page 38 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Figure 2 Request last month s data for all relevant electricity parameters - Require Communication speed per packet for varying numbers of meters and assumed latency (response s) kbps 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5 secs 30 secs 3 mins 5 mins 15 mins 1 hour Latency periods No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps kbps kbps kbps kbps 200 13,276 2,213 369 221 74 18 2 400 26,553 4,425 738 443 148 37 3 600 39,829 6,638 1,106 664 221 55 5 800 53,106 8,851 1,475 885 295 74 6 1000 66,382 11,064 1,844 1,106 369 92 8 Clearly as such response s needed dropped to say 15 minutes, the required speed that the communication system would need to support escalates as the table above demonstrates. Rather than access all data held in a smart metering system, it may be only one parameter that is of interest e.g. voltage. Figure 3 (shown on the next page) represent the required communication speeds to support retrieval of just voltage data for each half-hour for the last month from a varying number of meters. For a response within 5 15 minutes for 600 1,000 meters indicates a speed required of 100 500 kbps. Engage Consulting Limited Page 39 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Figure 3 Request last month s data for a single electricity parameter e.g. voltage - Require Communication speed per packet for varying numbers of meters and assumed latency (response s) 35,000 30,000 kbps 25,000 20,000 15,000 10,000 5,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5 secs 30 secs 3 mins 5 mins 15 mins 1 hour Latency periods No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps kbps kbps kbps kbps 200 6,027 1,004 167 100 33 8 1 400 12,053 2,009 335 201 67 17 1 600 18,080 3,013 502 301 100 25 2 800 24,106 4,018 670 402 134 33 3 1000 30,133 5,022 837 502 167 42 3 4.3.1.3 Electricity Use Case 09 (Scenario 4) Direct Control of Household Appliances Similar data traffic volume is associated with Use Case 08 (Scenario 4) Perform Active Management of Network Power Flow; Use Case 10 (Scenario 4) Perform System Balancing; Use Case 13 Query meter energisation status to determine outage source and location. Engage Consulting Limited Page 40 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Figure 4 Exert direct control over a number of household appliances - Require Communication speed per packet for varying numbers of meters and assumed latency (response s) kbps 25,000 20,000 15,000 10,000 5,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5000 meters 10000 meters 5 secs 30 secs 3 mins 5 mins 15 mins 1 hour Latency periods No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps kbps kbps kbps kbps 200 382 64 11 6 2 1 0 400 764 127 21 13 4 1 0 600 1,146 191 32 19 6 2 0 800 1,528 255 42 25 8 2 0 1000 1,910 318 53 32 11 3 0 5000 9,552 1,592 265 159 53 13 1 10000 19,104 3,184 531 318 106 27 2 This demand side management (DSM) tool will become more necessary as new technology is deployed. Again the impact on the local communication infrastructure will be dictated by the number of meters that would respond using the same communication infrastructure. If we look at seeking a DMS response from 1,000 meters in a specific localised part of network that uses the same communication infrastructure node, it can be seen that as the response needed reduces from 15 minutes to something of the order of 30 seconds, then the speed needed to support this activity would need to increase from 11kbps to 318 kbps. Clearly this type of consideration needs to be a key part of any communication infrastructure design. 4.3.1.4 Electricity Use Case 17 Restore and maintain supply during outages This Use Case reflects the overall process of Engage Consulting Limited Page 41 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential a. Power is restored to the Smart Metering System b. The Smart Metering System sends a date and stamped power restored message to the Distribution Network Operator c. The Distribution Network Operator receives the message and sends a message to the Smart Metering System activating the maximum power consumption threshold d. The Smart Metering System receives the message and validates it e. The Smart Metering System activates the maximum power consumption threshold and sends a confirmation response to the Distribution Network Operator Figure 5 summarises the outcome of the evaluation of this Use Case. Figure 5 Activate Maximum Power Consumption levels - Require Communication speed per packet for varying numbers of meters and assumed latency (response s) 35,000 kbps 30,000 25,000 20,000 15,000 10,000 5,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5000 meters 10000 meters 5 secs 30 secs 3 mins 5 mins 15 mins 1 hour Latency periods No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps kbps kbps kbps kbps 200 573 96 16 10 3 1 0 400 1,146 191 32 19 6 2 0 600 1,719 287 48 29 10 2 0 800 2,292 382 64 38 13 3 0 1000 2,866 478 80 48 16 4 0 5000 14,328 2,388 398 239 80 20 2 10000 28,656 4,776 796 478 159 40 3 Engage Consulting Limited Page 42 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential It has been suggested that this Use Case should be completed within 5 minutes. Again, the impact on the local communication infrastructure will depend on how many meters are linked to specific local nodes of the communication infrastructure. For this level of response for 1,000 meters the communication infrastructure needs to support a speed of 48 kbps. This increases to approaching 0.5 Mbps if this covers 10,000 meters. 4.3.1.5 Gas Use Case 03 Disable Supply of Gas This Use Case is based on the assumption that the gas smart meter incorporates a valve within the final meter functional specification. A use could be made of the gas valve by a Gas Distribution Network to prevent gas being offtaken from the network in the following circumstances; Temporary isolation - following public reported emergency, such as a smell of gas in the premises or suspected Carbon Monoxide (CO) report by consumer. Temporary isolation by GDN for poor pressure - Where the GDN has identified effected premises and wishes to reduce risk to consumers by temporarily isolating the supplies. Temporary isolation to reduce demand following damage to distribution mains or temporary reduction in gas availability - Possible prevention measure where consumers (whether a percentage or all for a particular Gas Supply Emergency) are isolated to ensure the overall pressure is maintained in the mains and services. Temporary isolation for Water Ingress - Isolate to protect consumers from poor pressure and some protection to consumer s appliances from water ingress. These scenarios potentially provide, once identified, an almost immediate response to a potential issue and allow the GDN to take some action prior to the visit by a competent person to site under the normal attendance policies and safety case requirements. There are likely to be a limited number of incidents each year where this provides benefit. Robust procedures would be required to ensure that these processes operate safely. Figure 6 illustrates required speeds necessary to issue these commands for a varying number of meters with the three specified response s of 5 seconds, 15 minutes and 1 hour. In the assumptions from ENA members it was stated that this action would need to be completed by the end of an hour. This indicates a very low speed of 3 kbps or less. As Figure 6 illustrates, this Use Case would only pose a problem for any local communication infrastructure if the response was to be in the seconds, which current thinking believes that it will not require such immediate response for this action. Engage Consulting Limited Page 43 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Figure 6 Send relevant request to disable gas supply to a number of meters kbps 9,000 8,000 7,000 6,000 5,000 4,000 3,000 2,000 1,000 0 200 meters 400 meters 600 meters 800 meters 1000 meters 5 secs 15 mins 1 hour Latency periods No. of Meters Speed per packet depending on response required 5 sec 15min 1 hour kbps kbps kbps 200 382 2 1 400 7,642 4 1 600 1,146 6 2 800 1,528 8 2 1000 1,910 11 3 Engage Consulting Limited Page 44 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential 5 Conclusions Based on the set of assumptions described in this report, the data flow volumes that will be generated by network operators business processes, both on a per meter and total meter population per annum basis, are shown below (assuming a population of 27 million electricity meters and 20 million gas meters): Meter Type Single Meter p.a. Total Meter Population p.a. Electricity Less than 1.5 MB 30 40 TB 36 Gas Less Than 1 MB 15 20 TB TOTAL - 45 60 TB Table 7 below summarises for a single electricity or gas meter the following Networks assumptions for each relevant Use Case step and data volume outcomes for each activity and per year: Data granularity registered at the meter - ; Data Transmission granularity How often data is transferred; Latency required transfer for data; Cumulative per activity data in bytes; and Cumulative data volume per year. 36 1 Megabyte = 10 6, 1 Terabyte = 10 12 bytes Engage Consulting Limited Page 45 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Table 7 Details of Electricity & Gas assumptions and Use Case data requirements per meter ELECTRICITY USE CASES Assessment of network performance Data granularity registered at the meter Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom Basic Flow Data Periodically HH average 3 months on availability 145,888 583,552 Basic Flow DNO Requests data On event (assumed once Once every 3 months every 3 months) (1 month of ½ hour data) 41,489 165,956 HH average Use Case 02 - Determine network impact of proposed new demand / generation connections Basic Flow on event (assumed once 3 months every 3 months) (1 month of ½ hour data) 41,489 165,956 HH Average Use Case 03 - Determine network impact of proposed increase in demand / generation at existing connection points Basic Flow on event (assumed once every 3 months) HH Average 3 months (1 month of ½ hour data) Use Case 04 - Monitor demand and generation profiles for network load forecasting See Use Case 01 Use Case 05 - Determine Latent Demand due to Embedded Generation See Use Case 01 Use Case 06 - Identify Voltage Quality Issues Basic Flow Actively manage network / System Balancing on event (assumed once a month) Assumed send Reports every 6 months) 41,489 165,956 656 1,312 Use Case 07 - Collect data for active management Basic Flow As in Use Case 01 but with a lower latency HH average As Required Lower Latency required than UC 01 As UC 01 As UC 01 Use Case 08 - Active network management of network voltage Uses Voltage information captured to instigate actions on DNO Assets to control voltage, as well as having the same data flows as Use Case 09 to undertake actions in the household to address voltage issues via ToU/Peak tariffs, control household equipment etc. 09 Use Case - Perform Active Management of Network Power Flow 1. Operation of (Distribution Use of System) Time of Use tariff (Scenario 1) 2. Operation of (Distribution Use of System) Real Time Pricing (Scenario 2) on occurrence (assumed to happen every 3 months) on occurrence (assumed to happen every 3 months) 3 months Up to 5-15 min. to configure. TOU Readings 12 hours 3 months Up to 5-15 min. to configure. RTP Readings 12 hours 2,006 8,024 1,194 4,776 Engage Consulting Limited Page 46 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential ELECTRICITY USE CASES Data granularity registered at the meter 3. Power Sharing by Maximum Thresholds (Scenario 3) on occurrence (assumed to happen every 3 months) 4. Direct Control, by DNOs, of appliance or microgeneration (Scenario 4) System Balancing 10 Use Case - Perform System Balancing Same data flow as in Use Case 09 on occurrence (assumed to happen every 3 months) On occurrence (assumed to happen every 3 months) Data transmission granularity ENA Latency req. (command execution ) 3 months Between Metering System and IHD via HAN no DNO related data traffic 3 months 5-15 min. for up to 1,000 meters (may need to be repeated across the country) On event (assumed to happen once every 3 months) 11 Use Case - Check effectiveness of active network management / system balancing measures 1. The Smart Metering System measures power flow and HH Average voltage data (as in Use Case 01) 2. DNO requests data 3. Smart System sends data on occurrence (assumed to happen once every 3 months) 3 months (1 month of ½ hour data) Actively manage network during planned and unplanned outage Use Case 12 - Notify consumer of planned outage 1. Consumer notification of planned / emergency outage 2. Consumer notified that outage is over on occurrence of the event (assumed one planned outage per Use Case 13 - Query Meter Energisation Status to determine outage source and location 1. False Outage Report (DNO checks meter energisation On occurrence of the event status: supply on) (assumed to happen once per once per year 5 15 min latency (On localised basis, which is constraining factor, only small subset of meters involved assume 1,000. However at national level could be millions) Cumulative per activity (bytes) Not related to DNO Cumulative Data volume per year (bytes) Data flows between Meter & IHD, nothing to DNO 1,194 4,776 See UC 09 See UC 09 5-15min. 41,489 165,956 Message confirmation within. 5-10 min. (within Hour) once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of 1,791 1,791 1,791 1,791 Engage Consulting Limited Page 47 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential ELECTRICITY USE CASES Data granularity registered at the meter 2. Confirmed network outage On occurrence of the event (assumed to happen once per Use Case 14 - Send Alarm to DNO during network outage 1. Outage alarm sent to the Distribution Network On occurrence of the event Operator (assumed to happen once per Use Case 15 - Verify restoration of supplies after outage 1. Meter notifies DNOs of power restoration On occurrence of the event (assumed to happen once every 6 months) Use Case 16 - Regulatory Reporting of outages 1. DNO requests stored outage information on event (assumed once 2. Meter sends outage report every 3 months) Use Case 17 - Restore and maintain supply during outages 1. Smart Metering System sends "power restored" message to the DNO 2. DNO activates the maximum power consumption threshold 3. Smart Metering confirms activation of the maximum On occurrence of the event (assumed to happen once every 6 months) On occurrence of the event (assumed to happen once every 6 months) Data transmission granularity ENA Latency req. (command execution ) extreme weather events. 30 sec per single meter once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of extreme weather events. 30 sec per single meter once a year For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 6 months For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 3 months (Reporting period) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) 1,194 1,194 597 597 597 1,194 1,161 4,644 6 months 5 min. 597 1,194 6 months 15 min. 1,194 2,388 Engage Consulting Limited Page 48 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential ELECTRICITY USE CASES Data granularity registered at the meter power consumption threshold Manage safety issues Use Case 18 - Manage meter safety alarm 1. Smart Metering System sends alarm to DNOs on event (assumed once a 2. DNO remotely disconnects the supply through the Smart Metering System (where necessary) 3. The Smart Metering sends the confirmation message to the DNO Use Case 19 - Manage extreme voltage at meter 1.The Smart Metering System sends alarm of a voltage level outside its configured tolerance levels 2.(Optionally) the Smart Metering System autodisconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO 3.Supply is enabled by DNO after emergency/safety action on event (assumed once a On occurrence of the event (assumed to happen once every 6 months) on event (assumed once a Support network activities Use Case 20 - Configure Smart Metering System 1. DNO configures meter reading registers on event (assumed every 3 years) 2. DNO configures meter alarms on event (assumed every 3 years) 3. DNO configures meter load threshold on event (assumed every 3 years) Basic Flow Total (Everything works as required) Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) once a year 15 min 597 597 once a year 15 min. 1,194 1,194 6 months once a year Alarm in up to 15 min. 5 min. 1,791 2,388 every 3 years Assumed 15 minutes up to 12 hours (i.e. confirming meter changes) 1,194 1,194 every 3 years As Above 1,194 1,194 every 3 years As Above 1,194 1,194 332,980 1,288,818 Engage Consulting Limited Page 49 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential GAS USE CASES Use Case 1 - Gather information for planning 1.The Smart Metering System sends the recorded gas demand data to the GDNO (6min) Data granularity registered at the meter 2.The Smart Metering System sends the recorded gas demand data to the GDNO (daily) Use Case 02 - Configure Smart Metering System 1. GDN configures meter reading registers on event (assumed to happen every 3 years) Use Case 03 - Disable Supply of Gas 1. Gas is disabled by GDNs on event (assumed once every 3 years) Use Case 04 - Display Messages from Gas Distribution Network 1.GDN sends notification to IHD Data transmission granularity ENA Latency req. (command execution ) Cumulative per activity (bytes) Cumulative Data volume per year (bytes) Every 6 minutes all day for once a year 5 days the winter period (Was 351,544 351,544 November-March) - 6 months every day at 6 am every 6 months 5 days 1,302 2,604 on occurrence to happen once every 10 years every 3 years every 3 years every 10 years confirmation almost real Up to 1 hour (was almost real ) Up to 1 hour (was almost real ) Use Case 05 - Measure and Store Calorific Values at the meter Update CV daily daily Up to 1 hour (was almost real ) (Optionally) GDN update the message Tampering Notification send to GDNs meter sends tampering notification to GDNs Basic Flow Total (Everything works as required) on occurrence (assumed to happen once a month) on occurrence (assumed once a monthly Up to 1 hour (was almost real ) 2,388 2,388 1,791 1,791 1,194 1,194 1,177 429,605 1,177 14,124 once a year almost real 597 597 361,170 803,847 Engage Consulting Limited Page 50 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Currently, Network Operators are able to rely on Radio Teleswitching, which has the capability to address large populations of meters in a matter of seconds, for control of off-peak appliances such as electric storage (space) and water heating. However, this service is due to be withdrawn in 2014. Network Businesses also have the capability, through their SCADA systems, to identify major disruptions to their network that affect many thousands of their customers. In both these examples, the communications system is able to transmit the data at the necessary transmission granularity and latency. With regard to the smart metering communications system, one concern for network operators will be to ensure that where required to do so, it will be able to simultaneously transmit data to or from a few hundred, or perhaps up to a thousand, meters that are geographically closely located (e.g. covering one or more 11kV feeders over a small geographical area e.g. less than 1 km 2 ). Some communication technologies that could be deployed would support fast response s for several hundred meters. For example an LV network Power Line Carrier system acting through a local concentrator could provide a dedicated communication path for perhaps 100 meters at premises served from a given distribution substation. However, with some communication technologies, such as GPRS where a local transmitter might serve an area covered by perhaps hundreds of distribution substations, the communication infrastructure might be put under considerable strain should it be called upon to handle simultaneous data flows to or from all meters associated with the networks served by those substations. The risk is that if the communication infrastructure is not sufficiently sized to deal with these peak activities within the required response s (latency), this could result in the local communications infrastructure becoming overloaded and unable to provide the functionality required by network operators. In a worst case scenario this could conceivably result in the network operating outside its thermal and voltage capabilities. Clearly the required response s for processes supporting planning activities tend not to be too onerous; for example is a typical latency figure used for these activities in the Assess Network Performance Use Cases. However, where there is a need to actively manage parts of the network, the latency will need to align with network operators requirements to receive, assess and act on the information within a given critical scale. In general terms, the active management of networks will require that the communications infrastructure is able to support a higher speed of data transfer. How quickly and widely active network management will need to become commonplace will depend on the speed of uptake of new sources of electricity demand and production such as electric vehicles (EVs), heat pumps and micro-generation. However, it is anticipated that there will be some early clustering of these sources of demand and generation that will require pockets of the network to be actively managed in the very near future. To gain insight into these peak activities Section 4.3 of the report considered a number of Use Case examples for a varying number of meters and different potential latency periods. The example below is based on Section 4.3.1.2 (Use Case 01 Request latest month s data for all relevant electricity parameters). This data capture process initially supports the assessment of the network s performance (planning activities), but it will also form a key part of the active Engage Consulting Limited Page 51 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential management of the network in the future (Use Case 07) with the deployment of new technology such as EVs and heat pumps etc. Table 8 highlights this Use Case example and clearly illustrates the required speed that localised communication infrastructure may need to support at peak periods, for varying number of meters and different levels of latency: Table 8 Example of Speed per data packet needed for varying numbers of meters and different latencies. No. of Meters 5 sec Speed per packet depending on response required 30 sec 3min 5min 15min 1 hour kbps kbps kbps Kbps kbps Kbps kbps 200 13,276 2,213 553 221 74 18 2 400 26,553 4,425 1,106 443 148 37 3 600 39,829 6,638 1,660 664 221 55 5 800 53,106 8,851 2,213 885 295 74 6 1000 66,382 11,064 2,766 1,106 369 92 8 This example does not assume any scheduling or grouping of meters to control the response, but simply assumes that the data from the specified number of meters for this activity needs to be delivered in the specified latency s across the local communication infrastructure. If the network operator needed to acquire data from 600-1,000 meters from a localised part of their network for planning purpose and this only needed a response within, then the local communication infrastructure covering these meters only needs to support a speed of 5 8 kbps. However, once new types of demand have been connected to the network and there is a need for the DNOs to proactively manage their network, the DNO will need to capture data in a much shorter frame to facilitate speedy responses. In Table 8 above, if this meant the response would need to be 15 minutes rather than, then the local communication infrastructure would need to deal with data traffic in to 0.2 0.4 Mbps range (Million bits per second) shown in yellow in Table 8. These figures assume no group addressing or broadcast capability in place, so represent what could be considered as a worst case response requirement. In conclusion the key points to note from this work are as follows: Initially network operators only need data for network planning purposes which will normally be collected on a rolling 3 month basis. The volume of this data and the required latency should be easily managed by any communication solution deployed; The required latency for communicating with the smart metering system will reduce as new demand and production are deployed and this will require any communication infrastructure to be able to deal with these potential local peaks within the operational scales that network operators can respond. Engage Consulting Limited Page 52 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential This report and analysis supports the conclusions stated above and describes how network operators requirements of the smart metering system will evolve over to support the needs of a smart grid. Engage Consulting Limited Page 53 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Appendix 1 Electricity & Gas Use Case Data Traffic Analysis Detail Cells highlighted in yellow reflect the typical response s for one meter for the cases shown in Section 4.3. Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour Assessment of network performance Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom 1. Data is periodically sent from 145,888 233,421 38,903 6,484 3,890 1,297 324 27 the Smart Metering System (All Data) 2. DNO requests data Included in step 3 below 3. The Smart Metering System 41,489 66,382 11,064 1,844 1,106 369 92 8 sends the requested data 1. Smart Metering System 1,187 1,899 317 53 32 11 3 0 rejects the message as invalid 2. The Smart Metering System 4,300 6,880 1,147 191 115 38 10 1 does not have any measured data stored 3.1 The DNO does not receive 3,103 4,965 827 138 83 28 7 1 the data from the Smart Metering System 3.2 The DNO does not receive 3,103 4,965 827 138 83 28 7 1 the data from the Smart Metering System Use Case 02 - Determine network impact of proposed new demand / generation connections 1. DNO requests stored HH Included in step 2 below power flow and voltage data (and micro-generation data where available) 2. Smart Metering System 41,489 66,382 11,064 1,844 1,106 369 92 8 retrieves the requested data Engage Consulting Limited Page 54 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour 1. The DNO does not receive 3,103 4,965 827 138 83 28 7 1 the data Use Case 03 - Determine network impact of proposed increase in demand / generation at existing connection points 1. DNO requests stored HH Included in step 2 below power flow and voltage data (and micro-generation data where available) 2. Smart Metering System 41,489 66,382 11,064 1,844 1,106 369 92 8 retrieves the requested data 1. The DNO does not receive 3,103 4,965 827 138 83 28 7 1 the data Use Case 04 - Monitor demand and generation profiles for network load forecasting 1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01 scenario 1 and alternate flow 4) Use Case 05 - Determine Latent Demand due to Embedded Generation 1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01 scenario 1 and alternate flow 4) Use Case 06 - Identify Voltage Quality Issues 1. The Smart Metering System 656 1,050 175 29 17 6 1 0 accumulates and data stamped voltage quality events (assumed 6 events) 1. Meter fails to send the 3,103 4,965 827 138 83 28 7 1 message Actively manage network / System Balancing Engage Consulting Limited Page 55 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Use Case 07 - Collect data for active management 1. Data is periodically sent from the Smart Metering System (import/export; real/reactive flow, real/reactive generation flow and voltage as specified by DNOs) as in Use Case 01 Scenario 1 1. Meter fails to send the message Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour 3,103 4,965 827 138 83 28 7 1 08 Use Case - Active network management of network voltage The same data flow as in Use Case 09 09 Use Case - Perform Active Management of Network Power Flow 1. Operation of (Distribution 2,006 3,210 535 89 53 18 4 0 Use of System) Time of Use tariff 2. Operation of (Distribution 1,194 1,910 318 53 32 11 3 0 Use of System) Real Time Pricing 3. Power Sharing by Maximum 0 0 0 0 0 0 0 0 Thresholds 4. Direct Control, by DNOs, of 1,194 1,910 318 53 32 11 3 0 appliance or micro-generation 1. Maximum Power Threshold 0 0 0 0 0 0 0 0 Reached - consumer does not turn off appliances 2. Power Sharing by Maximum Power Thresholds - consumer turns off some of the appliances 0 0 0 0 0 0 0 0 Engage Consulting Limited Page 56 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour System Balancing 10 Use Case - Perform System Balancing The same data flow as in Use Case 09 11 Use Case - Check effectiveness of active network management / system balancing measures 1. The Smart Metering System 0 0 0 0 0 0 0 0 measures power flow and voltage data (as in Use Case 01) 2. DNO requests data Included in step 3 below 3. The Smart Metering System 41,489 66,382 11,064 1,844 1,106 369 92 8 sends the requested data 1. Meter fails to send the 3,103 4,965 827 138 83 28 7 1 message Actively manage network during planned and unplanned Outage Use Case 12 - Notify consumer of planned outage 1. Consumer notification of Included in Step 2 below planned / emergency outage 2. Consumer notified that 1,791 2,866 478 80 48 16 4 0 outage is over 1. Smart Metering System 1,187 1,899 317 53 32 11 3 0 deems the request invalid for scenario 1 2. DNOs do not receive 3,103 4,965 827 138 83 28 7 1 acknowledgment message for scenario 1 3. Smart Metering System 1,187 1,899 317 53 32 11 3 0 deems the request invalid for scenario 2 4. DNOs do not receive acknowledgment message for 3,103 4,965 827 138 83 28 7 1 Engage Consulting Limited Page 57 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour scenario 2 Use Case 13 - Query Meter Energisation Status to determine Outage Source and Location 1. False Outage Report (DNO 1,791 2,866 478 80 48 16 4 0 checks meter energisation status: supply on) 2. Confirmed network outage 1,194 1,910 318 53 32 11 3 0 1. Smart Metering deems the 1,187 1,899 317 53 32 11 3 0 request invalid (for scenario 1) 2. DNO does not receive the 3,103 4,965 827 138 83 28 7 1 message (scenario 1) Use Case 14 - Send Alarm to DNO during network outage 1. Outage alarm sent to the 597 955 159 27 16 5 1 0 Distribution Network Operator 1. Smart Metering System is 3,103 4,965 827 138 83 28 7 1 unable to send the outage alarm message 2. DNO does not receive 3,103 4,965 827 138 83 28 7 1 notification Use Case 15 - Verify restoration of supplies after outage 1. Meter notifies DNOs of 597 955 159 27 16 5 1 0 power restoration 1. Smart Metering System fails 3,103 4,965 827 138 83 28 7 1 to detect power restoration 2. DNO does not receive 3,103 4965 827 138 83 28 7 1 notification Use Case 16 - Regulatory Reporting of outages 1. DNO requests stored outage information 2. Meter sends outage report 1,161 1,858 310 52 31 10 3 0 Engage Consulting Limited Page 58 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour 1. Smart Metering rejects the 1,187 1,899 317 53 32 11 3 0 message as invalid 2. Smart Metering System does 4,300 6,880 1,147 191 115 38 10 1 not have any of the requested information stored 3. DNO does not receive 3,103 4,965 827 138 83 28 7 1 notification Case 17 - Restore and maintain supply during outages 1. Smart Metering System 597 955 159 27 16 5 1 0 sends "power restored" message to the DNO 2. DNO activates the maximum Included in Step 3 below. power consumption threshold 3. Smart Metering confirms 1,194 1,910 318 53 32 11 3 0 activation of the maximum power consumption threshold 1. DNO does not receive 3,103 4,965 827 138 83 28 7 1 "power restored" message 2. Smart Metering deems the 1,187 1,899 317 53 32 11 3 0 request invalid 3. DNO does not receive the 3,103 4,965 827 138 83 28 7 1 confirmation response Manage safety issues Use Case 18 - Manage meter safety alarm 1. Smart Metering System Included in Step 3 below sends alarm to DNOs 2. DNO remotely disconnects Included in Step 3 below the supply through the Smart Metering System (where necessary) 3. The Smart Metering sends the confirmation message to 1,791 2,866 478 80 48 16 4 0 Engage Consulting Limited Page 59 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour the DNO 1. DNO does not receive the 3,103 4,965 827 138 83 28 7 1 alarm 2. Smart Metering deems the 1,187 1,899 317 53 32 11 3 0 request invalid 3. DNO does not receive 3,103 4,965 827 138 83 28 7 1 confirmation of the supply switch activating to cut-off supply Use Case 19 - Manage extreme voltage at meter 1. The Smart Metering System Included in Step 3 below sends alarm of a voltage level outside its configured tolerance levels 2. (Optionally) the Smart Included in Step 3 below Metering System autodisconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO 3. Supply is enabled by DNO 1,791 2,866 478 80 48 16 4 0 after emergency/safety action 1. The Smart Metering System 3,103 4,965 827 138 83 28 7 1 fails to send the extreme voltage alarm 2. The Smart Metering System 3,103 4,965 827 138 83 28 7 1 fails to auto disconnect Support network activities Use Case 20 - Configure Smart Metering System 1. DNO configures meter reading registers 1,194 1,910 318 53 32 11 3 0 Engage Consulting Limited Page 60 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Electricity Use Cases Bytes 5secs Speed on cumulative volumes depending on response required (bps) 30secs 3min 5min 15min 1 hour 2. DNO configures meter 1,194 1,910 318 53 32 11 3 0 alarms 3. DNO configures meter load 1,194 1,910 318 53 32 11 3 0 threshold 1. Smart Metering deems the 1,187 1,899 317 53 32 11 3 0 request invalid 2. DNOs do not receive 3,103 4,965 827 138 83 28 7 1 notification Basic Flow Total 332,980 532,768 88,795 14,799 8,879 2,960 740 62 Basic + Alternative Flow Total 419,342 670,947 111,825 18,637 11,182 3,727 932 124 Engage Consulting Limited Page 61 of 62

High-level Smart Meter Data Traffic Analysis Client Confidential Gas Use Cases Bytes Speed on cumulative volumes depending on response required (bps) 5secs 15min 1 hour Use Case 1 - Gather information for planning 1. The Smart Metering System sends the recorded gas demand data to the GDNO (6min) Included in Step 2 below 2. The Smart Metering System sends the recorded gas demand data to the GDNO (daily) 352846 564554 3136 784 1. Meter does not communicate requested data to the authorised GDN party 3103 4965 28 7 2. Meter data reads are missing / corrupted 4300 6880 38 10 Use Case 02 - Configure Smart Metering System 1. GDN configures meter reading registers 2388 3821 21 5 1. Smart Metering deems the request invalid 1187 1899 11 3 2. GDNs do not receive confirmation 3103 4965 28 7 Use Case 03 - Disable Supply of Gas 1. Gas is disabled by GDNs 1791 2866 16 4 1. GDNs do not receive confirmation 3103 4965 28 7 2. Smart Metering deems the request invalid 1187 1899 11 3 Use Case 04 - Display Messages from Gas Distribution Network 1. GDN sends notification to IHD 1194 1910 11 3 1. Meter fails to send confirmation message 3103 4965 28 7 Use Case 05 - Measure and Store Calorific Values at the meter 1177 1883 10 3 (Optionally) GDN update the message 1177 1883 10 3 1. The Smart Metering System rejects the message as invalid 2364 3782 21 5 Tampering Notification send to GDNs 597 955 5 1 Basic Flow Total 361,170 577,872 3,210 803 Basic + Alternative Flow Total 382,620 612,192 3,401 850 Engage Consulting Limited Page 62 of 62