Beyond Transmission Performance: 5G Opportunities for Developing e-Energy Applications

Beyond the expected improvement of key performance indexes (like bandwidth, delay, jitter), the advent of 5G networks is expected to bring radical changes in the way services are realized and managed in several key vertical sectors, including energy. In this paper, we elaborate on the opportunity for quicker service development and deployment for the smart grid.


INTRODUCTION
The transition of the traditional power system towards the smart grid has already started, and entails several phases. Today, focus has been given primary to wide-area connectivity and high performance, targeting bandwidth, latency, availability, density, and reliability levels in mobile networks similar to wired infrastructures [2,5]. Tomorrow, a large base of intelligent devices with processing and communication capability ("smart Things") will make possible re-engineering a broad range of applications for effective control and management of the grid, as well as new business services.
The big challenge for this evolutionary process will be seamless and effective integration of Things into applications and services, tackling the multiplicity of devices and their heterogeneity, while making the software flexible, portable, and adaptable to different environments (for instance, the same control application should be usable in different microgrids without requiring modifications, and with minimal configuration and installation efforts) [4]. IoT Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request  middleware and frameworks have already been largely investigated, including context-brokers, service-oriented architectures, and other paradigms for decoupling information and context from physical devices. This facilitates software development but not service deployment: in fact, there is still the need for manual configuration every time the service is used in a different contexts or just for life-cycle management (e.g., in case of failures).
Virtualization and orchestration are the buzzwords that are recently re-shaping the software industry, starting from cloud applications and already involving networks (i.e., network function virtualization -NFV). The next step will be the extension to the IoT, and the 5G initiative has already anticipated this trend by some visionary concepts at first [4] and resulted in more concrete architectural layers recently [1]. Indeed, service deployment time is already included among the 5G Key Performance Indicators, but most telecommunications vendors and operators have largely overlooked it till now.
In this paper, we elaborate on the great opportunity brought by the 5G architecture to radically change the way software applications are developed and deployed in the energy sector, with specific examples of their usage for developing control and management applications for the electrical grid.

THE 5G VISION: BEYOND PERFORMANCE
At first glance, fifth-generation mobile networks (5G) may just look a straight evolution bringing key performance indexes one step further than today, but there is indeed far more under the hood. 5G will largely build on recent advances in virtualization, targeting more flexibility and cost-effectiveness in network operation and management, as well as the effective implementation and maintenance of large applications for the vertical industries. The combination of edge computing, smart Things (IoT), and network function virtualization will create a pervasive computing continuum with associated low latency, reliability, and Quality of Service (QoS) features, suitable to run software functions wherever needed, while providing end-to-end control and data plane connectivity between software peer entities and physical devices/terminals (in technical slang indicated as network slicing), in order to achieve the target end-to-end service performance. This vision may be depicted as the stack of network-centric services (at the lowest layers) and vertical-centric services (at the topmost layers), as briefly described in Appendix A.
However, the effective implementation and maintenance of large applications will also seek more automation in software deployment and lifecycle management (i.e., orchestration). To this aim, a transition from "prescriptive" (i.e., procedural languages) to descriptive models is ongoing, both for cloud applications and network function virtualization [6]. Such models describe the application as a logical topology (service graph, see Fig. 1) of elementary microservices [3], where the links represent some kind of logical connection (e.g., client/server relationship, communication link, or other dependency).
Graphs also include deployment constraints and management policies. The orchestration process takes a descriptive service graph and, according to its policies and metadata, selects proper implementation for each microservice from available software repositories, provisions virtual resources from virtualization environments, deploys and configures the software, monitors software execution, and performs management actions.

INTEGRATING ELECTRICAL DEVICES INTO 5G
The creation of more powerful, autonomic, and elastic electrical applications for the Smart Grid leverages the 5G vision and the evolving software development paradigms. The fundamental step is the abstraction of electrical devices as business functions (see Fig. 3) that can be seamlessly integrated into business applications and deployed by orchestration tools over a mix of heterogeneous hardware. Things may be integrated in the 5G architecture by creating virtual instances. A virtual instance is a software abstraction of a real object that mediates between the hardware and the applications. It hides all low-level details of the device, and just exposes simple Application Programming Interfaces (APIs) for the logical functions the device offers (e.g., read measurements, write configuration parameters, move or rotate some mechanical parts). Different instances may be used to provide different services: for example, a simple implementation for a wind turbine may give read-only access to operational parameters (like rotation speed, energy generation, frequency and voltage measurement), while another implementation may give raw access to IEC 61850 or similar protocols. Clearly, binding virtual instances with specific physical devices is not trivial, but this task will be managed by the 5G architecture (virtualization and business functions layers) through registration and discovery functions similar to those already used for cloud installations.
By wrapping virtual instances with specific metadata and service hooks, we get an orchestrable microservice that can be linked to other software components. The implementation of a virtual instance might also include some processing logic, so to reduce communication latency and network overhead when deployed close to the real hardware (i.e., with fog computing installations). Figure 2: A simple example of control application for the smart grid. Fig. 2 depicts a very simple example. We define specific interfaces for a renewable generator and electrical switchgear. The interfaces are pictorially represented by the shaped connectors between the blocks (ellipse and square shape, respectively). The API for wind turbine provides access to operational parameters (like rotation speed, voltage, current, frequency) and reports failures, errors, and other logs. The API for the virtual switchgear reports current position and allows to change the position (open/closed). The developer of the control logic for the wind turbine uses simple function calls, just like the two devices were an internal routine, without the need for more complex network APIs (e.g., RESTful XML or JSON protocols) or direct use of TCP/UDP sockets. The interface between the turbine control and the web server is again a simple function call, which returns an HTML or XML formatted page that will be transferred to the client by the web microservice. Even if we cannot go into more technical details for the sake of brevity, we again remark that most of time-consuming configuration issues can be triggered and carried out by orchestration engines, while the developer focuses on the application topology and the selection of the field components that must be used.

Interface to other control and management microservices
Developing the above service would be as simple as dragging and dropping the microservices on the dashboad, drawing links among them, and set deployment requirements and policies. With the proper constraints on latency, the 5G orchestrator will take care of finding the right set of physical devices, selecting proper microservices implementations, and deploying low-latency tasks at the edge cloud closest to physical devices, while a dedicated network slice will be instantiated for communication. If we need the same system to control another turbine at another location, we can just copy the service graph and edit its properties, by selecting different physical devices. The whole process would require just a few minutes, to draw the graph and set the properties, while a conventional approach would require days or weeks to properly configure the hardware appliances and the electrical wiring.

CONCLUSIONS
The vision behind 5G boosts the creation of novel applications and services, leveraging pervasive connectivity, virtualization, and orchestration technologies. Key step in this evolution is the logical abstraction of physical devices, enabling the composition and automatic management of orchestratable applications.
We are already moving in this direction, by developing software instances for electrical devices, which will be integrated and evaluated in real-field experimental testbeds, bridging Smart Grid and 5G.

A 5G CONCEPTUAL ARCHITECTURE
The overall 5G architecture may be viewed as the stack of networkcentric services (at the lowest layers) and vertical-centric services (at the topmost layers) [1], as depicted in Fig. 3.
The infrastructure layer collects all physical resources, including switching/routing devices and communication links, massive computing and storage resources, smart things (sensors, actuators, gateways, smartphones, drones, robots, cars, etc.). It represents a rich ICT fabric, where things, computing, storage, and networking resources are interconnected by a broad range of access and transport technologies.
Resources at the infrastructure layer are then abstracted and exposed to upper layers in the virtualization layer. Here, virtual resources are dynamically provisioned as of virtual machines, block and object storage (POP, Cloud), software-defined connectivity (WAN), logical IoT functions (T). This layer maps virtual instances to physical resources, hiding low-level management details to upper layers. Some effort has already been undertaken to abstract, model, and "program" things (e.g., ThingML).
The network function layer implements network services as combination of virtual functions. The core elements of this layer entail the repository of network virtual functions (firewall, encryption, Network Address Translation, load balancer, Radio Access Network, Deep Packet Inspection, Enhanced Packet Core, etc.), and the management mechanisms that provision virtual resources from the underlying layer, deploy the service, and orchestrate it during its life-cycle. There are several complementary frameworks that cope most of the technical aspects mentioned above: ETSI Network Function Virtualization, ETSI Mobile Edge Computing, IEEE Service Function Chaining, not to mention the plethora of research and industrial initiatives.
The multi-service control layer enables the creation, operation, and control of multiple separated communication networks, by 'slicing' the physical infrastructure. This will provide a dedicated network and all management functions to the service tenant, functionally indistinguishable by a real network, which interconnects things, computing and storage resources. This layer maps business requirements into network topology and configuration, by reserving physical resources and composing network services through the underlying network function layer. Key aspects of this layer are strict isolation among different tenant and enforcement of QoS according to contractual service level agreement.
The business function layer collects software functions for the vertical industries. They include electrical applications as well as virtual instances of things, enabling the composition of management and control services (e.g., collecting meter readings and phasor measurements, opening or closing circuit breakers, load and production forecast, failure and short-circuit detection). Such functions are then mapped to computing resources and things by the multi-service control layer, according to specific placement and QoS requirements in terms of latency, throughput, jitter, availability, security, etc.
Finally, the business service layer describes value chains by composing generic and specific service functions for each industry (e.g., load shedding, demand-response schemes). The description combines different activities, as logical sequences or conditional alternatives, while setting execution constraints for the underlying   layers (e.g., accuracy, due dates, service levels, security and safety requirements). The whole set of requirements will impact both the selection of specific function implementation (business function layer) as well as the topology and configuration of the network slice (multi-service control layer).