Report on Communication Network Requirements -...

FLEXMETER 646568 D1.2 Report on Communication Requirements H2020-LCE-2014-3

Public

H2020-LCE-2014-3 FLEXMETER

Flexible smart metering for multiple energy vectors with

active prosumers

Project Duration 2015-01-01 – 2017-12-31 Type CP

WP no. Deliverable no. Lead participant

WP1 D1.2 TI

Report on Communication Network Requirements

Prepared by Dario Sabella

Issued by FLEXMETER Project Office

Document Number/Rev. FLEXMETER/D1.2/V3.0

Classification Public

Submission Date 2016-02-18

Due Date 2015-01-31

This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under grant agreement no. 646568

©Copyright 2015 POLITECNICO DI TORINO, IREN ENERGIA SPA,

STMICROELECTRONICS SRL, TELECOM ITALIA, RHEINISCH-WESTFAELISCHE

TECHNISCHE HOCHSCHULE AACHEN, INSTITUT POLYTECHNIQUE DE

GRENOBLE, UNIVERSITATEA POLITEHNICA DIN BUCURESTI, SIVECO ROMANIA

SA, ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA, E-ON SVERIGE AB.

This document and the information contained herein may not be copied, used or disclosed in

whole or in part outside of the consortium except with prior written permission of the partners

listed above.

FLEXMETER 646568 D1.2 Report on Communication Requirements H2020-LCE-2014-3

Document

Title Press Release

Type Deliverable

Ref D1.2

Target version V3.0

Current issue V3.0

Status Final

File D1.2_flexmeter_v3.0.doc

Author(s) Dario Sabella, Federico BoniCastagnetti, Dario Martellacci, Thomas

Heiliger, Luca Barbierato, Christian Camarda, Edoardo Fadda, Enrico

Pons, Marco Pau, Edoardo Patti, Staffan Hjort, Thomas Pehrsson

Reviewer(s) All consortium

Approver(s) Andrea Acquaviva

Approval date 2016-02-10

Release date 2016-02-10

Distribution of the release

Dissemination level PU

Distribution list All Consortium

History of Changes

Date Version Comment

14/01/2015 V0.1 Alignment on report purpose

17/12/2015 V0.2 Skeleton ready

18/12/2015 Agreed work split

10/01/2016 V1.0 Partners contributions ready

20/01/2016 V2.0 Integration and harmonization

31/01/2015 V3.0 Final Delivery

D1.2 Report on communication network requirements

– 3 – FLEXMETER is a project co-funded by the European Union

1 EXECUTIVE SUMMARY

The present deliverable aims to define the main characteristics and requirements (from a communication

network point of view) given by all use cases in FLEXMETER project. In particular, all use cases are

described (with particular emphasis on the traffic exchanges between different nodes and entities in

FLEXMETER, and for each use case a set of communications requirements is derived (e.g. throughtput,

latency, reliability, ...).

The project will use these requirements to design and implement, for both pilots, the necessary technical and

network improvements.



2 Communication Network role in FLEXMETER architecture and use cases

In this section we describe the role of telecommunication network infrastructure to support FLEXMETER

architecture and use cases: in a first section we provide a more general overview of the communication

networks characteristics (including devices) related to smart metering scenarios, also with the aim of giving

the point of view of communication operators from an evolutionary perspective; then, we list all FLEXMETER

use cases, by providing a mapping to the two project pilots (Turin and Malmo).

FLEXMETER objectives of testing different solutions of multi-services smart meters in the two pilots, Turin

and Malmo, need strong IT and telecom infrastructures enabling the services and use cases better described

in this document.

For both pilots the positive aspect is that they are not starting from scratch, as the two utilities involved are

already managing reliable infrastructures for their core business activities, that is delivering electric energy,

thermal energy, water and other services to their clients.

Moreover, both IREN and EON have important development plans to implement new services in the smart

metering and “smart home” fields: the possibility to test innovative hardware and software infrastructures,

with related applications and the resulting opportunity to have a deeper vision on new enabling telecom

infrastructures is for sure a plus.

Benchmarking activities and studies on the best communication protocols, architectures and devices solving

problems, in a close future, of near real time data pushing and analysis, signal coverages and ranges, cloud

VS local intelligence are the real objectives, in research projects like FLEXMETER, for a utility aiming at wide

spreading the chosen solution to millions of clients.

2.1 Operational characteristics of communication networks in smart metering scenarios

Communication networks have been designed initially to support voice (TACS, GSM) and data connections

(GPRS, EDGE) managed by humans; moreover, the evolution of network performances from 2G systems to

3G and also LTE has been driven by the need to increase capacity and user throughput (but again by

considering traffic generated by users).

With the initial deployment of Machine to Machine (M2M) services, especially in smart meters scenarios,

cheap GPRS devices has been widely used, due to the low needs in terms of throughput, and to the high

efficiency and good coverage characteristics of GSM networks (thanks to the usage of low frequency

carriers, e.g. 900 MHz).

For these reasons, nowadays most of the M2M use cases (and also the majority of FLEXMETER use cases

listed in the following sections) can be considered satisfied by current GPRS networks.

Nevertheless, due to the massive presence of today’s LTE networks, a more careful consideration should be

done, especially when taking into account the deployment of new smart meters or new M2M services, in a

long term perspective. In fact, the introduction of LTE also in low frequency carriers (e.g. 800 MHz in Italy)

permit in certain cases to obtain even better coverage conditions with respect to GSM networks (at 900

MHz). In addition to that, LTE networks offer good performances in terms of end-to-end latency (see table

below), thus enabling also in perspective the possibility to conceive new M2M services (e.g. with more

challenging requirements and timing constraints).



LTE (3GPP Release 8)

Downlink Uplink

Peak data rate 300 Mbps (4x4 MIMO)

150 Mbps (2x2 MIMO) 75 Mbps (1x2 SIMO)

Bandwidth Up to 20 MHz Up to 20 MHz

Peak Spectrum efficiency 16.3 bit/s/Hz 4.3 bit/s/Hz (1x2 SIMO)

Average Spectrum efficiency

[bit/s/Hz/cell]

1.69 (2x2 MIMO)

1.87 (4x2 MIMO)

2.67 (4x4 MIMO)

0.74 (1x2 SIMO)

Latency Data plane : 10 ms (round trip delay)

Control plane : 100 ms (idle to active state)

Finally, apart from the network performances, another consideration should be done, from a evolutionary

perspective: LTE networks can be considered future-proof in terms of long term exploitation by

communication network operators. In fact, the need for an increasing operational efficiency (due to the

necessity of saving CAPEX and OPEX costs) will impose operators to progressively switch off old radio

access technologies (2G, 3G) in favour of newly established network equipment (e.g. LTE and in future also

5G). For all these reasons, the advent of LTE should be considered with attention (and in some cases

preferred to GPRS connections), especially when new M2M systems will be designed with the need to avoid

any replacement through the years.

In addition to that, the recent standardization effort of communication network ecosystem is providing further

improvements also from terminal side, in order to enable a massive deployment of M2M devices in the next

years. In particular, new categories of terminals have been introduced, with several goals:

Efficient support of M2M communication in coexistence with traffic generated by legacy terminals;

Reduction of the cost of M2M devices, both in terms of hardware (CAPEX) and power consumption

(OPEX), where the latter improvement will increase also battery lifetime (in some cases even the

aim to enable offgrid deployment of meters)

For this purpose, several technical solutions are currently being proposed in SDOs. In general, we talk about

new CIoT (Cellular-IoT) technologies, where new devices will be introduced by 3GPP with the intention to be

integrated with the cellular networks, and to satisfy at least the following requirements:

Deployment in a very small bandwidth (e.g. 200 kHz)

Optimized for ultra-low terminal cost (< 4$)

Optimized for very long terminal battery life (10 years)

Extended coverage compared with existing cellular (20 dB enhancement)



Cat.1 Cat.0 Cat.M1 (eMTC) Cat.M2 (NB-IOT)

Downlink

OFDMA w/ 15 KHz sub-carrier spacing,

64QAM, dual-Rx, turbo code

OFDMA w/ 15 KHz sub-carrier spacing, 64QAM, Single-Rx,

turbo code

OFDMA w/ 15 KHz sub-carrier spacing, 16QAM, single-Rx,

turbo code

OFDMA w/ 15 KHz sub-carrier spacing, 16QAM,

single-Rx, tail biting convolutional code

Uplink

SC-FDMA w/ 15KHz sub-carrier spacing, 16QAM, turbo code,

23dBmTx

SC-FDMA w/ 15KHz sub-carrier spacing, 16QAM, turbo code,

23 dBm Tx

SC-FDMA w/ 15KHz sub-carrier spacing, 16QAM, turbo

code, 20 dBm Tx

SC-FDMA w/ 15KHz sub-carrier spacing, 16QAM or

single tone, TPSK, turbo code, 20 dBm Tx

System bandwidth

≤ 20 MHz ≤ 20 MHz 1.4 MHz 200 KHz

DL/UL peak rate 10 Mbps DL

5MbpsUL

1Mbps DL 1MbpsUL

1Mbps DL 1MbpsUL

500 Kbps DL 500 /40 multi/single-tone

Kbps UL

Duplex mode Full duplex Full duplex,

Half duplex type B

Full duplex, Half duplex type B

Full duplex, Half duplex type B

Deployment In-band In-band In-band In-band; In-guard band;

standalone

Coverage >140dB >140dB >155.7dB >TBD (in-band)

>164dB (standalone)

Reduced power states

PSM (in Rel.12) Extended I/C-DRX

(Rel.13)

PSM Extended I/C-DRX

(Rel.13)



Mobility Full mobility Full mobility

Full mobility in normal coverage

No connected mode mobility in extended coverage

No connected mode mobility

3GPP specs timeline

Rel.8 (completed)

Rel.12 (completed)

Rel.13 Core spec.: Dec.’15 ASN.1 freeze: Mar.’16

Test specs: Jun.-Sep.’16 (estimated)

Rel.13 Core spec.: Mar.’16 ASN.1 freeze: Jun.’16

(estimated) Test specs: Dec.’16

(estimated)

Target applications

Low-end MBB MTC

Wearables

MTC Wearables

MTC Wearables

MTC

As a consequence of this standardization effort, the table in the above summarize the main characteristics of

recently introduced terminal categories, that are optimized for M2M services. More in detail, in addition to

Cat.1 and Cat.0 (respectively already present in LTE Rel.8 and in LTE-Advanced Rel.12), evolved LTE-

Advanced networks (from Rel.13 on) will support new terminal categories (M1 and M2), particularly

optimized for MTC (Machine-Type Communication) scenarios. In particular, in perspective the aim is to

support the following two categories on MTC services:

mMTC (massive MTC), where timing constraints are not strict, but on the other hand the number of

M2M devices (e.g.in densely deployed IoT scenarios) will be huge, compared to legacy terminals;



uMTC (ultra reliable MTC), where mission critical services are imposing strict timing requirements to

the communication network (this is the typical case of smart grid, or other M2M scenarios driven by

other vertical market segments, like for example vehicular communications).

As regards smart meters and in particular FLEXMETER use cases, these new terminal categories (that will

be introduced in the next few years) could be evaluated for a long term perspective, especially when new

and scalable systems will be designed.

2.2 FLEXMETER use cases and mapping into the two FLEXMETER pilots

FLEXMETER use cases considered by the consortium are summarized in the following table, which is

adding also a mapping with the two project pilots (Turin and Malmo).

item FLEXMETER Use Case Owner WP Applicab. to

Turin Pilot

Apllicab. to

Malmo Pilot

1 Prosumer load profiling MIDORI / IREN WP2/WP4 x x

2 User aggregation for load balancing TI WP4 x x

3 Network management POLITO WP4/WP3 x x

4 Energy storage integration UPB WP3 x x

5 Outage detection POLITO WP3 x x

6 User awareness about utilities POLITO WP2 x x

7 Scheduling of daily operation of

electro-thermal loads RTWH WP6 x

As a clarification, item 1 will be applied also for Malmo Pilot, but meters installation scenarios described

below are not valid anymore (MIDORI will work on meter design and installation only in Turin Pilot).

All the listed use cases will be applicable for the Turin pilot exept for one:

Scheduling of daily operation of electro-thermal loads

o In fact, this use case has been only simulated, and not actually implemented in Malmo pilot. In

any case, the communciation requirements are extremely scarse, since this service doesn’t

require any realtime constraints.

3 TURIN PILOT: communication network requirements

For the Italian case, Regulator defined standards and communication requirements (point-point or point-

multipoint), together with privacy and safety issues, pushing for the use of ad-hoc networks instead of open

and public network (i.e. internet). This is of course true for official, fiscal data from the existing smart meters:

add-on solutions for energy empowerment (meaning post-fiscal meter devices) are not following these kind

of rules up to now.



PLC technologies are the standard for the fiscal electrical smart meters (in the DSO Scope) while new

regulations are pushing for the introduction of radio technologies for Gas and Water smart meters. Solutions

exploiting point-point wired transmission technologies (M-BUS –MODBUS), mobile transmissions (i.e. IP) are

also being developed.

In FLEXMETER we will test both scenarios: official, certified smart meters infrastructure (ST meters in

substations and in EnviPark, water meters, District heating) will follow the rules in official regulations (as he

ENI/UNI 11291 for water and gas) and will enable the experimentation of W-MBUS technologies, trying to

figure out performances, ranges and management costs; for the second scenario (domestic devices for

energy savings and empowerments) we will test free transmission systems with the aim to apply the same

security issues of legacy systems.

As better described in the following chapter and in deliverable 1.4 ”Report on Pilots Descriptions”, Turin pilot

is caracterized by an heterogeneity of technical solutions addressing different objectives and use cases.

The MV/LV electric energy network will be addressed in terms of technical solutions for better O&M of the

network by the DSO (energy balance of portions of networks, fault and outage detections, studies on energy

storage integration). In details, prototype smart meters will be installed in few MV/LV substations exploiting

the same concentrator used by IREN in the District Heating management and control. In terms of telecom

requirements, in a future scaled-up vision of all substations (4000 up to now) equipped with 3-phase smart

meters at the beginning of the LV lines which are downstream of the LV side of the transformer, the needs

for a near real-time data pushing of active and reactive power (meaning voltage and currents) plus some

other possible parameters at 1Hz frequency should be carefully evaluated. If the localization of the

substations will permit it, the test of LTE communication from the concentrator to the Control center could be

evaluated (the current solution is the GPRS). From the meter to the concentrator IREN and ST are studying

a prototype solution based on PLC communication (wired). NIALM algorithms at substation levels will be

tested in the project together with network resilience studies that will benefit from near real time data pushed

in the cloud system.

The final energy consumers will be the other important portion of Turin Pilot. Because of the deep regulation

changes Italy is undergoing in terms of unbundling scheme and energy footprint needs for final clients

(please see D 7.3 ” Dissemination and Exploitation Plan” for all the details), IREN objective is to test different

solutions (both in terms of hardware and IT and telecom infrastructure) enabling innovative empowering and

advanced home-control services at differnet levels (DSO, Retailers, ESCo...). Once the technicalities (also in

terms of network features) of the next generation of smart meters will be issued by the Italian Regulator

together with the defined data stream (and frequency) between the actors of the Energy world (from

producers to customers, with TSO, DSO, reailers and new figures in the middle), IREN will already have

peculiar, innovative and tested services using the defined, final technical and regualtory scheme, thanks to

FLEXMETER project.

Coming to network requirements for this part of the pilot, final users in EnviPark will be testing the same

electrical smart meters (single-phase) of the MV/LV substation described above. 868/169 MHz

communication protocol will be installed between the water smart meters and the concentrator. Tests will be

implemented on the best communication mode (fiber optic, LTE, 3G or GPRS) to push data from the

concentrator to the Control center and cloud infrastructure, where data will be processed and services for the

different stakeholders defined and created.

When talking about the more ”conventional clients” in residential building, users’ energy awareness and

empowerment (as NIALM for example) will be tested thanks to prototype ”not-invasive” (meaning with limited

installation requirements) smart meter solutions developed by UNIBO and MIDORI [although not a partner of

the project, ENEL is enabling FLEXMETER partners to test in a real environment their ”SMART INFO”: the

device will grant the possibility for energy data to flow from the current DSO smart meter to the customers via

local PLC communication and then to the cloud via wi-fi. Looking at preliminary documents, this is one of the



few solutions the Italian regulator will endorse for energy footprint purposes for the final clients, so

FLEXMETER Italian partners considered important to test it in the project].

Both MIDORI and UNIBO solutions will be post-DSO smart meters devices (meaning not in the DSO Scope

of Work and responsibility) that will push 1Hz consumption data (both active and reactive) to the cloud

thanks to the ”home gateway” developped by ENNOVA. The need of a gateway (instead of a direct wi-fi

connection with the home DSL router of the customer) lies in the future marketing plans of IREN, willing to

provide to its customers innovative ”smart home” solutions not only related to energy but also to security,

health care and others, exploiting a single, powerful IT and TELECOM infrastructure. Gateway will grant a bi-

directional flow from and to the house: it could be both coupled to the home router or with a dedicated SIM

for a stand-alone connection to the cloud (this could be considered a backup, recovery connection).

The other services (district heating and water), because they refers to the entire building and not to the

single apartments, will be exploiting the current IT and TELECOM infrastructure of the District Heating

(described in the following chapter 3.1.1). Improvements, as for the EnviPark pilot on the water side, will be

made in the installation of 169/868 MHz water smart meters. The current concentrators of the district heating

are placed in the basements of the selected buildings (where also the bulding water meters are). Because of

coverage problems, GPRS solution from the concentrator to Control Center were considered as the best

solution for IREN needs in terms of District Heating network management, near-real time data pushing and,

above all, actuation of the district heating smart meters and hot water controllers. For this part of the Turin

Pilot, the integration of multi-smart meters data and services will be made at cloud level.

3.1 Description and characteristics of the pilot (excerpt from D1.4)

To grant consistency to this document, we decided to report here an excerpt of the description for the Turin

Pilot of D1.4 “Report on Pilot Description”.

Heterogeneity of the Turin pilot could be described as follow:

• MV/LV substations: around 50 meters will be installed in several MV/LV substations so that to test the

smart meter infrastructure with the purpose of real time monitoring of the loads in order to improve system

reliability. NIALM techniques will be also tested at substation level with the aim of:

automatically detect faults and overloads throughout the application of pattern recognition

techniques on the energy distribution network;

understand if the presence of sharp increases of the electric load on a MV/LV substation is due

to a failure or to sudden changes in energy demand.

• “Environment Park” Premises: EnviPark premises, covering 30.000 m2 of private area with buildings

devoted to offices and laboratories, will represent a very privileged private pilot site of a “smart city”. Existing

distributed generation from RES, electric mobility infrastructures, eco-buildings, green area will be equipped

with a multi-smart meter infrastructure enabling several test or actuations (like demand side management

above all) without dealing with the existing regulatory constraints, at least at Italian level. EnviPark will have

an average of 100 electrical smart meters and 20 water smart meters installed during the Project. Exact

figures will be defined once the meters will be chosen and specific technical surveys on site will be

conducted so that to evaluate possible incompatibilities (e.g. not enough space in the boxes or where meter

will be installed).

• Residential users: more than 30 “new generation” electrical smart meters (at apartment level) and 10-20

district heating and water smart meters (at building level) will be installed in residential apartments and

buildings. These users will benefit of innovative services of user empowerment and home consumptions

management, testing prototypes or market devices and evaluating pros and cons. Please note that the roll



out of the new generation of electrical smart meters will start soon in Italy with the main aim to enable such

services that current smart meter infrastructure, together with regulatory constraint, isn’t able to provide.BLA

bla bla

As a whole, more than 200 smart meters of three different commodities (district heating, water and

electricity) will be installed in Turin pilot.

3.1.1 Existing network infrastructure

The actual District heating Smart meter network is made by about 6000 meter connectet by a MBUS

connection to a GPRS Concentrator.

The current local network (from meters to concentrator) is fully compliant with the standard described in the

M-BUS specification (http://www.m-bus.com/default.php) .

The M-Bus (Meter Bus) was developed to fill the need for a system for the networking and remote reading of

utility meters, for example to measure the consumption of gas or water in the home. This bus fulfills the

special requirements of remotely powered or battery driven systems, including consumer utility meters.

When interrogated, the meters deliver the data they have collected to a common master, which can, for

example, be a hand-held computer, connected at periodic intervals to read all utility meters of a building. An

alternative method of collecting data centrally is to transmit meter readings via a modem.

Two user programs can exchange information on Layer 7. The MBUS standard is evolved in the wireless

version W-MBUS.

The metered resources are electricity, thermal energy and water at the dwelling level and electricity at

substation level.

The different smart meter types collect the data then the communication module of the meter connects to

concentrator or gateway and send reading data in regular intervals that range from real time (1 Hz) to 1/900

Hz. Data is sent from meters to the concentrator either wirelessly or wired connection. In particular at

building level data is sent to concentrators via Ethernet, at substation level the data transmission occurs via

optic fibre instead.

The concentrator, typically situated in the same building as the meters, or just outside where multiple

dwellings are monitored, aggregates data from multiple meters then it transfers data at regular intervals (e.g.

daily) to the data center via mobile network (GPRS). Data collection and processing servers are located in

IREN premises



4 MALMO PILOT: communication network requirements

For the FLEXMETER Pilot, an RF-Mesh based Smart Meter network will be implemented in the Hyllie area. It

consists of Landis+Gyr meters with a RF-Mesh communication to either GPRS gateways or broadband

gateways to the central system.

The aim of the pilot is to cover:

Electricity metering

Heat metering

Substation metering

Substation monitoring equipment



Control equipment, in order to be able to implement for example load management applications or

load balancing applications

For the project, an RF-Mesh solution from Connode AB was selected, but there are now coming other similar

RF-mesh on the market.

The Connode 4 solution is an IP-based Machine-to-Machine platform over radio mesh network, where all

communication components and security components are based on open-standards. The system is intended

for use in Smart Metering / Smart Grid applications.

The new features with Connode 4, compared to its predecessors, is that it is built on international standards,

such as IEC 802.15.4.g (Mesh Radio, 868 Mhz) and IPv6LoWPAN.

The Central system is cloud-based and has a standardised application interface, IEC 61968 och is

compatible with DLMS/COSEM.

System features include auto-installation and auto routing which is very interesting features for operation and

maintenance of the system.

Currently, the IPv6 communication is under development and under beta-test in Norway and Sweden. The

technology has also been selected in E.ON UK as one of the preferred meter communication technologies,

in the Telefónica consortium.

The main advantages with this technology are:

Open, standardized communication. Both IPv6 and the web service interface is open (IEC61968)

Robust, the technology is based on an auto routing concept where the nodes can find the

communication path themselves. It also support plug and play installations.

Expected to be widely spread, it is the future solution also for other smart applications

The benefits are mainly in three areas:

Real-time communication is implemented, which allows E.ON to get a fast response on inquiries to

the meter, not only for meter reading but also as a support for Customer Service to check meter

status when the customer is calling in, and also as an operational tool in power system operations

Communication cost is expected to be very low since the cost of communication (based on existing

available contracts is “flat-rate”) and the fact that several meters can use the same TCP/IP

communication channel, but also be able to use existing LAN/WAN connection in the buildings.

The communication technology meter2meter is based on “mesh-radio” which is “self-healing” and

does not require a lot of on-site maintenance.

4.1 Description and characteristics of the pilot

Hyllie is an urban area with 2G / GPRS and 3G coverage. In addition, LTE network is also well covered in

this area (the figure below is showing the map of 4G coverage of Telia Sonera

https://www.telia.se/privat/support/tackningskartor ).

https://www.telia.se/privat/support/tackningskartor



4.1.1 Existing network infrastructure

All the communication modules that uses Mesh radio can help eachother to reach a communication gateway

terminal that sends the information further over either 2G GPRS or over the broadband fibre network to the

MDM system. The Mesh radio cells are dynamic and changes over time to optimize the coverage and to

secure to have connection to all terminals.



All the Mesh terminal are addressed based on IPv6, 6LoWPAN (End-to-End IPv6 connectivity) and

802.15.4(g) (Radio communication in Mesh network) and has CoAP (Http like application protocol) and

DTLS (Security layer equivalent to TLS for web browsing) secutity. The built-in security support strong

asymetric encryption based authentication and AES based transmission encryption.

The Mesh communication terminal communicate with internal serial interface to the energy meter).

The system is real plug-and-play and if there is an new terminal installed it will directly try to find an Mesh

radio cell to connect to. If the terminal is known by the Connode server it will be accepted by the server and

the terminal instantly start sending values to the MDM server.

Furher specification on the Connode Mesh system:

Connectivity Management / Communication

Feature Details

EXI

EXI is a Binary XML encoding for COAP payloads to skip the verbose nature of

XML or JSON

Open standard: W3C (World Wide Web Consortium) Recommendation 10 Marc

2011

CoAP v1.1

CoAP provides the same services as HTTP with Rest semantic for devices with

limited resources:

GET

PUT

POST

DELETE Open standard: RFC 7252

DTLS v1.1

DTLS is the Datagram version of TLS

To negotiate a cipher suite between Agent and Server

To mutual authenticate both end-points

To generate a symmetric key for encryption of each IP packet Open standard: RFC 4347 and associated

IPv6

6LoWPAN

IPv6 supported for all IP traffic between the Connode Server and each Gateway

Node.

6LoWPAN supported for all IP traffic over radio Mesh networks

Open standard: RFC4944 and associated

802.15.4g

Radio spectrum: 869.400 - 650 MHz

2-GFSK@50Kbits/sec

Link budget: 135 dB with PA and 125 dB without PA (Error rate: 1 %

BER@868MHz)



Max output power: 500 mWatts

Adaptive Transmit Power is supported to not use the maximum output power

when this is not required

Recommendations expected in ERC-70-03 to define the frequency which should

be used

IEEE 802.15.4.g

Radio Link Layer encryption (AES)

Open standard: IEEE 802.15.4g (IEEE 802 Standard Committee)

Cellular connection

v1.0

The Mesh Gateway can use a 3G Cellular connection as backhaul

Ethernet Connection

v1.0

The Mesh Gateway can use a Ethernet connection as backhaul

IPv4 Tunnel v1.0 Setup an IPv4 Tunnel between a Gateway Node and the Connode Server to

traverse non IPv6 networks

Connectivity Management / Data Management

Feature Details

Agent Event Push

v1.0

Agents Events are pushed to the Connode Server after generation. All

collected Agents Events:

• Must be visible in table

• Can be retrieved by external system via Web Service

Automatic Push of

Readings v1.0

Readings must be pushed to the Connode Server after sampling.

Readings may be re-transmitted a few times over a 1 min period within the

COAP communication layer until they are delivered to the Connode Server

Reliable transfer to

Server v1.0

There is functionality that guarantees that any event generated and persisted

in a Agent has been successfully delivered and stored in the database of the

Connode Server

HTTP / CoAP

Proxy in Server

v1.0

The Server is able to convert a CoAP message to HTTP and back

Event and Reading

caching v1.0

Events/Readings must be stored locally in a rotating buffer within the Agent for

later transmission if the connection to the Connode Server is currently not

available



Connectivity Management / Device Management

Feature Details

Agent Monitoring

v1.0

The following attributes are pushed periodically from the Agent

Firmware version – on login

Hardware version – on login

Next Hop information o Available from each Agent via Web Services to put together a topology

map of each radio mesh network

Node Event

Management v1.0

Node Events in the Connode Solution are generated by each mesh Node and

delivered to the Connode Server reliably.

A circular buffer is defined in each node to store locally notifications (Node

Events) before they are pushed to the Connode Server. If some of those

notifications are detected as missing in the Connode Server, the Connode

Server starts pulling for those missing entries.

Server Initiated

Agent Restart v

1.0

Restart the Agent from the Connode Server

DTLS/CoAP Ping

v1.0

COAP Ping request/response from the Connode Server to any Agent over the

secure DTLS session

Data Rate

Evaluation v1.1

The Data Rate Test is an action the User can trigger from the Web Interface or

from the Web Service interface to initiate a Data Rate Test between the

Connode Server and a specific Node.

The results of this Data Rate Test must be presented in the User Interface or

included in the response to the Web Service Request.

Unicast Firmware

Update v1.0

The Unicast Firmware Update must be done over the DTLS/COAP session

between the Connode Server and one Agent.

Web Service must be available to query the status of this job

Multicast

Firmware Update

v1.0

The multicast firmware update must be supported over the DTLS/COAP session

from the Connode Server to one Gateway Node and then distributed over

multicast to a set of Mesh Nodes within a mesh network to reduce the overall

use of the cellular network and radio mesh network.

Once the integrity of the firmware image has been verified in a Gateway Node,

the Connode Server must trigger the radio broadcasting over a radio mesh

network in order to distribute this firmware image to the target list of Agents.

Once all blocks of the file have been broadcasted, each Mesh Node must

request any missing block from the Gateway Node before reporting back to the

Connode Server that this file transfer is successful and that the firmware update

itself can now be triggered.

Configuration

management v1.0

The C4 Solution provides a way to configure and reconfigure a user-defined

group of Agents



Last Gasp v1.0

The C4 Solution supports a last gasp notification to report power outage or

restart.

In this version, a Power Down Event is generated and pushed to the Server

before power failure (or soon after power restart).

Adaptive Output

Power v1.0

The Agent support adaptive power usage and 500mW or less of output power

@ 868MHz using IEEE 802.15.4g.

If radio communication between two nodes in a mesh network does not require

maximum output power, then the output power for this radio link is lowered.

Configurable

Reading Interval

v1.0

Readings can be sampled at a configurable interval, from minimum 5 seconds

up to at least 24h.

L+G E350 energy

meter

Driver support the following features:

Discovery of device properties

Power switch management

On demand sampling of registers

Sampling of register based on a series profile

The following registers: 1.8.0, 2.8.0, 37.7, 52.7, 72.7, 36.7, 56.7, 76.7, 82.8.1, 82.8.3, C.5.0, 82.8.2, C.7.0, C.7.1, C.7.2, C.7.3, C.1.0

5 FLEXMETER Use cases and related requirements

5.1.1 Prosumer load profiling

NIALM (Not Intrusive Appliances Load Monitoring) approach applied to FLEXMETER project tackles the

energy disaggregation problem making use of generic appliance specific usage patterns and features that

can be applicable to any households unlike most of the previous works which concentrate their work on

methods requiring a lot of time consuming training and a long list of appliance database which are subjected

to change from apartment to apartment. Hence, the significance of this system is that it requires only one

smart sensor applied to the main counter or in another equivalent point in the electrical domestic line and no

deep user training is necessary.

The smart meter will acquire current and voltage at high frequency sampling and then evaluate 1Hz-sampled

active and reactive power to feed NIALM algorithms. Data will be delivered to a gateway and then sent to an

external server. The transmission between smart meters and the general gateway is defined in the following.

Midori has been cooperating together with Gruppo Iren to find out the best and most attractive use cases in

terms of smart sensor installation and communication between smart sensors and gateways. In particular,

we’ve been focusing on the followings:



1. the smart sensor will be installed at the main counter inside the user apartment by mean of a

common current clamp. The way to acquire the voltage will be further investigated and is currently

an open problem. The data will be transmitted via Wi-Fi by means of the user router or the gateway

MyTEC offered by Ennova;

2. the smart sensor will be installed by means of a DIN Rail standard module in the case where the

main counter is not inside the user apartment, but - for instance – installed at the building

basement1. The hardware requirements for this scenario must be still designed and the data

transmission will be made exploiting the two ways described at the previous point;

3. the smart sensor will be installed at the main counter in the basement of the building. Data will be

transmitted exploiting three different ways:

a. a gateway, property of Gruppo Iren, installed at the district heating building unit that can

centralize data stream coming from several sources;

b. the gateway MyTEC offered by Ennova;

c. via powerline directly to a receiver plugged in the house and then via Wi-Fi to the domestic

router.

The following table is summarizing the communication requirements given by the present use case (notice

that information in the requirement table will be further investigated during the development ofthe project).

Requirement Importance

(Low&Mid/High) Value Range

Notes

Throughput Mid Up to 8Kbps

Estimated value based on “Frequency of Messages to be exchanged” and “Size of message”

Latency Low - The data transmission protocol (MQTT) uses policies that prevent any problems in this regard.

Reliability Low - The data transmission protocol (MQTT) uses policies that prevent any problems in this regard.

Frequency of Messages to be exchanged

Mid 1 Hz Max

This data refers to sending data in streaming mode. We are also considering sending data less frequently in order to seek the best tradeoff.

Sending nodes Mid XXX It is the number of users.

Receiving nodes High 1 It is the server that receives, stores and processes data.

Size of message Mid About 1KByte -

1 an example of standard DIN boxes can be seen at the following link http://docs-europe.electrocomponents.com/webdocs/105b/0900766b8105ba74.pdf

http://docs-europe.electrocomponents.com/webdocs/105b/0900766b8105ba74.pdf



5.1.2 User aggregation for load balancing

In this Use Case we aim at designing an Energy Aggregator Multi Sided Platform, able to deploy different

types of energy related service. In this diagram we present the General Architecture.

Figure 1 - User aggregation for load balancing use-case diagram

The IoT Platform collect the energy management system data, like power production and consumption. First

of all, the Historical Data Provisioning block retrieve and aggragate data from the IoT platform and transmit

the result to three different blocks:

• User Habits Analysis: that aims at modeling the consumer behavior for each one of their devices;

• Load Forecasting: once received the aggregated energy consumption data and the consumer device

models, this block will infer about his future energy consumption pattern;

• Production Forecast: once received the aggregated energy production data and the weather

forecast, this block will infer about the prosumer future energy production pattern;

The block results are input for the Energy Aggregator Core, a container of all the functionalities described

before in the use case definition. The essential blocks are:

• Smart Scheduler: that aims at scheduling different IoT and non-IoT devices to achieve a

predetermined energy consumption pattern;

• Matching Consumption/Production: it works in parallel to the Smart Scheduler to achieve the

optimization of the energy flows outgoing/incoming from a grid portion;



• IoT Devices Management: once received the IoT device scheduled activation timestamps,

accomplish the direct control of the devices; In case the IoT device has not the possibility to

postpone the activation, this block manage and send the activation command at the scheduled

timestamps.

• Human Recommendation Interaction: once received the non-IoT device scheduled activation

timestamps, manage the human interaction to achieve the scheduled activation;

• Demand Response Event Management: once received a DR event instance by the DSO/TSO, select

the set of devices to activate/curtail to obtain the desired growth/decrease of power absorption.

Not only the results of the Forecasting and Learning blocks are input for the Energy Aggregator Core, but

also the results of Energy Market and Tariff Provisioning blocks, that are blocks with functionalities of data

retrieval from the Energy Market and the Energy Retailer that provide different information to assure

earnings for the consumer prosumer and a marketplace impact of the Energy Aggregator MSP.

5.1.2.1 Smart Device Scheduler

The Smart Device Scheduler (SDS) works by accessing real-time consumption and production power

measurements from the database in the cloud, market and tariff information, weather prevision and other

relevant data; then it processes such information in order to achieve the load balancing and shaping of a

portion of the grid by means of smart scheduling of different kinds of device belong to the same grid portion.

The result of the Smart Device Scheduler is a set of timestamp activations of the different devices. Both

direct control (IoT Device Management System) and indirect control (Human Recommendation Interaction

System) are considered.

The Smart Device Scheduler (SDS) needs to extract from the IoT Platform the following data:

real-time measurements (IoT Platform);

non-intrusive automatic load monitoring (NIALM) analysis results (Midori);

model of the network nodes (DSOs/utilities);

low voltage state estimation (IoT Platform)

energy market and tariff information (Regulatory Authority/ Energy Retailer)

weather forecast (Weather Forecast Provider)

The information relatives to the energy consumption measurement and NIALM results are used by:

Human Habits Analysis System (HHAS) in order to build a usage model of different devices

associated to each consumer/prosumer.

The results of the HHAS, the energy consumption and production measurement and the weather forecast

are used by:

Load Forecasting System (LFS) in order to predict the energy consumption profile of customers

belong to the grid portion of interest. Furthermore, the LFS will generate energy consumption profile

for customers that are not monitored by means of smart meters or unavailability of updated data in

the database due to possible problems in the equipment or in the communication;



Generation Forecasting System (GFS) in order to predict the energy production profile of prosumer

belong to the grid portion of interest. Furthermore the GFS will generate energy production profile of

prosumer PV plants that are not monitored by the means of smart meter or unavailability of data in

the database due to possible problems in the equipment, in the communication or in the case of

absence of prosumers in the grid portion of interest to simulate production behaviours.

All these input data are then processed by:

Smart Scheduler (SS) in order to solve the device scheduling problem of the grid portion of interest

to achieve the aggregated load profile shape provisioned by the DSO. The SS needs information

about the energy market and energy tariff. The SS requests details of the current tariff from the

Energy Retailer and produces optimized schedule to ensure earning in customer energy billing.

The output of the SS algorithm has then to be sent to:

IoT Device Management System (IoT DMS) in order to control the remote IoT device. IoT DMS is

able to transmit the scheduled departure to each IoT device to achieve remote control of the device

activation. Furthermore, IoT DMS is able to receive the acknowledgment of the device activation;

Human Recommendation Interaction System (HRIS) in order to assure that non-IoT devices could interact

with the SDS. HRIS generates activation suggestions and sends them to the users by means of a mobile

application. The activation suggestion can be accepted by the user, whom is responsible of the device

activation. HRS has to assure the detection of the activation to notify earned credit to the consumer.

5.1.2.2 Production and Consumption Synchronizer

The Production and Consumption Synchronizer works by accessing real-time consumption and production

power measurements from the database in the cloud, tariff information, weather prevision and other relevant

data; then it processes such information in order to achieve the production and consumption profile matching

on a portion of the grid by means of smart scheduling of different kinds of device. The results of the

Production and Consumption Synchronizer is a set of timestamp activations of the different devices. Both

direct control (IoT Device Management System) and indirect control (Human Recommendation Interaction

System) are considered The Production and Consumption Synchronizer (PCS) needs to extract from the IoT

Platform the following data:





tariff informations (Energy Retailer)

weather forecasts (Weather Forecast Provider)


Human Habits Analysis System (HHAS) in order to build a usage model of different devices

associated to each consumer/prosumer.

The results of the HHAS, the energy consumption and production measurement and the weather forecast

are used by:



Load Forecasting System (LFS) in order to predict the energy consumption profile of customers

belong to the grid portion of interest. Furthermore, the LFS will generate energy consumption profile

for customers that are not monitored by means of smart meters or unavailability of updated data in

the database due to possible problems in the equipment or in the communication;

Generation Forecasting System (GFS) in order to predict the energy production profile of prosumer

belong to the grid portion of interest. Furthermore the GFS will generate energy production profile of

prosumer PV plants that are not monitored by the means of smart meter or unavailability of data in

the database due to possible problems in the equipment, in the communication or in the case of

absence of prosumers in the grid portion of interest to simulate production behaviours.

All these input data are then processed by:

Production Consumption Matching System (PCMS) in order to solve the device scheduling problem

of the grid portion of interest to achieve the production and consumption power profile matching. The

PCMS needs information about the energy tariff. The PCMS requests details of the current tariff from

the Energy Retailer and produces optimized schedule to ensure earning in customer energy billing.

The output of the PCMS algorithm has then to be sent to:

IoT Device Management System (IoT DMS) in order to control the remote IoT device. IoT DMS is

able to transmit the scheduled departure to each IoT device to achieve remote control of the device

activation. Furthermore, IoT DMS is able to receive the acknowledgment of the device activation;

Human Recommendation Interaction System (HRIS) in order to assure that non-IoT devices could interact

with the SDS. HRIS generates activation suggestions and sends them to the users by means of a mobile

application. The activation suggestion can be accepted by the user, whom is responsible of the device

activation. HRS has to assure the detection of the activation to notify earned credit to the consumer..

5.1.2.3 Demand Response Event Manager

The Demand Response Event Manager works by accessing real-time consumption power measurements

from the database in the cloud, tariffs information and other relevant data; then it processes such information

in order to change real-time consumption patterns of portions of the grid in response to specific Demand

Response Event request from the DSO and/or Energy Retailer by direct control of IoT devices belong to the

grid portions of interest. The result of the Demand Response Event Manager is a set of IoT devices to

curtail/activate through direct control (IoT Device Management System) to achieve the Demand Response

technical request.

The Demand Response Event Manager (DREM) needs to extract from the IoT Platform the following data:





tariff information (Energy Retailer)




Demand Response Event Management System (DREMS) in order to select the IoT device set

belong to the affected portion of the grid to achieve the curtail/increment of the power consumption

of the same portion. The DREMS needs also information about the energy. The DREMS requests

details of the current tariff from the Energy Retailer and select an optimized schedule to assure

earnings in customer energy billing.

The results of the DREMS are used by:

IoT Device Management System (IoT DMS) in order to control the remote IoT device. IoT DMS is able to

transmit the scheduled departure to each IoT device to achieve remote control of the device activation.

Furthermore, IoT DMS is able to receive the acknowledgment of the device activation.

5.1.2.4 Network requirements

Our Energy Aggregator Multisided Platform resides in the cloud and will interact with the FLEXMETER IoT

platform through a Backend as a Service infrastructure. The metering data collected are estimated to be:

Energy Measurement (Energy, Active and Reactive Power): Data Model [1] (used also in INTrEPID

project [3]) encloses in JSON format the Energy Measurements: the dimension of a measure in

JSON format is 200 bytes. We want to receive data with a sample rate of 1 second to achieve our

services (NIALM,DR,..).

Direct Load Control: it requires low latency to be almost instantaneous an to mislead the human

response time (almost 300 ms). INTrEPID Data Model enclose in JSON format the Direct Load

Control Messages: the dimension of the packet will be 200 bytes.

Energy Measurement Requirement

Importance (Low&Mid/High)

Value Range Notes

Throughput MID 600 B/s uplink Latency MID ≤ 1 s - Reliability HIGH - - Frequency of Messages to be exchanged

HIGH 1 Hz -

Sending nodes - 30-300 - Receiving nodes - 1 - Size of message MID 600 B -

Direct Load Control Requirement

Importance (Low&Mid/High)

Value Range Notes

Throughput MID 200 B/s downlink Latency HIGH ≤ 300 ms real-time Reliability HIGH - - Frequency of Messages to be exchanged

LOW 1-10 times/day -

Sending nodes - 1 - Receiving nodes - 1 - Size of message MID 200 B -



5.1.3 Network management

The use case about “Network management” aims to balance network load profile by using energy storages.

The goal is to write an algorithm that manages the charge and discharge operations of a battery situated in

the medium to low voltage cabins. In the sequel, we will call this algorithm as “storage manager”. This tool

will work by using real-time consumption and production power measurements from the database in the

cloud, and by using the load profile scenarios generate from the ING. The output of the storage manager is,

for each time step, the control of the energy storage. By using this tool, the energy network will gain stability

and further renewable energy will be more competitive.

Figure 2 – Communication network connecting Cloud DB and MV/LV cabin

The use case diagram2 is the following:

Figure 3 – Storage management use-case diagram

2 In the use case diagram, we have called Storage management instead of Storage manager because we still do not know if we are

going to use one or more algorithms.



The information flow from the Cloud DB to the Storage Manager consists of:

Real-Time Consumption (RTC) of the buildings connected to the medium to low voltage cabin where

the battery is located in table 1 below. We need these values every 5 minutes, the quantity of

information required is a double3 stored in a csv file.

Real-Time Production (RTP) of energy of the buildings connected to the medium to low voltage

cabin where the battery is located in table 1 below. We need these values every 5 minutes; the

quantity of information required is a double stored in a csv file.

A reasonable amount of Load Profile Scenarios (LPS) in table 1 below. We need these values every

5 minutes and we need at least 1 MB of information stored in a csv file.

The information flow from the Storage Manager to the Battery consists of:

For each time step the ACTION (charge - discharge - do nothing) that the battery must do in table 1

below. The data (2 bits) will be sent once every 5 minutes. The algorithm will send a .csv file

The following table is summarizing the communication requirements given by the use case described in the

above.

Information transferred

Direction Requirement Notes

Transmission of RTC Cloud DB Store Manager ( 8 bytes x N )

every 5 min N is the number of

buildings

Transmission of RTP Cloud DB Store Manager ( 8 bytes x N )

every 5 min N is the number of

buildings

Transmission of LPS Cloud DB Store Manager 1 MB

every 5 min

ACTION Store Manager Battery ( 2 bits x N ) every 5 min

The algorithm will send a .csv file

5.1.4 Energy storage integration

The “Energy Storage Integration” use case focuses on the study of the technical and economic opportun ity

to add energy storage units in a specified set of nodes in a section of the distribution network, meeting

several power quality and quality of service criteria.

The set of nodes having a prosumer profile which is given by the storage elements will be identified in the

planning stage of grid development by an algorithm developed as part of Task 3.2. This algorithm is based

on information concerning the existing grid infrastructure and on a comprehensive measurement data set;

the latter is enabling expressing relevant power quality parameters (mainly: voltage) in all network nodes.

The database will consist on information stored for 1 year with a time resolution of at least 15 minutes. The

relevant quantities in database will include voltages, currents, active and reactive power.

The proposed algorithm runs off-line and therefore does not require additional communication resources.

However, the measurement database, when considering the optimal time resolution used by dedicated data

3 Here we could assume that a floating number with double precision occupies 8 bytes in the database.



acquisition and by the existing metering infrastructure will require low bandwidth for meter- data

concentrators communication.

Also, it is foreseen that the measurement information in some nodes is stored locally and retrieved manually.

In addition, time delay and latency are not an issue when the measurement infrastructure is based

exclusively on smart meters. Ideally, the voltage profile in selected nodes should be known with higher time

resolution (i.e. 1s). However, even if smart meters able to provide such data (Nobelgrid project) are

available, in case that the network is not fully observable with this resolution, the voltage profile will be

derived from information with the lowest time resolution (15 min).

In the operation phase (distribution network with controllable prosumers, i.e. electrical storage in grid

connected mode), it will be required to send control signals to storage management systems; control tasks

should be further addressed by the communication infrastructure.

Data volume and latency are not an issue in this case.

5.1.5 Outage detection

At the moment most DSOs use customer calls to detect and locate the LV network outages. After detection

and identification of the outage area, fault location in MV and LV is normally performed by inspection by the

operators. This process has the following disadvantages:

During the nights there would be a little number of customer calls which makes the outage detection

process difficult or impossible.

False or fake reports are hard to realize.

The whole process is time consuming and inefficient.

In the FLEXMETER project new meters will be installed at the user level and in MV/LV substation on each

LV feeder. Thanks to the data measured by these devices it is possible to enhance the outage detection and

location and perform it with no or little human intervention.

Three levels of service can be implemented, depending on the capabilities of the meters and on the

communication network performances. They will be listed in increasing performance and requirements order:

1. LV Outage detection and location

In case of outage, all the meters in the outage area detect the absence of voltage and send a “last

gasp” signal to the cloud system. No particular stringent requirements are needed from the point of

view of the communication network. The main issue is that the communication network should work

also in a power outage condition, thanks to a UPS system.



Table 1. Requirements in the Turin pilot

Requirement Importance Value Range Notes Throughput * N.A.

Latency * N.A.

Reliability ***** Extremely high


N.A. 1 last gasp message per outage event

Less than 300 events per year

Sending nodes N.A. 1 to 300 meters All meters involved in the outage event

Receiving nodes N.A. The Flexmeter cloud (the outage detection algorithm)

Size of message N.A. < 100 byte, overhead excluded

Last gasp message should contain at least the error code + the id of the meter + time stamp

Table 2. Requirements in the Malmo pilot


Latency * N.A.



N.A. 1 last gasp message per outage event

Less then 10 events per year in Malmo

Sending nodes N.A. 1 to 300 meters in Malmo.

All meters involved in the outage event


Size of message N.A. < 100 byte, overhead excluded

Last gasp message should contain at least the error code + the id of the meter + time stamp

2. LV Fault location

After the detection of the outage and the identification of the area affected by the outage itself,

thanks to the measurements at MV/LV substations, it is possible to design an algorithm to identify

the fault location on the LV lines. For this purpose the meters in the MV/LV substation feeding the

fault should send the during-fault current and voltage waveforms or phasors immediately after the

outage detection. Also in this case no particular stringent requirements are needed from the point of

view of the communication network. The amount of data to be sent is quite small and there are no

stringent latency requirements. Even if the data arrive to the cloud some seconds after the event, it

would be much faster than with conventional fault location methods. Also in this case the main issue

is that the communication network should work also in a power outage condition, thanks to a UPS

system.



Table 3. Requirements in the Turin pilot


Latency * N.A.



N.A. 1 message per outage event


Sending nodes N.A. 1 MV/LV substation meter

Only the MV/LV substation meter feeding the fault will send a message


Size of message N.A. Around 1.5 KB, protocol overhead excluded

4

The message contains an error code + the id of the meter + time stamp + 20 cycles voltage and current float values for the three phases

Table 4. Requirements in the Malmo pilot


Latency * N.A.



N.A. 1 message per outage event


Sending nodes N.A. 2 MV/LV substation meter

Only the MV/LV substation meter feeding the fault will send a message

Receiving nodes N.A. The flexmeter cloud (the outage detection algorithm)

Size of message N.A. N.A N.A

3. MV Fault location

The HV/MV substations are already equipped with voltage and current measurements for the

purpose of protection. MV network fault location is an additional feature which could be implemented

in HV/MV substations or in the main control centre. In the first case just the fault location is to be

reported, while in the second case the during-fault voltage and current waveforms or their calculated

4 The approximate size has been calculated with the following hypothesis that need to be corrected by the meters providers: 3 phases; v, i

measurement on each phase , t measurement; 20 cycles of the waveforms; 256 samples per cycle; 32 bit (1 float) per numerical value.



phasors should be sent from the primary HV/MV substation to the cloud. The requirements from the

communication network point of view are the same of the previous point.

5.1.6 User awareness about utilities

The use case about “User awareness about utilities” aims at providing information about energy

consumption and/or production to end-users (e.g. consumer, prosumenrs), in order to promote green

behaviours among citizens.

Knowing the itemized consumption of the household devices means having the necessary actionable

feedback information to propose for reducing the energy waste. The platform provides to end-users detailed

knowledge of the household consumption for each appliance and suggest personalized tips to reduce energy

waste. Generally, the benefits for end-users are summarized in the following:

knowing the energy production from renewable sources;

comparing the energy production of renewable sources among different weeks, months or years;

knowing the disaggregated energy of the household appliances;

discovering which appliance is the most inefficient by comparing its consumption with more efficient

models present in other apartments;

being aware of consumption for each appliance in terms of energy, money and CO2 footprints;

comparing the disaggregated appliance consumption among different weeks, months or years;

observing the energy consumption in real-time to monitor the apartment and receive alarms

whenever the energy situation is not as expected.



Figure 4 – User awareness application use-case diagram

As shown in the above Figure, User Awareness Applications retrieves the following data from the

FLEXMETER Cloud:

real-time measurements for cumulative energy consumption (electricity, water, heating, etc.);

historical measurements for cumulative energy consumption (electricity, water, heating, etc.);

historical measurements for cumulative energy production

comparison and correlation of cumulative energy consumption and production for prosumers

historical measurements for appliances energy consumption among different weeks, months or

years:

o NIALM results for its own appliances;

o Compare energy consumption of his/her appliances with more efficient benchmark models for

the same appliance

receive real-time alerts when the energy situation is not as expected (e.g. the power consumption is

over a certain threshold)

Prediction of energy production (e.g. PV panels) for prosumers.

Notifications and suggestions



The following table reports the communication requirements for this use case. The End User application (see

Figure 4), running on mobile devices (such as Android smartphone or tablets), supports the widely used

connections 3G/4G/Wi-Fi 802.11 b-g. The various software actors running into the FLEXMETER cloud (see

Figure 4) are components running in a back-end as a service environment. Finally, the Energy Management

System (User home-side) (see Figure 4), sends to FLEXMETER cloud information about Energy, Active and

Reactive Power. Such information is sent in JSON format with a payload of about 200 bytes (protocol

overhead exluded) and sample rate of 1 second to address the requirements of other FLEXMETER services,

such as NIALM.

Requirement Importance Value Range Notes Throughput * 600 B/s (uplink)

Latency * N.A.

Reliability ***** high


***** 1 sample per second

Sending nodes ***** smart meter per home

Receiving nodes ***** The FLEXMETER cloud (e.g. Historical Data stores and NIALM)

Size of message ***** Around 200 byte, protocol overhead excluded

5

5.1.7 Scheduling of daily operation of electro-thermal loads

End-users are expected to play an increasingly active role in the Smart Grid scenario. For example, they can

actively manage their demand to save money, not only through a more efficient behaviour aimed at reducing

energy consumption, but also by adapting their demand profile according to changing energy prices. At the

same time, they can also support a more efficient operation of the grid, for example by offering flexibility in

their power demand. Financial incentives could be optionally provided to encourage customers to accord

some flexibility in their loads.

Electro-thermal devices (e.g. heat pumps, electric heaters, etc.) are an example of flexible loads that could

be suitably exploited to achieve a more efficient operation of the grid as well as an easier integration of

renewable energy sources [1], [2]. In fact, the thermal storage characteristics of the buildings, together with

the relatively slow dynamics of temperature variations, allow managing the schedule of the thermal devices

operation in a flexible way and without affecting the thermal comfort of the customers. As a consequence,

this flexibility can be used by DSOs to meet their needs in terms of grid management, allowing for example

the reduction of power peaks and power losses.

This use case focuses on the design, implementation, test and validation of different strategies for the

optimal scheduling of the daily operation of electro-thermal devices. The main goal is to develop an

intelligent management of the thermal loads that allows the reduction of the power peaks in the grid, while

providing at the same time the required thermal comfort to the customer.

The conceived solution will rely on the communication infrastructure designed for the FLEXMETER

architecture and will exploit some of the services made available in the FLEXMETER central cloud. In

particular, the services required for the management of the electro-thermal loads are: the weather forecast

5 The approximate size has been calculated with the following hypothesis that need to be corrected by the meters providers: 3 phases

voltage; current measurement on each phase, timing= 20 waveforms cycles; 256 samples per cycle; 32 bit (1 float) per numerical value



service and the load forecast service. Both the services have to provide the data associated to the following

day, in order to allow the day-ahead scheduling of the thermal devices operation. The weather forecast

service is needed to estimate the amount of energy necessary to fulfil the requirements, in terms of thermal

comfort, of each customer. The load forecast service is instead needed by the DSO to estimate the resulting

load profile in the electrical grid during the day. On the basis of the estimated load profile, a virtual price

variable over the time is generated for each customer, which is used within the optimization process.

From the communication point of view, two cases can be distinguished: the centralized and the decentralized

scenario. In the first case, the optimization algorithm resides in the central cloud. At the beginning, the

preferences of the end-user are sent from his energy management unit (connected to the FLEXMETER

communication infrastructure) to the scheduling service on the cloud and stored there. Then, when the

optimization problem runs (once a day), as soon as the scheduling solutions are obtained, they are sent to

the corresponding energy management unit of the customer. In case of decentralized control, the

optimization algorithm is directly executed on the energy management units of the customers (even in this

case once a day). In this scenario, the customer preferences are locally stored in the energy management

unit so they do not need to be transmitted; on the other hand, the virtual prices generated by the DSO and

the weather forecast have to be sent to the customer units to allow the execution of the scheduling

optimization process. The results of the scheduling are then sent to the central cloud database and made

available to the DSO to refine the load forecast. In both the cases, a bi-directional communication is thus

needed to correctly manage the service.

From the above description, it is clear that the electro-thermal loads scheduling does not need stringent

requirements from the communication point of view. The amount of data to be transmitted is very limited,

since the transmission of few data per day (related, for example, to the scheduling output or the virtual price

over the time) is sufficient for the proper operation of the service. Therefore, the requirements in terms of

bandwidth are not relevant and low transfer rate can be accepted. Similarly, since this service does not have

real-time communication requirements, latency and transfer times are not a critical issue Low priority can be

assigned to these packets, leaving higher priority to real-time management or control services. Finally, as for

the reliability of the data transmission, even though this service is not crucial for the reliable and safe

operation of the electrical system, a medium/high level of reliability in the communication is recommended in

order to properly operate the service.

Communication requirement Accepted level

Bandwidth low

Transfer rate low

Latency high

Priority low

Time synchronization Not needed

Reliability Medium/high



References

[1] C. Molitor, D. Cali, R. Streblow, F. Ponci, D. Müller and A. Monti, “New Energy Concepts and

Related Information Technologies: Dual Demand Side Management,” in Innovative Smart Grid

Technologies Europe (ISGT), 2012 IEEE PES, Washington, 2012, Pages:1-6

[2] C. Molitor, M. Milan, L. Hernandez and A. Monti, “Decentralized coordination of the operation of

residential heating units,” in Innovative Smart Grid Technologies Europe (ISGT EUROPE), 2013 4th

IEEE/PES, 2013, Pages: 1-5

[3] INTRePID project, http://www.fp7-intrepid.eu/

http://www.fp7-intrepid.eu/

Date post:	26-Mar-2018
Category:	Documents
Upload:	dangdung
View:	226 times
Download:	1 times

Report on Communication Network Requirements -...

Documents