Content for  TR 22.867  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   5…   5.2…   5.3…   5.4…   5.5…   5.7…   5.8…   5.10…   5.12…   5.13…   5.15…   5.16…   5.17…   5.18…   5.20…   5.22…   5.23…   6…   8…


5.13  Use case of 5GS support for synchrophasors in wide-area Smart Gridp. 54

5.13.1  Descriptionp. 54

Using phasors as a mathematical approach to describe a power system operation quantities is not new. With the advent of GNSS and other time sources that provide phasor measurement units (PMUs) with accurate timing signals, the concept of synchrophasor came into existence [21]. Modern PMUs and accompanying entities such as Phasor Data Concentrators (PDCs) [22] could connect to the time source and with each other in a number of different ways such as: using direct connection with GPS via an internal GPS receiver, using a connection via IRIG-B (legacy method) or IEEE Std 1588-2008 [23] / IEEE C37.238-2011 [24] or PTP time synchronization profile in IEC 61850-9-3 [7], over an Ethernet to achieve 1 μs time accuracy. This 1 μs time accuracy as referred to in these IEC standards assumes every PMU is has a built-in synchronization modem.
As a result, the phasors throughout a wide-area power system can be measured at different but strategically selected locations (such as at tie-lines and on the key network buses) in a synchronized fashion. This powerful possibility releases huge potential for power utility operators to innovate, so as to achieve various goals in safe, robust and efficient network operation and maintenance. Some interesting applications based on synchrophasors are: power system model validation, wide-area protection, advanced state estimation, frequency-control and oscillation mitigation, etc. With the fast adoption of DERs, the power system will undergo challenges of increased variability and unpredictability, which means the synchrophasors could offer utility operators an effective means to understand, respond and predict the real-time dynamics of the power systems.
Up till now, wide-area measurement systems based on synchrophasors have been under expansion in large scale throughout America, Europe, and Asia. It is an area of opportunity for 5G systems to provide connectivity and services. Thanks for the wide-area coverage of 5G, it is seen by many utilities that 5G could play a major role in supporting PMU wide-area applications paradigm.
Synchrophasors are measured and collected in a hierarchical structure to meet the power system needs. The Figure below comes from [25]. But it is important to know that PDCs can have one to many interconnections with each other for the sake of e.g. redundancy. There could be many internal and external functions defined at each PDC, and PDCs could eventually interface with SCADA, EMS and DMS, where applicable. As defined in [25], a PMU and a PDC may transmit its data in one or more separate data streams. Each stream may have different content and may be sent at a different rate. The destination of each stream may be different device(s) and location(s) (multicast data is sent to multiple destinations). Each stream must then be individually controllable, and have its own identification and a separate configuration control. This feature is useful for sending data to different devices with different purposes, allowing streams with different wait times and class of service (M and P class), as specified in [22].
Copy of original 3GPP image for 3GPP TS 22.867, Fig. 5.13.1-1: Synchrophasor data collection network [X6]
Within the synchrophasor system, PMUs can be configured with various reporting rates [25]. In a 60Hz system, reporting rates could be {12, 15, 20, 3, 60} per second, and in a 50Hz system, the reporting rates could be {25, 50} per second. It is encouraged to adopt higher rates up to 120 per second. Table 5.13.1-1 shows the corresponding reporting period 1/Fs.
Reporting Rate (Fs)
in Hz
Reporting Period (1/Fs)
in ms
With regard to the data flows, each synchrophasor data flow could have an individual QoS - the performance aspects are addressed in [27]. In [28], the real-time communication between PMUs is addressed, and there two performance classes (P and M) are specified with the corresponding dynamic performance requirements. The P class is mainly for protection and control purposes, which requires fast response, minimum filtering and minimum delay. The M class is mainly used for measurements in the presence of out-of-band signals, which requires greater precision and significant filtering, and allows slower response and longer delay. Intuitively, the higher the PDC in the hierarchy (as in Figure 5.13.1-1), the more prone to class M an application deployed there seems to be.
The measurement reporting latency compliance specification defines the PMU real-time output reporting latency is dependent on the corresponding reporting rate Fs. For both performance classes, the measurement reporting latency is defined in Table 2 [25].
Performance Class Max Measurement Reporting Latency
P Class2/Fs
M Class5/Fs
The communication end-to-end latency shall be the reporting latency subtracted from the reporting period. Therefore for different reporting rate, the communication latency is shown in Table 3.
12 15 20 25 30 50 60 100 120
P Class83.366.67504033.32016.67108.3
M Class333.3266.67200160133.38066.674033.3

5.13.2  Pre-conditionsp. 55

Throughout the wide-area power system, according to the smart-grid application architecture, PMUs and PDCs are deployed at selected locations. A 5G UE is integrated into a PMU or a PDC. They are switched on. According to specified reporting rate, the synchrophasor data is collected, aggregated and made available to the applications accordingly.

5.13.3  Service Flowsp. 55

Step 1.
In general, a PMU in a wired network can operate in unicast mode and multicast mode. The communication between PMU and its peers in wired networks is usually multicast in spontaneous mode [28] of operation.
Thus, while the use case is based on multicast in existing, wired networks, in this use case, we consider 5G technology to be capable of resembling the connectivity needs for the aforementioned spontaneous mode of PMU in a resource efficient way that might not always be multicast but could also be unicast.
Step 2.
PMUs are configured to operate in spontaneous mode to provide the measurement data to PDCs. According to U's deployment choice, a PDC can make use of data from multiple PMUs and/or from other PDCs.
Step 3.
In the grid, some busses may have priority over others, therefore data produced by PMUs deployed at different busses can have different priority too.
Step 4.
For a PMU deployed at a given bus in the grid, different types of data are generated to feed different applications of divergent criticality (such as monitoring, control, protection, state estimation, etc.). Also, the same data can be needed by different destinations requiring different QoS treatment. Because of that, these different streams of data is needed by different destinations with different QoS. Additionally, the algorithms a TSO or DSO decides to use further influences the difference in criticality (QoS requirements in other words) of various streams of data this PMU generates.
Step 5.
At company U, the automation engineer Antoine is installing PMUs in U's distribution networks according to the PMU-based WAN application design. For each PMU, he configures the data types, calibration factors, and other meta-data for the data that the PMU will send. Antoine also configures the PMU to transmit multiple data streams, each with different content, rate, format, priority. Each data stream shall have its own IDCODE so that the data, configuration, header, and command messages can be appropriately identified. Each stream shall be independently operable including command execution and data, header, and configuration messages.
Step 6.
PMUs transmits measurement according to the configured reporting period. Multiple data streams generated by the same PMU are transmitted by the 5G network with different QoS treatment as Antoine has configured on the PMU.
Step 7.
PDCs received the synchrophasors, performs configured local processing functions, forwards data further down the hierarchy.
Step 8.
Advanced logics in the applications receive the synchrophasors as prescribed, the designed logics such as control, protection and measurement are carried out as expected.

5.13.4  Post-conditionsp. 56

Applications can execute designed logic to perform protection, control and monitor actions per design.

5.13.5  Existing features partly or fully covering the use case functionalityp. 56

  1. In TR 22.804, a similar PMU study proposes 10ms end-to-end communication latency.
  2. In TS 22.104, for PMUs synchronization, 1 μs is specified as 5GS synchronicity budget requirement in a service area < 20 km².
  3. Support of IEEE 1588 PTP is an existing feature. Additional traffic from running IEEE 1588 PTP is around 0.004 Mbit/s.
  4. In TS 22.261, 5G system shall support operation of downlink only broadcast/multicast over a specific geographic area (e.g. a cell sector, a cell or a group of cells).
  5. In TS 22.261, the 5G system shall support downlink parallel transfer of the same content, via broadcast/multicast and/or unicast, such that all receiver group members in a given area receive the media at the same time according to user perception.
  6. In TS 22.261, the 5G system shall be able to apply QoS, priority and pre-emption to a broadcast/multicast service area.
  7. In TS 22.261, The 5G network shall support parallel transfer of multiple quality levels (i.e. video resolutions) of broadcast/multicast content for the same user service to the same UE taking into account e.g. UE capability, radio characteristics, application information.
  8. In TS 22.261, the Ethernet transport service shall support routing based on information extracted from Virtual LAN (VLAN) ID by the 3GPP system.
  9. 5G system can provide 5ms with existing 5QI to support the 8.33ms latency as required by the class P PMU with highest reporting rate 120Hz.
  10. In TS 22.261, the 5G system shall support on-demand establishment of unicast, multicast, and broadcast private communication between members UEs of the same 5G LAN-VN. Multiple types of data communication shall be supported, at least IP and Ethernet.
  11. In TS 22.261, the 5G network shall enable member UEs of a 5G LAN-VN to use multicast/broadcast over a 5G LAN-type service to communicate with required latency (e.g. 180ms).
  12. In TS 22.263 (VIAPA), Table 6.3.1-1 includes Note 4 that mentions the UL stream originating from a UE may be the source of a DL multicast stream.

5.13.6  Potential New Requirements needed to support the use casep. 57

5G System should support the IEC 61850-9-3 [7] profile and IEEE Std C37.238-2017 [24].
[PR 5.13-002]
5G system should support at least one of the two profiles for synchrophasor communications: IEC 61850-90-5:2012 [26], or IEEE Std C37.118.2-2011 [28].
The 5G system should support the IEEE 802.1Q as the QoS profile, as defined in IEC 61850-90-5 [26].
The 5G system shall support delivery of the same UE originated data in a resource-efficient manner in terms of bandwidth to UEs distributed over a large geographical area.
The 5G system shall allow a UE to request a communication service to send data to different groups of UEs at the same time.
The 5G system shall allow a UE to request different QoS for the communication in each of those groups.

5.14  Energy Substation Surveillancep. 57

5.14.1  Descriptionp. 57

The use case concerns the use of surveillance cameras in sensitive locations and the implications on telecommunications where that serves as the means by which the surveillance media data is collected in a remote location.
Closed-circuit video (CCTV) is the most bandwidth-intensive of all utility applications. The data rates depend on the required resolution of images, number of colors and frame rate. There are existing standards that reduce this data rate considerably while still providing excellent video quality. During incidents (such as security breaches, equipment malfunctions and power outages,) a higher resolution can be used.
Many utility substations today use fiber optic cables to provide sufficient communications capacity to transport surveillance media data. This use case explores the use of 5G instead either as the sole means for transporting surveillance media data, or as a backup in case the primary means of transport (fiber) has been compromised. This could occur inadvertently if the fixed communication network suffers damage, or intentionally as part of a coordinated local attack that compromises substation security.
While it is often necessary and prudent to transport surveillance media data continuously, there are approaches that reduce this need, e.g. triggers based on motion detectors, tampering (e.g. with cameras, locks, etc.), heat sensors, etc. In addition, video analytics can identify suspicious changes in a field of view within the secure permission, such as people present when they are unexpected, or people present at places within the secure perimeter for too long, etc. In this case, video could be stored locally and only transmitted on demand, or when triggered by an event. The design of a secure facility is beyond the scope of this use case. In any case, there are times in which transport of all surveillance data is needed - so the capacity model is based on this situation. This capacity may only be needed intermittently, for the reasons given above, or it may be required constantly.
Some regulations however, e.g. NERC CIP in North America, require continuous live video transport from cameras monitoring the substation's Electronic Security Perimeter.
Further, given the use of fiber optic cables, the networks are vastly over-provisioned. For this reason, even where regulation does not require constant video media transport for perimeter security, there is a tendency to transport all surveillance media, at all times.
The most common video codecs used are MPEG-2, MPEG-4 and more recently, the Motion-Joint Photographic Expert Group (M-JPEG). The frame rate commonly used is 25-30 video frames per second. The resolutions often used, per the Common Interchange Format (CIF), are QCIF (176x120), CIF (352x240), 2CIF (704x240), and 4CIF (704x480). [16] This reference is 7 years out of date, though, and the current rate used by some energy utilities is now HDTV (1280x720) resolution.
For the purposes of this use case HDTV with continual media transport will be considered as the service requirement, as this is most realistic looking forward in time. 1280x720 * 8 bit resolution * 30 frames per second = 2.4 (10)7 bits per second (uncompressed.) For H.264 compression (MPEG-4), this can be transported with 3 Mbit/s.

5.14.2  Pre-conditionsp. 58

The substation has the capacity to generate surveillance data. The utility operator "U" needs for this data to be sent from the substation to a central operation center reliably, so they arrange services with a telecommunications service provider "T" for this purpose.
Surveillance cameras use mechanisms for mechanical panning, zooming and tilting (PZT) so they do not need to be more than high definition (HD).

5.14.3  Service Flowsp. 58

There are two potential service flows.
  1. Continuously transport surveillance media from the substation site to a central operation center.
  2. When triggered due to local conditions or remote control, transport surveillance media from the substation site to a central operations center.

5.14.4  Post-conditionsp. 58

The substation security has some assurance, as the substation surveillance media data that is generated on the site can be transported reliably to a central operations center.

5.14.5  Existing features partly or fully covering the use case functionalityp. 58

The video rates described below can be supported by 5G. In fact, 4G suffices as a 'backup' mechanism to carry surveillance video data in some existing substations today.
Scenario User experienced data rate (Mbit/s per camera) Latency(ms) Reliability % Connection density Coverage (km)
Surveillance HD camera media3 (up 5 if a lot is going on)(note 1)(note 1)~12/sub-station>=30km (city range)
Media transport typically uses a streaming protocol that allows for buffering of media in the event of changes of latency (jitter) or intermittent failure. This may result in transient interruptions of the video stream but does not result in loss of media. For this reason, no KPI target is given for these metrics.

5.14.6  Potential New Requirements needed to support the use casep. 58

This use case is included for completeness but no new requirements have been identified.

Up   Top   ToC