It is important to understand that this use case is widely present in the DSO networks in many regions across the world. This use case resembles the realistic situation in which a utility M2M system interacts with an MNO for consuming cellular technologies. This use case focuses on how 5G can provide improved management related services offered to DSOs, in the realistic real-life context. To bring context to this paper, the use case of AMI is used.
M2M has existed in DSO networks for a long time. Started with the support by legacy GPRS, CDMA, UMTS and later LTE, smart metering and AMI systems have enjoyed rapid deployment by a DSO to reach their operation and business targets. Not only for metering systems, but also a large number of DSOs have brought cellular connectivity to substations that are remotely located and have relatively less sophisticated Smart Grid applications running. For the sake of clear and comprehensive explanation, the architecture with TCP-UDP/IP communication profile from the DLMS/COSEM UA 
international standard is referred to, so as to elaborate the topic of the hour in truthful context.
The concept is well-known, a device with a cellar module connects to the target server(s) via cellular connectivity. Figure 5.17.1-1
shows how the utility-adopted DLMS/COSEM standard utilizes this concept.
Since the cellular connectivity is provided by an MNO, usually the DSO need to setup a dedicated VPN connection between its own RADIUS server and the MNO's RADIUS (as a proxy) to ensure the DSO's own RADIUS server will be responsible for the E2E authentication of the meters or the Smart Grid terminal devices. Figure 5.17.1-2
illustrates a typical situation, where a DSO called EDL has two separate subscriptions with two mobile operators for the many M2M devices they need to connect. The DSO manages its own RADIUS servers (RADIUS A and RADIUS B) in its own IT domain (e.g. own data centre or in a hosting environment), each RADIUS server has a secure tunnel to the peer RADIUS proxy in the corresponding MNO network (here namely the Operator A RADIUS and the Operator B RADIUS). The mechanism of a DSO's M2M system and the related RADIUS interaction is illustrated in Figure 5.17.1-3
For the target M2M applications based on the TCP-UDP/IP profile in DLMS/COSEM 
, and the actual existing M2M management platform widely adopted in DSO's utility M2M infrastructure, it is very important for the DSO to expect successful data connection fulfilling the application's communication needs, as agreed in the SLA. In reality, even the most recently known metering applications in the European Union is the 15-minutes reading cycle 
. That means, the successful meter reading as required by legislation is changing from once a month, to recently once a day and in the future once every 15 minutes. For a DSO's M2M head-end server, Smart Grid sector specifications have standardized wake-up mechanisms for the head-end server to contact the end devices for data retrieval, so that the data can be fetched within the service window determined by a specific business process. Realistically speaking, if the data must be available every 15 minutes, then the M2M service administrator has sufficient time (roughly a 15-minute window in this case) to trigger this wake-up process multiple times for retrieving the data. Another well-used resort has been that the DSO uses APIs of the MNO's SIM management platform to "reanimate"
the device back to the mobile network connectivity by means of mechanisms such as reattach and re-registration.
From the experience of some DSOs, it has happened that some M2M systems relying on 2G/3G connectivity did lose contact with the head-end server(s) for hours or even for days, and sometimes a wake-up push message manually sent from the head-end might also fail in getting the M2M device back online (w.r.t connectivity). Apparently, the most and foremost target of 5G is to focus on how to provide more reliable connectivity to the M2M devices, through enhancement of technology evolution, and introduce adequate quality assurance mechanisms to add to warranty. In respect of this, the 5G technology already introduces ground-breaking improvement in connectivity KPIs including reliability.
Equally important, as the industry-wide wake-up procedure goes, a service maintenance personnel of a DSO might look into their RADIUS server to check the session establishment status. This process has been in existence, ever since legacy cellular technologies were used. But this manual process has been labour-intensive and at times impractical for utility the personnel, who in general do not always have sufficient mobile telecom expertise to analyse the RADIUS call flows. Therefore, it makes sense for a 5G operator to inform the DSO in easy-to-comprehend terms of the following information on a per-M2M-device basis:
RADIUS session setup information
Device session status information
Device session setup success rate
Exposing these information during M2M service trouble-shooting can effectively improve the DSO's incident management process.
Certainly the M2M systems and applications will continue to proliferate in utility network. The reliance on 5G technology encourages the telecom providers to provide more relevant performance and events data to the DSOs. The genuine pursuit of a DSO is that by means of effective reporting the DSO obtains timely information and advice on maintaining resilient operation of their utility grid and services. This basically includes the following:
5G should introduce to an MNO means to keeping track of the offered connectivity's status, and to abiding by the factually contracted service KPIs (incl. availability) in the SLA;
5G should enable notifying a DSO in time the events related to MNO-planned maintenance (e.g. time period and impacted cell sites), for the DSO to timely adjust its service operation;
5G should enable reporting to a DSO the forecasted performance degradation over a specific geographic area (e.g. a cell sector, a cell or a group of cells).
Pieter-Jansen is the M2M service administrator at UT. Every day his primary job is to monitor the service status of the applications underpinning the M2M service. Pieter-Jansen uses the GUI to check application status, and whether the M2M data has arrived in the head-end systems before the service window closes (e.g. new data should arrive in the system from an M2M device every 15 minutes). This is normally the case, and Pieter-Jansen could spend time learning UT's business processes related to this M2M service.
One morning while Pieter-Jansen arrives at work, eager as he always is he logs in the service manager portal to take a quick glance of the M2M service status collected last night. Frowning, Pieter-Jansen notices the GUI of the head-end system alerts missing data from a particular M2M device --- data missing for several continuous service cycles (e.g. 120 data points missing in the past 8 hour). Pieter-Jansen has the admin login credential to UT's RADIUS server, however, Pieter-Jansen is not specialized in telecom and has not gained experience in the corresponding IEEE protocols. His supervisor, one of the very few personnel at UT who understands both electricity and telecom was unfortunately under the weather and had called in sick. Pieter-Jansen therefore switches to the GUI that visualizes RADIUS session status in the historian with the data received from TEL's RADIUS servers. The data from TEL is translated in layman's terms, hence Pieter-Jansen easily understands that the authentication process of this M2M device has failed due to wrong credentials.
Pieter-Jansen goes on to check the logbook whether any recent changes have been introduced in UT's M2M system. He realized for this particular M2M device, the corresponding credential at the RADIUS server has been updated by the administrator of the RADIUS server at UT. Hence Pieter-Jansen calls that personnel to revert the credential. This M2M device soon comes back on the network and resumes to deliver data to the M2M head-end server.
Time goes on, summer holiday arrives and lots of people are leaving for the passionate south. TEL usually plans network maintenance services during this period. However, since TEL and UT have an SLA in the contract, TEL informs UT of the network activity and the perceived interruption of mobile service.
UT checks that the service interruption is within the availability window of the telecom service, and UT can timely inform the customers when the M2M service is expected to be unavailable. This process is agreed beforehand and is conformant with the grid code of the country where UT operates.
Therefore, UT confirms with TEL the acceptance of the period for the planned network maintenance to be carried out by TEL.
UT fulfils its role as public sector service provider conforming the national norm. TEL provides 5G service that fits UT's actual needs with minimal burden on the customer side.
UT is able to provide to their customers the M2M services both during incidents and over time.
TS 22.261 Table 7.5.2-1
captures performance requirements for high availability IoT traffic.
Under normal conditions, 5G service performance KPIs regarding bandwidth, delay, jitter, and availability are sufficient for utility M2M applications.
5G system can provide periodic performance reporting, the corresponding report interval can be configured by the application layer.
TS 22.261, clause 126.96.36.199
TS 22.261, clause 6.23.2
The 5G system shall support means by which the operator can differentiate policy control, functionality and performance provided in different network slices. Therefore, the M2M service performance KPIs could be provided by means of network slicing.
The 5G system shall provide a mechanism for supporting real time E2E QoS monitoring within a system.
The 5G network shall provide an interface to application for QoS monitoring (e.g. to initiate QoS monitoring, request QoS parameters, events, logging information).
The 5G system shall be able to log the history of the communication events. This includes for examples parts of the SLA that are not met, time-stamp of the events, and event position (e.g. UEs and radio access points associated with the events).
The 5G system shall support different levels of granularity for QoS monitoring (e.g. per flow or set of flows).
The 5G system shall be able to provide event notification upon detecting error that the negotiated QoS level cannot be met/guaranteed.
The 5G system shall be able to provide information that identifies the type and the location of a communication error. (e.g. cell id).
The 5G system shall be able to provide notification of communication events to authorized entities per pre-defined patterns (e.g. every time the bandwidth drops below a pre-defined threshold for QoS parameters the authorized entity is notified and event is logged).
The 5G system shall be able to respond to a request from an authorized entity to provide real-time QoS monitoring information within a specified time after receiving the request (e.g. within 5s).
The 5G system shall be able to provide statistical information of service parameters and error types while a communication service is in operation.
The 5G system shall provide information on the current availability of a specific communication service in a particular area (e.g. cell id) upon request of an authorized entity.
Based on MNO policy, the 5G network shall provide suitable means to expose to a trusted third party the communication network performance parameters
Based on MNO policy, the 5G network shall provide suitable means to proactively inform a trusted third party of possible events that could interrupt or cause performance degradation of the 5G service over a specific geographic area (e.g. a cell sector, a cell or a group of cells).