Employees have the freedom to select in which language they want to express themselves.
You can find more entries selecting Spanish language in the top left corner link.

Virtualizing sensor network: final Video presentation

Author: Javier Lucio

The EU FP7 VITRO project (http://www.vitro-fp7.eu), about virtualization of sensor networks, is reaching its end. It has been working on the virtualization of sensor networks as shown in older posts: http://www.lacofa.es/index.php/general/english-virtualizing-sensor-network-vitro-practical-scenarios?lang=en and http://www.lacofa.es/index.php/general/english-virtualizing-sensor-networks?lang=en.

Now, you can see a video explaining the concept developed in the project through a practical use case:

Notification Server

Authors: Fernando Rodríguez Sela, Guillermo Lopez Leal, Ignacio Eliseo Barandalla Torregrosa

Introduction

Today mobile applications retrieve asynchronously information from multiple sites. Developers have two ways to retrieve this information:

  • Poll: Periodically query for information from the server.
  • Push: The server sends the information to the client when the required information is available.

The first method is strongly discouraged due to the large number of connections made to the server needlessly, because information is not available and you lose time and resources.

This is why the Push methods are widely used for information retrieval. Anyway, how Push platforms are currently developed are misusing mobile radio resources and also consuming too much battery.

This article aims to explain how to manage this kind of messaging, problems with existing solutions and finally how Telefónica Digital, within the framework of the development of Firefox OS operating system, ideated a new solution designed to be friendly to the network and use few battery on mobile terminals.

State of the art

Historically, mobile operators offered (and offer) real mechanisms of Push notifications, also known as WAP PUSH. This technology can “wake up” applications when any action is required by them from the server side (without interaction from the user). Sending WAP PUSH messages is done in the circuit-switching domain, the same used for voice and SMS, and that is why the user does not have the need to establish a data connection. These kind of messages work properly out of the box.

WAP PUSH solutions works great when the user is registered in the mobile network, but if you are out of coverage or connected to a WiFi hotspot instead of a celular network, you can not receive the messages.

Also, if we add that sending messages imply an economic cost (basically it is a normal SMS) the effect is that major smartphone operating systems (Apple iOS and Google Android) have implemented a parallel solution that would work regardless of mobile networks to which the user belongs and it can run smoothly when they are using WiFi networks.

Current solutions issues

These alternative solutions are based on a public server that is accesible from the Internet, from which all Push messages are canalized for the mobile devices and act as a intermediate between all platforms between third party app servers and the devices.

These new platforms of Push messaging had a big problem to solve, because usually mobile devices belonging to users are inside private networks (not accessible from the Internet) and their communications are managed by NAT servers and firewalls that block the access to the phone from outside of the private network, or to call it, from the Internet. To solve this, different operating systems has decided to open a connection from the device to their proprietary servers, and keep the connection open using this channel as a platform to communicate and receive Push notifications.

Both Apple and Google has used this approach. But that forces the phone to keep a permanent open connection with their server and to avoid the connection to be closed, either by the own TCP timers or by the NAT timers that they need to pass thought to reach the platform server, by sending small data packets, known as keep-alive, that do not have any valuable data and they are used only to say that some data is being transferred across the connection.

This solution has some serious issues:

  • Keeping open connections on intermediate routers reduce notably the performance of these devices causing big scalability problems on mobile networks. For example, in Spain there are more than 15 million of smartphones connected to the Internet.
  • Signaling storms: Mobile networks use a lot of signaling messages to manage the location of a device, their status, stablising new connections… Each time they send a small data packet, there are generated a big number of signaling events. The problem is that, multiplying the number of smartphones by the signaling produced by each device, networks are saturated just by the signaling messages, that lower the quality of service provided by the mobile networks.
  • On the other hand, these solutions that a first glance are valid on traditional networks (like wired or WiFi home networks), are not valid on a cellular network, due to how operates a radio modem chosen for the mobile phones, because they are designed to lower the battery usage when they are not transmitting any data, however, this Push solutions used by the main operating systems, need to send keep-alive messages so they prevent the phone to enter to that idle state, or low energy consumption mode.

Collateral effects of these solutions are that the device batteries are consumed at quick speed to perform redundant operations (like sending small messages to prevent that their connections are closed).

Those problems are worse when we see that a lot of applications (most of them, on the top 10 of each market) create their own connections without using the technique provided by the operating systems, so they are literally multiplying problems with each new application.

So, what is happening on the mobile network?

As we said before, mobile networks do not work as the same way as a WiFi network, and designing previous solutions without considering first how this network work derives on the problems told in the previous section.

So, to really understand the problem, we need to know the different states under the radio modem can be:

On the 3GPP TS 23.060 specification, we can see all the things related with the states of the GMM layer (GPRS Mobility Management), that corresponds to the packet-switching domain on mobile devices. On the 3GPP TS 25.331 we can consult the information relative to the RRC layer (Radio Resource Control) where those radio levels are defined.

Joining the radio states and GPRS states we can know what is the actual state of the terminal.

NOTE: To simplify, in the next table we consider that there are no activity on the domain-switching circuit, so there are not any voice calls:

GMM

RRC

Description

2G state 3G state

3G

READY PMM-CONNECTED Cell_DCH Phone is transmitting or receiving data using a dedicated channel or a HSPA shared channel.

Cell_DCH timers are really small, so if there is no data transmitting or receiving during the past seconds, the timer will bring us to the Cell_FACH.

This timer is known as T1 and can vary between 5 and 20 seconds.

Cell_FACH The phone has been transmitting or receiving data some seconds ago, and due to inactivity (>T1) it has been moved from the state Cell_DCH to Cell_FACH.

If inactivity remains for more than T2 seconds, RRM will order the phone to move to the states Cell_PCH, URA_PCH or Radio Idle.

It’s also possible that the phone is transmitting or receiving small data packets, like pings, keep-alives or cell updates…

Usually, the T2 timer lasts for around 30 seconds.

Cell_PCH o URA_PCH Phone has been on the Cell_FACH state some seconds ago and due to inactivity (>T2), RRM has moved from Cell_FACH to Cell_PCH or URA_PCH.

However, the signaling connection is still available, despite no data will be send right now.

If new data must be sent by the connection, it is not necessary to re create the connection, but reuse the old one.

STANDBY PMM-IDLE Cell_PCH o URA_PCH Phone is not transmitting data and signalling connection has been erased, however, the PDP context is still active and the phone has a valid IP address.

Those are the reasons why this state is one of the most interesting ones to keep the phone on, because battery usage is really low and it maintains their IP address so it can receive data from the network

On this state there are no resources wasted: nor network, nor battery, nor traffic… Despite this, phones can send and receive data at any moment.

As soon as the data link need to be stablished, by the phone or by the network, this can be easily changed the radio state from  Cell_PCH or URA_PCH to Cell_FACH or Cell_DCH. This change is made in less than a half a second and consumes few signaling.

RRC IDLE This state is the same as above but in this case the radio is in Idle mode.

When the phone is in Cell_PCH or URA_PCH without any activity for more than the time stablished on T3, the RRM will move the radio from *_PCH to Idle.

Reestablish the radio link from this state will spend more than 2 seconds and a lot of signaling.

IDLE PMM-DETACHED RRC IDLE Phone is not transmitting any data and there are no connection stablished, nor signaling. Phone does not have any PDP context also.

In this state, the phone does not have any IP address.

If a phone has a PDP context, probably it will be closed automatically after 24h of inactivity (not receiving or sending anything)

Battery consumption on each of this states is:

  • RRC Idle – 1 relative unit of battery usage.
  • Cell_PCH – less than 2 relative units.
  • URA_PCH – less than Cell_PCH on mobility scenarios and the same on scenarios where there are no mobility
  • Cell_FACH – 40 times IDLE consumption.
  • Cell_DCH – 100 times IDLE consumption.

It is easy to see how previous solutions and the keep-alive packets prevent the device to stay long times on the IDLE state of low battery consumption.

Solution proposed by Telefónica

With all those problems on the table, and with the intention of making an operating system with new and innovative solutions, Telefónica Digital, with collaboration of Mozilla, has designed a new notification system that avoids to keep open connections inside a mobile network.

This new solution, implemented and distributed integrally open source, defines, not only how the notification server must communicate with the devices, but also the different APIs that need to communicate with itself.

To solve the previous problems, this solution is able to keep two different communication channels with the mobile devices, so when the device is on a network not managed by the carrier, for example, on the Wi-Fi at home, the connection is kept open, like others solutions do, using the HTML5 standard WebSockets, however, when the device is on a mobile network that is managed by the carrier, the WebSocket connection is closed by the server, and will wake up the device when there will be messages to it.

To wake up the phone, the notification platform is based in a single but elegant solution:

  • We know that when the device establish a data connection, establishing a PDP context, its IP address (public or private) is kept by the carrier servers (GGSM) and not by the terminal itself, so, even if the device enters in a low comsumption mode, the IP address is not lost.
  • When the device in on IDLE mode, but with a data connection enabled and the network need to send it some data (the GGSM has received a TCP or UDP packet for the terminal’s IP address) it sends a signaling message, known as PAGING used to “wake up” the phone and changing the IDLE mode. This PAGING message is similar to the used by the cellular network to notify the phone that it needs to attend a circuit-switching call (voice, SMS…)
  • Using this way of working of the mobile networks, the only piece we have left to finish the puzzle is the ability to send a direct message to the phone, but, being inside the mobile network (with a private IP) it’s necessary to put a server inside each OB, or mobile networks.

So, this solution is used by the WakeUp server inside a mobile network, that will send a small UDP packet to the IP of the phone to “wake up” it. The phone, once received this message, will be waked up by the network and will connect to the notification server using the connection based on WebSockets to retrieve the pending messages.

Some examples about actual apps

We cannot disclose the names of the apps analyzed here, nor the names of the terminals in which they have been tested. But we can say that they are pretty popular apps, that you probably have installed on your phone, and the most popular phones in the market, with the most used operating systems.

On the following graphs, we can see the data consumption this applications have when they are on idle mode, which is the same to say: doing nothing. Colors indicate different terminals.

We can observe that some applications send small punctual sends, but other ones are transmitting constantly.

Study made by: Telefonica – NSN Smartphones lab

As we can see, the apps try to keep their connections open by sending “pings”, made in short intervals, stable in time. Meanwhile the first graphic shows an app that sends messages each 10 minutes, the second and the last one messages are sent continuously, making the phone to be always in the maximum state of the network (remember the table and the relative consumption), wasting resources just to say: “I’m alive”.

So, with our solution, this regular “pings” are completely removed, making a connection only when a notification is received by the phone, improving the use of the network, lowering the signaling and also making that phones’ battery leasts more, due to statying in less excited radio states.

Virtualizing sensor network: VITRO practical scenarios

Author: Javier Lucio

The virtualization of sensor networks concept was explained in an older post .

In that post, the concept under the title of the virtualization of sensor networks and the EU fp7 project VITRO, were introduced and described.

Now, a set of practical scenarios (6) covering the virtualization concept are described here for a better understanding and an open door for conceptualizing new services, functionalities and business models in the development, deploying and use of sensor networks.

Each of the selected scenarios is intended to demonstrate relevant VITRO functionalities. Namely, we concentrate on service virtualization, resource virtualization, service composition, service provisioning and security among additional functionalities.

Scenario 1: Service virtualization

A virtual service is obtained by extending, merging and reconfiguring the behaviour of existing services and by composing involved resources in a transparent way with respect to the underlying technology.

A number of different sensor islands are connected. These heterogeneous islands are administrated by different administrative domains and provide access to existing services and resources e.g. Energy Efficient Smart Schools and Buildings in general. The end-user would be able to monitor observations and measurements on room temperature, humidity and lighting for multiple buildings at disparate locations.

Each Wireless Sensor Island (WSI) is deployed in order to form a unique Virtual Sensor Network (VSN). Each WSI is equipped with different types of sensors, therefore information about one metric of observation may come from one out of the different WSIs.

 

Scenario 2: Service virtualization II

This scenario consists on the formation of 2 Virtual Sensor Networks (VSN) using the same sensor network infrastructure. Two VSN instantiations are formed within the same Wireless Sensor Island (WSI). A sensor participating in the first VSN e.g. providing one of its sensing capabilities can be part of the second VSN providing a supporting service such as routing for data packets of the second VSN.

Service Virtualization scenario can be distinguished in two different cases: 1) two users requesting data from the same node and 2) users request data from different nodes but one or more of the traversed nodes serve as routers, supporting both network instances.

This scenario could be applicable for use cases as controlling the traffic lights and managing the traffic in a city.

 

Scenario 3: Resource virtualization

The third scenario demonstrates the concept of node resources virtualization in order to provide relaying capabilities and form a Virtual Sensor Network (VSN) able to recover from network disconnections.

A Delay Tolerant Networking (DTN) scheme is used when a formerly connected Wireless Sensor Island (WSI) becomes disconnected for a long period of time, and therefore partitioned in a number of smaller WSI. DTN basically relies on some nodes’ mobility in order to deliver data among these WSIs and establish end‐to‐end communication.

This scenario could be applicable for the management of disasters or security in public spaces where the recovery of the network connection is an issue. For that, the scenario uses the employment of DTN mechanisms supporting the delivery of data when end-to-end connectivity within a VSN is intermitted or unavailable.

 

Scenario 4: Security related virtualization

This scenario is based on trust-aware routing protocols, and could be applicable to services as monitoring the production in sales chains or security in public spaces.

The scenario deals with the case when a Wireless Sensor Island (WSI) has some malicious nodes. The routing metrics that are utilized by the routing protocol for establishing the routes to forward the data packets, will be shown to efficiently detect any malicious nodes (e.g. grey or black nodes that drop part of or all of their incoming traffic) and re-route the data traffic around them. Also, this scenario demonstrates the effectiveness of excluding a node that does not support encryption capabilities, providing robustness and attack resistance to the WSI.

Scenario 5: Service composition

This scenario consists on the composition of a new high-level service from a set of available primary services. For example:

  • Composition of a new service called “fire detection” from two primary services: C02 measurements and temperature/light intensity measurements.
  • Composition of a “public security” service from a composed motion-detection and light intensity observation services.

In both cases, a wireless sensor network (WSN) is formed by a set of nodes (CO2 and light sensors or motion-detection and light sensors), which are deployed in order to monitor a given area. The sensors run the CoAP protocol, so they are able both to periodically send data to a specific CoAP client, who is querying the information and to answer to specific interrogation.

The nodes are connected to a Gateway which acts as a bridge between the sensor and the service provider in charge of processing the data received from the WSN, combining the observations carried out by the WSN and, eventually, raising an alarm if a target event is detected. In the scenario of “fire detection”, the SP will aggregate the data received from the light intensity and the fire temperature. When both these values are too elevated, exceeding a given threshold, an alarm is raised. In the scenario of “public security”, the behaviour of the SP is similar: the sensor publishes the measurements collected by the sensor and the SP processes received data, notifying the end-user in case of event detection.

Scenario 6: Service provisioning

This last scenario is devoted to demonstrating the continuation of service provisioning under adverse circumstances. Let’s use as the example service a composite service providing average temperature measurements from a set of temperature sensors in a room or another predefined area. The scenario demonstrates the robust and continued provision of this service in the event that one of the sensors participating in the corresponding Virtual Sensor Network (VSN) goes “down” (for example, due to energy depletion or malfunction). The system shall be able to select another sensor (in the vicinity) or group of sensors that provides an equivalent operational service and integrate it to the VSN, thus allowing the continuation of service provisioning, in a transparent way to the final user.

An end-user requests from a Service Provider an average temperature monitoring service for one or more locations, additionally specifying the number of sensors that will be providing the measurements per location. For example, the user can define that it is required that the average temperature result is reliable only when it is calculated based on 5 measurements from different sensors in a location.

After the service is initiated and the end-user receives the first results for the average temperature at each location, some sensors involved in the formed VSN will become unavailable (e.g. when they have exhausted their power resources and shut down). In this case, the gateway should be able to detect that the required number of sensors supporting the VSN is not met, based on a “disappearing node” event and inquire the “Resource and Services Controller” for other nodes within its Wireless Sensor Island (WSI) that can also provide temperature measurements. Finally, the required number of these equivalent temperature sensing nodes will be tasked to join the VSN, so that the service will continue to be provided to the end-user uninterrupted.

Fast, open and smart: Why Firefox OS is a game-changer

By Carlos Domingo, Director, Product Development & Innovation, Telefónica Digital

Originally posted in Telefonica Digital blog

 

The unveiling today of Mozilla’s Firefox OS is another big step forward – for smartphones, for HTML5 and for bringing the wonders of mobility to the entire world and not just the privileged few. Working with Mozilla, we showed off the technology at Mobile World Congress earlier this year and are proud to have played a part in what we believe will be a very compelling and useful new option for customers.

By focusing on HTML5, Mozilla has created a platform for very fast yet affordable devices based on open source technology.

Firefox OS combines HTML5 with a Linux kernel, allowing every function of the mobile phone to be developed as a web app and run through a special version of the Firefox web browser. Making a call, sending a text, taking a photo would all be done by an HTML5 app.

The result is a better experience and performance, even at low end price points. And this is crucial if we’re going to get smartphones into the hands of more and more customers in the developing world. Take Brazil where current smartphone penetration is approximately 14% and only a small percentage of people have the money to buy top-end smartphones from the mega-brands. Yes there are low end Android devices for $100 but they tend to use older versions of the OS which rapidly become out of date and performance is not that great.

Firefox OS can deliver a far better experience at these price points and that’s why are so keen to bring it to markets like Brazil.

The early signs for Firefox OS are positive: strong carrier and device support. But also, the openness of the architecture bodes well for the third leg of the stool: developer support. The history of technology suggests that being open and offering great value are common ingredients of success – just look at how Mozilla drove innovation in web browsing through Firefox.

And that’s why we’re bullish on the prospects for Firefox OS.

Follow Telefonica Digital on Twitter @tefdigital for more updates

FINSENY: Future Internet Technologies for the Smart Energy (II)

FINSENY Mission & Strategy:

The FINSENY Mission and Strategy, which define what the project plans are, and how they will be accomplished:

« Demonstrate, by 2015, how open Future Internet Technologies can enable the European energy system to combine adaptive intelligence with reliability and cost-efficiency to meet, sustainably, the demands of an increasingly complex and dynamic energy landscape. »

 FINSENY is specifying use cases, ICT requirements and architectures in the Smart Energy domain for five scenarios which have been identified as strongly benefiting from Future Internet technologies:

a)      Distribution Networks,
b)     
Microgrids,
c)     
Smart Buildings,
d)     
Electric Mobility and
e)     
Electronic Marketplace for Energy.

Distribution System (DS):

Problem Statements

  • The increasing amount of volatile DER generation in the Distribution System will change today’s well planned, standard load profile based operation to a dynamic demand response based approach based on actual status information from the medium down to the low voltage parts of the grid.
  • Energy flows are increasingly bidirectional, intensifying person safety and grid overload issues and demanding an increase of efficiency of energy distribution.
  • New smart energy applications are to be incorporated which handle the need for varying generation and demand levels to be balanced while optimally utilising grid resources.
  • Ubiquitous ICT solutions need to be defined, designed, financed, built, operated & maintained (see design principles in the above section).

Mission

  • “Design a future ICT solution for Distribution System automation & control to increase energy quality, reliability, robustness and safety and to ease integration of Distributed Energy Resources.”

Focus

  • Automated fault restoration, power analysis & control, grid maintenance.

Customers and Benefits

  • DSOs will get the solutions to optimally handle grid capacity and energy flows.
  • Service providers will get the interfaces to provide innovative energy services.
  • Prosumers can optimise their generation and consumption based on a stable distribution grid.

Key factors to judge the quality of the outputs

  • Reliability, safety, security and cost-efficiency of the solutions.

Key Features and Technologies

  • Decentralised operation, connectivity and control by scalable ICT solutions.

Outputs Critical Factors

  • Interoperability and integration (with legacy systems), scalability, allowing both centralised and de-centralised control, open & secure ICT solutions.

Microgrid:

Problem Statements

  • How to operate local low voltage or even mid-voltage distribution systems with Distributed Energy Resources (DERs) and storage devices to satisfy demand of energy consumers in an autonomous (islanding mode) or semi-autonomous (interconnected to the main grid) way.
  • How to build the Microgrid platform on Future Internet technologies to be more cost-efficient, flexible, secure, scalable, reliable, robust and modular.

Mission

  • “Design a reliable and cost-efficient Microgrid platform which ensures flexibility, scalability and robustness. The design will be modular and applications/services will be loosely coupled. Devices in or at the edge of the grid (e.g. DERs) will be easily integrated and control/communication networks will be managed to ensure the right level of QoS.”

Focus

  • Microgrid Control Centre and interface to the control and communication network to operate the system and integrate prosumers with e.g. DERs or Smart Buildings.
  • Configuration, monitoring & control, data management & processing.

Customers and Benefits

  • Microgrid operator has a flexible Microgrid platform to deploy in his environment.
  • Prosumers have an aggregation platform to include their DERs and flexible demand.

Key factors to judge the quality of the outputs

  • Internet of Things technologies for device & resource management, connectivity services at the interface to networks, data management and security.

Key Features and Technologies

  • Decentralised operation, connectivity and control by scalable ICT solutions.

Outputs Critical Factors

  • Regulatory hurdles, but already aligned with the governmental goals for an increased share of renewable energy and higher reliability by providing cost-efficiency.

Smart Buildings:

Problem Statements

Comprehensive building energy management:

  • With the combined goals of building-scale optimisation (local source-load-storage balancing and efficiency and grid-scale optimisation (demand-response)).
  • Under constraints of scalability, separation of concerns and auto-configuration.

Mission

  • “Design of future comprehensive Building Energy Management Systems as flexible edge of the Smart Energy system and as key element for shared Future Internet platforms.”

Focus

  • Make it possible to monitor and control all energy-relevant building subsystems, appliances and other physical entities operating on top of a shared platform, a building “operating system” provided to all building applications.
  • Managing all entities through common interfaces based on a generic model akin to that of a peripheral driver in a computer operating system.

Customers and Benefits

  • Building owners and stakeholders
  • Facilities managers and building services providers
  • Building end-users
  • All shall benefit from a horizontal building energy management system that interoperates fully with other building automation systems operating on top of the same shared building operating system.

Key factors to judge the quality of the outputs

  • Use smart building “operating system” providing interface to the buildings physical entities and common service layer to be shared by all building applications.

Key Features and Technologies

  • Provide information models and interfaces that encompass all energy-relevant legacy building hardware and equipment. Demonstrate corresponding monitoring and control interfaces for key types of such equipment.
  • Provide information models and interfaces that make it possible to interoperate with existing building ICT systems. Demonstrate corresponding monitoring and control interfaces for such systems.
  • Specify application layer that combines local and global energy optimisation.

Electric Vehicles:

Problem Statements

  • As the number of electric vehicles on our roads increases, the charging of electric vehicles will become a major load on the electricity grid and it’s management poses challenges to the energy system as well as offering a contribution to solutions to balancing the volatility of energy generation from renewable sources.
  • The provision of a seamless infrastructure for charging electric vehicles in Europe poses challenges to the transport, the energy and the payment infrastructure owners as well as well as to regulators. At the same time, electric vehicles, if connected wirelessly to the transport infrastructures, offer the potential to support multi-modal transport solutions.

Mission

  • “Design Smart Energy solutions so that electric vehicles will be an integrated part of the energy infrastructure, maximising their benefits to the energy infrastructure.”

Focus

  • Defining the role that electric vehicles can play in the Smart Energy infrastructure.

Customers and Benefits

  • Energy stakeholders are provided with scenarios for integrating electric vehicles into their plans for evolution towards Smart Energy solutions.
  • Energy stakeholders are given an overview of the ICT requirements and functional architecture issues from the perspective of electrical vehicle usage.
  • Users can charge in a user friendly way and can use electric vehicles as part of multi-modal transport solutions.
  • Energy stakeholders could possibly use the control of charging times for the vehicles to assist in energy grid management.

Key factors to judge the quality of the outputs

  • Defined ICT requirements and functional architecture enabling the integration of electric vehicles into the energy infrastructure.

Key Features and Technologies

  • Scalable solutions as number of vehicles grow, access to services wherever the user is via cloud computing and defined network interfaces. Wireless and fixed converged networks, infrastructure as a service.

Outputs Critical Factors

  • Open interfaces and secure ICT solutions are needed. The high speed of change in the market as the commercial side of electric vehicles develops is already evident creating timing issues for the introduction of common solutions. Regulatory issues will play a key role in this emerging market.

Electronic Market Place for Smart Energy:

Problem Statements

  • Those who are going to participate more actively in the energy supply, such as DSM customers, Prosumers, Microgrids, DERs, need a kind of electronic market place (for information and services). The services should be offered via the Future Internet. This electronic market place could in particular give information useful for balancing supply and demand and to check grid restrictions.

Mission

  • “Design ICT systems to extend web based energy information, demand shaping and energy trading services for the emerging energy market players.”

Focus

  • ICT systems to enhance contract negotiation, competitive price awareness and energy trading also at regional-level.

Customers and Benefits

  • Final Energy customers should be more aware and have a broader choice of Energy supply; energy trading at micro levels will be available for new prosumers, as well as better management of grid stability and planning for utilities.

Key factors to judge the quality of the outputs

  • Very flexible and secure web based energy services.

Key Features and Technologies

  • Large scale data gathering and management via web, Internet of Energy linked objects and customers-prosumers.

Outputs Critical Factors

  • Perceived marketplace trustworthiness from energy stakeholders will be fundamental together with the user engagement via the Internet in Smart Energy services promoted in FINSENY.

Conclusion:

FINSENY is a Future Internet (FI) project studying innovative new FI technologies to apply them to the Smart Energy landscape. The need for more ICT as described in this paper is widely agreed in the Smart Energy community to accomplish the challenges of the envisioned energy system. Future Internet technologies offer several opportunities for Smart Energy solutions, including connectivity, management, service enablement, distributed intelligence as well as security and privacy.

In the FINSENY project, key players from the ICT and energy sectors teamed-up to analyse the most relevant Smart Energy scenarios, identify prominent ICT requirements, develop reference architectures and prepare pan-European trials. As part of the FI-PPP, FINSENY will demonstrate over the three phases of the programme that Smart Energy needs can be fulfilled through an ecosystem of generic and Smart Energy specific ICT enablers running on top of an open Future Internet platform.

FINSENY will shape the European Future Internet ICT platform(s) to support the emerging European Smart Energy era. The growing Smart Grid Stakeholder Group will provide broad visibility of the on-going project work in the energy community, enhancing the acceptability of the project results and facilitating the development of the Smart Energy landscape.