Internet DRAFT - draft-geng-iiot-edge-computing-problem-statement
draft-geng-iiot-edge-computing-problem-statement
T2TRG L. Geng
Internet-Draft China Mobile
Intended status: Standards Track M. Zhang
Expires: September 6, 2018 M. McBride
B. Liu
Huawei
March 5, 2018
Problem Statement of Edge Computing on Premises for Industrial IoT
draft-geng-iiot-edge-computing-problem-statement-01
Abstract
This document introduces the concept of Beyond Edge Computing (BEC)
which brings edge computing capabilities down to the level of
customers' premises for industrial IoT use cases. The purpose of the
document is to discuss the general problem statement of BEC including
capabilities, and use cases. Potential technical gaps in IETF
problem scope that are related to BEC are also evaluated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Geng, et al. Expires September 6, 2018 [Page 1]
Internet-Draft IIoT Edge Computing March 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Concept and Capabilities of Beyond Edge Computing . . . . 3
2.1. Heterogeneous IoT Device Compatibility . . . . . . . . . 4
2.2. Deterministic Networking . . . . . . . . . . . . . . . . 5
2.3. Management of Massive Amount of Devices . . . . . . . . . 5
2.4. Support of Network Slicing . . . . . . . . . . . . . . . 5
2.5. Multi-ecosystem Environment . . . . . . . . . . . . . . . 5
3. Reference Architecture . . . . . . . . . . . . . . . . . . . 5
4. Use Cases of BEC . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Edge computing is an important network architecture particularly in
the support of Industrial verticals such as Energy, Manufacturing,
Healthcare, Mining and Smart City/Buildings. Edge computing will
provide local compute, storage and connectivity services particularly
for latency and bandwidth sensitive applications. There are several
organizations which are working on edge computing definition and
architecture with various emphases. For instance, ETSI MEC
(previously mobile edge computing and now multi-access edge
computing) looks at edge computing from the perspective of the edge
of the provider network. It also has an successive convention of
focusing on cellular network requirements. The Industrial Internet
Consortium (IIC) and Edge Computing Consortium (ECC) works on edge
computing in a more general view of industrial IoT, where edge
computing nodes are even closer to verticals (i.e. the very first
hops where the service is connected to the network). Typically, the
edge computing nodes are located at customers' premises. However,
IIC and ECC are not standard organizations and they rely on
communities such as IETF to provide protocols and API definitions for
their architectural use especially as Operation Technology (OT),
Information Technology (IT) and Communication Technology (CT)
converge.
Geng, et al. Expires September 6, 2018 [Page 2]
Internet-Draft IIoT Edge Computing March 2018
Edge computing concepts have been presented in various groups within
the IETF/IRTF. The edge computing topic, similar to cloud computing,
is much too broad to tackle within the IETF. There are specific
protocol/interface areas, however, that can be worked on in the IETF
once we identify a specific area of focus. BEC is one of the
specific area which looks at edge computing from the industrial
verticals such as factory, hospital, power and city/ building
perspective and down to the level of local edge support for sensors,
engines, pumps and machinery.
A simple example, of BEC, is factory equipment having connected
sensors which are generating data and sending to the equipment within
an edge computing environment. One sensor, connected to this
equipment, could generate an event, such as overheating, and an
connected actuator could quickly increase fan span or reduce engine
speed depending upon the data within the local edge computing node.
This type of event is being controlled today within closed industrial
command and control protocols. But what is not generally available
is the ability for open edge computing equipment to generate
predictive maintenance and command and control across factories,
verticals and into the cloud. This is where we see a gap in
standards definitions and an opportunity for new protocols and
interfaces, in which IETF could play a particularly important role.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
o BEC - Beyond Edge Computing, a concept of on-premises edge
computing where the devices deployed directly at customers'
premise are worked on.
2. The Concept and Capabilities of Beyond Edge Computing
Beyond Edge Computing (BEC) looks at the on-site intelligent
evolution of industrial verticals. It brings the edge computing
capability down to the level of customer premises, which are typical
beyond the access network of a service provider.
Geng, et al. Expires September 6, 2018 [Page 3]
Internet-Draft IIoT Edge Computing March 2018
+-------------------------------+
| Core Data Center |
+-------------------------------+
*** Backbone
* * Network
***
+-------------------------------+
| Regional Data Center |
+-------------------------------+
*** Metropolitan
* * Network
***
+-------------------------------+
| Local Data Center/Access Point|
+-------------------------------+
*** Access ***
* * Network * *
*** ***
+-----------+ +-----------+
| Beyond | | Beyond |
| Edge | | Edge |
| Computing | | Computing |
+-----------+ +-----------+
Figure 1: Beyond Edge Computing in the Network
Figure 1 illustrates the schematic diagram of BEC in terms of its
position in a overall network. BEC takes care of the first hop where
the service of a particular industrial vertical connects to the
network. It can be regarded as an extended intelligent connectivity
capability of a service provider's network to industrial verticals.
Meanwhile, it also expands the cloud computing ability directly to
customers' sites.
2.1. Heterogeneous IoT Device Compatibility
Vertical industries have various interfaces for on-premises LAN and
WAN. This include both wireless and fixed line systems. Taking the
field bus as an example, 10 different specification are defined in
IEC61158, which is only a small portion of the existing field bus
technologies people can actually find in real world. BEC should
provide the capability of protocol translation and mapping, which
enables the inter-operation between different systems.
Geng, et al. Expires September 6, 2018 [Page 4]
Internet-Draft IIoT Edge Computing March 2018
2.2. Deterministic Networking
One of the most important motivation of BEC is to reduce the
propagation latency by the deployment of services most closer to
users. However, the processing and scheduling latency cannot
directly benefit from closer deployment. Especially as the end-to-
end propagation latency for a edge service has been reduced to less
than 1 ms, processing and scheduling latency became even more
essential. At the same time, emerging services including AR/VR,
Remote robot system and motion control rely on not only low but also
a strictly deterministic latency. Real-time operation system will be
a preferred choice for BEC. Additionally, high-precision time
synchronization and packet preemption are also significant
characteristics for deterministic network in BEC system.
2.3. Management of Massive Amount of Devices
It is expected the hundreds of millions of BEC nodes will be deployed
in industrial internet scenario, typically in a form of gateway.
Management is the key to provide reliable and flexible edge services
using BEC nodes. It is preferred to have unified interface to
realize both device-level and resource-level management of BEC nodes.
2.4. Support of Network Slicing
An important benefit of BEC is the capability of edge service
deployment. Based on light-weight distributed NFV technologies, the
resource on BEC nodes can be dedicated for particular application.
At the same time, the packet of a certain edge service can be labeld
and steered to the preferred network slice at the WAN side, creating
a true end-to-end network slice for industrial verticals.
2.5. Multi-ecosystem Environment
It is preferred to have a unified set of APIs, which achieve a deep-
level capability exposure of the BEC nodes. The functions can be
exposed to the upper layer applications in terms of forwarding,
address, management and physical interface functionalities.
3. Reference Architecture
Geng, et al. Expires September 6, 2018 [Page 5]
Internet-Draft IIoT Edge Computing March 2018
+--------------------------------+
| BEC Management Platform |
| |
| +----------------------------+ | +-------------+
| | Application Management | | | |
| +----------------------------+ | | IoT |
| +------------+ +------------+ | | Cloud |
| | Device | | Resource | | | Services |
| | Management | | Management | | | |
| +------------+ +------------+ | | |
| +----------------------------+ | | |
| | SDN Platform | | +----+--------+
| +----------------------------+ | |
+--------------------------------+ |
| Management |Data
| Channel |Channel
+----------------------------------------------------+
| +-------------v-------------------+ | |
| | Management Data Model | | |
| +---+-------+-------+---------+---+ | |
| | | | | | |
| | | | | | |
| | | | +------------------+ |
| | | | | +---------+ | |
| | | | | | APP | | |
| | | | | +---------+ | |
| | | | |Container/VM | |
| | | | +------------------+ |
| | | +-v----------------------------+ |
| | | | Virtualization Layer | |
| | | +------------------------------+ |
| | +-----v------------------------------------+ |
| | | API Exposure | |
| | +------------------------------------------+ |
| +---v--------------------------------------------+ |
| | Linux Kernel | |
| +------------------------------------------------+ |
| Ethernet Bluetooth PLC RF RS485 |
| WiFI FXS DI/DO RS232 |
+----------------------------------------------------+
Figure 2: The Reference Architecture of Beyond Edge Compuring
Figure 2 demonstrates the reference architecture of BEC system with a
managed BEC node and a cloud-based management platform. An IoT
Geng, et al. Expires September 6, 2018 [Page 6]
Internet-Draft IIoT Edge Computing March 2018
gateway is the typical form of a BEC node device. Gateways always
play important role in the Cloud-Edge architecture since they are the
most popular devices where verticals are provided with various
capabilities such as computing, storage and networking. In addition,
applications for various vertical customers are developed by
themselves or third-party while deployed on demand. Giving the edge
computing ability of BEC, much of the data can be processed by
applications running on the gateway locally as required by vertical
customers. The gateways are commonly versatile protocol speakers so
that devices speaking different protocols can communicate with the
them. The East-West connectivity between BEC nodes might be enabled
by various protocols such as OPC-UA, MQTT, TSN and other
deterministic Ethernet protocols, for example EtherCat, Ethernet/IP,
Profinet. To facilitate the operation of the BEC system, a central
controller in the cloud is provisioned to the customer. It mainly
supervise the device, virtulization resource and application life
cycle of the BEC node.
The key requirements of BEC are in providing distribution service
entities on the customers site (end AP, devices) to meet the growing
demand for low latency, reliable, and secure vertical industries.
The Computing, Storage, I/O isolation are remotely managed at the
edge to provide certain dedication and quality guarantees. Agile,
flexible and scalable deployment of services from operator/third
party down to the edge through software entities (VM/ Containers). A
light weight MANO like approach is needed to provide resource
provisioning and VNF deployment. A unified API definition is needed
to support the co- existence of multi-ecosystem at the BEC node. And
there needs to be the ability for the edge device to map specific
service requirements with an end to end network slice with certain
guarantees and pass the policy identification along the path to the
centralized DC.
4. Use Cases of BEC
1. Elevator Networks
Description: There are more than 15 million elevators around the
world and the daily maintenance of these elevators costs elevator
operators a large amount of revenue. An elevator usually carries
hundreds of sensors which are generating a large amount of data to be
uploaded to the cloud. The BEC nodes can preprosess the data
gathered from elevator sensors so that the volume to be uploaded to
the Cloud is greatly reduced. Based on the input from elevator
sensors, AI programs installed on BEC nodes may locally make
decisions without the intervention of the Cloud. For example, when
the noise or vibration of an elevator exceeds a certain level, the
Geng, et al. Expires September 6, 2018 [Page 7]
Internet-Draft IIoT Edge Computing March 2018
BEC node may notify elevator maintainers to reach this elevator and
perform maintanence or repair.
Goal: BEC nodes are deployed into elevators to gather/preprocess/
compress the data to save the communication cost. Based on the data
gathered from elevator sensors, BEC nodes can assist operators to do
predictive maintenance.
Requirements: Customized gateways operated by elevator providers. An
open platform with VMs/containers which can hold customized Apps.
These Apps are managed by elevator operators while developed by
gateway vendors or any other third parties. Various connectivities
are supported (2G/3G/LTE/eMTC/Ethernet) by BEC nodes. A central
controller to perform configuration and management of the network.
AI models are trained on the Cloud while the reasoning of these AI
models are performed at the Edge.
2. Intelligent Street Lights
Description: BEC nodes are placed on street lights to act as board
routers of LLNs. BEC nodes may act as RSUs of vehicle networks.
With AI programs installed on the BEC nodes, reasoning and decisions
might be made locally at the edge. For example, For example, BEC
nodes can adjust the lights' brightness and operating hours according
to environment parameters, providing illumination when needed while
reducing power consumption. With sensors on trash cans, BEC nodes
are aware whether a trash can is full. Trash collecting cars can
communicate with the BEC nodes to determine whether to reach a trash
can to collect the trash.
Goal: BEC nodes gather data from sensors which are used to monitor
various information (e.g., brightness, temperature, humidity) of a
district.
Requirements: BEC nodes SHOULD support ROLL [RFC] in order to join
the LLN as a board router. Various wired/wireless communication
protocols such as Radio Frequency (RF) protocols (e.g., Zigbee, WI-
SUN) and Power Line Communication (PLC) should be supported. The BEC
nodes can use 2G/3G/LTE/Ethernet to communicate with the Cloud.
3. Smart Manufacturing
Description: BEC nodes join the industiral manufacturing network and
provide the networking function. Control messages that requires
deterministic latency will be carried on this network. BEC nodes
need to support deteministic networking protocols such IEEE Time
Sensitive Networking (TSN), Profinet, Ethernet/IP, EtherCat, etc.
Geng, et al. Expires September 6, 2018 [Page 8]
Internet-Draft IIoT Edge Computing March 2018
The gateway can also help monitor the equipments' status, and send
out alarms or warnings when malfunction is detected or predicted.
Goal: Edge computing enables interconnection of deterministic
networks.
Requirements: BEC nodes should support industrial machine-to-machine
message bus connectivity protocols such as OPC-UA, DDS, MQTT. The
network may be configured by a central controller using Netconf/YANG.
BEC nodes should support the interconnection of heterogeneous
deterministic Ethernet protocols.
4. Smart grid
Description: BEC nodes can be deployed in three scenarios of the
smart grid. In advanced metering infrastructure (AMI), besides the
routing function, it can also act as a concentrator to collect and
aggregate the meters' data. It can also provide primary analysis to
detect theft and outage. Firewall function can be deployed at the
gateway to deal with attacks from the edge. In distribution
automation (DA), BEC nodes provide bounded latency connection between
controller and actuators such as switches and transformers. Edge
computing applications can be implemented on these devices to monitor
the status and react rapidly to faults. In terms of microgrid, the
BEC node monitors the local power generation and storage, and helps
smoothly integrate the energy generated by photovoltaic panels and
wind turbines, whose power is very unstable, into the macro grid.
Goal: In AMI, the BEC node works as a router, firewall and
concentrator, providing data preprocess services. In DA, BEC node
enables the deterministic connection between controllers and
actuators. In microgrid, BEC node is the coordinator between
distributed and centralized generation.
Requirements: The gateway should support various wired/wireless
communication protocols, such as Power Line Communication (PLC),
Radio Frequency (RF), NB-IOT and 2G/3G/LTE. Bounded latency is
required in automation use cases. Open platforms are needed to
accommodate various applicaitons providing data analysis, fault
detection and automation control capabilities.
5. IANA Considerations
N/A
Geng, et al. Expires September 6, 2018 [Page 9]
Internet-Draft IIoT Edge Computing March 2018
6. Security Considerations
Security considerations will be a critical component of IIoT edge
computing particularly as intelligence is moved to the extreme edge.
7. Acknowledgement
The authors would like to thank Sami Kekki for his feedback on this
draft.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Mingui (Martin) Zhang
Huawei
Email: zhangmingui@huawei.com
Mike McBride
Huawei
Email: michael.mcbride@huawei.com
Bing Liu
Huawei
Email: remy.liubing@huawei.com
Geng, et al. Expires September 6, 2018 [Page 10]
