idnits 2.17.1 draft-hong-t2trg-iot-edge-computing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 125 has weird spacing: '... IoT on back-...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (2 March 2020) is 1515 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hong 3 Internet-Draft Y-G. Hong 4 Intended status: Informational ETRI 5 Expires: 3 September 2020 X. de Foy 6 InterDigital Communications, LLC 7 M. Kovatsch 8 Huawei Technologies Duesseldorf GmbH 9 E. Schooler 10 Intel 11 D. Kutscher 12 University of Applied Sciences Emden/Leer 13 2 March 2020 15 IoT Edge Challenges and Functions 16 draft-hong-t2trg-iot-edge-computing-03 18 Abstract 20 Many IoT applications have requirements that cannot be met by 21 the traditional Cloud (aka Cloud computing). These include time 22 sensitivity, data volume, uplink cost, operation in the face of 23 intermittent services, privacy and security. As a result, the IoT is 24 driving the Internet toward Edge computing. This document outlines 25 the requirements of the emerging IoT Edge and its challenges. It 26 presents a snapshot of the state-of-the-art, a general model, and 27 major components of the IoT Edge, with the goal to provide a common 28 base for future discussions in T2TRG and other IETF WGs and RGs. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 3 September 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 65 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Internet of Things (IoT) . . . . . . . . . . . . . . . . 4 67 3.2. Cloud Computing . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. Edge Computing . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Example of IoT Edge Computing Use Cases . . . . . . . . . 6 70 3.4.1. Smart Construction . . . . . . . . . . . . . . . . . 7 71 3.4.2. Smart Grid . . . . . . . . . . . . . . . . . . . . . 7 72 3.4.3. Smart Water System . . . . . . . . . . . . . . . . . 8 73 3.5. Common Aspects of Current IoT Edge Computing Service 74 Platforms . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. Challenges for IoT and Impacts of Edge Computing . . . . . . 9 76 4.1. Time Sensitivity . . . . . . . . . . . . . . . . . . . . 10 77 4.2. Uplink Cost . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.3. Resilience to Intermittent Services . . . . . . . . . . . 10 79 4.4. Privacy and Security . . . . . . . . . . . . . . . . . . 11 80 5. IoT Edge Computing Functions . . . . . . . . . . . . . . . . 11 81 5.1. OAM Components . . . . . . . . . . . . . . . . . . . . . 13 82 5.1.1. Resources Discovery . . . . . . . . . . . . . . . . . 13 83 5.1.2. Virtualization Management . . . . . . . . . . . . . . 13 84 5.1.3. Authentication and Authorization . . . . . . . . . . 14 85 5.1.4. Edge Organization and Federation . . . . . . . . . . 14 86 5.2. Functional Components . . . . . . . . . . . . . . . . . . 14 87 5.2.1. External APIs . . . . . . . . . . . . . . . . . . . . 14 88 5.2.2. Communication Brokering . . . . . . . . . . . . . . . 14 89 5.2.3. In-Network Computation . . . . . . . . . . . . . . . 15 90 5.2.4. Edge Caching . . . . . . . . . . . . . . . . . . . . 15 91 5.2.5. Other Services . . . . . . . . . . . . . . . . . . . 15 92 5.3. Application Components . . . . . . . . . . . . . . . . . 16 93 5.3.1. IoT End Devices Management . . . . . . . . . . . . . 16 94 5.3.2. Data Management . . . . . . . . . . . . . . . . . . . 16 96 5.4. Simulation and Emulation Environments . . . . . . . . . . 16 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 101 8.2. Informative References . . . . . . . . . . . . . . . . . 17 102 Appendix A. Overview of the IoT Edge Computing . . . . . . . . . 20 103 A.1. Open Source Projects . . . . . . . . . . . . . . . . . . 21 104 A.1.1. Gateway/CPE Platforms . . . . . . . . . . . . . . . . 21 105 A.1.2. Edge Cloud Management Platforms . . . . . . . . . . . 22 106 A.1.3. Related Projects . . . . . . . . . . . . . . . . . . 23 107 A.2. Products . . . . . . . . . . . . . . . . . . . . . . . . 23 108 A.2.1. IoT Gateways . . . . . . . . . . . . . . . . . . . . 23 109 A.2.2. Edge Cloud Platforms . . . . . . . . . . . . . . . . 24 110 A.3. Standards Initiatives . . . . . . . . . . . . . . . . . . 24 111 A.3.1. ETSI Multi-access Edge Computing . . . . . . . . . . 24 112 A.3.2. Edge Computing Support in 3GPP . . . . . . . . . . . 25 113 A.3.3. OpenFog and Industrial Internet Consortium . . . . . 26 114 A.3.4. Related Standards . . . . . . . . . . . . . . . . . . 26 115 A.4. Research Projects . . . . . . . . . . . . . . . . . . . . 26 116 A.4.1. Named Function Networking . . . . . . . . . . . . . . 26 117 A.4.2. 5G-CORAL . . . . . . . . . . . . . . . . . . . . . . 27 118 A.4.3. FLAME . . . . . . . . . . . . . . . . . . . . . . . . 28 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 121 1. Introduction 123 Currently, many IoT services leverage the Cloud, since it can provide 124 virtually unlimited storage and processing power. The reliance of 125 IoT on back-end cloud computing brings additional advantages such as 126 flexibility and efficiency. Today's IoT systems are fairly static 127 with respect to integrating and supporting computation. It's not 128 that there is no computation, but systems are often limited to static 129 configurations (edge gateways, the Cloud). 131 However, IoT devices are creating vast amounts of data at the network 132 edge. To meet IoT use case requirements, that data increasingly is 133 being stored, processed, analyzed, and acted upon close to the data 134 producers. These requirements include time sensitivity, data volume, 135 uplink cost, resiliency in the face of intermittent connectivity, 136 privacy, and security, which cannot be addressed by today's 137 centralized cloud computing. These requirements suggest a more 138 flexible way to distribute computing (and storage) and to integrate 139 it in the edge-cloud continuum. We will refer to this integration of 140 edge computing and IoT as "IoT edge computing". Our draft describes 141 uses cases, challenges, a proposed system model and derived 142 functional components. 144 2. Conventions and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Background 152 3.1. Internet of Things (IoT) 154 Since the term "Internet of Things" (IoT) was coined by Kevin Ashton 155 in 1999 working on Radio-Frequency Identification (RFID) technology 156 at the Auto-ID Center of the Massachusetts Institute of Technology 157 (MIT) [Ashton], the concept of IoT had been broadened to reflect the 158 vision of connecting the physical world to the virtual world of 159 computers using (wireless) sensor networks with any kind of 160 technology with which the Things can send and receive information 161 without human intervention. Recently, the term has become more 162 literal by actually connecting Things to the Internet and converging 163 on Internet and also Web technology. Things are usually embedded 164 systems of various kinds, such as home appliances, mobile equipment, 165 wearable devices, etc. Things are widely distributed, but typically 166 have limited storage and processing power, which raise concerns 167 regarding reliability, performance, energy consumption, security, and 168 privacy [Lin]. 170 3.2. Cloud Computing 172 Cloud computing has been defined in [NIST]: "cloud computing is a 173 model for enabling ubiquitous, convenient, on-demand network access 174 to a shared pool of configurable computing resources (e.g., networks, 175 servers, storage, applications, and services) that can be rapidly 176 provisioned and released with minimal management effort or service 177 provider interaction". Cloud computing has been a predominant 178 technology which has virtually unlimited capacity in terms of storage 179 and processing power. The availability of virtually unlimited 180 storage and processing capabilities at low cost enabled the 181 realization of a new computing model, in which virtualized resources 182 can be leased in an on-demand fashion, being provided as general 183 utilities. Companies like Amazon, Google, Facebook, etc. widely 184 adopted this paradigm for delivering services over the Internet, 185 gaining both economical and technical benefits [Botta]. 187 Now with IoT, we will reach the era of post-clouds where 188 unprecedented volume and variety of data will be generated by things 189 at edge/local networks and many applications will be deployed on the 190 edge networks to consume these IoT data. Some of the applications 191 may need very short response times, some may contain personal data, 192 and others may generate vast amounts of data. Today's cloud-based 193 service models are not suitable for these applications. 195 It is predicted that by 2019, 45% of the data created in IoT will be 196 stored, processed, analyzed and acted close to, or at the edge of the 197 network and about 50 billion devices will connect to the Internet by 198 2020 [Evans]. So, moving all data from edge/local networks to the 199 cloud data center may not be an efficient way anymore to process vast 200 amounts of data. 202 In cloud computing, users traditionally only consumed IoT data 203 through cloud services. Now, however, users are also producing IoT 204 data with their mobile devices. This change requires even more 205 functionality at edge/local networks [Shi], to support mobile edge 206 computing considerations. 208 3.3. Edge Computing 210 Edge computing, under certain aspects also referred to as fog 211 computing, is a new paradigm in which substantial computing and 212 storage resources are placed at the edge of the Internet, that is, in 213 close proximity to mobile devices, sensors, actuators, or machines, 214 so that computing happens near data sources [Mahadev], or closer 215 (topologically, physically, in term of latency, etc.) to where 216 decisions or interactions with the physical world are happening. It 217 works on both downstream data on behalf of cloud services and 218 upstream data on behalf of IoT services. 220 An edge device is any computing or networking resource residing 221 between data sources and cloud-based datacenters. In edge computing, 222 end devices not only consume data, but also produce data. And at the 223 network edge, devices not only request services and information from 224 the cloud, but also handle computing tasks including processing, 225 storage, caching, and load balancing on data sent to and from the 226 cloud [Shi]. This does not preclude end devices from hosting 227 computation themselves when possible, independently or as part of a 228 distributed edge computing platform. 230 The definition of edge computing from ISO is a "form of distributed 231 computing in which significant processing and data storage takes 232 place on nodes which are at the edge of the network" [ISO_TR]. 233 ETSI's definition of multi-access edge computing is a "system which 234 provides an IT service environment and cloud-computing capabilities 235 at the edge of an access network which contains one or more type of 236 access technology, and in close proximity to its users" 237 [ETSI_MEC_01]. 239 The similar concept of fog computing from the Industrial Internet 240 Consortium (formerly OpenFog) is "a horizontal, system-level 241 architecture that distributes computing, storage, control and 242 networking functions closer to the users along a cloud-to-thing 243 continuum" Appendix A.3.3. The term fog computing usually represents 244 the notion of a multi-tiered edge computing, that is, several layers 245 of compute infrastructure between the end devices and the cloud. 247 Based on these definitions, we can summarize a general philosophy of 248 edge computing as to distribute the required functions close to users 249 and data, while the difference to classic local systems is the usage 250 of management and orchestration features adopted from cloud 251 computing. 253 Actors from various industries approach edge computing using 254 different terms and reference models, although in practice these 255 approaches are not incompatible and may integrate with each other: 257 * The telecommunication industry tends to use a model where edge 258 computing services are deployed over NFV infrastructure at 259 aggregation points, or in proximity to the user equipment (e.g., 260 gNodeBs) Appendix A.3.1. 262 * Enterprise and campus solutions often interpret edge computing as 263 an "edge cloud", that is, a smaller data center directly connected 264 to the local network (often referred to as "on-premise"). 266 * The automation industry defines the edge as the connection point 267 between IT from OT (Operational Technology). Hence, here edge 268 computing sometimes referres to applying IT solutions to OT 269 problems such as analytics, more flexible user interfaces, or 270 simply having more compute power than an automation controller. 272 It is clear that the combination of these models leads to a multi- 273 tier edge computing solution as mentioned above. 275 3.4. Example of IoT Edge Computing Use Cases 277 IoT edge computing can be used in home, industry, grid, healthcare, 278 city, transportation, agriculture, and/or education scenarios. We 279 discuss here only a few examples of such use cases, to point out 280 differentiating requirements. 282 3.4.1. Smart Construction 284 In traditional construction domain, heavy equipment and machinery 285 pose risks to humans and property. Thus, there have been many 286 attempts to deploy technology to protect lives and property in 287 construction sites. For example, measurements of noise, vibration, 288 and gas can be recorded on a remote server and reported to an 289 inspector. Today, data produced by such measurements is collected by 290 a local gateway and transferred to a remote server. This incurs 291 transmission costs, e.g., over a LTE connection, and storage costs, 292 e.g., when using Amazon Web Services. When an inspector needs to 293 investigate an incident, he checks the information stored on a 294 server. 296 If we leverage IoT edge computing, sensor data can be processed and 297 analyzed on a gateway located within or near a construction site. 298 And with the help of statistical analysis or machine learning 299 technologies, we can predict future incidents in advance and this 300 prediction can trigger an on-site alarm and a notification to an 301 inspector. 303 To determine the exact cause of an incident, sensor data including 304 audio and video are transferred to a remote server. In this case, 305 audio and video data volume is typically very large and the cost of 306 transmission can be an issue. Edge computing can be leveraged to 307 predict the time of an incident, which can reduce the volume of 308 transmitted data; while during a normal time period audio and video 309 data may be transmitted with a low resolution, during an emergency, 310 this transmission may use a high resolution. This adjustment can 311 reduce transmission cost significantly. 313 3.4.2. Smart Grid 315 In future smart city scenarios, the Smart Grid will be critical in 316 ensuring highly available/efficient energy control in city-wide 317 electricity management. Edge computing is expected to play a 318 significant role in those systems to improve transmission efficiency 319 of electricity; to react and restore power after a disturbance; to 320 reduce operation costs and reuse renewable energy effectively, since 321 these operations involve local decision making. In addition, edge 322 computing can help monitoring power generation and power demand, and 323 making electrical energy storage decisions in the smart grid system. 325 3.4.3. Smart Water System 327 The water system is one of the most important aspects of a city. 328 Effective use of water, and cost-effective and environment-friendly 329 water treatment are critical aspects of this system. They can be 330 facilitated by edge computing in smart water systems, to help monitor 331 water consumption, transportation and prediction of future water use. 332 For example, water harvesting and ground water monitoring will be 333 supported through edge computing. Edge computing will also enable 334 locally analyzing collected information related to water control and 335 management, and limit water losses. 337 3.5. Common Aspects of Current IoT Edge Computing Service Platforms 339 This section provides an overview of today's IoT edge computing 340 field, based on a limited review of standards, research, open-source 341 and proprietary products in Appendix A. 343 IoT gateways (Appendix A.2.1, Appendix A.1.1) represent a common 344 class of IoT edge computing products, where the gateway is providing 345 a local service on customer premises, and is remotely managed through 346 a cloud service. IoT communication protocols are typically used 347 between IoT devices and the gateway, including CoAP, MQTT and many 348 specialized IoT protocols (such as OPC UA and DDS in the Industrial 349 IoT space), while the gateway communicates with the distant cloud 350 typically using HTTPS. Virtualization platforms enable the 351 deployment of virtual edge computing functions (as VMs, application 352 containers, etc.), including IoT gateway software, on servers in the 353 mobile network infrastructure (at base station and concentration 354 points), in edge datacenters (in central offices) or regional 355 datacenters located near central offices. End devices are envisioned 356 to become computing devices in forward looking projects, but are not 357 commonly used as such today. 359 Physical or virtual IoT gateways can host application programs, which 360 are typically built using an SDK to access local services through a 361 programmatic API. Edge cloud system operators host their customers' 362 applications VMs or containers on servers located in or near access 363 networks, which can implement local edge services. For example, 364 mobile networks can provide edge services for radio network 365 information, location and bandwidth management. 367 Life cycle management of services and applications on physical IoT 368 gateways is often cloud-based. Edge cloud management platforms and 369 products (Appendix A.1.2, Appendix A.2.2) adapt cloud management 370 technologies (e.g., Kubernetes) to the edge cloud, i.e., to smaller, 371 distributed computing devices running outside a controlled data 372 center. Services and application life-cycle is typically using a 373 NFV-like management and orchestration model. 375 The platform typically includes services to advertise or consume APIs 376 (e.g., Mp1 interface in ETSI MEC supports service discovery and 377 communication), and enables communicating with local and remote 378 endpoints (e.g., message routing function in IoT gateways). The 379 service platform is typically extensible by edge applications, since 380 they can advertise an API that other edge applications can consume. 381 IoT communication services include protocols translation, analytics 382 and transcoding. Communication between edge computing devices is 383 enabled in tiered deployments or distributed deployments. 385 An edge cloud platform may enable pass-through without storage or 386 local storage (e.g., on IoT gateways). Some edge cloud platforms use 387 a distributed form of storage such as an ICN network (e.g., NFN nodes 388 can store data in NDN, Appendix A.4.1) or a distributed storage 389 platform (e.g., such as Ceph, Appendix A.1.2). External storage, 390 e.g., on databases in distant or local IT cloud, is typically used 391 for filtered data deemed worthy of long term storage, or in some 392 cases for all data, for example when required for regulatory reasons. 394 Stateful computing is supported on platforms hosting native programs, 395 VMs or containers. Stateless computing is supported on platforms 396 providing a "serverless computing" service (a.k.a. function-as- 397 a-service), or on systems based on named function networking. 399 In many IoT use cases, a typical network usage pattern is high volume 400 uplink with some form of traffic reduction enabled by processing over 401 edge computing devices. Alternatives to traffic reduction include 402 deferred transmission (to off-peak hours or using physical shipping). 403 Downlink traffic includes application control and software updates. 404 Other, downlink-heavy traffic patterns are not excluded but are more 405 often associated with non-IoT usage (e.g., video CDNs). 407 4. Challenges for IoT and Impacts of Edge Computing 409 As the IoT is maturing, systems are converging, deployments are 410 growing, and IoT technology is used with more and more demanding 411 applications such as industrial, automotive, or healthcare. This 412 leads to new challenges for the network infrastructure. In 413 particular, the amount of data created at the edge is expected to be 414 vast. Industrial machines such as laser cutters already produce over 415 1 terabyte per hour, the same applies for autonomous cars [NVIDIA]. 416 90% of IoT data is expected to be stored, processed, analyzed, and 417 acted upon close to the source [Kelly], as cloud computing models 418 alone cannot address the new challenges [Chiang]. Below we discuss 419 IoT use case requirements that are moving cloud capabilities to be 420 more proximate and more distributed and disaggregated. Beyond 421 addressing those requirements, however, edge computing can also bring 422 flexibility to classic networking functions such as protocol 423 translation in gateways. 425 4.1. Time Sensitivity 427 Many industrial control systems, such as manufacturing systems, smart 428 grids, oil and gas systems, etc., often require stringent end-to-end 429 latency between the sensor and control node. While some IoT 430 applications may require latency below a few tens of milliseconds 431 [Weiner], industrial robots and motion control systems have use cases 432 for cycle times in the order of microseconds [_60802]. An important 433 aspect for real-time communications is not only the latency, but also 434 guarantees for jitter. This means control packets need to arrive 435 with as little variation as possible with a strict deadline. Given 436 the best-effort characteristics of the Internet, this challenge is 437 virtually impossible to address, without comprehending end-to-end 438 guarantees for individual message delivery and continuous data flows. 440 4.2. Uplink Cost 442 Many IoT deployments are not challenged by a constrained network 443 bandwidth to the cloud. The fifth generation mobile networks (5G) 444 and Wi-Fi 6 both theoretically top out at 10 gigabits per second 445 (i.e., 4.5 terabyte per hour), which enables high-bandwidth uplinks. 446 However, the resulting cost for high-bandwidth connectivity to upload 447 all data to the cloud is unjustifiable and impractical for most IoT 448 applications. In some settings, e.g. in aeronautical communication, 449 higher communication costs reduce the amount of data that can be 450 practically uploaded even further. 452 4.3. Resilience to Intermittent Services 454 Many IoT devices such as sensors, data collectors, actuators, 455 controllers, etc. have very limited hardware resources and cannot 456 rely solely on their limited resources to meet all their computing 457 and/or storage needs. They require reliable, uninterrupted or 458 resilient services to augment their capabilities in order to fulfill 459 their application tasks. This is hard and partly impossible to 460 achieve with cloud services for systems such as vehicles, drones, or 461 oil rigs that have intermittent network connectivity. 463 4.4. Privacy and Security 465 When IoT services are deployed at home, personal information can be 466 learned from detected usage data. For example, one can extract 467 information about employment, family status, age, and income by 468 analyzing smart meter data [ENERGY]. Policy makers started to 469 provide frameworks that limit the usage of personal data and put 470 strict requirements on data controllers and processors. However, 471 data stored indefinitely in the cloud also increases the risk of data 472 leakage, for instance, through attacks on rich targets. 474 Industrial systems are often argued to not have privacy implications, 475 as no personal data is gathered. Yet data from such systems is often 476 highly sensitive, as one might be able to infer trade secrets such as 477 the setup of production lines. Hence, the owner of these systems are 478 generally reluctant to upload IoT data to the cloud. 480 5. IoT Edge Computing Functions 482 Edge computing is expected to play an important role in deploying new 483 IoT services integrated with Big Data and AI, enabled by flexible in- 484 network computing platforms. Although there are lots of approaches 485 to edge computing, we attempt to lay out a general model and list 486 associated logical functions in this section. In practice, this 487 model can map to different architectures, such as: 489 * A single IoT gateway, or a hierarchy of IoT gateways, typically 490 connected to the cloud (e.g., to extend the traditionally cloud- 491 based management of IoT devices and data to the edge). A common 492 role of an IoT Gateway is to provide access to an heterogeneous 493 set of IoT devices/sensors; handle IoT data; and deliver IoT data 494 to its final destination in a cloud network. Whereas an IoT 495 gateway needs interactions with cloud like as conventional cloud 496 computing, it can also operate independently. 498 * A set of distributed computing nodes, e.g., embedded in switches, 499 routers, edge cloud servers or mobile devices. In the future, 500 some IoT end devices may have enough computing capabilities to 501 participate in such distributed systems. In this model, edge 502 computing nodes can collaborate with each other to share their 503 resources. 505 +---------------------+ 506 | Remote network | +---------------+ 507 |(e.g., cloud network)| | Service | 508 +-----------+---------+ | Operator | 509 | +------+--------+ 510 | | 511 +--------------+-------------------+-----------+ 512 | Edge Computing Domain | 513 | | 514 | Computing Nodes (edge or end devices) | 515 | | 516 | OAM Components | 517 | - Resources Discovery | 518 | - Virtualization Management | 519 | - Authentication | 520 | - Edge Organization and Federation | 521 | - ... | 522 | | 523 | Functional Components | 524 | - External APIs | 525 | - Communication Brokering | 526 | - In-Network Computation | 527 | - Edge Caching | 528 | - Other Services | 529 | - ... | 530 | | 531 | Application Components | 532 | - IoT End Devices Management | 533 | - Data Management | 534 | - ... | 535 | | 536 +------+--------------+-------- - - - -+- - - -+ 537 | | | | | 538 | | +-----+--+ 539 +----+---+ +-----+--+ | |compute | | 540 | End | | End | ... |node/end| 541 |Device 1| |Device 2| ...| |device n| | 542 +--------+ +--------+ +--------+ 543 + - - - - - - - -+ 545 Figure 1: Model of IoT Edge Computing 547 In this general model, the edge computing domain is interconnected 548 with IoT end devices (southbound connectivity) and possibly with a 549 remote/cloud network (northbound connectivity), and with a service 550 operator's system. Edge computing nodes provide multiple logical 551 functions, or components, which may not all be present in a given 552 system. They may be implemented in a centralized or distributed 553 fashion, in the edge network, or through some interworking between 554 the edge network and a remote cloud network. 556 We now attempt to enumerate major edge computing domain components. 557 They are here loosely organized into OAM, functional and application 558 components, with the understanding that the distinction between these 559 classes may not always be clear, depending on actual system 560 architectures. 562 5.1. OAM Components 564 Edge computing OAM goes beyond the network-related OAM functions 565 listed in [RFC6291]. Besides infrastructure (network, storage and 566 computing resources), edge computing systems can also include 567 computing environments (for VMs, software containers, functions), IoT 568 end devices, data and code. 570 Operation related functions include performance monitoring for 571 service level agreement measurement; fault management and 572 provisioning for links, nodes, compute and storage resources, 573 platforms and services. Administration covers network/compute/ 574 storage resources, platforms and services discovery, configuration 575 and planning. Management covers monitoring and diagnostics of 576 failures, as well as means to minimize their occurrence and take 577 corrective actions. This may include software updates management, 578 high service availability through redundancy and multipath 579 communication. 581 We further detail a few OAM components. 583 5.1.1. Resources Discovery 585 This component is about finding infrastructure resources, such as 586 compute, network and storage, but also other resources such as IoT 587 end devices, sensors, data, code, or services. 589 5.1.2. Virtualization Management 591 Some IoT edge computing systems make use of virtualized (compute, 592 storage and networking) resources, which need to be allocated and 593 configured. 595 5.1.3. Authentication and Authorization 597 This can cover authenticating platforms, end devices, data, code 598 units and applications or users interacting with the system. Today, 599 centralized gateway-based systems rely for device authentication on 600 the installation of a secret on IoT end devices and on computing 601 devices (e.g., a device certificate stored in a hardware security 602 module). 604 5.1.4. Edge Organization and Federation 606 In a distributed system context, once edge devices have discovered 607 and authenticated each other, they can be organized, or self- 608 organize, into hierarchies or clusters. Such groups can also form 609 federations with other edge or remote clouds. 611 5.2. Functional Components 613 5.2.1. External APIs 615 An IoT edge cloud may provide a northbound data plane or management 616 plane interface to a remote network, e.g., a cloud, home or 617 enterprise network. This interface does not exist in standalone 618 (local-only) scenarios. To support such an interface when it exists, 619 an edge computing component needs to expose an API, deal with 620 authentication and authorization, support secure communication. 622 An IoT edge cloud may provide an API or interface to local users 623 (e.g., to facilitate local management), or to mobile users (e.g., to 624 provide access to services and applications, or to manage data 625 published by the mobile device). 627 5.2.2. Communication Brokering 629 A typical function of IoT edge computing is to facilitate 630 communication with IoT end devices: for example, enable clients to 631 register as recipients for data from devices, as well as forwarding/ 632 routing of traffic to or from IoT end devices, enabling various data 633 discovery and redistribution patterns, e.g., north-south with clouds, 634 east-west with other edge devices [DATA-DISCOVERY]. Another aspect 635 of a communication component is dispatching of alerts and 636 notifications to interested consumers both inside and outside of the 637 edge computing domain. Protocol translation, analytics and 638 transcoding may also be performed when necessary. 640 Communication brokering may be centralized in some systems, e.g., 641 using a hub-and-spoke message broker, or distributed like with 642 message buses, possibly in a layered bus approach. Distributed 643 systems may leverage direct communication between end devices and 644 communication devices, such as device-to-device links. Brokers 645 functions can include ensuring communication reliability, 646 traceability, and in some cases transaction management. 648 QoS can be provided in some systems through the combination of 649 network QoS (e.g., traffic engineering or wireless resource 650 scheduling) and compute/storage resource allocations. In some 651 systems a bandwidth manager service can be exposed to enable 652 allocation of bandwidth to/from an edge computing application 653 instance. 655 5.2.3. In-Network Computation 657 A core function of IoT edge computing is to enable computation 658 offloading, i.e., to perform computation on an edge node on behalf of 659 a device or user. The support for in-network computation may vary in 660 term of capability, e.g., computing nodes can host a virtual machine 661 able run stateful or stateless code, or a rule engine providing an 662 API to register actions in response to conditions such as IoT device 663 ID, sensor values to check, thresholds, etc. Computation offloading 664 includes orchestration or application lifecycle related aspects, such 665 as: selecting an appropriate compute device based on available 666 resources, compute node properties, etc., and with varying goals 667 including for example load balancing and energy conservation; 668 onboarding code on a platform or compute device; assisted or 669 automatic partitioning of code; invoking remote code execution; 670 relocating an instance from one compute node to another; session 671 continuity when communicating with mobile end devices. 673 5.2.4. Edge Caching 675 A purpose of local caching may be to enable local data processing 676 (e.g., pre-processing or analysis), or to enable delayed virtual or 677 physical shipping. A responsibility of the edge caching component is 678 to manage data persistence, e.g., to schedule removal of data when it 679 is no longer needed. Another aspect of this component may be to 680 authenticate and encrypt data. It can for example take the form of a 681 distributed storage system, and deal with related issues, e.g., 682 reaching and maintaining data consistency; enabling efficient access 683 to data, for example using some form of sharding. 685 5.2.5. Other Services 687 Data generated by IoT devices and associated information obtained 688 from the access network may be used to provide high level services 689 such as end device location, radio network information and bandwidth 690 management. 692 5.3. Application Components 694 5.3.1. IoT End Devices Management 696 IoT end device management includes managing information about the IoT 697 devices, including their sensors, how to communicate with them, etc. 698 Edge computing addresses the scalability challenges from the massive 699 number of IoT end devices and IoT data value by separating the 700 scalability domain into edge/local networks and remote network. 702 5.3.2. Data Management 704 With regard to the high level challenges listed in Section 4, data 705 storage and processing at the edge is a major aspect of IoT edge 706 computing. Data may therefore need to be classified (e.g., in terms 707 of privacy, importance, validity, etc.). Data analysis such as 708 performed in AI/ML tasks performed at the edge may benefit from 709 specialized hardware support on computing nodes. IoT edge computing 710 will face challenges in term of, for example, programmability, 711 naming, data abstraction, data service management and data discovery 712 (discussed in communication brokering). Furthermore, while edge 713 computing can support IoT services independently of cloud computing, 714 it can also be connected to cloud computing. Thus, the relationship 715 of IoT edge computing to cloud computing, with regard to data 716 management, is another potential challenge [ISO_TR]. 718 5.4. Simulation and Emulation Environments 720 IoT Edge Computing brings new challenges to simulation and emulation 721 tools used by researchers and developers. A varied set of 722 applications, network and computing technologies can coexist in a 723 distributed system, which make modelling difficult. Scale, mobility 724 and resource management are additional challenges [SimulatingFog]. 726 Tools include simulators, where simplified application logic runs on 727 top of a fog network model, and emulators, where actual applications 728 can be deployed, typically in software containers, over a cloud 729 infrastructure (e.g. Docker, Kubernetes) itself running over a 730 network emulating edge network conditions such as variable delays, 731 throughput and mobility events. To gain in scale, emulated and 732 simulated systems can be used together in hybrid federation-based 733 approaches [PseudoDynamicTesting], while to gain in realism physical 734 devices can be interconnected with emulated systems. Examples of 735 related work and platforms include the publicly accessible MEC 736 sandbox work recently initiated in ETSI [ETSI_Sandbox], and open 737 source simulators and emulators ([AdvantEDGE] emulator and tools 738 cited in [SimulatingFog]). 740 6. Security Considerations 742 T.B.D. 744 7. Acknowledgement 746 The authors would like to thank Joo-Sang Youn, Akbar Rahman, Michel 747 Roy, Robert Gazda and Rute Sofia for their valuable comments and 748 suggestions on this document. 750 8. References 752 8.1. Normative References 754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 755 Requirement Levels", BCP 14, RFC 2119, 756 DOI 10.17487/RFC2119, March 1997, 757 . 759 8.2. Informative References 761 [AdvantEDGE] 762 "Mobile Edge Emulation Platform", Source Code Repository , 763 March 2020, 764 . 766 [Ashton] Ashton, K., "That Internet of Things thing", RFID J. vol. 767 22, no. 7, pp. 97-114 , 2009. 769 [Botta] Botta, A., Donato, W., Persico, V., and A. Pescape, 770 "Integration of Cloud Computing and Internet of Things: A 771 survey", Future Gener. Comput. Syst., vol. 56, pp. 772 684-700 , 2016. 774 [Chiang] Chiang, M. and T. Zhang, "Fog and IoT: An overview of 775 research opportunities", IEEE Internet Things J., vol. 3, 776 no. 6, pp. 854-864 , 2016. 778 [DATA-DISCOVERY] 779 McBride, M., Kutscher, D., Schooler, E., and CJ. 780 Bernardos, "Edge Data Discovery for COIN", Work in 781 Progress, Internet-Draft, draft-mcbride-edge-data- 782 discovery-overview, March 2020, 783 . 786 [ENERGY] Beckel, C., Sadamori, L., Staake, T., and S. Santini, 787 "Revealing Household Characteristics from Smart Meter 788 Data", Energy, vol. 78, pp. 397-410 , 2014. 790 [ETSI_MEC_01] 791 ETSI, ., "Multi-access Edge Computing (MEC); Terminology", 792 ETSI GS 001 , 2019, . 795 [ETSI_MEC_02] 796 ETSI, ., "Multi-access Edge Computing (MEC); Phase 2: Use 797 Cases and Requirements", ETSI GS 002 , 2016, 798 . 801 [ETSI_MEC_03] 802 ETSI, ., "Mobile Edge Computing (MEC); Framework and 803 Reference Architecture", ETSI GS 003 , 2019, 804 . 807 [ETSI_MEC_WP_28] 808 ETSI, ., "MEC in 5G networks", White Paper , 2018, 809 . 812 [ETSI_Sandbox] 813 "Multi-access Edge Computing (MEC) MEC Sandbox Work Item", 814 Portal , March 2020, 815 . 818 [Evans] Evans, D., "The Internet of Things: How the next evolution 819 of the Internet is changing everything", CISCO White 820 Paper , 2011. 822 [FLAME] Horizon 2020 Programme, ., "FLAME Project", Portal , 2019, 823 . 825 [IEEE-1934] 826 IEEE, ., "FOG - Fog Computing and Networking Architecture 827 Framework", Portal , 2019, 828 . 830 [ISO_TR] "Information Technology - Cloud Computing - Edge Computing 831 Landscape", ISO/IEC TR 23188 , 2018. 833 [Kelly] Kelly, R., "Internet of Things Data to Top 1.6 Zettabytes 834 by 2022", 2016, 835 . 839 [Lin] Lin, J., Yu, W., Zhang, N., Yang, X., Zhang, H., and W. 840 Zhao, "A survey on Internet of Things: Architecture, 841 enabling technologies, security and privacy, and 842 applications", IEEE Internet of Things J., vol. 4, no. 5, 843 pp. 1125-1142 , 2017. 845 [Linux_Foundation_Edge] 846 Linux Foundation, ., "Linux Foundation Edge", Portal , 847 2019, . 849 [Mahadev] Satyanarayanan, M., "The Emergence of Edge Computing", 850 Computer, vol. 50, no. 1, pp. 30-39 , 2017. 852 [NIST] Mell, P. and T. Grance, "The NIST definition of Cloud 853 Computing", Natl. Inst. Stand. Technol, vol. 53, no. 6, p. 854 50 , 2009. 856 [NVIDIA] Grzywaczewski, A., "Training AI for Self-Driving Vehicles: 857 the Challenge of Scale", NVIDIA Developer Blog , 2017, 858 . 861 [OpenEdgeComputing] 862 "Open Edge Computing", Portal , 2019, 863 . 865 [OpenFog] "OpenFog Reference Architecture for Fog Computing", 866 OpenFog Consortium , 2017. 868 [POINT] Horizon 2020 Programme, ., "IP Over ICN - the better IP 869 (POINT) Project", Portal , 2019, 870 . 872 [PseudoDynamicTesting] 873 Ficco, M., Esposito, C., Xiang, Y., and F. Palmieri, 874 "Revealing Household Characteristics from Smart Meter 875 Data", IEEE Communications Magazine, Nov. 2017 , 2017. 877 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 878 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 879 Acronym in the IETF", BCP 161, RFC 6291, 880 DOI 10.17487/RFC6291, June 2011, 881 . 883 [Shi] Shi, W., Cao, J., Zhang, Q., Li, Y., and L. Xu, "Edge 884 computing: vision and challenges", IEEE Internet of Things 885 J., vol. 3, no. 5, pp. 637-646 , 2016. 887 [Sifalakis] 888 Sifalakis, M., Kohler, B., Scherb, C., and C. Tschudin, 889 "An Information Centric Network for Computing the 890 Distribution of Computations", Proceedings of the 1st 891 International Conference on Information-centric networking 892 (INC) , 2014. 894 [SimulatingFog] 895 Svorobej, S. and . al, "Simulating Fog and Edge Computing 896 Scenarios: An Overview and Research Challenges", MPDI 897 Future Internet 2019 , 2019. 899 [StarlingX] 900 OpenStack Foundation, ., "StarlingX", Portal , 2019, 901 . 903 [Weiner] Weiner, M., Jorgovanovic, M., Sahai, A., and B. Nikolie, 904 "Design of a low-latency, high-reliability wireless 905 communication system for control applications", IEEE Int. 906 Conf. Commun. (ICC), Sydney, NSW, Australia, pp. 907 3829-3835 , 2014. 909 [_3GPP.23.501] 910 3GPP, ., "System Architecture for the 5G System", 3GPP TS 911 23.501 , 2019, 912 . 914 [_5G-CORAL] 915 Horizon 2020 Programme, ., "5G Convergent Virtualised 916 Radio Access Network Living at the Edge (5G-CORAL) 917 Project", Portal , 2019, . 919 [_60802] IEC/IEEE, ., "Use Cases IEC/IEEE 60802 V1.3", IEC/IEEE 920 60802 , 2018, . 923 Appendix A. Overview of the IoT Edge Computing 925 This list of initiatives, projects and products aim to provide an 926 overview of the IoT edge computing. 928 Our goal is to be representative rather than exhaustive. 930 Please help us complete this overview by communicating with us about 931 entries we have missed. 933 A.1. Open Source Projects 935 A.1.1. Gateway/CPE Platforms 937 EdgeX Foundry, Home Edge, Edge Virtualization Engine are Linux 938 Foundation projects ([Linux_Foundation_Edge]) aiming to provide a 939 platform for edge computing devices. 941 Such an open source platform can, for example, host proprietary 942 programs currently run on IoT gateway products (Appendix A.2). 944 EdgeX Foundry develops an edge computing framework running on the IoT 945 gateway. 947 Home Edge develops an edge computing framework especially dedicated 948 to home computing devices, controlling home appliances, sensors, 949 etc., and enabling AI applications, especially distributed and 950 parallel machine learning. 952 The Edge Virtualization Engine (EVE) project develops a 953 virtualization platform (for VMs and containers) designed to run 954 outside of the datacenter, in an edge network; EVE is deployed on 955 bare-metal hardware. 957 Computing devices: Hardware support for EdgeX and EVE is similar: 958 they support x86 and ARM-based computing devices; A typical target 959 can be a Linux Raspberry Pi with 1GB RAM, 64bit CPU, 32GB storage. 961 Service platform: EdgeX uses a micro-service architecture. Micro- 962 services on the gateway are connected together, and to outside 963 applications, through REST, or messaging technologies such as 964 MQTT, AMQP and 0MQ. The gateway can communicate with external 965 backend applications or other gateways (north-south in tiered 966 deployments or east-west in more distributed deployments). 967 Gateway-device communication can use a wide range of IoT 968 protocols. "Export services" enable on-gateway and off-gateway 969 clients to register as recipient for data from devices. Core 970 services are microservices that deal with persisting data from 971 devices or alternatively "streaming" device data through, without 972 persistence (core data service); managing information about the 973 IoT devices, including their sensors, how to communicate with 974 them, etc. (metadata service); and actual communication with IoT 975 devices, on behalf of other on-gateway or off-gateway services 976 (command service). A rule engine provides an API to register 977 actions in response to conditions typically including an IoT 978 device ID, sensor values to check, thresholds, etc. The 979 scheduling micro service deals with organizing the removal of data 980 persisted on the gateway. Alerts and notifications microservice 981 can be used to dispatch alert/notifications from internal or 982 external sources to interested consumers including backend 983 servers, or human operators through email or SMS. 985 Edge cloud applications: Target applications for EdgeX include 986 Industrial IoT (e.g., IoT sensor data and actuator control mixed 987 with augmented reality application for technicians). Home Edge 988 focuses on smart home use cases, including using AI lifestyle and 989 safety applications. 991 A.1.2. Edge Cloud Management Platforms 993 This set of open-source projects setup and manage clouds of 994 individual edge computing devices. 996 StarlingX ([StarlingX]) extends OpenStack to provide virtualization 997 platform management for edge clouds, which are distributed (in the 998 range of 100 compute devices), secure and highly available. 1000 Akraino Edge Stack, another project from the Linux Fundation Edge 1001 [Linux_Foundation_Edge], has a wider scope of developing a management 1002 platform adapted for the edge (e.g., covering 1000 plus locations), 1003 aiming for zero-touch provisioning, and zero-touch lifecycle 1004 management. 1006 Computing devices: Compute devices are typically Linux-based 1007 application servers or more constrained devices. 1009 Service platform: StarlingX adds new management services to 1010 OpenStack by leveraging building blocks such as Ceph for 1011 distributed storage, Kubernetes for orchestration. The new 1012 services are for management of configuration (enabling auto- 1013 discovery and configuration), faults, hosts (enabling host failure 1014 detection and auto-recovery), services (providing high 1015 availability through service redundancy and multi-path 1016 communication) and software (enabling updates). 1018 Edge cloud applications: An edge computing platform may support a 1019 wide range of use cases. E.g., autonomous vehicles, industrial 1020 automation and robotics, cloud RAN, metering and monitoring, 1021 mobile HD video, content delivery, healthcare imaging and 1022 diagnostics, caching and surveillance, augmented/virtual reality, 1023 small cell services for high density locations (stadiums), 1024 universal CPE applications, retail. 1026 A.1.3. Related Projects 1028 Open Edge Computing ([OpenEdgeComputing]) is an initiative from 1029 universities, manufacturers, infrastructure providers and operators, 1030 enabling efficiently offloading cloudlets (VMs) to the edge. 1031 Computing devices are typically powerful, well-connected servers 1032 located in mobile networks (e.g., collocated with base stations or 1033 aggregation sites). The service platform is built on top of 1034 OpenStack++, an extension of OpenStack to support cloudlets. This 1035 project is mentioned here as a related project because of its edge 1036 computing focus, and potential for some IoT use cases. Nevertheless, 1037 its primary use cases are typically non-IoT related, such as 1038 offloading processing-intensive applications from a mobile device to 1039 the edge. 1041 A.2. Products 1043 A.2.1. IoT Gateways 1045 Multiple products are marketed as IoT gateways (Amazon Greengrass, 1046 Microsoft Azure IoT Edge, Google Cloud IoT Core, and gateway 1047 solutions from Bosh and Siemens). They are typically composed of a 1048 software frameworks that can run on a wide range of IoT gateway 1049 hardware devices to provide local support for cloud services, as well 1050 as some other local IoT gateway features such as relaying 1051 communication and caching content. Remote cloud is both used for 1052 management of the IoT gateways, and for hosting customer application 1053 components. Some IoT gateway products (Amazon Snowball) have a 1054 primary purpose of storing edge data on premises, to enable 1055 physically moving this data into the cloud without incurring digital 1056 data transfer cost. 1058 Computing devices: Typical computing devices run Linux, Windows or a 1059 Real-Time OS over an ARM or x86 architecture. The level of 1060 service support on the computing device can range from low-level 1061 packages giving maximum control to embedded developers, to high- 1062 level SDKs. Typical requirements can start at 1GHz and 128MB RAM, 1063 e.g., ranging from Raspberry Pi to a server-level appliance. 1065 Service platform: IoT gateways can provide a range of service 1066 including: running stateless functions; routing messages between 1067 connected IoT devices (using a wide range of IoT protocols); 1068 caching data; enabling some form of synchronization between IoT 1069 devices; authenticating and encrypting device data. Association 1070 between IoT devices and gateway based can require a device 1071 certificate. 1073 Edge cloud applications: Pre-processing of IoT data for later 1074 processing in the cloud is a major driver. Use cases include 1075 industrial automation, farming, etc. 1077 A.2.2. Edge Cloud Platforms 1079 Services such as MobileEdgeX provide a platform for application 1080 developers to deploy software (e.g., as software containers) on edge 1081 networks. 1083 Computing devices: Bare metal and virtual servers provided by mobile 1084 network operators are used as computing devices. 1086 Service platform: The service platform provides end device location 1087 service, using GPS data obtained from platform software deployed 1088 in end devices, correlated with location information obtained from 1089 the mobile network. The service platform manages the deployment 1090 of application instances (containers) on servers close to end 1091 devices, using a declarative specification of optimal location 1092 from the application provider. 1094 Edge cloud applications: Use cases include autonomous mobility, 1095 asset management, AI-based systems (e.g., quality inspection, 1096 assistance systems, safety and security cameras) and privacy- 1097 preserving video processing. There are also non-IoT use cases 1098 such as augmented reality and gaming. 1100 A.3. Standards Initiatives 1102 A.3.1. ETSI Multi-access Edge Computing 1104 The ETSI MEC industry standardization group develops specifications 1105 that enable efficient and seamless integration of applications from 1106 vendors, service providers, and 3rd parties across multi-vendor MEC 1107 platforms ([ETSI_MEC_03]). 1109 Basic principles followed include: leveraging NFV infrastructure; 1110 being compliant with 3GPP systems; focusing on orchestration, MEC 1111 services, applications and platforms. 1113 Phase 1 (2015-2016) focused on basic platform services. Phase 2 1114 (2017-2019) focuses on: supporting non-3GPP radio access 1115 technologies, especially WiFi; supporting a distributed, multi- 1116 operator and multi-vendor architecture; supporting non-VM based 1117 virtualization such as containers and PaaS. 1119 Computing devices: Computing devices are typically application 1120 servers, attached to an eNodeB or at a higher level of aggregation 1121 point, and provide service to end users. 1123 Service platform: The mobile edge platform offers an environment 1124 where the mobile edge applications can discover, advertise, 1125 consume and offer mobile edge services. The platform can provide 1126 certain native services such as radio network information, 1127 location, bandwidth management etc. The platform manager is 1128 responsible for managing the life cycle of applications including 1129 informing the mobile edge orchestrator of relevant application 1130 related events, managing the application rules and requirements 1131 including service authorizations, traffic rules, DNS 1132 configuration. 1134 Edge cloud applications: Some of the use cases for MEC 1135 ([ETSI_MEC_02]) are IoT-related, including: security and safety 1136 (face recognition and monitoring), sensor data monitoring, active 1137 device location (e.g., crowd management), low latency vehicle-to- 1138 infrastructure and vehicle-to-vehicle (V2X, e.g., hazard 1139 warnings), video production and delivery, camera as a service. 1141 A.3.2. Edge Computing Support in 3GPP 1143 The 3GPP standards organization included edge computing support in 5G 1144 [_3GPP.23.501]. Integration of MEC and 5G systems has been studied 1145 in ETSI as well [ETSI_MEC_WP_28]. 1147 Computing devices: From 3GPP standpoint, a mobile device may access 1148 any computing device located in a local data network, i.e., 1149 traffic is steered towards the local data network where the 1150 computing device is located. 1152 Service platform: An external party may influence steering, QoS and 1153 charging of traffic towards the computing device. Session and 1154 service continuity can ensure that edge service is maintained when 1155 a client device moves. The network supports multiple-anchor 1156 connections, which makes it possible to connect a client device to 1157 both a local and a remote data network. The client device can be 1158 made aware of the availability of a local area data network, based 1159 on its location. 1161 Edge cloud applications: Edge cloud applications in 3GPP can help 1162 support the major use cases envisioned for 5G, including massive 1163 IoT and V2X. 1165 A.3.3. OpenFog and Industrial Internet Consortium 1167 The OpenFog Consortium (now merged with the Industrial Internet 1168 Consortium) aims to standardize industrial IoT, fog, and edge 1169 computing. It produced a reference architecture for the fog 1170 ([OpenFog]), which has been published as IEEE standard P1934 in 2018. 1171 This work continues within the Industrial Internet Consortium. 1173 Computing devices: Fog nodes include computational, networking, 1174 storage and acceleration elements. This includes nodes collocated 1175 with sensors and actuators, roadside or mobile nodes involved in 1176 V2X connectivity. Fog nodes should be programmable and may 1177 support multi-tenancy. Fog computing devices must employ a 1178 hardware-based immutable root of trust, i.e., a trusted hardware 1179 component which receives control at power-on. 1181 Service platform: The service platform is structured around 1182 "pillars" including: security end-to-end, scalability by adding 1183 internal components or adding more fog nodes,openness in term of 1184 discovery of/by other nodes and networks, autonomy from 1185 centralized clouds (for discovery, orchestration and management, 1186 security and operation) and hierarchical organization of fog 1187 nodes. 1189 Edge cloud applications: Major use cases include smart cars and 1190 traffic control, visual security and surveillance, smart cities. 1192 A.3.4. Related Standards 1194 The IEEE Fog Computing and Networking Architecture Framework Working 1195 Group [IEEE-1934] published the OpenFog architecture as an IEEE 1196 document, and plan to do further work on taxonomy, architecture 1197 framework, and compliance guidelines. 1199 A.4. Research Projects 1201 A.4.1. Named Function Networking 1203 Named Function Networking ([Sifalakis]) is a research project that 1204 aims to extend ICN concepts (especially named data networking) to 1205 have the network orchestrate computation. Interests are sent for a 1206 combination of function and argument names, instead of using the 1207 content name in NDN. 1209 Computing devices: NFN-capable switches are collocated with 1210 computing devices. 1212 Service platform: NFN enables accessing static data and dynamic 1213 computation results in one data-oriented framework, thus 1214 benefiting from usual ICN features such as data authenticity and 1215 caching, as well as enabling the network to perform various 1216 optimizations, e.g., moving data, code or both closer to 1217 requesters. NFN also enables secure access to individual elements 1218 within Named Data Objects, e.g., for filtering or aggregation. 1220 Edge cloud applications: Use cases include some form of MapReduce 1221 operations and service chaining. NDN, on which NFN is based, has 1222 been studied in the context of IoT, where it can provide local 1223 trust management and rendezvous service. 1225 A.4.2. 5G-CORAL 1227 The 5G-CORAL project ([_5G-CORAL]) aims to enable convergence of 1228 access across multiple radio access technologies using fog computing, 1229 using for this purpose an edge and fog computing system (EFS). 1231 Computing devices: Computing devices used in 5G-CORAL include cloud 1232 and central data center servers, edge data center servers, and 1233 fixed or mobile "fog computing devices", which can be computing 1234 devices located in vehicles or factories, e.g., IoT gateways, 1235 mobile phones, cyber-physical devices, etc. 1237 Service platform: 5G-CORAL architecture is based on an integrated 1238 virtualized edge and fog computing system (EFS), that aims to be 1239 flexible, scalable and interoperable with other domains including 1240 transport (fronthaul, backhaul), core and clouds. An 1241 Orchestration and Control System (OCS) enables automatic discovery 1242 of heterogeneous, multiple-owner resources, and federate them into 1243 a unified hosting environment. OCS monitors resource usage to 1244 guarantee service levels. Finally, OCS also includes 1245 orchestration and life cycle functions, including live migration 1246 and scaling. Applications (user and third-party) both inside and 1247 outside the EFS subscribe to EFS services through APIs, with 1248 emphasis on IoT and cyber-physical functionalities. 1250 Edge cloud applications: EFS-hosted services include analytics 1251 obtained from IoT gateways (e.g., LORA or eNodeB gateways), 1252 context information services from RATs, transport (fronthaul and 1253 backhaul) and core networks. EFS-hosted functions include network 1254 performance acceleration functions, virtualized C-RAN functions 1255 for access nodes and possible end user devices. 1257 A.4.3. FLAME 1259 The FLAME project ([FLAME]) aims to improve performance of 1260 interactive media systems while keeping infrastructure costs low. 1262 It builds over virtualization technologies such as XOS, OpenStack and 1263 ONOS/ODL to offer a programmable media service platform. 1265 FLAME leverages IP-over-ICN technology developed through earlier 1266 projects including POINT ([POINT]). 1268 Computing devices: The FLAME platform provides a service layer on 1269 top of an infrastructure platform, which can include cloud servers 1270 as well as computing devices collocated with WiFi access points. 1272 Service platform: The FLAME platform can be seen as an "edge + 1273 cloud" computing platform with a use case focus on media 1274 dissemination, although the basic platform can be suitable for 1275 micro-services in general. The computing platform is comprised 1276 of: computing devices, an infrastructure platform (XOS, OpenStack, 1277 ONOS/ODL), NFV-MANO components (orchestrator, virtual 1278 infrastructure manager) and FLAME platform core services (PCE, 1279 network access point, surrogate manager). 1281 Edge cloud applications: IoT use cases include public safety, such 1282 as supporting body-worn camera for police and social workers. As 1283 opposed to other multi-media applications that are also envisioned 1284 (pre-processing, user reporting, curation...), where a typical 1285 goal is to curate content early at the edge, to reduce expected 1286 high data volume, public safety use cases are typically about 1287 implementing triggers at the edge: everything needs to be kept 1288 anyway, to be available in case of an audit. Content is stored 1289 offline during off peak-hours delivery. For privacy and data 1290 volume concerns, triggers for, e.g., alerting police, cannot be 1291 performed in the cloud and should be performed as close to the 1292 data source as possible. 1294 Authors' Addresses 1296 Jungha Hong 1297 ETRI 1298 218 Gajeong-ro, Yuseung-Gu 1299 Daejeon 1301 Email: jhong@etri.re.kr 1302 Yong-Geun Hong 1303 ETRI 1304 218 Gajeong-ro, Yuseung-Gu 1305 Daejeon 1307 Email: yghong@etri.re.kr 1309 Xavier de Foy 1310 InterDigital Communications, LLC 1311 1000 Sherbrooke West 1312 Montreal H3A 3G4 1313 Canada 1315 Email: xavier.defoy@interdigital.com 1317 Matthias Kovatsch 1318 Huawei Technologies Duesseldorf GmbH 1319 Riesstr. 25 C // 3.OG 1320 80992 Munich 1321 Germany 1323 Email: ietf@kovatsch.net 1325 Eve Schooler 1326 Intel 1327 2200 Mission College Blvd. 1328 Santa Clara, CA, 95054-1537 1329 United States of America 1331 Email: eve.m.schooler@intel.com 1333 Dirk Kutscher 1334 University of Applied Sciences Emden/Leer 1335 Constantiaplatz 4 1336 26723 Emden 1337 Germany 1339 Email: ietf@dkutscher.net