Content for  TR 22.867  Word version:  18.2.0

In some networks, communication is done in different security domains.

There are three domains depicted above. One is in the premises with the devices at the edge of the utility network, e.g. sensors. The second domain is the 3GPP network. The third is the service network. This scenario, to secure communication, requires application communication above the network layer (e.g. TLS or another transport layer security mechanism, S/MIME or another presentation layer security mechanism or encryption at the application layer.) The situation becomes even more complex if there are multiple applications, different networks used at the edge and different communications systems used for the end to end service. In this use case, integration of communication end to end with the 5G system presents benefits to end to end service delivery.

A gateway (UE and router) provides 5GLAN service from a Distribution Service Operator (DSO), EnergyCo to 1000s of sites (e.g. substations) in which there is diverse communication-enabled equipment. This set of devices is provisioned with security configuration sufficient for authorization and registration with the 5G system. Specifically, the devices are equipped with USIMs or, in NPNs, with non-3GPP credentials, to allow for the network operator to perform Authentication, Authorization and Accounting (AAA.) The service platform of EnergyCo is also has sufficient configuration to obtain services with the 5G system from a 'northbound interface'.

EnergyCo's equipment (e.g. sensors, remote controllable devices, etc.) within the premises of 1000s of substations uses its configuration authorize access to the UE/Gateway, which provides access to the 5G System for communication services. One such device sends an alert message to EnergyCo's service platform.

The communication between the device and the Router/UE is secured with respect to the constraints acceptable to EnergyCo. The communication through the 5G system employs 5G security, which provides secure communication to the service levels expected by EnergyCo. Finally, a secure session can be provided using credentials between the Service Platform and the 3GPP system - whose edge is depicted as a gateway (GW), if network layer security services are required by EnergyCo.

The EnergyCo equipment to Service platform communication is secured end-to-end in a uniform manner for all their equipment, meeting EnergyCo's security requirements.

There are several ways that the existing 5G system could support this use case. First, by means of alternative authentication methods between the equipment and the UE. The ' uniformity' in this case would rely upon establishing the same configuration and operation regime in the equipment and UE/Router in all installations. Clause 8.3 of TS 22.261 v17.3.0: While this may suffice to secure the Equipment to UE/Router communication, it is not significantly different than the scenario described in clause 5.10.1. There is no 'end-to-end' support in this scenario, unless a security association is established between the equipment and the service platform (by means outside of the scope of 3GPP, i.e. over the top.) Second, the equipment could establish a security association with the 5G system (not just with the router.) Clause 8.3 of TS 22.261 v17.3.0: In this approach, assuming the EAP framework chosen afforded sufficient security protections for the non-public network, the communication from the equipment to the Router/UE and through the 5G System would be in the same security domain. A gap (described below in clause 5.10.6) is the communication between the 5G System and the EnergyCo service platform, which is currently not defined in the 5G standard. Third, the equipment in the EnergyCo network could be provided with sufficient credentials (including a USIM) to fully become authorized with the 5G System. In this case, end to end security is possible by means of the GAA framework. Clause 4 of TS 33.220 v16.2.0:

[PR.5.10-001]

This use case explores in more detail an aspect of service level management that is the business relationship between an energy utility operator, "EnergyCo" and the telecommunications operator, "Telecomm1". While their business relationship itself is out of scope of 3GPP standardization, there are aspects of the SLA, specifically agreements for achieving and monitoring performance and satisfaction of KPIs, and managing incidents improve the suitability of Telecomm1's service offerings for EnergyCo.

The different services offered by Telecomm1 should behave as expected according to the KPIs defined in the Table 5.5.5-1. Only if that is the case, is service delivery acceptable according to the SLA, to meet the different services' requirements (whether mission critical or not.) If the telecommunication service degrades below these KPIs, EnergyCo may experience a service interruption or degradation. This might affect mission critical operations and/or quality of service delivered ultimately to the customer. The granularity of the use case considers the support of QoS to a particular UE, per class of service. This is the model described in clause 5.5. Here the UE is a gateway serving as a router to a network: the UE is essentially a router with a mobile telecommunication interface for communication beyond the local network. Smart energy applications are not generally running on the UE - they are deployed in the network behind the UE. See Figure 5.5.3-1. This use case assumes that the SLA is in place and service is offered by Telecomm1 to EnergyCo. In addition, both interfaces and procedures are in place to respond to failures to deliver KPIs according to the SLA.

For the KPIs, part of SLA definition between EnergyCo and Telecomm1, there is a report sent by EnergyCo to Telecomm1 on a monthly basis in order to inform of the degree of compliance of the requirements set in the SLA for the different KPIs. Telecomm1 will reconcile this report with their own records. KPIs will be measured by means of EnergyCo owned Network Management platforms in real time. These platforms will check periodically the availability, latency and packet loss rate of the connection. Different periodicities can be configured and as a result average information will be obtained. Reports are available in order to deliver accumulated information of the different parameters on a daily, weekly, monthly or yearly basis. This information will be checked in order to verify the degree of compliance of the SLA. Connectivity status, stability and Performance will be part the technology reports. Only Latency and Packet loss rate will be constantly measured as a part of Performance parameters, Throughput will only be measured during commissioning process. If there is a problem such as quality of service degradation (high latency and packet loss rate below thresholds) or instability of the connection affecting a specific substation or group of substations (connected to the same server) for more than one week an automatic alarm will be generated towards the MNO. In the event of massive communication loss affecting most services and substations (quantity above % threshold), this will be detected in real time and an automatic alarm will be sent to the MNO. In the event of sustained connection loss events affecting a number of Substations located within a well limited geographical area this might shed light on a problem related to a specific eNB site or sector. An automatic alarm will be generated and sent to the MNO.

Since EnergyCo provides Telecomm1 with their report of service degradations, and Telecomm1 provides their report to EnergyCo, both organizations have a full set of records with respect to achieved performance of service according to KPIs in the SLA. It is possible for EnergyCo and Telecomm1 to reconcile the SLA and the achieved performance at any time. Further, EnergyCo is able to alert Telecomm1 when critical events occur that affect performance in a manner that requires intervention (or at least scrutiny) by the MNO. Finally, Telecomm1 can alert EnergyCo to issues they have detected. This explains why regular periodic QoS reporting needs to be shared from the customer to the provider and vice versa.

No existing features have been identified that partially or fully cover the use case functionality.

[PR.5.11-001] [PR.5.11-002]