5G is expected to provide a highly reliable platform for communications. Requirements for industrial automation and URLLC (e.g. in TS 22.104) are extremely high and appropriate for connectivity for Smart Energy. However, network incidents could happen and the scenario in use case below may mitigate the impact of such a failure to further increase the system reliability.
It is important to emphasize that this use case is not theoretical. There are many substations around the world that use 3GPP access for communication services in more or less ad hoc fashion (where management interfaces between the 3GPP system and the DSO are not standardized.) This use case focusses on how 5G can provide service to DSOs as well.
A DSO has many, e.g. 100s to 10,000s of substations. These substations are managed from operation centers typically referred to as control centers.
Within the substation there are many services (shown here remote metering, automation, MV supervision, LV supervision, etc.) In addition, there are power line communication links beyond, to customer premises equipment, that increasingly will spread the reach of IP services up to the smart meters. The thick red line represents the termination of communication outside the substation. For 3GPP telecommunication services supporting the DSO, the model of the interface between the switch and the network can be considered a 5GLAN service.
The actual topology between substations is more complex than shown, since there may be several communication services (back up links to provide greater reliability, etc.) For the purposes of this use case this is not considered further.
The traffic from the diverse services in the substation is aggregated before it leaves the switch and may be encrypted - the 5G system will not see the individual service flows. Of particular importance to the DSO is the interface exposed by the switch. Information about this from the mobile network that has proved very important in the past.
Previous generations of 3GPP systems, as deployed, did not effectively achieve high availability.
There are different alternatives to achieve high availability that a DSO might choose. This use case focuses on of the alternatives: closely monitoring actual performance. This is a way to enable DSOs to respond to possible future problems proactively. DSOs can troubleshoot more effectively. DSOs can continue service in the case of reductions in performance due to a number of factors. To identify these problems proactively, obtaining sufficient information about configuration and radio operation has been the key to identifying 'communication health' by the DSO, so as to identify patterns that result in poor performance and be able to react in a timely manner before communications performance declined to an inadequate level, e.g. by activating alternative access options to the 3GPP access whose performance shows signs of decline.
It is important to note that for the purpose of this use case, the UE that is considered is the devices that connects the substation network to the DSO's network, not any UE (e.g. a smart phone, or IoT device.) Nevertheless, it is seen by the 5G system as a UE.
Specific information that is required includes UE information, Connectivity status including QoS parameters, and session status information including user plane performance and fault information. Specific events should trigger a notification to the DSO from the MNO in a timely manner. Utilities (DSOs) can choose to rely on 3GPP technologies to enable telecommunications connectivity for mission critical services and sites. These technologies are used to connect endpoints (Substations) and a set of different Smart Grid traffic flows by means of a device with cellular WAN access.
As with any other type of telecommunications networks, the connectivity status and performance management information must be available.
In the event of an incident affecting the MNO's network, utilities need to be notified in a timely manner regarding the potential communication performance failure, so that a DSO can take proactive measures such as switching to an 'alternative' connection. This information could be predicted future events related to possible communication service degradation (derived from information exposed by an operator's network analytics), or it would be some additional information identified in close correlation with communication service degradation. The latter is the approach described further. This use case shows how an interface could deliver this information that could provide network management information to be accessible to utilities in a manageable way.
A DSO "U" has a service contract with a MNO "A" and MNO "B" to provide telecommunication service to U's substations. (U has more than one service contract in order to increase the redundancy and to achieve greater coverage, as a means of achieving higher availability.
The requirements described in clause 5.7.6 below do not depend on there being 2 USIM contracts. There is no interaction or communication between the two MNOs (A and B) implied by this use case.
U has shared parameters for delivery of information (e.g. monitoring and alarms) with A and B in advance from a standard set of them grouped in a SNMP MIB or any similar standard artefact offering the needed functionality, and established standard communication interfaces (e.g. APIs) that allow secure and highly available exchange of management data between U and A and B. The parameters and the communication interface must be standard for all MNOs and DSOs be able to receive a consistent service in the different world regions independently of the service provider.
In the following text IT management is discussed to motivate the management requirements and to explain the need. There is no intention however to require IT management at the process level be supported by 3GPP standards. Nor does this use case imply exposure or integration of IT management processes of the DSO or MNO.
The smart energy applications motivating this use case are distribution automation and distribution / substation automation applications involving supervision, control and data acquisition in order to recover from or avoid communication problems in substations. Though the availability requirements of these applications can be met by the 5G system, taken as an aggregate of several applications in a substation with critical importance to the energy system, the availability has to be extremely high. This is because the consequence of failure is severe - in terms of loss of business productivity and even risk of human life in a power outage. A DSO faces severe regulatory penalties in the event of outages that could be prevented.
The following IT processes are in place in U's network. Specific IT management objectives require timely and sufficiently detailed input. The processes that most concern this use case are Incident Management, Change Management and Service Configuration Management. These services are defined in [12]. The processes discussed in this section occur within the DSO network. Though there is no doubt a parallel set of processes within the MNO network, these are (aside from incident reporting and management data acquisition by the DSO network) out of scope. This may surprise the reader, but the reasons are the following.
It is the IT process requirements of the DSO that motivate the exposure of information by the MNO.
Though the details of the IT processes of both DSO and MNO are not matters of standardization, the interface between the two must be considered. If the DSO needs to employ different management standards with each communications provider, this increases complexity and the lack of standards based management interfaces constitutes a significant drawback when considering whether to employ and integrate services over a particular communication system.
Incident Management [13] is a process that can be triggered by a customer upon reporting an issue or raised automatically by an event monitoring system. Incident records correspond to the reported or raised event. It is vital to link incident management records to link them to Configuration Items (maintained in a database by means of the Configuration Management process [14].) A set of incidents may also motivate a Change, according to the Service Asset and Change Management Process [15].
Configuration Management is particularly important for the DSO, since they must track the total configuration of all essential systems, especially any change that occurs to components that could cause a system failure. Each item in the IT system is identified and has a controlled configuration that can be verified and audited. This allows other processes to be automated and the complete IT status to be taken into consideration in real-time, e.g. during an incident. If some components of the IT system are outside of the control of the DSO, the configuration of these must however remain constantly known. Any change to the configuration of these components requires notification to the DSO as it could possibly trigger an incompatibility with other configuration.
Change Management provides a process with significant oversight (record keeping and authorization), ability to undo the change if required through the linked process of Release Management, and an evaluation of the consequences of the change. It is particularly important that it is unacceptable under the Change Management regime that changes occur without passing through the process. For example, if a UE were to change the terms of its contract and service, or its SIM card and its configurations without going through the Change Management process this would be considered an Incident, resulting in immediate actions by DSO, and possibly further interactions with MNO.
The delivery of relevant information would be part of the service level agreement between the DSO and MNO. The information required by the relevant interfaces are listed below at a high level. A further analysis of the details of these requirements and how to fulfil them is out of scope of stage 1 specification.
In a DSO network operation center for U' s distribution services, a technician "Fred" observes a number of substation local area networks, ready to detect and resolve any sign of trouble that arises. Supplementing the DSO's network management information, the MNO exposes management data to enable Fred to properly respond to failures in the DSO network.
U uses a Dual SIM router which is configured to use MNO A as primary in normal conditions, failover mechanism to B is enabled so that standby connection can be triggered in the event of complete loss of connection or quality of connection below thresholds.
Utility DSO U's NOC (Network Operating Center) will perform efficient and effective monitoring of Smart Grid assets connectivity and incident resolution if it can rely on trustworthy information coming from the following sources:
Health Check platform to monitor availability of the connection
Performance Check procedures to monitor that performance levels are above required thresholds
Accurate and updated Inventory to geographically locate the Cellular connection (USIM) at a specific Smart Grid asset (typically Substation)
Real time Access to MNO's SIM card Management and operation platforms (lifecycle control, i.e. whether the subscription is active, suspended, in 'test' mode, deactivated, etc. APN configuration,)
Information provided by the MNO on a timely manner and related to radio access, for example RAT type and CellID.
The usage of this data as a combined input to a single utility-owned "Monitoring and Management" (M&M) platform are instrumental for the DSO to make decisions and start actions that will impact the availability of the Smart Grid and, thus, the final service delivered to its customers. The utility DSO counts on a dashboard to represent the most relevant KPIs to the connectivity health status of the Substation switches and routers, to monitor the stability of the connection and the quality of the service delivered by the MNO.
The elements in this model are explained below.
The KPI Dashboard in the figure above contains information regarding the
Connectivity status of the UEs and their status with respect to their service with the MNOs A and B. Inputs: volume of data consumption per substation and MNO A. Output: check whether expected traffic levels persist. If there is a massive failure to achieve KPIs, Fred (U) can switch to use the other MNO B. This permits detection of failure in a way that avoids massive incidents (part of the Incident Management process.)
Stability of service of the UEs in terms of their mobile telecommunication service.
Configuration is another aspect of stability. Any change to the service configuration (as agreed between U and MNOs A and B) needs to be reported. In addition, U needs to be able to request the configuration information. (This is an essential part of the Configuration Management process.)
Performance determines if the mobile telecommunication network continues to perform as expected. U checks the performance by means of network tools, based on ping packets being sent (this increases traffic used over the connection with A and B.) This information is combined with AAA events (e.g. registration and deregistration with networks.) Output: Information on average performance indicators is obtained, including latency, packet loss rates, per technology. (This is an essential part of the Service Level Management process, not considered further in this use case.)
Report Generation
Reports from U are provided to A and B on a monthly basis. U expects a certain quality of service delivered by A and B. The achieved service levels are tracked and presented in the report. If A or B do not comply with the service level agreement, actions are specified in the SLA (and these are out of scope of this study.)
A DSO might request the following to be included in the report:
Network performance (latency and packet loss above threshold),
Network stability (the connection remains stable over time), (3) Accumulated alarms arising due to the MNOs network (e.g. massive or isolated RAN issues.)
Alarms Panel
Alarms can be triggered so that incident's responsible parties are informed in real time and the remediation actions and/or escalation processes can be initiated. Alarms are reported by U to A and B as part of the Incident Management process. Incidents may be of the following forms (this is not an exclusive list):
Massive incident where all UEs connectivity is affected whose SIM cards are provided by A or B.
The service flows below are examples of typical situations encountered by "Fred", a technician at Utility U's Network Management Center (NMC), to illustrate the normal operation and maintenance processes (with emphasis on Change Management, Incident Management and Configuration Management):
Fred is checking M&M "KPI Dashboard" and, while looking at the Weekly graph of Connectivity status, he notices a sudden drop of accumulated traffic consumption of MNO A and a sudden increase of MNO B traffic. At the same time at "Alarms" panel there is an incoming alarm informing of a Massive event. An automatic ticket is created to MNO A and the counter of massive events is updated to be reflected in the next SLA monthly report to track MNO A's quality of service.
Fred tries to remotely perform a firmware upgrade to the Substation Automation unit and, after a couple of unsuccessful attempts, notices that the firmware upgrade cannot be fully completed because the connection is unstable. Fred checks the Stability graph on "KPI Dashboard" for this particular Substation code and confirms that there is a recurring cell roaming of MNO A's SIM card during the last 12 hours. Fred accesses remotely to the cellular router that is providing cellular access to the substation Automation units and provokes a failover to MNO B. This turns out into a stable connection which enables a successful completion of firmware upgrade process. At the same time, he checks the "Alarm panel" and confirms that a notification has been sent to the MNO A because this bad behaviour has been happening for the last month.
Utility U is embarked in the renewal of electric MV cables of a group of 10 Substations located in the proximity of "Main Convention centre". These Substations are using BPL (Broadband PLC over Medium Voltage) as the main backhaul connection with failover to cellular backhaul in case of main connection failure. Fred observes that the backup cell communication with MNO A for the 10 Substations is working, though runs unstably. Fred checks the "Dashboard KPI" Performance graph and confirms that the Substations' cellular connections have high latency and packet loss rate during day working hours for the last two weeks. At the same time, after checking Stability graph on "KPI Dashboard" Fred confirms that the USIM cards in the 10 Substations also present constant technology roaming from E-UTRAN service to UTRAN service. This issue has been affecting hourly smart meter readings. Fred remembers that there has been an Automobile Fair at the Convention centre in the last two weeks that might have affected the Radio resources available at the eNodeB. He checks the alarms and sees that there has been an alarm sent to MNO A to report on Service Quality degradation. This alarm triggers an auditing process lead by MNO's radio team in order to increase the capacity of 2 specific sectors of 1 eNodeB serving the Convention centre area. (This is an example of a performance based trigger for Change Management as part of the overall Service Level Management process between U and A.)
While analysing MNO A's monthly SLA report, Fred observes that the average latency of all connected SIM cards has dramatically increased in the last two months from an average of 200 ms up to 630 ms. Furthermore, there has been an accumulated amount of 10 massive incidents in the last month. This information is instrumental to contact MNO A that was aware of the massive incidents but was not of the increase in latency. In order to solve it the MNO takes appropriate action.
While monitoring the Performance graph on "KPI Dashboard", Fred observes high packet loss rate affecting all connected Substations through MNO B. This issue is starting to affect the smart meter reading rates. Fred promptly opens a ticket to MNO B (as part of the Incident Management process.)
Alternatively, if B detects a problem in their network that will degrade service levels in U's network, B will use a standard mechanism to raise an alarm in U's network. This will alert Fred, who will note that there is already an open ticket related to the incident, as well as other data associated with the service degradation.
MNOs A and B have recently informed DSO "U" about the imminent phase out of 3G services at national level. They inform about the process timeline which is planned to start in the next 6 months to be fully completed along one year starting in urban areas. Fred has been designated to coordinate the remediation activities that will avoid MNO's network operations to affect DSO U's Smart Grid operations. Fred checks "KPI dashboard" in "M&M platform" to do a first evaluation of the dimensions of the situation. The accumulated graph per technology and frequency band for each MNO shows that there are 20,000 substations currently connected by means of Cellular 3G. "3G remediation" project definition starts. (This is an example of the Change Management process informed by Configuration Management and performance data.)
"3G remediation" project requires DSO "U" to undertake both field and administrative operations. Field operations will consist on replacing cellular devices and SIM cards of MNOs A and B all over 20,000 substations. Inventory information of SIM cards' location available on "M&M" platform allows to efficiently coordinate field operations. (Configuration Management is needed during Release Management process. The release management process is not discussed further in this use case.)
Administrative operations consist on provisioning 20,000 new generation technology SIM cards of both MNOs A and B. "M&M" platform will enable a single interface of operation which will make the task more efficient and straightforward than it was before when provisioning had to be performed by means of two separate MNO's Web Portals. This is possible thanks to the fact that SIM card parameters (APN, status, IP, Subscription group, etc.) for both MNO's A and B are standard, delivered through the same API definition. This allows an easy integration of all MNO information into a single operating platform. (This is an example of Configuration management processes making use of standard interfaces.)
U is able to work to maintain and improve the services they provide to their customers both during incidents and over time as part of Incident Management and Change Management processes. U is able to report incidents to A and B with standard mechanisms and content that will help the identification and solution of it with less effort and time. A and B receive input from U and is able to improve and maintain their service quality. A and B provide notifications to U regarding changes for selected components (e.g. specific UE aspects) to status and configuration (both long term and every time that specified components change) as per their service agreement. A and B can inform U of service changes in advance. A and B inform U when an incident occurs by means of standards based mechanisms.
Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to monitor the network slice used for the third-party.
The 3GPP network shall be able to provide suitable and secure means to enable an authorized third-party to provide the 3GPP network via encrypted connection with the expected communication behaviour of UE(s).
The 3GPP network shall be able to provide suitable and secure means to enable an authorized third-party to provide via encrypted connection the 3GPP network with the actions expected from the 3GPP network when detecting behaviour that falls outside the expected communication behaviour.
Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party to scale a network slice used for the third-party, i.e. to adapt its capacity.
Based on operator policy, the 5G network shall provide suitable APIs to allow a trusted third-party application to request appropriate QoE from the network.
Based on operator policy, the 5G network shall expose a suitable API to allow an authorized third-party to monitor the resource utilisation of the network service (radio access point and the transport network (front, backhaul)) that are associated with the third-party.
Based on operator policy, the 5G network shall expose a suitable API to allow an authorized third-party to define and reconfigure the properties of the communication services offered to the third-party.
Based on operator policy, the 5G system shall provide suitable means to allow a trusted and authorized third-party to consult security related logging information for the network slices dedicated to that third-party.
Based on operator policy, the 5G network shall be able to acknowledge within 100ms a communication service request from an authorized third-party via a suitable API.
The 5G network shall provide suitable APIs to allow a trusted third-party to monitor the status (e.g. locations, lifecycle, registration status) of its own UEs.
The 5G system shall provide suitable APIs to allow third-party infrastructure (i.e. physical/virtual network entities at RAN/core level) to be used in a private slice.
A 5G system shall provide suitable APIs to enable a third-party to manage its own non-public network and its private slice(s) in the PLMN in a combined manner.
The 5G network shall enable the network operator to create, manage, and remove 5G LAN-VN including their related functionality (subscription data, routing and addressing functionality).
The 5G system shall support traffic scenarios typically found in an industrial setting (from sensors to remote control, large amount of UEs per group) for 5G LAN-type service.
Based on MNO policy, the 5G network shall provide suitable APIs to allow a trusted third-party to create/remove a 5G LAN-VN.
Based on MNO policy, the 5G network shall provide suitable APIs to allow a trusted third-party to manage a 5G LAN-VN dedicated for the usage by the trusted third-party, including the address allocation.
Based on MNO policy, the 5G network shall provide suitable APIs to allow a trusted third-party to add/remove an authorized UE to/from a specific 5G LAN-VN managed by the trusted third-party.
For a private network using 5G technology, the 5G system shall support network access using identities, credentials, and authentication methods provided and managed by a third-party and supported by 3GPP.
TS 23.628, clause 5.6.1 provides monitoring of UE location, IMSI-IMEI association changes, UE connectivity and PDN connection status.
Clause 4.15.3.1 of TS 23.502 provides the analogous monitoring capabilities for the 5GC.
It may be possible for the utility to interact using non-standard means with the MNO to determine the status of any of their subscriptions (and associated UICC/USIMs.) This capability is entirely out of scope of 3GPP.
It also may be possible using non-standard means for the utility to request configuration default information related to their subscriptions (and associated UICC/USIMs.) This capability is entirely out of scope of 3GPP.
Based on MNO policy, the 5G network shall provide means to allow a trusted third party to monitor LAN-VN performance parameters, to configure and receive information for conditions relevant to a specific UE, specifically performance of the network and configuration aspects of the UE in the VN.
[PR.5.7-002]
The 5G system shall provide a means by which an MNO informs 3rd parties of network events (failure of network infrastructure affecting UEs in a particular area, etc.).
[PR.5.7-003]
The 5G system shall provide a means by which an MNO informs 3rd parties of congestion or other general performance degradation (especially if planned or known).
[PR.5.7-004]
The 5G system shall provide a means by which an MNO can report site specific and massive events to 3rd parties.
[PR.5.7-005]
The 5G system shall provide means by which an MNO informs 3rd parties of changes in UE subscription information. The 5G system shall also provide a means for 3rd parties to request this information at any time from the MNO.
[PR.5.7-005a]
Based on operator policy, the 5G system shall provide means for the 3rd parties to request changes to UE subscription parameters for access to data networks, e.g. static IP address, APN/DNN.
[PR.5.7-006]
The 5G system shall provide a means by which an MNO can inform 3rd parties of changes in the RAT type serving UE, cell ID, quality of signal information, change in frequency band assigned with a suitable frequency via OAM and/or 5G core network to aid the 3rd party user in taking proactive actions to achieve their own service availability.