Technical Field

[0001] The present disclosure relates to synchrophasor networks, and more particularly to a non-intrusive method for online quality of experience assessment in wireless synchrophasor networks.

Background

[0002] As power distribution grids are shifting towards smart and complex systems, advanced metering and sensor technologies are being developed for data acquisition and grid intelligence purposes. In particular, fast and accurate measurements provided by synchrophasor technology can significantly improve monitoring, control and protection applications in smart grids. Phasor measurement units (PMUs), phasor data concentrators (PDCs) and communication systems are the main components of synchrophasor networks. PMUs generate synchrophasor packets that carry the measured phasors, frequency, rate of change of frequency, real/reactive powers, and the unique time-stamps. Communication systems deliver the synchrophasor packets to the PDCs which collect, and time align the data provided by geographically distributed PMUs. Communication systems directly affect data integrity and therefore play a crucial role in the performance of synchrophasor networks.

[0003] Power utilities may adopt wireless communications to facilitate transfer of synchrophasor packet. In some distribution grids, wireless communications is the only feasible solution where Ethernet is not available. However, wireless systems may lead to unforeseen access failures and time-varying access delays. The access delays are essentially stochastic and may impact PMU channels during different time intervals. The extent and duration of the access failure/delay should be minimized to meet the requirements of time-critical control and protection applications in smart grids. Access failures and access delays adversely intervene in the data collection mechanism at the PDC. Under such circumstances, incomplete datasets characterized by not-a-number (NaN) indicators appear at the PDC output. Incomplete datasets that bear multiple NaN indicators severely deteriorate the performance of control and protection applications. Smart grids may alleviate this problem and improve data integrity by using elaborate data recovery methods. The data recovery methods require remarkable computations and archiving to replace the NaN indicators by estimates of the actual measurements. Moreover, the accuracy of the recovered data degrades with increasing number of NaN indicators. Hence, data recovery methods still require reliable communication links to deliver high-quality synchrophasor datasets to the applications.

[0004] The communication aspects of synchrophasor networks have been addressed by several papers. See, for example: K. V. Katsaros, et al., “Low latency communication infrastructure for synchrophasor applications in distribution networks.” in Proc. Int. Conf. on Smart Grid Communications, Nov. 2014; S. Das, and T. S.

Sidhu, “Application of compressive sampling in synchrophasor data communication in

WAMS.” IEEE Trans. Ind. Inf., vol. 10, no. 1 , pp. 450-460, Feb. 2014.; P. Castello, et al., “Adaptive management of synchrophasor latency for an active phasor data concentrator.” in Proc. Int. Instrumentation and Measurement Technol. Conf., May 2017; and X. Zhu, et al.. “Optimal PMU-communication link placement for smart grid wide-area measurement systems,” IEEE Trans. Smart Grid, Early Access, DOI:

10.1109/TSG.2018.2860622.

[0005] Katsaros, et al propose a hybrid infrastructure based on power-line and wireless communications to constrain the packet delays while maintaining the bandwidth at low levels.

[0006] In Application of compressive sampling in synchrophasor data communication in WAMS. Das and Sidhu show that synchrophasor networks can benefit from compressive sampling technique to minimize delays and reduce the communication bandwidth.

[0007] Castello et al. propose a method that evaluates the delay statistics in individual PMU links. Their adaptive method dynamically changes waiting time and data aggregation at the PDC to meet the application requirements.

[0008] The impact of communication constraints on optimal PMU placement is studied in Optimal PMU-communication link placement for smart grid wide-area measurement systems. In this paper, Zhu, et al. present an optimization procedure that accounts for data rate and routing to achieve fully observable power grids.

[0009] Limitations of prior art methods include:

• They do not provide a systematic method for online QoE assessment in wireless synchrophasor networks.

• They require offline computer simulations and prior knowledge of the PMU or PDC parameters to deal with the communication constraints. In many practical scenarios, however, the communication operators do not have access to the power utility premises, and prior knowledge of the PMU/PDC parameters is not available.

• They impose extra computations on the power utility devices.

• They cannot be employed for improvement of the synchrophasor packet communications in real-time.

• Algorithms often need to be modified or updated whenever the communication system topology changes.

Summary

[0010] An objective of the present disclosure is to provide techniques that overcome at least some of the above-noted limitations of the prior art.

[0011] Thus, the present disclosure provides techniques for real-time QoE assessment and improvement of synchrophasor packet communications which can be applied to any wireless synchrophasor network with arbitrary topology/parameters. The QoE may be evaluated in terms of Not a Number (NaN) sequences (NaNS) in the form of a series of missing packets over successive time-stamps at the PDC output. Non- intrusive parameter estimation, online probabilistic prediction, and prioritized handover are principal steps involved in the disclosed techniques. Parameter estimation deals with extracting the reporting rate of PMUs and the delay thresholds by analyzing the time of arrival (TOA) and time of departure (TOD) of synchrophasor packets. An advantage of this non-intrusive method is that it does not require prior knowledge of the PMU/PDC parameters. The extracted parameters are used by the online prediction algorithms that evaluate the emergence of NaNS under absolute and relative waiting time strategies. Early prediction of NaNS allows the network operator to carry out prioritized handover for unreliable PMU channels and improve the QoE in a timely manner.

[0012] Accordingly, an aspect of the present invention provides a method in a network node of a wireless communication system. The method comprises: receiving a synchrophasor packet from a Phasor Measurement Unit, PMU, the synchrophasor packet including a timestamp indicative of when the synchrophasor packet was generated; determining an uplink time of arrival, TOA, indicative of a time that the synchrophasor packet was received by the network node; and forwarding, to a remote node in the wireless communication system, at least one of the received synchrophasor packet and uplink packet data including any one or more of: the timestamp, the determined uplink TOA, and either a copy of the received synchrophasor packet or an uplink hash code generated using the received synchrophasor packet.

[0013] In some embodiments the forwarding step comprises forwarding, to the remote node, both of the received synchrophasor packet and the uplink packet data.

[0014] In some embodiments the forwarding step comprises: forwarding, to the remote node, only the received synchrophasor packet; and forwarding, to a management node, MN, in the wireless communication network, the uplink packet data, the MN being different than the remote node.

[0015] A further aspect of the present invention provides a network node of a wireless communication system. The network node comprises processing circuitry configured to: receive a synchrophasor packet from a Phasor Measurement Unit, PMU, the synchrophasor packet including a timestamp indicative of when the synchrophasor packet was generated; determine an uplink time of arrival, TOA, indicative of a time that the synchrophasor packet was received by the network node; and forward, to a remote node in the wireless communication system, at least one of the received synchrophasor packet and uplink packet data including any one or more of: the timestamp, the determined uplink TOA, and either a copy of the received synchrophasor packet or an uplink hash code generated using the received synchrophasor packet. [0016] A still further aspect of the present invention provides a method in a network node of a wireless communication system. The method comprises: receiving a synchrophasor packet from a remote network node; determining a downlink time or arrival, TOA, indicative of a time that the synchrophasor packet was received by the network node; forwarding the synchrophasor packet to a phasor data concentrator, PDC; determining a downlink time of departure, TOD, indicative of a time that the synchrophasor packet was transmitted to the PDC; and transmitting, to a management node, MN, at least downlink packet data including the determined downlink TOA, the determined downlink TOD, and either a copy of the synchrophasor packet or a downlink hash code generated using the synchrophasor packet.

[0017] In some embodiments, receiving a synchrophasor packet from the remote network node further comprises receiving uplink packet data from the remote network node, and wherein the transmitting step further comprises transmitting the received uplink packet data to the MN.

[0018] A yet further aspect of the present invention provides a network node of a wireless communication system. The network node comprises processing circuitry configured to: receive a synchrophasor packet from a remote network node; determine a downlink time or arrival, TOA, indicative of a time that the synchrophasor packet was received by the network node; forward the synchrophasor packet to a phasor data concentrator, PDC; determine a downlink time of departure, TOD, indicative of a time that the synchrophasor packet was transmitted to the PDC; and transmit, to a management node, MN, at least downlink packet data including the determined downlink TOA, the determined downlink TOD, and either a copy of the synchrophasor packet or a downlink hash code generated using the synchrophasor packet.

[0019] A further aspect of the present invention provides a method in a network node of a wireless communication system. The method comprises: receiving, for each synchrophasor packet in a stream of synchrophasor packets, respective uplink packet data including any one or more of: a timestamp indicative of a time that the synchrophasor packet was generated; an uplink Time of Arrival, TOA, indicative of a time that the synchrophasor packet was received by an uplink node; and either a copy of the synchrophasor packet or an uplink hash code generated by the uplink node using the synchrophasor packet. The further comprises: receiving, for each synchrophasor packet in the stream of synchrophasor packets, respective downlink packet data including any one or more of: a downlink TOA indicative of a time that the synchrophasor packet was received by a downlink node, a downlink Time of Departure (TOD) indicative of a time that the synchrophasor packet was forwarded to a phasor data concentrator, PDC; and either a copy of the synchrophasor packet or a downlink hash code generated by the downlink node using the synchrophasor packet. The method further comprises: predicting whether or not a Not a Number Sequence (NaNS) in the stream of synchrophasor packets is likely, based at least in part on the received uplink and downlink packet data; and triggering a prioritized handover of a Phasor Measurement Unit (PMU) associated with the stream of synchrophasor packets when a NaNS in the stream of synchrophasor packets is predicted to be likely.

[0020] In some embodiments, predicting whether or not a NaNS in the stream of synchrophasor packets is likely comprises: calculating respective values of one or more parameters based on the received uplink and downlink packet data; and predicting whether or not a NaNS in the stream of synchrophasor packets is likely, based at least in part on the derived parameter values.

[0021] In some embodiments, calculating respective values of one or more parameters comprises: filtering the uplink and downlink packet data based at least in part on the respective uplink TOA and downlink TOA of each synchrophasor packet, to exclude uplink and downlink packet data associated with synchrophasor packets having a delay that exceeds a predetermined threshold; and calculating the respective values of the one or more parameters based at least in part on the filtered uplink and downlink packet data.

[0022] In some embodiments, the stream of synchrophasor packets comprises a respective stream of synchrophasor packets for each one of at least two PMUs, and wherein deriving respective values of one or more parameters further comprises: aligning the uplink and downlink packet data associated with each stream of synchrophasor packets, based at least in part on the respective timestamp of each synchrophasor packet of each stream; filtering the uplink and downlink packet data associated with each stream of synchrophasor packets based at least in part on the respective uplink TOA and downlink TOA of each synchrophasor packet, to exclude uplink and downlink packet data associated with synchrophasor packets having a delay that exceeds a predetermined threshold; and calculating the respective values of the one or more parameters for each stream of synchrophasor packets, based at least in part on the respective filtered uplink and downlink packet data.

[0023] In some embodiments, the one or more parameters comprise a delay threshold and a PMU reporting rate.

[0024] In some embodiments, the network node is a management node (MN) in a core network.

[0025] In some embodiments, receiving respective uplink and downlink packet data for each synchrophasor packet comprises receiving the uplink and downlink packet data from the downlink node.

[0026] In some embodiments, receiving respective uplink and downlink packet data for each synchrophasor packet comprises: receiving the uplink packet data for each synchrophasor packet from the uplink node; and receiving the downlink packet data for each synchrophasor packet from the downlink node.

[0027] In some embodiments, predicting whether or not a Not a Number sequence (NaNS) in the received stream of synchrophasor packets is likely, comprises calculating a likelihood of a Not a Number (NaN) indication in a number of consecutive timestamps of the stream of synchrophasor packets, the number being equal to or greater than a predetermined minimum.

[0028] In some embodiments, triggering a prioritized handover comprises: identifying a new uplink node capable of serving the PMU; and causing handover of the PMU to the new uplink node.

[0029] A yet further aspect of the present invention provides a network node of a wireless communication system. The network node comprising processing circuitry configured to: receive, for each synchrophasor packet in a stream of synchrophasor packets, respective uplink packet data including any one or more of: a timestamp indicative of a time that the synchrophasor packet was generated; an uplink TOA indicative of a time that the synchrophasor packet was received by an uplink node; and either a copy of the synchrophasor packet or an uplink hash code generated by the uplink node using the synchrophasor packet. The processing circuitry is further configured to receive, for each synchrophasor packet in the stream of synchrophasor packets, respective downlink packet data including any one or more of: a downlink TOA indicative of a time that the synchrophasor packet was received by a downlink node, a downlink Time of Departure (TOD) indicative of a time that the synchrophasor packet was forwarded to a phasor data concentrator, PDC; and either a copy of the synchrophasor packet or a downlink hash code generated by the downlink node using the synchrophasor packet. The processing circuitry is further configured to: predict whether or not a Not a Number Sequence (NaNS) in the stream of synchrophasor packets is likely, based at least in part on the received uplink and downlink packet data; and trigger a prioritized handover of a Phasor Measurement Unit (PMU) associated with the stream of synchrophasor packets when a NaNS in the stream of synchrophasor packets is predicted to be likely.

[0030] The QoE assessment in accordance with embodiments of the present disclosure may have one or more of the following advantages:

• embodiments may be non-intrusive in the sense that the communication service providers do not need to deploy probes in the power utility network, and prior knowledge of the PMU and PDC configuration parameters is not required.

• embodiments can be implemented in real-world communications infrastructure.

• embodiments empower wireless service providers to carry out online remedial actions, such as prioritized handover, when the QoE is poor for one or more PMUs.

• embodiments may be capable of detecting latent poor QoE conditions that are not detectable by the existing methods. Such latent QoE conditions may occur when the access delay for some PMUs gradually increases over time, for example.

[0031] Embodiments of a base station, communication system, and a method in a communication system are also disclosed. Brief Description of the Drawings

[0032] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain principles of the disclosure. [0033] Figure 1 is a block diagram schematically illustrating a representative network in which embodiments of the present invention may be deployed;

[0034] Figures 2A and 2B are block diagrams schematically illustrating examples of a computing device usable in embodiments of the present invention;

[0035] Figure 3 is a block diagram schematically illustrating an architecture of a representative network element virtualization usable in embodiments of the present invention;

[0036] Figure 4 is a block diagram schematically illustrating a representative synchrophasor network;

[0037] Figures 5A and 5B illustrate example datasets generated by a PDC; [0038] Figure 6 is a flowchart illustrating principle steps of a process in accordance with representative embodiments of the present invention;

[0039] Figure 7 is a flowchart illustrating an example process usable in the process of Figure 6;

[0040] Figure 8 is a flowchart illustrating an example process usable in the process of Figure 6;

[0041] Figure 9 is a flowchart illustrating an example process usable in the process of Figure 6;

[0042] Figures 10A-10D illustrate example algorithms usable in the process of Figure 6; [0043] Figure 11 shows a table of example parameter values;

[0044] Figure 12 is a chart showing average prediction time vs. minimum NaNS length in a simulation using the example parameter values of Figure 11 ; [0045] Figure 13 shows a pair of charts showing lost synchrophasor packets in a simulation using the example parameter values of Figure 11 , both with and without methods in accordance with representative embodiments of the present invention; and

[0046] Figure 14 shows a second pair of charts showing lost synchrophasor packets in a simulation using the example parameter values of Figure 11 , both with and without methods in accordance with representative embodiments of the present invention.

Detailed Description

[0047] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0048] At least some of the following abbreviations and terms may be used in this disclosure.

• 2D Two Dimensional

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• AAS Antenna Array System

• AoA Angle of Arrival

• AoD Angle of Departure

• ASIC Application Specific Integrated Circuit

• BF Beamforming

• BLER Block Error Rate

• BW Beamwidth

• CPU Central Processing Unit

• CSI Channel State Information

• dB Decibel • DCI Downlink Control Information

• DFT Discrete Fourier Transform

• DSP Digital Signal Processor

• eNB Enhanced or Evolved Node B

• FIR Finite Impulse Response

• FPGA Field Programmable Gate Array . gNB New Radio Base Station

• ICC Information Carrying Capacity

• IIR Infinite Impulse Response

• LTE Long Term Evolution

• MIMO Multiple Input Multiple Output

• MME Mobility Management Entity

• MMSE Minimum Mean Square Error

• MTC Machine Type Communication

• NR New Radio

• OTT Over-the-Top

• PBCH Physical Broadcast Channel

• PDCCH Physical Downlink Control Channel

• PDSCH Physical Downlink Shared Channel

• P-GW Packet Data Network Gateway

• RAM Random Access Memory

• ROM Read Only Memory

• RRC Radio Resource Control

• RRH Remote Radio Head

• SCEF Service Capability Exposure Function

• SINR Signal to Interference plus Noise Ratio

• TBS Transmission Block Size

• UE User Equipment

• ULA Uniform Linear Array

• URA Uniform Rectangular Array

• PMU Phasor measurement unit

• PDC Phasor data concentrator • NaN Not-a-Number

• NaNS Not-a-Number sequence

• UTC Coordinated universal time

• UN Uplink node

• DN Downlink node

• CDF Cumulative distribution function

• TOA Time of arrival

• TOD Time of departure

• LOP Local outlier probability

• IP Internet protocol

• TCP Transmission control protocol

• UDP User datagram protocol

• FPS Frame-per-second

• LTE Long-Term Evolution

• EPC Evolved packet core

• QoE Quality of experience

[0049] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device.

[0050] Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0051] Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like. [0052] Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e. , is served by) a cellular communications network by wirelessly transmitting (and/or receiving) signals to (and/or from) a radio access node. Some examples of a wireless device include, but are not limited to, a User Equipment (UE) device in a 3GPP network; a Machine Type Communication (MTC) device; a phasor measurement unit (PMU); and a phasor data concentrator (PDC).

[0053] Network Node: As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.

[0054] Cell: As used herein, a “cell” is a combination of radio resources (such as, for example, antenna port allocation, time and frequency) that a wireless device may use to exchange radio signals with a radio access node, which may be referred to as a host node or a serving node of the cell. However, it is important to note that beams may be used instead of cells, particularly with respect to 5G NR. As such, it should be appreciated that the techniques described herein are equally applicable to both cells and beams.

[0055] Note that references in this disclosure to various technical standards (such as 3GPP TS 38.211 V15.1.0 (2018-03) and 3GPP TS 38.214 V15.1.0 (2018-03), for example) should be understood to refer to the specific version(s) of such standard(s) that is(were) current at the time the present application was filed, and may also refer to applicable counterparts and successors of such versions.

[0056] The description herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0057] Figure 1 illustrates one example of a cellular communications network 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications network 100 is a Public Land Mobility Network (PLMN) conforming to one or more of the LTE, 3G, 4G and 5G NR standards, or their successors. In the illustrated example, the cellular communications network 100 includes a (Radio) Access Network (RAN) 102 comprising base stations 104-1 and 104-2 controlling radio communications with wireless devices 106-1 , 106-2, 106-3, 106-4,106-5 within corresponding macro cells 108-1 and 108-2. Each macro cell 108 may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT) and modulation scheme.

[0058] Base stations 104 can be any type of network access device capable of establishing radio connection(s) with one or more wireless devices 106 within a respective coverage area of the base station 104 or low power node 112, and further configured to forward subscriber traffic between the core network 114 and the one or more wireless devices 106. An important feature of a base station 104 is that it is configured with both a radio interface configured to send and receive radio signals to and from a wireless device 106, and a network interface configured to exchange electronic and/or optical signals with the core network 114. Examples of base stations 104 and low power nodes 112 include: Evolved Node B (eNB) systems (known, for example, in the 3GPP standards): WiFi access points (known, for example from IEEE 802.11 standards) or the like. In some contexts, a base station 104 may be referred to as an access point (AP) regardless of the Radio Access Technology (RAT) that it supports.

[0059] The illustrated RAN 102 also includes small cells 110-1 through 110-4, within which radio communication can be controlled by corresponding low power nodes 112-1 through 112-4. As with the macro cells 108, each small cell may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT) and modulation scheme. As with the base stations 104, a low power node 112 can be any type of network access device capable of establishing radio connection(s) with one or more wireless devices 106 within a respective coverage area of the low power node 112, and further configured to forward subscriber traffic between the core network 114 and the one or more wireless devices 106. An important feature of a low power node 112 is that it is configured with both a radio interface configured to send and receive radio signals to and from a wireless device 106, and a network interface configured to exchange electronic and/or optical signals with the core network 114. In some embodiments, a low power node 112 may be connected to the core network 114 by a direct connection, such as an optical cable. In other embodiments, a low power node 112 may be connected to the core network 114 by an indirect connection, such as via a radio or optical fiber link to a base station 104. Examples of low power nodes 112 include: Remote Radio Heads (RRHs) connected to a base station or a network router (not shown): WiFi access points or the like. In some contexts, a low power node 112 may be referred to as an access point (AP) regardless of the specific Radio Access Technology (RAT) that it supports.

[0060] Notably, while not illustrated, a particular small cell 110 may alternatively be controlled by a base station 104, for example using a beam-forming technique. In such cases, the particular small cell 110 will not be associated with a respective low power node 112 per se. Rather, the particular small cell 110 will be associated with a respective set of parameters implemented in the base station 104. In this disclosure, the term “cell” is used to refer to a defined combination of parameters (such as geography, frequency, Radio Access Technology (RAT), modulation scheme, identifiers and the like) that can be used by a wireless device 106 to access communication services of the network 100. The term “cell” does not imply any particular parameter values, or any particular physical configuration of devices needed to enable a wireless device 106 to access those communication services.

[0061] Wireless devices 106 can be any type of device capable of sending and receiving radio signals to and from a base station 104 and/or low power node 112. Examples of wireless device 106 include cellular phones, Personal Data Assistants (PDAs), mobile computers, Internet of Things (loT) devices, autonomous vehicle controllers, and the like. In some contexts, a wireless device 106 may be referred to as a User Equipment (UE) or a mobile device. In the context of synchrophasor networks, a wireless device 106 may be implemented as a phasor measurement unit (PMU) and/or as a phasor data concentrator (PDC).

[0062] In some embodiments, the macro cells 108-1 and 108-2 may overlap each other, and may also overlap one or more small cells 110. For example, a particular macro cell 108-1 may be one macro cell 108 among a plurality of macro cells covering a common geographical region and having a common RAT and modulation scheme, but using respective different frequencies and/or AP identifiers. In such cases, a wireless device 106 located within a region covered by two or more overlapping cells 108, 112 may send and receive radio signals to and from each of the corresponding base stations 104 and/or low power nodes 112. [0063] In the illustrated example, the RAN 102 is connected to a Core Network (CN) 114, which may also be referred to as Evolved Core Network (ECN) or Evolved Packet Core (EPC). The CN 114 includes (or, equivalently, is connected to) one or more servers 116 configured to provide networking services such as, for example, Network Functions (NFs) described in 3GPP TS 23.501 V15.2.0 (2018-06) “System Architecture for the 5G System” and its successors. The CN 114 also includes one or more gateway (GW) nodes 118 configured to connect the CN 114 to a packet data network (DN) 120 such as, for example, the internet. A gateway node 118 may be referred to as a packet gateway (PGW) and/or a serving gateway (SGW). The DN 120 may provide communications services to support end-to-end communications between wireless devices 106 and one or more application servers (ASs) 122 configured to exchange synchrophasor packet flows with the wireless devices 106 via the CN 114 and RAN 102. In some contexts, an application server (AS) 122 may also be referred to as a host server.

[0064] In some contexts, an end-to-end signal path between an AS 122 and one or more wireless devices 106 may be referred to as an Over-The-Top (OTT) connection. Similarly, a communication service that employs signal transmission between an AS 122 and one or more wireless devices 106 may be referred to as an OTT service.

[0065] It should be appreciated that the separation between the CN 114 and the DN 120 can be purely logical, in order to simplify understanding of their respective roles. In particular, the CN 114 is primarily focused on providing wireless device access services and supporting wireless device mobility. On the other hand, the DN 120 is primarily focused on providing end-to-end communications, particularly across network domains. However, it will be appreciated that both the CN 114 and the DN 120 can be implemented on common physical network infrastructure, if desired.

[0066] Figures 2A and 2B is a block diagram schematically illustrating a communications system 200 including a computing device 202 usable in embodiments of the present invention. In various embodiments, any or all of the base stations 104 or 112, wireless devices 106, core network servers 116 or gateways 118 and data network servers 122 may be implemented using systems and principles in accordance with the computing device 202. It may also be appreciated that any or all of the elements of the network 100 may be virtualized using techniques known in the art or developed in the future, in which case the functions of any or all the base stations 104 or 112, core network servers 116 or gateways 118, and/or any or all network functions of the DN 120 or CN 114 may be implemented by suitable software executing within a computing device 202 or within a data center (non shown) composed of multiple computing devices 202.

[0067] In the example of Figure 2A, the communications system 200 generally includes computing device 202 connected to one or more networks 210 and one or more radio units 212. The computing device 202 includes processing circuitry such as one or more processors 204, a memory 206, and one or more network interfaces 208. The processors 204 may be provided as any suitable combination of Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or the like. Similarly, the memory 206 may be provided as any suitable combination of Random Access Memory (RAM), Read Only Memory (ROM) and mass storage technologies such as magnetic or optical disc storage or the like. The network interfaces 208 enable signaling between the computing device 200 and the networks 210, such as the Core Network 114, the data network 120, or a private domain network such as a data center (not shown).

[0068] Each radio unit 212 typically includes at least one transmitter (Tx) 214 and at least one receiver (Rx) 216 coupled to one or more antennas 218. In the example of Figure 2A, the radio unit(s) 212 is(are) shown as being external to the computing device 202 and connected to the computing device 202 via a suitable physical connection (such as a copper cable or an optical cable). In the example of Figure 2B, the radio unit(s) 212 is(are) shown as being connected to computing device 202 via a network 210 and a network interface 208. In still other embodiments, the radio unit(s) 212 and optionally also the antenna(s) 218 may be integrated togetherwith the computing device 202.

[0069] The one or more processors 204 operate to provide functions of the computing device 202. Typically, these function(s) are implemented as software applications (APPs) 220 or modules that are stored in the memory 206, for example, and executed by the one or more processors 204. In some embodiments, one or more software applications or modules 220 may execute within a secure run-time environment (RTE) 222 maintained by an operating system (not shown) of the computing device 202.

[0070] It may be appreciated that specific embodiments may exclude one or more of the elements illustrated in Figures 2A and 2B. For example, a computing device 202 configured to implement a wireless device 106 may incorporate one or more processors 204, a memory 206, and one or more radio units 212, but may exclude a network interface 208. Conversely, a computing device 202 configured to implement a server 116 or 122 may include one or more processors 204, a memory 206, and one or more network interfaces 208, but may exclude radio units 212. A computing device 202 configured to implement a base station 104 or 112, on the other hand, will normally include one or more processors 204, a memory 206, and both radio units 212 and network interfaces 208.

[0071] Figure 3 is a block diagram schematically illustrating an example architecture for network element virtualization usable in embodiments of the present invention. It is contemplated that the network elements may be physically implemented using one or more computers, data storage devices and routers (any or all of which may be constructed in accordance with the system 200 described above with reference to Figure 2) interconnected together and executing suitable software to perform its intended functions. Those of ordinary skill will recognize that there are many suitable combinations of hardware and software that may be used for this purpose, which are either known in the art or may be developed in the future. For this reason, a figure showing physical hardware components and connections is not included herein.

[0072] As may be seen in Figure 3, the illustrated architecture 300 generally comprises hosting infrastructure 302, a virtualization layer 303 and an Application Platform Services layer 306. The hosting infrastructure 302 comprises physical hardware resources provided by the infrastructure on which the architecture 300 is being implemented. These physical hardware resources may include any or all of the processors 204, memory 206, network interfaces 208 and radio units 212 described above with reference to Figure 2, and may also include traffic forwarding and routing hardware 308. The virtualization layer 304 presents an abstraction of the hardware resources 302 to the Application Platform Services layer 306. The specific details of this abstraction will depend on the requirements of the applications 220 being hosted by the Application Platform Services layer 306. Thus, for example, an APP 220 that provides traffic forwarding functions may be presented with an abstraction of the hardware resources 306 (e.g. processor(s) 202, memory 206 and traffic forwarding hardware 308) that simplifies the implementation of traffic forwarding policies.

Similarly, an application that provides data storage functions may be presented with an abstraction of the hardware resources 306 (e.g. processor(s) 203 and memory 206) that facilitates the storage and retrieval of data (for example using Lightweight Directory Access Protocol - LDAP).

[0073] The application platform 306 provides the capabilities for hosting applications. In some embodiments, the application platform 306 supports a flexible and efficient multi-tenancy run-time and hosting environment for applications 220 by providing Infrastructure as a Service (laaS) facilities. In operation, the application platform 306 may provide a security and resource “sandbox” for each application 220 being hosted by the platform 306. Each “sandbox” may be implemented as a Virtual Machine (VM) image 310 that may include an appropriate operating system and controlled access to (virtualized) hardware resources 302. Alternatively, each “sandbox” may be implemented as a container 311 that may include appropriate virtual memory and controlled access to host operating system and (virtualized) hardware resources 302. The application platform 306 may also provide a set of middleware application services and infrastructure services to the applications 220 hosted on the application platform 306, as will be described in greater detail below.

[0074] Applications 220 from vendors, service providers, and third-parties may be deployed and executed within a respective Virtual Machine 310. For example, PCF 220 may be implemented by means of one or more applications 220 hosted on the application platform 306 as described above. Communication between applications 220 and services of the application platform 306 may conveniently be designed according to the principles of Service-Oriented Architecture (SOA) known in the art.

[0075] Communication services 312 may allow applications 220 to communicate with the application platform 306 (through pre-defined Application Programming Interfaces (APIs) for example) and with each other (for example through a service- specific API). [0076] A Service registry 314 may provide visibility of the services available to applications 220. In addition, the service registry 314 may present service availability (e.g. status of the service) together with the related interfaces and versions. This may be used by applications 220 to discover and locate the end-points for the services they require, and to publish their own service end-point for other applications to use.

[0077] Network Information Services (NIS) 316 may provide applications 220 with low-level network information pertaining to a network service instance or one or more PDU sessions, for example. For example, the information provided by NIS 316 may be used by an application 220 to calculate and present relevant data (such as: cell-ID, location of the subscriber, cell load and throughput guidance) to network functions of the CN 114 or DN 120, any or all of which may themselves to implemented by applications 220 executing in respective VMs 310 or container 311.

[0078] A Traffic Off-Load Function (TOF) service 318 may prioritize traffic, and route selected, policy-based, data streams to and from applications 220.

[0079] Systems and methods are disclosed herein that provide techniques for real time QoE assessment and improvement of synchrophasor packet communications which can be applied to any wireless synchrophasor network with arbitrary topology/parameters. The QoE may be evaluated in terms of Not a Number (NaN) sequences (NaNS) in the form of a series of missing packets over successive time- stamps at the PDC output. Non-intrusive parameter estimation, online probabilistic prediction, and prioritized handover are principal steps involved in the disclosed techniques. Parameter estimation deals with extracting the reporting rate of PMUs and the delay thresholds by analyzing the time of arrival (TOA) and time of departure (TOD) of synchrophasor packets. An advantage of this non-intrusive method is that it does not require prior knowledge of the PMU/PDC parameters. The extracted parameters are used by the online prediction algorithms that evaluate the emergence of NaNS under absolute and relative waiting time strategies. Early prediction of NaNS allows the network operator to carry out prioritized handover for unreliable PMU channels and improve the QoE in a timely manner.

[0080] Figure 4 illustrates an example wireless synchrophasor network 400. In the illustrated example, the synchrophasor network 400 comprises a plurality of Phasor measurement units (PMUs) 402 configured to transmit synchrophasor packets to a phasor data concentrator (PDC) 404, via a wireless network which may be structured as described above with reference to figures 1-3. A management node (MN) 406 is provided in the core network 114 for managing operation of the synchrophasor network 400. The MN 406 may be implemented using the techniques described above with reference to figures 1-3. For example, the MN 406 may be implemented as a computing device 202 connected to the core network 114. Alternatively, the MN 406 may be implemented as an application 220, executing in a RTE 222 of a computing device 202 such as a server 116. In still further embodiments, the MN 406 may be implemented in the data network 120, either as computing device 202 or as an application 220 executing on an application server 122. In yet further embodiments, the MN 406 may be implemented in access node 104-3, either as computing device 202 or as an application 220 executing on computing device 202. Access nodes 104-1 and 104-2 that are connected to PMUs 402 handle predominantly uplink traffic from the PMUs 402, and so may be referred to as Uplink Nodes (UNs). Conversely, access node 104-3 is connected to PDCs 404 and handles predominantly downlink traffic to the PDC 404. Accordingly, this access node 104-3 may be referred to as a Downlink Node (DN). The UNs and the DN, which are typically base stations (such as an eNB or a gNB, for example), are indirectly interconnected by means of the core network 114. The alignment of synchrophasor packet received by the PDC 404 may be carried out based on coordinated universal time (UTC) and a timestamp of the synchrophasor packets. If a synchrophasor packet arrives at the PDC 404 later than a pre-determined threshold (or with a delay greater than a predetermined threshold), then the corresponding entry of the dataset is filled by a data loss indicator such as a Not-a- Number (NaN) indicator. Data pushing (e.g. to the PDC 404) with time alignment can be performed based on either absolute or relative waiting time strategies.

[0081] Figures 5A and 5B show example datasets generated by the PDC 404 for the example synchrophasor network 400. In the example of Figure 5A, the data sets for PMU 1 and PMU 3 each contain a NaN sequence (NaNS) consisting of NaN (or packet error) indications in a series of 5 successive timestamps. The presence of NaNS in a data set (e.g. missing packets for a period of N=5 consecutive time-stamps) indicates that the associated PMU 402 is suffering from unreliable communications and poor QoE,. In contrast, the datasets depicted in Figure 5B exhibit scattered NaN indications which can be estimated by known data recovery methods. Accordingly, the example data set of Figure 5B is not considered to indicate a case of poor QoE.

[0082] The block diagram shown in Figure 6 illustrates principle steps and important parameters in methods in accordance with representative embodiments of the present invention. The illustrated example process can broadly be subdivided into steps of: deriving respective values of one or more parameters based on the received stream of synchrophasor packets; predicting whether or not a Not a Number sequence (NaNS) in the received stream of synchrophasor packets is likely, based at least in part on the derived parameter values; and triggering a prioritized handover of a Phasor Measurement Unit (PMU) associated with the received stream of synchrophasor packets when a Not a Number sequence (NaNS) in the received stream of synchrophasor packets is likely. This process is based on both the timestamp of each synchrophasor packet, and TOA and TOD data associated with each synchrophasor packet by the UNs and the DN.

[0083] Referring to Figures 6 and 10A-10D, consider an embodiment in which a synchrophasor network has N spatially separated PMUs 402, and their reporting rate is equal to F frames-per-second (fps). The first step towards non-intrusive QoE assessment is to estimate the important parameters of the synchrophasor packet streams. To this aim, it is useful to implement an estimation window for measuring the TOA and TOD data. The estimation window, may be defined as the time interval (or equivalently a predetermined number of synchrophasor packets) during which streams of synchrophasor packets are analyzed for parameter estimation. The length of the estimation window should preferably be much larger than the maximum reporting time of PMUs to allow for processing of a large number of packets, and to thereby increase the accuracy of the parameter estimation. The core network 114 has stored information of the basic parameters of the links between the PMUs 402 and the UNs including capacity and bandwidth of the channels, packet sizes, etc. Hence, the network 114 can determine the normal uplink delay, i.e. , the time that a packet requires to be successfully received by a UN when the uplink is in the normal operation condition. Let the parameter denote the normal uplink delay for PMU n. The upper- bound of the uplink delay in the normal state can then be described as: where the parameter e represents the largest variation in the packet transmission time (due to PMU processing). This parameter is known by the network (or can be determined using known methods) and satisfies the inequality where represents the maximum PMU reporting rate that can be supported by the wireless communication system. The role of the parameter e is to prevent false alarms in the prediction of NaNS. Next, the following packet data may be defined:

• The uplink TOA, is the time instant at which the k ^th synchrophasor packet from the nth PMU arrives at a UN;

• The downlink TOA, is the time instant at which the k ^th synchrophasor packet from the n ^th PMU arrives at the DN that serves the PDC 404; and

• The downlink TOD, is the time instant at which the k ^th synchrophasor packet from the n ^th PMU is successfully transmitted by the DN that serves the PDC 404.

[0084] Figures 10A show an example Algorithm 1 , which may be used for collection of TOA and TOD data over the estimation window.

[0085] Algorithm 1 consists of three subroutines (identified in Figure 10A as subroutines A, B and C) and is configured to overcome the packet reordering problem by using a hash code matching technique.

[0086] Subroutine A may be carried out by each UN 104-1 , 104-2 in order to extract uplink TOAs and hash codes from synchrophasor packets received from PMUs 402. As may be seen in FIGs. 7 and 10A, during the estimation window, upon receiving (at 702) a new synchrophasor packet from a given PMU 402 (with an index of n) at a UN, the uplink TOA of the packet is determined (at 704) and optionally a hash code of the uplink packet payload is generated (at 706). The received synchrophasor packet may include a timestamp indicative of a time that the synchrophasor packet was generated. The synchrophasor packet is then forwarded to the DN (at 708). In addition to forwarding received synchrophasor packets to the DN for transmission to the PDC 404, each UN may also forward uplink packet data to the MN 406. Alternatively, each UN may forward uplink packet data to the DN. The uplink packet data may include any one or more of: the timestamp indicative of the time that the synchrophasor packet was generated; the uplink TOA indicative of a time that the synchrophasor packet was received by the uplink node, and either a copy of the synchrophasor packet or the uplink hash code generated by the uplink node based on the synchrophasor packet.

[0087] Subroutine B may be carried out by the DN 104-3 in order to obtain downlink TOAs based on synchrophasor packets received from UNs, as well as TODs and hash codes for synchrophasor packets transmitted to the PDC 404. As may be seen in FIGs. 8 and 10A, during the estimation window, upon receiving (at 802) a new synchrophasor packet at the DN, the Downlink TOA , indicative of a time that the synchrophasor packet was received is determined (at 804) and optionally a downlink packet hash code of the synchrophasor payload is generated (at 806). The synchrophasor packet is forwarded (at 808) to the PDC 404, and the Downlink TOD indicative of the time that the synchrophasor packet was forwarded to the PDC 404 is determined (at 810). In addition to forwarding received synchrophasor packets to the PDC 404 (at 808), the DN may also forward (at 812) downlink packet data to the MN 406. The downlink packet data may include any one or more of: the downlink TOA indicative of a time that the synchrophasor packet was received by the downlink node, the Downlink TOD indicative of the time that the synchrophasor packet was forwarded to the PDC 404, and either a copy of the synchrophasor packet or the downlink hash code generated by the downlink node based on the synchrophasor packet. In embodiments in which the DN receives uplink packet data for each synchrophasor packet from the UN, the DN may also forward the uplink packet data to the MN 406. The UNs and the DN can calculate their respective uplink and downlink hash codes in a manner known in the art, such as by discarding the IP and TCP/UDP headers of each synchrophasor packet and then applying SHA-1 algorithm to the remaining synchrophasor packet payload. Preferably, the uplink and downlink hash codes are calculated using the same techniques, so that for a given synchrophasor packet, the corresponding uplink and downlink hash codes will match and so enable the uplink and downlink packet data to be properly associated by the MN 406. [0088] Subroutine C may be carried out by the MN 406 in order to receive and align packet data, which facilitates subsequent filtering (Algorithm 2, FIG. 10B) and NaNS prediction (algorithms 3 and 4, FIGs. 10C-D).

[0089] Referring to FIG. 9, in very general terms, a network node (such as the MN 406) receives (at 902) respective uplink and downlink packet data for each synchrophasor packet in a stream of synchrophasor packets. The network node subsequently predicts (904) whether or not a Not a Number Sequence (NaNS) in the stream of synchrophasor packets is likely, based at least in part on the received packet data; and triggers (906) a prioritized handover of a Phasor Measurement Unit (PMU) associated with the stream of synchrophasor packets when a NaNS in the stream of synchrophasor packets is predicted to be likely.

[0090] For each synchrophasor packet, the respective uplink packet data may include any one or more of: a timestamp indicative of when the synchrophasor packet was generated; an uplink time of arrival (TOA) indicative of a time that the synchrophasor packet was received by an uplink node, and either a copy of the synchrophasor packet or an uplink hash code generated by the uplink node based on the synchrophasor packet. Similarly, for each synchrophasor packet, the respective down link packet data may include: a downlink TOA indicative of a time that the synchrophasor packet was received by a downlink node; a downlink time of departure (TOD) indicative of a time that the synchrophasor packet was transmitted to a phasor data concentrator (PDC) by the downlink node, and either a copy of the synchrophasor packet or a downlink hash code generated by the downlink node based on the synchrophasor packet.

[0091] The inclusion uplink and downlink hash codes, or corresponding uplink and downlink copies of the sychrophasor packets themselves, enables uplink packet data received from the uplink node to be properly associated with downlink packet data received from the downlink node. In this respect, the use of uplink and downlink hash codes is beneficial in that it reduces the network traffic associated with conveying the uplink and downlink packet data to the MN 406.

[0092] During the estimation window, the MN 406 may receive and store packet data including uplink and downlink packet data from the UNs and/or the DN. Uplink packet hash codes associated with the nth PMU 402 received from the UN (either directly or via the DN) may be added to a corresponding uplink hash code set Similarly, downlink packet hash codes for the packet stream associated with the nth PMU 402 may be added to a corresponding downlink hash code set At the end of the estimation window, the MN 406 may execute Subroutine C in order to first align the recorded TOA and TOD data across all of the reporting PMUs 402, and then construct respective sorted datasets for each PMU 402 by comparing uplink and downlink hash codes. The alignment task is beneficial for maintaining synchronization between different PMU channels such that dataset elements with identical indices refer to identical time-stamps. In the illustrated example, these datasets include an uplink data set containing sorted values of the uplink TOA recorded by the UN; a core delay dataset containing sorted values of the core delay as determined by the difference between the uplink TOA recorded at the UN and the downlink TOA recorded at the DN; and downlink transmission delay dataset containing sorted values of the downlink transmission delay as determined by the difference between the downlink TOA · and downlink TOD recorded at the DN.

[0093] It is known that IP-based core networks 114 may impose significant delays on the synchrophasor packets between the UNs and the DN. Abnormally large delays through the core network 114 (which can be detected as the delay between the uplink TOA and the downlink TOA of a given synchrophasor packet) can span a large number of synchrophasor time-stamps and degrade decision making if not detected. Therefore, it is useful to identify any outliers in the core delay datasets and discard them before parameter estimation. For example, each stream of synchrophasor packets can be filtered based at least in part on the respective uplink TOA and downlink TOA of each synchrophasor packet, to exclude packets having a delay that exceeds a predetermined threshold. Figure 10B shows an example Algorithm 2, which may be implemented in the MN 406 for finding outliers based on local outlier probabilities (LOPs) of measured core delays.

[0094] In Algorithm 2, the LOPs are calculated based on the K ^th nearest neighbor search and the parameter λ is the significance level. The threshold G in Algorithm 2 is the confidence level in the delay analysis, and is typically very close to unity, e.g., 99.8%. According to Algorithm 2, if the LOP of a sample exceeds the threshold G, then that sample is ignored or discarded as an outlier. The dataset is updated to include only samples with LOP less than G in the recorded core delays. [0095] When the MN 406 uses an absolute waiting time strategy, the reference time for data pushing is the packet time-stamp or equivalently the packet generation time. In this case, the following delay threshold may be used for predicting data loss:

[0096] Operators respectively represent the empirical cumulative distribution function (CDF) and histogram. For a relative waiting time strategy, the arrival of the first packet with a given time-stamp can be used to establish the reference for the data pushing. In this case, the following delay threshold may be used which accounts for the range of the measured delays: [0097] The uplink TOA datasets can be used to estimate the reporting rate of the

PMUs in the synchrophasor network. The estimate of the PMU reporting rate is crucial in prediction of the data loss under the absolute waiting time logic. First, the uplink inter-packet times are calculated as: [0098] Then, the peak analysis of the empirical histogram of the uplink inter-packet times provides the estimate of as

[0099] It is worth mentioning that in this example, contains permissible PMU reporting rates tailored to power systems that operate at 60 Hz frequency. For power systems that operate at different frequencies, corresponding different permissible PMU reporting rates may be used.

[0100] Once the delay thresholds and the PMU reporting rate are estimated, the MN 406 can detect unreliable communications and poor QoE through prediction of NaNS in one or more PMU channels. The prediction of NaNS under the absolute and relative strategies is based on Algorithm 3 (Figure 10C) for the absolute waiting time strategy, or Algorithm 4 (Figure 10D) for the relative waiting time strategy, respectively. These event-based algorithms may trigger an operation either upon arrival of a synchrophasor packet at a UN, or at a predetermined time instant. The parameter η indicates the minimum number of successive NaN indicators that are considered as a NaNS. These prediction algorithms ignore a group of successive NaN indicators if their number is less than η. The parameter is calculated as

[0101] where the operator denotes the arithmetic mean function. Compared to the mode of distribution, the mean value is found to produce more accurate predictions. The outputs of Algorithms 3 and 4 are the sequence signals respectively. A value of may be used to indicate that the corresponding channel of PMU n is not likely to produce a NaNS, whereas a value of indicates that the corresponding channel of PMU n is very likely to produce at least one NaNS, and thus poor QoE for PMU channel n is detected.

[0102] A promising use case of the illustrated example algorithms is to improve the QoE of synchrophasor networks over shared wireless systems. When either of the sequence signals rise from 0 to 1 , the communication system can search for another UN that can better serve the affected PMU n 402. Upon identification of the substitute UN, a prioritized handover mechanism may be initiated to accelerate data transmission and prevent further data losses. In this regime, early prediction of NaNS combined with prioritized handover can significantly reduce the number of missing packets, and improve the integrity of synchrophasor datasets at the PDC output. The resulting improvement is useful for data recovery methods as well as control/protection applications in smart grids.

[0103] The performance and effectiveness of the illustrated algorithms have been verified by simulations of a distribution-level synchrophasor network based on LTE wireless communications. In the case of LTE, the UNs and DN are called evolved Node B (eNodeB), and the core network 114 is called evolved packet core (EPC). For the purposes of simulation, a test synchrophasor network 400 was designed based on 10 PMUs 402 that are distributed within a selected neighborhood in the city of Montreal, Quebec, Canada. Table 1 shown in Figure 11 gives selected parameter values used for the simulation.

[0104] An elaborate LTE simulator was used, which reads realistic eNodeB information, such as location, antenna type and antenna height, available from a public database, and handles the synchrophasor packets that are generated by the PMUs. Base station distances to the PMUs 402 and the PDC 404, as well as coverage, based on wireless propagation, are taken into account by the LTE simulator. Also considered is how LTE handles access, the latency inserted by the EPC and the effect of other devices competing for the same LTE resources. More description of the LTE simulator and its use with smart city communications are found in: F. Malandra, L. Chiquette, L.- P. Lafontaine-B'edard, and B. Sanso, “Traffic characterization and LTE performance analysis for M2M communications in smart cities”, Pervasive and Mobile Computing, vol. 48, pp. 59-68, 2018. DOI: 10.1016/j.pmcj.2018.05.006; and F. Malandra, R. Pourramezan, H. Karimi, and B. Sanso, “Impact of PMU and Smart Meter Applications on the Performance of LTE-based Smart City Communications”, IEEE PIMRC, pp. 1- 6, Sept. 2018, Bologna. At any simulation time instant, the eNodeBs 104 that serve the PMUs 402 and the PDC 404 are determined based on a set of criteria including the channel quality, antenna coverage, available resource blocks, etc. Unreliable communications are created by failure of all antennas on specified eNodeBs 104. After the failure instant, the LTE simulator finds the best available substitute eNodeB and executes a handover mechanism for the affected PMU channels. [0105] The average time required for prediction of unreliable communications is illustrated in Figure 12. It may be seen that, for both absolute and relative logics, the average prediction time linearly increases with increasing the value of parameter η.

The fastest prediction is achieved under the absolute logic with η = 2 which has an average prediction time equal to 56 msec. The average prediction time under the relative logic with the same value of η is 10 msec higher.

[0106] Figure 13 shows a pair of charts (labeled as (a) and (b)) illustrating the number of missing packets at the PDC output when an eNodeB 104 fails at t = 2 sec.

In both charts, the horizontal axis represents the time-stamp of the synchrophasors, and the vertical axis represents the total number of missing packets for the given time- stamp. In the absence of the prediction algorithms (i.e. algorithms 3 and 4) described above, only one regular handover is carried out that transfers one PMU 402 to a new eNodeB 104. Latent poor QoE occurs in this test. In fact, in this simulation, reconnection of the PMU 402 adversely affects the link of another PMU 402, such that incremental access delays bring about several missing packets at the PDC output, as shown in chart (a) of Figure 13. The results based on Algorithm 3 with η = 2 combined with prioritized handover are shown in chart (b) of Figure 13. In this case, two prioritized handovers are carried out, such that two PMUs are connected to respective different eNodeBs. As may be seen in chart (b) of Figure 13, the methods disclosed herein can prevent detrimental loss of synchrophasor packet such that only 2 incomplete datasets are observed at the PDC output.

[0107] Figure 14 shows a pair of charts (labeled as (a) and (b)) illustrating the number of missing packets at the PDC output when a given eNodeB 104 fails. In both charts, the horizontal axis represents the index of the failed eNodeB, and the vertical axis represents the total number of missing packets. The results shown in chart (a) of Figure 14 indicate that failure of eNodeBs can lead to a significant number of missing packets in the absence of the prediction algorithms disclosed herein. For example, failure of eNodeB 3 leads to 112 and 62 missing packets per PMU under absolute and relative logics, respectively. In this network, failure of the rest of eNodeBs may result in 10-13 missing packets on average. In contrast, chart (b) of Figure 14 reveals that the average number of missing packets per PMU can be significantly reduced by using the disclosed prediction algorithms and prioritized handover mechanism. In particular, the number of missing packets per PMU are around 1 and 2 for the absolute and relative logics, respectively. The simulation results corroborate the effectiveness of the disclosed methods for real-time reliability assessment and improvement of the synchrophasor communications. [0108] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is representative, and that alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc. [0109] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.