Content for  TR 22.867  Word version:  18.2.0

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 [46] 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 [47], 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 [48]. 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).

1. A DSO "UT" has a service contract with an MNO "TEL" for supporting its M2M services. In the service contract, UT and TEL have agreed on the SLA covering many aspects including the following:
   • Justification of business needs
   • Business process already in place on UT (the customer side)
   • Desired outcome of the connectivity service in terms of e.g. availability, reliability, performances, etc.
   • The classification of incidents (w.r.t. urgency etc.), and per classification the required response time, MTTR, and relevant information exposure if specifically requested.
2. UT has its ITIL process in place, of which the incident management process is expected to speed up incident resolution while minimizing operational and customer impact, in an efficient and cost-effective manner.
3. For event reporting and management related information exchange, UT and TEL have invested in setting up the infrastructure, which includes a secured highly-reliable BW-abundant OOB transport tunnel, secure interfaces (incl. layers across physical, VPN, APIs), and paid and governed by UT a special data collection and storage infrastructure (data centre or in the cloud) scaled properly to contain and store the exposed data from TEL, etc. UT is obliged by the CTO and the CFO to carefully consider the cost of such infrastructure.
4. M2M system of UT is up-and-running on 5G. The procured 5G service with provisioned availability provides reliable connectivity with sufficient performance to the M2M application.

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. Clause 6.1.2.2 of TS 22.261: Clause 6.23.2 of TS 22.261:

[PR.5.17-001] [PR.5.17-002]