Communication requirements and use of Information-centric Networking (ICN) approach for synchrophasors streaming

Introduction

Information-centric networking (ICN) is a new networking approach that aims to solve some fundamental issues of the current host-centric Internet infrastructure. The rationale behind ICN is that information consumers are mainly interested in the information itself rather than the explicit network location of the data/content source (e.g., the host IP address). The primary concerns of the network will no longer relate to the reachability of specific hosts but more on the efficient information dissemination and retrieval.  The ICN design focuses on information/data where information is published, resolved, delivered and stored natively based on names rather than on explicit host locations.

Contribution to the CIGRE WG C4.34

ICN example for synchrophasor data streaming: C-DAX

C-DAX[1] is an ICN-based middleware platform with a topic-based publish-subscribe engine that decouples data producers and consumers in time and space. PMUs as publishers and PDCs as subscribers, are clients to the C-DAX platform. In C-DAX, a topic represents a group based communication session for data distribution, e.g., a topic used by PMUs to publish their measurements towards interested PDC(s) in RTSE operations. The platform enables scalable and flexible (re)configuration of PMU data communication to maintain seamless full observability of power condition in complex and dynamic situations. Besides providing inherent security protection by obscuring target hosts, the decoupling of the communicating end hosts massively simplifies the configuration complexity of multipoint-to-multipoint communications in a decentralized manner. It eliminates the need to establish and maintain multiple and distinct point-to-point communication connections, thus achieving better system scalability in PMU-based RTSE communications. Emulating the function of multicast [17], C-DAX enables the forming of topic groups, for the replication of PMU data to all interested subscribers, saving the need for repeated unicast transmissions per subscriber. This is especially beneficial for the support of flexible topologies in ADNs. Fig. 2 shows the C-DAX architecture for supporting a PMU-based RTSE application.

C-DAX consists of a control and a data plane:

• Data Plane: supports the forwarding of PMU streaming data according to end-to-end QoS requirements. PMUs stream real-time measurement data under a given topic to a rendezvous point known as Data Broker (DB) connecting the publishers and the subscribers of this topic. C-DAX supports the C37.118 standard by providing a protocol adapter i.e., a thin C-DAX publisher client interfaces with a C37.118 compatible PMU device / or can be even installed on it, taking over the communication with the rest of the C-DAX entities, transparently to the PMU device. The DB forwards the data to PDC(s) (as legitimate subscribers of the topic). A corresponding protocol adapter is also supported by C-DAX on the PDC side providing support for the seamless emulation of a C37.118 compatible communication session on the application layer. In this communication environment, instead of explicitly handling pairs of communication endpoints, PMU data streams are manipulated based on a logical C-DAX topic rooted at a common DB. For scalability and resilience, especially in larger grids, multiple co-existing DBs can be simultaneously deployed for PMU streaming under a common topic. In this case, PMUs close to each other can publish to a nearby DB, and also upon the failure of one DB, an alternative DB can take over its role for seamless failure recovery. Finally, the use of DB enables the semantic grouping of PMUs in terms of management and configuration (e.g., PMUs in a certain feeder or part of a grid may need to be configured collectively with the same operating parameters). In this case, the DB may have extra functions in the data plane such as caching of PMU data for further usage and also data filtering or rate adaptation of data streams towards subscribers with heterogeneous data set or rate requirements.
• Control Plane: it is responsible for handling topic-based communication sessions. To join a topic, a publisher or subscriber client (either the PMU or the PDC protocol adapter) requires the knowledge of the responsible DB for that topic. This is handled by the topic resolver (RS) in the control plane which is responsible for mapping a topic name to the corresponding DB. Since there can be potentially a large number of clients in the grid, the notion of designated node (DN) is also introduced for the aggregation of topic join requests sent towards the RS. In this case, all the topic join request events originated from clients sharing a common DN are handled by that DN, such that the control signaling overhead can be potentially reduced. Taking a proxy role, each DN is also responsible for performing local authentications on publishers/subscribers in the grid for security purposes. Such an operation requires a dedicated security server (SecServ)[2] in the control plane to carry out the access control and client authentication operations upon the joining of new client reported by a DN.

As can be seen, the management of the PMU-based RTSE communication (including initial configuration and run-time reconfiguration) is completely based on the logical topic rather than the manipulation of explicit point-to-point communication points. Such a scheme offers increased scalability and flexibility in handling power grid topology dynamicity during normal operations.

[1] C-DAX stands for Cyber-secure DAta and Control Cloud for future power distribution networks. http://www.cdax.eu

[2] For scalability and resilience, multiple security servers may be deployed (possibly organized in a hierarchical manner).