Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

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.10  Utility End to End Securityp. 45

5.10.1  Descriptionp. 45

In some networks, communication is done in different security domains.
Copy of original 3GPP image for 3GPP TS 22.867, Fig. 5.10.1-1: Different Security Domains
Figure 5.10.1-1: Different Security Domains
(⇒ copy of original 3GPP image)
Up
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.
Up

5.10.2  Pre-conditionsp. 45

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'.
Up

5.10.3  Service Flowsp. 46

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.
Copy of original 3GPP image for 3GPP TS 22.867, Fig. 5.10.3-1: Different Security Domains
Figure 5.10.3-1: Different Security Domains
(⇒ copy of original 3GPP image)
Up
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.

5.10.4  Post-conditionsp. 46

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.

5.10.5  Existing features partly or fully covering the use case functionalityp. 46

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:
The 5G system shall support operator controlled alternative authentication methods (i.e. alternative to AKA) with different types of credentials for network access for IoT devices in isolated deployment scenarios (e.g. for industrial automation).
The 5G network shall support a 3GPP supported mechanism to authenticate legacy non-3GPP devices for 5G LAN-VN access.
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:
The 5G system shall support a suitable framework (e.g. EAP) allowing alternative (e.g. to AKA) authentication methods with non-3GPP identities and credentials to be used for UE network access authentication in non-public networks.
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:
The 3GPP authentication infrastructure, including the 3GPP Authentication Centre (AuC), the USIM or the ISIM, and the 3GPP AKA protocol run between them, is a very valuable asset of 3GPP operators. It has been recognised that this infrastructure could be leveraged to enable application functions in the network and on the user side to establish shared keys.
Up

5.10.6  Potential New Requirements needed to support the use casep. 47

[PR.5.10-001]
The 5G system shall enable support of a mechanism to support authentication and secured communication between the 5G system Core Network and a 3rd party's application function, in order to provide secure end to end communication service.

5.11  QoS Monitoring and Reporting Mechanismsp. 47

5.11.1  Descriptionp. 47

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.
Up

5.11.2  Pre-conditionsp. 47

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.
Up

5.11.3  Service Flowsp. 48

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.
Up

5.11.4  Post-conditionsp. 48

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.
Up

5.11.5  Existing features partly or fully covering the use case functionalityp. 48

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

5.11.6  Potential New Requirements needed to support the use casep. 48

[PR.5.11-001]
The 5G system shall provide a mechanism for a 3rd party to report to a MNO service degradations, communications loss and sustained connection loss. These reports use a standard form. The specific values, thresholds and conditions upon which alarms occur could include e.g. the measured values for Latency, Data Rate, Availability, Jitter, etc. for a UE, its location, and the time(s) in which the degradation occurred.
[PR.5.11-002]
The 5G system shall provide a mechanism for a MNO to report to 3rd parties service degradations, communications loss and sustained connection loss. These reports use a standard form. The specific values, thresholds and conditions upon which alarms occur could include e.g. the measured values for Latency, Data Rate, Availability, Jitter, etc. for a UE, its location, and the time(s) in which the degradation occurred.
Up

Up   Top   ToC