<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes" ?>
<rfc category="std"
     docName="draft-geng-iiot-edge-computing-problem-statement-01"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="IIoT Edge Computing">Problem Statement of Edge Computing on
    Premises for Industrial IoT</title>

    <author fullname="Liang Geng" initials="L" surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Mingui (Martin) Zhang" initials="M" surname="Zhang">
      <organization>Huawei</organization>

      <address>
        <email>zhangmingui@huawei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Huawei</organization>

      <address>
        <email>michael.mcbride@huawei.com</email>
      </address>
    </author>

    <author fullname="Bing Liu" initials="B" surname="Liu">
      <organization>Huawei</organization>

      <address>
        <email>remy.liubing@huawei.com</email>
      </address>
    </author>

    <date day="5" month="March" year="2018"/>

    <workgroup>T2TRG</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section title="Introduction">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <section anchor="requirements-language" title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>

      <section anchor="terminology" title="Terminology">
        <t><list style="symbols">
            <t>BEC - Beyond Edge Computing, a concept of on-premises edge
            computing where the devices deployed directly at customers'
            premise are worked on.</t>
          </list></t>
      </section>
    </section>

    <section title="The Concept and Capabilities of Beyond Edge Computing">
      <t>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.</t>

      <figure align="center" anchor="BEC_Position"
              title="Beyond Edge Computing in the Network">
        <artwork align="center" type="ascii-art"><![CDATA[
+-------------------------------+
|   Core Data Center            |
+-------------------------------+
         ***   Backbone
        *   *  Network
         ***
+-------------------------------+
|   Regional Data Center        |
+-------------------------------+
         ***   Metropolitan
        *   *  Network
         ***
+-------------------------------+
| Local Data Center/Access Point|
+-------------------------------+
      ***   Access    ***
     *   *  Network  *   *  
      ***             ***
+-----------+     +-----------+
|  Beyond   |     |  Beyond   |
|   Edge    |     |   Edge    |
| Computing |     | Computing |
+-----------+     +-----------+]]></artwork>
      </figure>

      <t>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.</t>

      <section title="Heterogeneous IoT Device Compatibility">
        <t>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.</t>
      </section>

      <section title="Deterministic Networking">
        <t>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.</t>
      </section>

      <section title="Management of Massive Amount of Devices">
        <t>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.
        </t>
      </section>

      <section title="Support of Network Slicing">
        <t>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.</t>
      </section>

      <section title="Multi-ecosystem Environment">
        <t>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.</t>
      </section>
    </section>

    <section title="Reference Architecture">
      <figure align="center" anchor="Arch"
              title="The Reference Architecture of Beyond Edge Compuring">
        <artwork align="center" type="ascii-art"><![CDATA[
+--------------------------------+
|     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     |
+----------------------------------------------------+

                             

]]></artwork>
      </figure>

      <t>Figure 2 demonstrates the reference architecture of BEC system with a
      managed BEC node and a cloud-based management platform. An IoT 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.</t>

      <t>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.</t>
    </section>

    <section title="Use Cases of BEC">
      <t>1. Elevator Networks</t>

      <t>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 BEC node may notify elevator
      maintainers to reach this elevator and perform maintanence or
      repair.</t>

      <t>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.</t>

      <t>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.</t>

      <t>2. Intelligent Street Lights</t>

      <t>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.</t>

      <t>Goal: BEC nodes gather data from sensors which are used to monitor
      various information (e.g., brightness, temperature, humidity) of a
      district.</t>

      <t>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.</t>

      <t>3. Smart Manufacturing</t>

      <t>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. The gateway can
      also help monitor the equipments' status, and send out alarms or
      warnings when malfunction is detected or predicted.</t>

      <t>Goal: Edge computing enables interconnection of deterministic
      networks.</t>

      <t>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.</t>

      <t>4. Smart grid</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="IANA Considerations">
      <t>N/A</t>
    </section>

    <section title="Security Considerations">
      <t>Security considerations will be a critical component of IIoT edge
      computing particularly as intelligence is moved to the extreme edge.</t>
    </section>

    <section title="Acknowledgement">
      <t>The authors would like to thank Sami Kekki for his feedback on this
      draft.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
