IIoT                                                             L. Geng
Internet-Draft                                              China Mobile
Intended status: Standards Track                                M. Zhang
Expires: May 3, 2018                                          M. McBride
                                                                  B. Liu
                                                                  Huawei
                                                        October 30, 2017


Problem Statement of Edge Computing beyond Access Network for Industrial
                                  IoT
          draft-geng-iiot-edge-computing-problem-statement-00

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 May 3, 2018.

Copyright Notice

   Copyright (c) 2017 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



Geng, et al.               Expires May 3, 2018                  [Page 1]


Internet-Draft             IIoT Edge Computing              October 2017


   carefully, as they describe your rights and restrictions with respect
   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.  Relationship between BEC and and Cloud Computing  . . . .   5
   3.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   5
   4.  Use Cases of BEC  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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

   Edge computing concepts have been presented in various groups within
   the IETF/IRTF.  The edge computing topic, similar to cloud computing,



Geng, et al.               Expires May 3, 2018                  [Page 2]


Internet-Draft             IIoT Edge Computing              October 2017


   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 a
   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 [RFC2119].

1.2.  Terminology

   o  BEC - Beyond Edge Computing, a concept of edge computing where the
      edge computing devices are deployed directly at customers'
      premises so that beyond the access network of a service provider.

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 computing
   capability down to the level of customer premises where devices are
   managed by customers therefore typically beyond the reach of access
   network of a service provider.










Geng, et al.               Expires May 3, 2018                  [Page 3]


Internet-Draft             IIoT Edge Computing              October 2017


                     +-------------------------------+
                     |   Core Data Center            |
                     +-------------------------------+
                              ***   Backbone
                             *   *  Network
                              ***
                     +-------------------------------+
                     |   Regional Data Center        |
                     +-------------------------------+
                              ***   Metropolitan
                             *   *  Network
                              ***
                     +-------------------------------+
                     | Local Data Center/Access Point|
                     +-------------------------------+
                              ***   Access
                             *   *  Network
                              ***
                     +-------------------------------+
                     |   Beyond Edge Computing       |
                     +-------------------------------+


              Figure 1: Beyond Edge Computing in the Network

   Figure 1 illustrates the schematic diagram of BEC in terms of its
   position in an 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.

   BEC has the following capabilities.

   1.  Heterogeneous IoT device compatibility

   2.  Extremely low and deterministic service latency

   3.  Local data pre-processing and offloading

   4.  Isolation of system resources

   5.  Offline process

   6.  End-to-end security

   7.  Distributed artificial intelligence



Geng, et al.               Expires May 3, 2018                  [Page 4]


Internet-Draft             IIoT Edge Computing              October 2017


   8.  Real-time operation

   9.  Unified API for multi-ecosystem edge application

   10.  Service isolation for network slicing

2.1.  Relationship between BEC and and Cloud Computing

   BEC is different from Cloud Computing in the following perspectives.

   o Edge is closer to things than the Cloud, it's feasible to meet the
   high reliability, bounded latency or real-time requirements of
   verticals such AR/VR, automatic driving and smart manufacturing.  For
   Cloud Computing, the latency is regarded as a performance index.  As
   for Edge Computing, bounded latency is often a mandatory requirement.

   o Data can be stored at the Edge which are under the control of end
   users so that user's privacy can be preserved.  Video surveillance,
   Healthcare are typical use case scenarios for this perspective.

   o Raw data can be preprocessed at the edge while only critical
   information is uploaded to the Cloud.  In this way, Edge Computing
   promises lower communication cost than the traditional Cloud-only
   architecture.

   o The resources for Cloud Computing can be elastically allocated
   thanks to virtualization and resource pooling.  Virtualization
   provides certain reliability to Cloud Computing.  In comparison, the
   resources are normally constrained for Edge Computing.  Reliability
   is sometimes realized through the redundant placement of physical
   edge devices.

   o The hardware and software of Cloud Computing are normally
   standardized.  Devices and software being used in Edge Computing can
   be quite different considering various verticals are adopting Edge
   Computing.

3.  Reference Architecture













Geng, et al.               Expires May 3, 2018                  [Page 5]


Internet-Draft             IIoT Edge Computing              October 2017


          +--------------------------------+
          |     BEC Management Platform    |
          |                                |
          | +----------------------------+ |   +-------------+
          | |     Application Management | |   |             |
          | +----------------------------+ |   | IoT         |
          | +------------+  +------------+ |   | Cloud       |
          | | Device     |  | Resource   | |   | Services    |
          | | Management |  | Management | |   |             |
          | +------------+  +------------+ |   |             |
          | +----------------------------+ |   |             |
          | |   SDN Platform             | |   +----+--------+
          | +----------------------------+ |        |
          +--------------------------------+        |
                          | Management              |Data
                          | Channel                 |Channel
          +----------------------------------------------------+
          | +-------------v-------------------+     BEC node   |
          | |   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 Computing

   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 May 3, 2018                  [Page 6]


Internet-Draft             IIoT Edge Computing              October 2017


   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 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 supervises 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 preprocess 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 May 3, 2018                  [Page 7]


Internet-Draft             IIoT Edge Computing              October 2017


   BEC node may notify elevator maintainers to reach this elevator and
   perform maintenance 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.  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, 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 industrial manufacturing network and
   provide the networking function.  Control messages that requires
   deterministic latency will be carried on this network.  BEC nodes
   need to support deterministic networking protocols such IEEE Time
   Sensitive Networking (TSN), Profinet, Ethernet/IP, EtherCat, etc.




Geng, et al.               Expires May 3, 2018                  [Page 8]


Internet-Draft             IIoT Edge Computing              October 2017


   The gateway can also help monitor the equipment's 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, a BEC node 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 micro grid, 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 micro grid, 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 applications providing data analysis, fault
   detection and automation control capabilities.

5.  Gap Analysis

   1.  Multiple Virtualization Technologies Coexistence/Coordination:

   Different virtualization technologies needed to meet the various
   vertical requirements.  Coexistence and resource coordination is



Geng, et al.               Expires May 3, 2018                  [Page 9]


Internet-Draft             IIoT Edge Computing              October 2017


   needed.  The focus is on the edge where different types of ASICs are
   found which require more input on selection.

   2.  Light weight Device-level management and virtual resource
   management:

   Netconf/YANG to be considered as a baseline interface solution.
   Information and data modelling will need to be defined.

   3.  Framework and API for multi-ecosystem:

   BEC framework for life cycle management.  Unified API definition
   between framework and app including Local networking, Computing,
   Storage, OAM, UNI IO management and event-message management.

   4.  Runtime Updates

   BEC nodes are commonly deployed to run for a long periods of time
   without downtime.  Even during the update of configuration, software
   or firmware, the BEC nodes are required to serve the network with no
   interruption.  For mesh-based networks, there might be some devices
   which are in sleeping mode.  IP multicast protocols are not
   applicable here [draft-iab-iotsu-workshop-00].  Multicast Protocol
   for Low-Power and Lossy Networks (MPL) [RFC7731] should be used.

6.  IANA Considerations

   N/A

7.  Security Considerations

   Security considerations will be a critical component of IIoT edge
   computing particularly as intelligence is moved to the extreme edge.

8.  Acknowledgement

   The authors would like to thank Sami Kekki for his feedback on this
   draft.

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






Geng, et al.               Expires May 3, 2018                 [Page 10]


Internet-Draft             IIoT Edge Computing              October 2017


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 May 3, 2018                 [Page 11]