idnits 2.17.1 draft-hong-t2trg-iot-edge-computing-00.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBA' is mentioned on line 611, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2T Research Group J. Hong 3 Internet-Draft Y-G. Hong 4 Intended status: Informational ETRI 5 Expires: January 9, 2020 X. de Foy 6 InterDigital Communications 7 M. Kovatsch 8 Huawei Technologies Duesseldorf GmbH 9 E. Schooler 10 Intel 11 D. Kutscher 12 University of Applied Sciences Emden/Leer 13 July 08, 2019 15 Problem Statement of IoT integrated with Edge Computing 16 draft-hong-t2trg-iot-edge-computing-00 18 Abstract 20 This document describes new challenges such as strict latency, uplink 21 cost, uninterrupted services, privacy and security, for IoT services 22 originated from the IoT environmental changes. In order to address 23 those new challenges, the integration of Edge computing and IoT has 24 been emerged as a promising solution. This document discribes the 25 concept of IoT integrated with Edge computing as well as the state- 26 of-the-art of IoT Edge computing. It also proposes an architecture 27 of IoT Edge computing. The direction of Edge computing for IoT 28 should be discussed in the IETF/IRTF. 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 January 9, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Internet of Things (IoT) . . . . . . . . . . . . . . . . 4 68 3.2. Cloud computing . . . . . . . . . . . . . . . . . . . . . 4 69 3.3. Edge computing . . . . . . . . . . . . . . . . . . . . . 5 70 4. New challenges of IoT . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Strict Latency and Jitter . . . . . . . . . . . . . . . . 5 72 4.2. Uplink Cost . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.3. Uninterrupted Services . . . . . . . . . . . . . . . . . 6 74 4.4. Privacy and Security . . . . . . . . . . . . . . . . . . 6 75 5. IoT integrated with Edge Computing . . . . . . . . . . . . . 7 76 5.1. IoT Data in Edge Computing . . . . . . . . . . . . . . . 7 77 5.1.1. Data Storage . . . . . . . . . . . . . . . . . . . . 8 78 5.1.2. Data Processing . . . . . . . . . . . . . . . . . . . 8 79 5.1.3. Data Analyzing . . . . . . . . . . . . . . . . . . . 8 80 5.2. IoT Device Management in Edge Computing . . . . . . . . . 9 81 6. Architecture of IoT integrated with Edge Computing . . . . . 9 82 7. State-of-the-art of IoT Edge Computing . . . . . . . . . . . 11 83 7.1. Common aspects of IoT edge computing service platforms . 11 84 7.2. Use Cases of IoT Edge Computing . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . 14 90 Appendix A. Overview of the IoT Edge Computing . . . . . . . . . 17 91 A.1. Open Source Projects . . . . . . . . . . . . . . . . . . 17 92 A.1.1. Gateway/CPE Platforms . . . . . . . . . . . . . . . . 17 93 A.1.2. Edge Cloud Management Platforms . . . . . . . . . . . 18 94 A.1.3. Related Projects . . . . . . . . . . . . . . . . . . 19 96 A.2. Products . . . . . . . . . . . . . . . . . . . . . . . . 19 97 A.2.1. IoT Gateways . . . . . . . . . . . . . . . . . . . . 19 98 A.2.2. Edge Cloud Platforms . . . . . . . . . . . . . . . . 20 99 A.3. Standards Initiatives . . . . . . . . . . . . . . . . . . 20 100 A.3.1. ETSI Multi-access Edge Computing . . . . . . . . . . 20 101 A.3.2. Edge Computing Support in 3GPP . . . . . . . . . . . 21 102 A.3.3. OpenFog Consortium . . . . . . . . . . . . . . . . . 22 103 A.3.4. Related Standards . . . . . . . . . . . . . . . . . . 22 104 A.4. Research Projects . . . . . . . . . . . . . . . . . . . . 22 105 A.4.1. Named Function Networking . . . . . . . . . . . . . . 22 106 A.4.2. 5G-CORAL . . . . . . . . . . . . . . . . . . . . . . 23 107 A.4.3. FLAME . . . . . . . . . . . . . . . . . . . . . . . . 23 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 110 1. Introduction 112 Nowadays, most IoT services are based on Cloud computing since it can 113 provide virtually unlimited storage and processing power. The 114 integration of IoT with Cloud computing brings many advantages such 115 as flexibility, efficiency, and ability to store and use data. 117 However, the IoT environment is changing in such a way that vast 118 amounts of data are created at edge/local networks and about a half 119 of data is stored, processed, analyzed and acted upon close to the 120 data producer. Thus, emerging IoT services introduce new challenges 121 that cannot be addressed by today's centralized Cloud computing 122 models alone. 124 In this document, we describe new challenges for emerging IoT 125 services such as strict latency, uplink cost, uninterrupted services, 126 privacy and security due to the IoT environmental changes. 128 In order to address those new challenges for IoT services, the 129 integration of Edge computing with IoT has been emerged as a 130 promising solution. In this document, we describe the concept of IoT 131 integrated with Edge computing as well as the state-of-the-art of IoT 132 Edge computing and propose an architecture of IoT Edge computing. 133 The purpose of this document is to bring up the issues of Edge 134 computing for IoT services in IETF/IRTF. 136 2. Conventions and Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Background 144 3.1. Internet of Things (IoT) 146 Since the phrase 'Internet of Things (IoT)' was coined by Kevin 147 Ashton in 1999 working on Radio-frequency identification (RFID) 148 technology at the Auto-ID Center of the Massachusetts Institute of 149 Technology (MIT) [Ashton], the concept of IoT has been that things 150 connected to the Internet can send and receive information collected 151 by sensors without human intervention, where things are various 152 embedded systems such as home appliances, mobile equipment, wearable 153 devices, etc. IoT has become one of the notable innovations playing 154 an important role in our daily lives [Lin]. IoT is generally 155 characterized by real world small things that are widely distributed 156 but have limited storage and processing power, which involve concerns 157 regarding reliability, performance, security, and privacy. 159 3.2. Cloud computing 161 Cloud computing have been defined in [NIST]: "Cloud computing is a 162 model for enabling ubiquitous, convenient, on-demand network access 163 to a shared pool of configurable computing resources (e.g., networks, 164 servers, storage, applications, and services) that can be rapidly 165 provisioned and released with minimal management effort or service 166 provider interaction". Cloud computing has been a predominant 167 technology which has virtually unlimited capacity in terms of storage 168 and processing power. The availability of virtually unlimited 169 storage and processing capabilities at low cost enabled the 170 realization of a new computing model, in which virtualized resources 171 can be leased in an on-demand fashion, being provided as general 172 utilities. Companies like Amazon, Google, Facebook, etc. widely 173 adopted this paradigm for delivering services over the Internet, 174 gaining both economical and technical benefits [Botta]. 176 Now with IoT, we will reach the era of post-Clouds where 177 unprecedented volume and variety of data will be generated by things 178 at edge/local networks and many applications will be deployed on the 179 edge netwoks to consume these IoT data. Some of the applications may 180 need very short response times, some may contain personal data, and 181 others may generate vast amounts of data. Today's Cloud based 182 service models are not suitable for these applications. 184 It is predicted that by 2019, 45% of the data created in IoT will be 185 stored, processed, analyzed and acted close to, or at the edge of the 186 network and about 50 billion devices will connect to the Internet by 187 2020 [Evans]. So, moving all data from edge/local networks to the 188 cloud data center may not be an efficient way anymore to process vast 189 amounts of data. 191 In Cloud computing, users traditionally only consumed IoT data 192 through Cloud services. Now, however, users are also producing IoT 193 data with their mobile devices. This change requires more 194 functionality at edge/local networks [Shi]. 196 3.3. Edge computing 198 Edge computing is a new paradigm in which substantial computing and 199 storage resources are placed at the Internet's edge in close 200 proximity to mobile devices or sensors so that computing happens near 201 data sources [Mahadev]. It works on both downstream data on behalf 202 of cloud services and upstream data on behalf of IoT services. An 203 edge device is any computing or networking resource residing between 204 data sources and cloud-based datacenters. In Edge computing, the end 205 device not only consumes data but also produces data. And at the 206 network edge, devices not only request services and information from 207 the cloud but also handle computing tasks including processing, 208 storage, caching, and load balancing on data sent to and from the 209 cloud [Shi]. 211 The definition of Edge computing from ISO is 'Form of distributed 212 computing in which significant processing and data storage takes 213 place on nodes which are at the edge of the network' [ISO_TR]. And 214 the similar concept of Fog computing from Open Fog Consortium is 'A 215 horizontal, system-level architecture that distributes computing, 216 storage, control and networking functions closer to the users along a 217 cloud-to-thing continuum' [OpenFog]. Based on these definitions, we 218 can summarize a general philosophy of Edge computing as "Distribute 219 the required functions close to users and data". 221 4. New challenges of IoT 223 As the IoT is maturing, systems are converging, deployments are 224 growing, and IoT technology is used with more and more demanding 225 applications such as industrial, automotive, or healthcare. This 226 leads to new challenges for the IoT. In particular, the amount of 227 data created at the edge is expected to be vast. Industrial machines 228 such as laser cutters already produce over 1 terabyte per hour, the 229 same applies for autonomous cars [NVIDIA]. 90% of IoT data is 230 expected to be stored, processed, analyzed, and acted upon close to 231 the source [Kelly], as Cloud Computing models alone cannot address 232 the new challenges [Chiang]. 234 4.1. Strict Latency and Jitter 236 Many industrial control systems, such as manufacturing systems, smart 237 grids, oil and gas systems, etc., often require stringent end-to-end 238 latency between the sensor and control node. While some IoT 239 applications may require latency below a few tens of milliseconds 240 [Weiner], industrial robots and motion control systems have use cases 241 for cycle times in the order of microseconds [_60802]. An important 242 aspect for real-time communications is not only the latency, but also 243 guarantees for jitter. This means control packets need to arrive 244 with as little variation as possible with a strict deadline. Given 245 the best-effort characteristics of the Internet, this challenge is 246 virtually impossible to address with a pure cloud model, when also 247 taking the further challenges into account. 249 4.2. Uplink Cost 251 Many IoT deployments are not challenged by a constrained network 252 bandwidth to the cloud. The fifth generation mobile networks (5G) 253 and Wi-Fi 6 both theoretically top out at 10 gigabits per second 254 (i.e., 4.5 terabyte per hour), which enables high-bandwidth uplinks. 255 However, the resulting cost for high-bandwidth connectivity to upload 256 all data to the cloud is unjustifiable and impractical for most IoT 257 applications. 259 4.3. Uninterrupted Services 261 Many IoT devices such as sensors, data collectors, actuators, 262 controllers, etc. have very limited hardware resources and cannot 263 rely solely on their limited resources to meet all their computing 264 and/or storage needs. They require reliable, uninterrupted services 265 to augment their capabilities in order to fulfill their application 266 tasks. This is hard and partly impossible to achieve with cloud 267 services for systems such as vehicles, drones, or oil rigs that have 268 intermittent network connectivity. 270 4.4. Privacy and Security 272 When IoT services are deployed at home, personal information can be 273 learned from detected usage data. For example, one can extract 274 information about employment, family status, age, and income by 275 analyzing smart meter data [ENERGY]. Policy makers started to 276 provide frameworks that limit the usage of personal data and put 277 strict requirements on data controllers and processors. However, 278 data stored indefinitely in the cloud also increases the risk of data 279 leakage, for instance, through attacks on rich targets. 281 Industrial systems are often argued to not have privacy implications, 282 as no personal data is gathered. Yet data from such systems is often 283 highly classified, as one might be able to infer trade secrets such 284 as the setup of production lines. Hence, the owner of these systems 285 are generally reluctant to upload related IoT to the cloud. 287 5. IoT integrated with Edge Computing 289 As described in section 4, there are new challenges for supporting 290 emerging IoT services and Edge computing is one of the candidates to 291 satisfy these challenges. The motivation for IoT Edge computing was 292 discussed at an Edge computing discussion in IETF/IRTF meetings as 293 follows: [IETF_Edge] 295 o Delay-sensitive 297 o High-volume 299 o Trust-sensitive 301 o (Intermittently) disconnected 303 o Energy-challenged 305 o Costly to transmit 307 As we described at previous sections, the above motivation for IoT 308 Edge computing could directly be benefits of Edge computing in the 309 IoT environment. The above motivation for IoT Edge computing is 310 mainly related to IoT data and other motivation for IoT Edge 311 computing can exist as other aspects of networking and communication. 313 In spite of its benefits, Edge computing in IoT services has 314 challenges such as programmability, naming, data abstraction, service 315 management, privacy and security and optimization metrics. 317 Edge computing can support IoT services independently of Cloud 318 computing. However, Edge computing is increasingly connected to 319 Cloud computing in most IoT systems for processing and storaging 320 data. Thus, the relationship of Edge Computing to Cloud Computing is 321 also another challenge of Edge Computing in IoT [ISO_TR]. 323 5.1. IoT Data in Edge Computing 325 As an aspect of IoT, Edge computing can provide many capabilities for 326 IoT services because IoT systems are based on sensors and actuator 327 devices in edge area and IoT data generated from sensors and actuator 328 devices are gathered through a gateway [ISO_TR]. Besides on IoT 329 data, other functions such as computing, control and network 330 functions are also very remarkable to support IoT services. In this 331 document, we will first concentrate on IoT data's aspect since the 332 benefit of Edge computing with IoT data is very big in use cases. 334 5.1.1. Data Storage 336 As tremendous IoT sensors, IoT actuators, and IoT devices are 337 connected to the Internet, IoT data volume from these things are 338 expected to increase explosively. And it is expected that much of 339 this high volume of IoT data is produced and/or consumed within edge/ 340 local networks, not to traverse through cloud networks. Until now, 341 most IoT data generated by IoT things is transferred and accumulated 342 in a remote server and storage of IoT data in a remote server is 343 expensive in transmission and storage. To mitigate the cost of 344 transmission and storage, it is required to divide IoT data into two 345 types of data; one is stored in edge/local networks and the other is 346 stored in cloud networks. The effect of Edge computing is revealed 347 with the handling IoT data in edge/local networks. 349 5.1.2. Data Processing 351 Until now, most network equipment such as routers, gateways, and 352 switches just forward data delivered from other network devices 353 without reading or modifying the content. In end-to-end 354 communication, data is acknowledged and proceed at a final 355 corresponding node. This is a typical usage of cloud computing and a 356 client-server communication. But, in the IoT environment, some IoT 357 data will be transferred to a cloud network and some will be 358 delivered to an edge node. The main reason of this separation is to 359 provide real-time processing and security enhancement in IoT. 360 Although there are many new technologies to reduce the delay and 361 transmission time, it is not easy to guarantee real-time processing. 362 The typical use case of this requirement is industrial Internet and 363 smart factory. Even though there are also several solutions to 364 provide security in IoT, the more basic rule is not to expose the 365 privacy data to public networks. If we separate IoT data into 366 private and non-private data, and keep private data within an edge/ 367 local network not to expose them in a public network, the security 368 and privacy in IoT cna be addressed by the separation. 370 5.1.3. Data Analyzing 372 If it is possible to separate IoT data in edge/local networks and 373 cloud networks, Edge computing can do more functions with IoT data in 374 edge/local networks. Because Edge computing has the capabilities to 375 handle IoT data in edge/local networks, it is also possible to 376 analyze IoT data to provide enhanced IoT services such as 377 intelligence. To analyze IoT data in an edge/local network, it is 378 required to have comparatively processing performance and this 379 requirement is not obstacle to deploy Edge computing due to the 380 development of H/W and S/W. 382 5.2. IoT Device Management in Edge Computing 384 If we consider new challenges of IoT services, not only the big 385 volume of IoT data but also the massive number of IoT things can be a 386 critical problem. Even though, we acknowledge this future problem, 387 the Internet architecture originally has the capability of 388 scalability and it will mitigate scalability issue in the IoT 389 environment. But, we cannot estimate the number of IoT things in the 390 future and we cannot guarantee the Internet architecture still 391 sustain the scalability issue in the IoT environment. Edge computing 392 will separate the scalability domain into edge/local networks and 393 outside network (e.g., cloud networks) and this separation of 394 scalability domain can provide more efficient way to tackle the 395 massive number of IoT things. 397 Because Edge computing can handle IoT data in an edge area and store 398 the IoT data in an edge node, and proceed IoT data if it is needed, 399 it can also separate the management domain into two parts. Edge 400 Computing can concentrate on management of IoT things in an edge area 401 and cooperate with the management of other outside networks. 403 6. Architecture of IoT integrated with Edge Computing 405 When we consider the implementation and deployment of Edge computing, 406 it can be mainly referred to an IoT Gateway. The role of an IoT 407 Gateway is to provide multiple accesses to the heterogeneous IoT 408 devices/sensors, handling IoT data and delivering the IoT data to the 409 final destinations such as cloud networks. Similar to an IoT 410 Gateway, an Edge computing architecture as an edge computing node 411 provides downside connectivity to IoT sensors and devices (southbound 412 connectivity) and upside connectivity to cloud networks (northbound 413 connectivity). Also, the architecture provides the function of data 414 storage. Beside these functions, the Edge computing architecture 415 should provide the computing functions, such as data processing, data 416 analyzing, and additional function of intelligence. 418 +---------------------------+ 419 | | 420 | Cloud networks | 421 | | 422 +------------+--------------+ 423 | 424 | 425 +----------------------+-----------------------+ 426 | | | 427 | +---------------+---------------+ | 428 | | | | 429 | | Edge gateway function | | 430 | | (Northbound) | | 431 | | | | 432 | +---------------+---------------+ | 433 | | | 434 | +---------------+---------------+ | 435 | | | | 436 | | Edge computing function | | 437 | | (Storage, Processing, | | 438 | | Analyzing, Intelligence) | | 439 | | | | 440 | +---------------+---------------+ | 441 | | | 442 | +---------------+---------------+ | 443 | | | | 444 | | Edge networking function | | 445 | | (Southbound) | | 446 | | | | 447 | +-------------------------------+ | 448 | | 449 | Edge computing node | 450 +-----+-------+------+-------+-------+-------+-+ 451 | | | | | | 452 | | | | | | 453 +---+----+ | +---+----+ | +---+----+ | 454 |Sensor 1| | |Sensor 2| .|.. |Sensor n| | 455 +--------+ | +--------+ | +--------+ | 456 | | | 457 | | | 458 +----+---+ +-----+--+ +-----+--+ 459 |Device 1| |Device 2| .... |Device n| 460 +--------+ +--------+ +--------+ 462 Figure 1: Architecture of IoT integrated with Edge computing 464 It is expected that the Edge computing architecture will play an 465 important role to deploy new IoT services with integration to big 466 data and AI services. 468 7. State-of-the-art of IoT Edge Computing 470 7.1. Common aspects of IoT edge computing service platforms 472 This section provides an overview of today's IoT Edge Computing 473 field, based on a limited review of standards, research, open-source 474 and proprietary products in Appendix A. Common aspects of IoT edge 475 computing service platforms are summarized here: 477 Computing devices: IoT gateways (Appendix A.2.1, Appendix A.1.1) 478 represent a common class of IoT edge computing products, where the 479 gateway is providing a local service on customer premises, and is 480 remotely managed through a cloud service. IoT communication 481 protocols are typically used between IoT devices and the gateway, 482 including CoAP, MQTT and many specialized IoT protocols, while the 483 gateway communicates with the distant cloud using typically HTTP 484 and WebSocket. 486 Virtualization platforms enable the deployment of virtual edge 487 computing functions, including IoT gateway software, on servers in 488 the mobile network infrastructure (at base station and 489 concentration points), in edge datacenters (in central offices) or 490 regional datacenters located near central offices. 492 End devices as computing devices are envisioned in fog 493 architecture and research projects, but are not commonly used as 494 such today. 496 Service models: Physical or virtual IoT gateways can host 497 application programs built using an SDK. 499 Edge cloud system operators host their customers' applications VMs 500 or containers on servers located in or near access networks. 501 These application have access to edge service APIs. For example, 502 mobile network services include radio network information, 503 location, bandwidth management. 505 In a cloud-like service model, service providers consume low-level 506 edge platform APIs and offer high-level APIs to their own 507 customers' applications. This cloud-like model can be offered as 508 an edge cloud service, or as an hybrid cloud service covering edge 509 and distant cloud. 511 Management: Life cycle management of services and applications on 512 physical IoT gateways is often cloud-based. Edge cloud management 513 platforms and products (Appendix A.1.2, Appendix A.2.2) adapt 514 cloud management technologies (e.g. kubernetes) to the edge cloud, 515 i.e. to smaller, distributed computing devices running outside a 516 controlled data center. Services and application life-cycle is 517 typically using a NFV-like management and orchestration model. 519 Communication services: The platform typically includes services to 520 advertise or consume APIs, and enables communicating with local 521 and remote endpoints. The service platform is typically 522 extensible by edge applications, since they can advertise an API 523 that other edge applications can consume. IoT communication 524 services include protocols translation, analytics and transcoding. 525 Communication between edge computing devices is enabled in tiered 526 deployments or distributed deployments. 528 Storage models: An edge cloud platform may enable pass-through 529 without storage, local storage (e.g. on IoT gateways). Some edge 530 cloud platforms use a distributed form of storage, e.g. an ICN 531 network or a distributed storage platform. External storage, e.g. 532 on databases in distant or local IT cloud, is typically used for 533 filtered data deemed worthy of long term storage, or in some cases 534 for all data, for example when required for regulatory reasons. 536 Computing models: Stateful computing is supported on platforms 537 hosting native programs, VMs or containers. Stateless computing 538 is supported on platforms providing a "serverless computing" 539 service (a.k.a. function-as-a-service), or on systems based on 540 named function networking. 542 Network traffic patterns: Network traffic is typically high volume 543 uplink with throttling by edge computing devices (or deferred to 544 off-peak hours or using physical shipping); and downlink for 545 control and software updates. 547 7.2. Use Cases of IoT Edge Computing 549 Smart Constructions: In traditional construction domain, there are 550 many heavy equipment and machineries and dangerous elements. Even 551 though human pay attention to risk elements, it is not easy to 552 avoid them. If some accidents are happened in a construction 553 site, it causes a loss of lives and property. Thus, there have 554 been many trials in a construction area to protect lives and 555 property. Measurements of noise, vibration, and gas in a 556 construction area are recorded on a remote server and reported to 557 an inspector. Today, data produced bu such measurements is 558 collected by a gateway in a construction area and transferred to a 559 remote server. This incurs transmission cost, e.g. over a LTE 560 connection, and storage cost, e.g. when using Amazon Web Services. 561 When an inspector wants to investigate some accidents, he checks 562 the information stored in a server. If we deploy Edge computing 563 in a construction area, the sensor data can be processed and 564 analyzed in a gateway located within or near a construction area. 565 And with the help of a statistical analysis or machine learning 566 technologies, we can predict future accidents in advance and this 567 prediction can be used as an alarm in a construction area and a 568 notification to an inspector. To determine the exact cause of 569 some accident, not only sensor data but also audio and video data 570 are transferred to a remote server or cloud networks. In this 571 case, the data volume of audio and video is quite big and the cost 572 of transmission can be a problem. If Edge computing can predict 573 the time of accident, it can reduce the data volume of 574 transmission; in general period, it can transmit the audio and 575 video data with a low resolution/degree and in emergent period, it 576 transmits the audio and video data with a high resolution/degree. 577 By adjusting the resolution/degree of audio and video data, it can 578 reduce transmission cost significantly. 580 Smart Grid: In future smart cities, Smart grids will be critical in 581 ensuring availability and efficiency for energy saving and control 582 in city-wide electricity management. Edge computing is expected 583 to play a significant role in those systems to improve 584 transmission efficiency of electricity, react and restore for 585 power disturbances, reduce operation cost, reuse renewable energy 586 effectively, save energy of electricity for future usage, and so 587 on. In addition, Edge computing can help monitoring power 588 generation and power demands, and making electrical energy storage 589 decisions in the Smart grid system. 591 Smart Water System: The Water system is one of the most important 592 aspects for building smart city. Effective use of water, and 593 cost-effective and environment-friendly treatment of water are 594 critical for water control and management. This can be 595 facilitated by Edge computing in Smart water systems, to help 596 monitor water consumption, transportation, prediction of future 597 water use, and so on. For example, water harvesting and ground 598 water monitoring will be supported from Edge computing. Also, a 599 Smart water system is able to analyze collected information 600 related to water control and management, control the reduction of 601 water losses and improve the city water system through Edge 602 computing. 604 Smart Buildings: [TBA] 606 Smart Cities: [TBA] 607 Connected Vehicles: [TBA] 609 8. Security Considerations 611 [TBA] 613 9. Acknowledgements 615 The authors would like to thank Joo-Sang Youn and Akbak Rahman for 616 their valuable comments and suggestions on this document. 618 10. References 620 10.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 10.2. Informative References 629 [Ashton] Ashton, K., "That Internet of Things thing", RFID J. vol. 630 22, no. 7, pp. 97-114, 2009. 632 [Lin] Lin, J., Yu, W., Zhang, N., Yang, X., Zhang, H., and W. 633 Zhao, "A survey on Internet of Things: Architecture, 634 enabling technologies, security and privacy, and 635 applications", IEEE Internet of Things J. vol. 4, no. 5, 636 pp. 1125-1142, Oct. 2017. 638 [NIST] Mell, P. and T. Grance, "The NIST definition of Cloud 639 computing", Natl. Inst. Stand. Technol 53 (6), pp. 50, 640 2009. 642 [Botta] Botta, A., Donato, W., Persico, V., and A. Pescape, 643 "Integration of Cloud computing and Internet of Things: A 644 survey", Future Gener. Comput. Syst. 56, pp. 684-700, 645 2016. 647 [Evans] Evans, D., "The Internet of Things: How the next evolution 648 of the Internet is changing everything", CISCO White 649 Paper vol. 1, pp. 1-11, 2011. 651 [Shi] Shi, W., Cao, J., Zhang, Q., Li, Y., and L. Xu, "Edge 652 computing: vision and challenges", IEEE Internet of Things 653 J. vol. 3, no. 5, pp. 637-646, Oct. 2016. 655 [Mahadev] Satyanarayanan, M., "The Emergence of Edge Computing", 656 Computer vol. 50, no. 1, pp. 30-39, Jan. 2017. 658 [Chiang] Chiang , M. and T. Zhang, "Fog and IoT: An overview of 659 research opportunities", IEEE Internet Things J. vol. 3, 660 no. 6, pp. 854-864, Dec. 2016. 662 [Weiner] Weiner, M., Jorgovanovic, M., Sahai, A., and B. Nikolie, 663 "Design of a low-latency, high-reliability wireless 664 communication system for control applications", IEEE Int. 665 Conf. Commun. (ICC) Sydney, NSW, Australia, pp. 3829-3835, 666 2014. 668 [Kelly] Kelly, R., "Internet of Things Data to Top 1.6 Zettabytes 669 by 2022", 670 https://campustechnology.com/articles/2015/04/15/internet- 671 of-thingsdata-to-top-1-6-zettabytes-by-2020.aspx , April 672 2016. 674 [ISO_TR] "Information Technology - Cloud Computing - Edge Computing 675 Landscape", ISO/IEC TR 23188 , April 2018. 677 [OpenFog] "OpenFog Reference Architecture for Fog Computing", 678 OpenFog Consortium , Feb. 2017. 680 [IETF_Edge] 681 Kutscher, D. and E. Schooler, "IoT Edge Computing 682 Discussion @ IETF-98", slides-99-t2trg-edge-computing- 683 summary-of-chicago-discussion-and-ideas-for-next- 684 steps-00 , Mar. 2017. 686 [ETSI_MEC_03] 687 ETSI, "Mobile Edge Computing (MEC); Framework and 688 Reference Architecture", ETSI GS 003, 2019, 689 . 692 [ETSI_MEC_02] 693 ETSI, "Multi-access Edge Computing (MEC); Phase 2: Use 694 Cases and Requirements", ETSI GS 002, 2016, 695 . 698 [_3GPP.23.501] 699 3GPP, "System Architecture for the 5G System", 3GPP 700 TS 23.501, 2019, 701 . 703 [ETSI_MEC_WP_28] 704 ETSI, "MEC in 5G networks", White Paper , June 2018, 705 . 708 [Linux_Foundation_Edge] 709 Linux Foundation, "Linux Foundation Edge", Portal , 2019, 710 . 712 [StarlingX] 713 OpenStack Foundation, "StarlingX", Portal , 2019, 714 . 716 [Sifalakis] 717 Sifalakis, M., Kohler, B., Scherb, C., and C. Tschudin, 718 "An Information Centric Network for Computing the 719 Distribution of Computations", Proceedings of the 1st 720 international conference on Information-centric 721 networking INC '14, 2014. 723 [FLAME] Horizon 2020 Programme, "FLAME Project", Portal , 2019, 724 . 726 [POINT] Horizon 2020 Programme, "IP Over ICN - the better IP 727 (POINT) Project", Portal , 2019, 728 . 730 [_5G-CORAL] 731 Horizon 2020 Programme, "5G Convergent Virtualised Radio 732 Access Network Living at the Edge (5G-CORAL) Project", 733 Portal , 2019, . 735 [OpenEdgeComputing] 736 "Open Edge Computing", Portal , 2019, 737 . 739 [IEEE-1934] 740 IEEE, "FOG - Fog Computing and Networking Architecture 741 Framework", Portal , 2019, 742 . 744 [NVIDIA] Grzywaczewski, A., "Training AI for Self-Driving Vehicles: 745 the Challenge of Scale", NVIDIA Developer Blog , October 746 2017, . 749 [_60802] IEEE 802, "Use Cases IEC/IEEE 60802 V1.3", IEC/IEEE 750 60802 , September 2018, 751 . 754 [ENERGY] Beckel, C., Sadamori, L., Staake, T., and S. Santini, 755 "Revealing Household Characteristics from Smart Meter 756 Data", Energy vol. 78, pp. 397-410, December 2014, 757 . 760 Appendix A. Overview of the IoT Edge Computing 762 This list of initiatives, projects and products aim to provide an 763 overview of the IoT Edge Computing. Our goal is to be representative 764 rather than exhaustive. Please help us complete this overview by 765 communicating with us about entries we have missed. 767 A.1. Open Source Projects 769 A.1.1. Gateway/CPE Platforms 771 EdgeX Foundry, Home Edge, Edge Virtualization Engine are Linux 772 Foundation projects ([Linux_Foundation_Edge]) aiming to provide a 773 platform for edge computing devices. Such an open source platform 774 can, for example, host proprietary programs currently run on IoT 775 gateway products (Appendix A.2). EdgeX Foundry develops an edge 776 computing framework running on the IoT gateway. Home Edge develops 777 an edge computing framework especially dedicated to home computing 778 devices, controlling home appliances, sensors, etc., and enabling AI 779 applications, especially distributed and parallel machine learning. 780 The Edge Virtualization Engine (EVE) project develops a 781 virtualization platform (for VMs and containers) designed to run 782 outside of the datacenter, in an edge network; EVE is deployed on 783 bare-metal hardware. 785 Computing devices: Hardware support for EdgeX and EVE is similar: 786 they support x86 and ARM-based computing devices; A typical target 787 can be a Linux Raspberry Pi with 1GB RAM, 64bit CPU, 32GB storage. 789 Service platform: EdgeX uses a micro-service architecture. Micro- 790 services on the gateway are connected together, and to outside 791 applications, through REST, or messaging technologies such as 792 MQTT, AMQP and 0MQ. The gateway can communicate with external 793 backend applications or other gateways (north-south in tiered 794 deployments or east-west in more distributed deployments). 795 Gateway-device communication can use a wide range of IoT 796 protocols. "Export services" enable on-gateway and off-gateway 797 clients to register as recipient for data from devices. Core 798 services are microservices that deal with persisting data from 799 devices or alternatively "streaming" device data through, without 800 persistence (core data service); managing information about the 801 IoT devices, including their sensors, how to communicate with 802 them, etc. (metadata service); and actual communication with IoT 803 devices, on behalf of other on-gateway or off-gateway services 804 (command service). A rule engine provides an API to register 805 actions in response to conditions typically including an IoT 806 device ID, sensor values to check, thresholds, etc. The 807 scheduling micro service deals with organizing the removal of data 808 persisted on the gateway. Alerts and notifications microservice 809 can be used to dispatch alert/notifications from internal or 810 external sources to interested consumers including backend 811 servers, or human operators through email or SMS. 813 Edge cloud applications: Target applications for EdgeX include 814 industrial IoT (e.g. IoT sensor data and actuator control mixed 815 with augmented reality application for technicians). Home Edge 816 focuses on smart home use cases, including using AI lifestyle and 817 safety applications. 819 A.1.2. Edge Cloud Management Platforms 821 This set of open-source projects setup and manage clouds of 822 individual edge computing devices. StarlingX ([StarlingX]) extends 823 OpenStack to provide virtualization platform management for edge 824 clouds, which are distributed (in the range of 100 compute devices), 825 secure and highly available. Akraino Edge Stack, another project 826 from the Linux Fundation Edge [Linux_Foundation_Edge], has a wider 827 scope of developing a management platform adapted for the edge (e.g., 828 covering 1000 plus locations), aiming for zero-touch provisioning, 829 and zero-touch lifecycle management. 831 Computing devices: Compute devices are typically Linux-based 832 application servers or more constrained devices. 834 Service platform: StarlingX adds new management services to 835 OpenStack by leveraging building blocks such as Ceph for 836 distributed storage, Kubernetes for orchestration. The new 837 services are for management of configuration (enabling auto- 838 discovery and configuration), faults, hosts (enabling host failure 839 detection and auto-recovery), services (providing high 840 availability through service redundancy and multi-path 841 communication) and software (enabling updates). 843 Edge cloud applications: An edge computing platform may support a 844 wide range of use cases. E.g., autonomous vehicles, industrial 845 automation and robotics, cloud RAN, metering and monitoring, 846 mobile HD video, content delivery, healthcare imaging and 847 diagnostics, caching and surveillance, augmented/virtual reality, 848 small cell services for high density locations (stadiums), 849 universal CPE applications, retail. 851 A.1.3. Related Projects 853 Open Edge Computing ([OpenEdgeComputing]) is an initiative from 854 universities, manufacturers, infrastructure providers and operators, 855 enabling efficiently offloading cloudlets (VMs) to the edge. 856 Computing devices are typically powerful, well-connected servers 857 located in mobile networks (e.g. collocated with base stations or 858 aggregation sites). The service platform is built on top of 859 OpenStack++, an extension of OpenStack to support cloudlets. This 860 project is mentioned here as a related project because of its edge 861 computing focus, and potential for some IoT use cases. Nevertheless, 862 its primary use cases are typically non-IoT related, such as 863 offloading processing-intensive applications from a mobile device to 864 the edge. 866 A.2. Products 868 A.2.1. IoT Gateways 870 Multiple products are marketed as IoT gateways (Amazon Greengrass, 871 Microsoft Azure IoT Edge, Google Cloud IoT Core, and gateway 872 solutions from Bosh and Siemens). They are typically composed of a 873 software frameworks that can run on a wide range of IoT gateway 874 hardware devices to provide local support for cloud services, as well 875 as some other local IoT gateway features such as relaying 876 communication and caching content. Remote cloud is both used for 877 management of the IoT gateways, and for hosting customer application 878 components. Some IoT gateway products (Amazon Snowball) have a 879 primary purpose of storing edge data on premises, to enable 880 physically moving this data into the cloud without incurring digital 881 data transfer cost. 883 Computing devices: Typical computing devices run Linux, Windows or a 884 Real-Time OS over an ARM or x86 architecture. The level of 885 service support on the computing device can range from low-level 886 packages giving maximum control to embedded developers, to high- 887 level SDKs. Typical requirements can start at 1GHz and 128MB RAM, 888 e.g. ranging from Raspberry Pi to a server-level appliance. 890 Service platform: IoT gateways can provide a range of service 891 including: running stateless functions; routing messages between 892 connected IoT devices (using a wide range of IoT protocols); 893 caching data; enabling some form of synchronization between IoT 894 devices; authenticating and encrypting device data. Association 895 between IoT devices and gateway based can require a device 896 certificate. 898 Edge cloud applications: Pre-processing of IoT data for later 899 processing in the Cloud is a major driver. Use cases include 900 industrial automation, farming, etc. 902 A.2.2. Edge Cloud Platforms 904 Services such as MobileEdgeX provide a platform for application 905 developers to deploy software (e.g. as software containers) on edge 906 networks. 908 Computing devices: Bare metal and virtual servers provided by mobile 909 network operators are used as computing devices. 911 Service platform: The service platform provides end device location 912 service, using GPS data obtained from platform software deployed 913 in end devices, correlated with location information obtained from 914 the mobile network. The service platform manages the deployment 915 of application instances (containers) on servers close to end 916 devices, using a declarative specification of optimal location 917 from the application provider. 919 Edge cloud applications: Use cases include autonomous mobility, 920 asset management, AI-based systems (e.g. quality inspection, 921 assistance systems, safety and security cameras) and privacy- 922 preserving video processing. There are also non-IoT use cases 923 such as augmented reality and gaming. 925 A.3. Standards Initiatives 927 A.3.1. ETSI Multi-access Edge Computing 929 The ETSI MEC industry standardization group develops specifications 930 that enable efficient and seamless integration of applications from 931 vendors, service providers, and 3rd parties across multi-vendor MEC 932 platforms ([ETSI_MEC_03]). Basic principles followed include: 933 leveraging NFV infrastructure; being compliant with 3GPP systems; 934 focusing on orchestration, MEC services, applications and platforms. 935 Phase 1 (2015-2016) focused on basic platform services. Phase 2 936 (2017-2019) focuses on: supporting non-3GPP radio access 937 technologies, especially WiFi; supporting a distributed, multi- 938 operator and multi-vendor architecture; supporting non-VM based 939 virtualization such as containers and PaaS. 941 Computing devices: Computing devices are typically application 942 servers, attached to an eNodeB or at a higher level of aggregation 943 point, and provide service to end users. 945 Service platform: The mobile edge platform offers an environment 946 where the mobile edge applications can discover, advertise, 947 consume and offer mobile edge services. The platform can provide 948 certain native services such as radio network information, 949 location, bandwidth management etc. The platform manager is 950 responsible for managing the life cycle of applications including 951 informing the mobile edge orchestrator of relevant application 952 related events, managing the application rules and requirements 953 including service authorizations, traffic rules, DNS 954 configuration. 956 Edge cloud applications: Some of the use cases for MEC 957 ([ETSI_MEC_02]) are IoT-related, including: security and safety 958 (face recognition and monitoring), sensor data monitoring, active 959 device location (e.g., crowd management), low latency vehicle-to- 960 infrastructure and vehicle-to-vehicle (V2X, e.g., hazard 961 warnings), video production and delivery, camera as a service. 963 A.3.2. Edge Computing Support in 3GPP 965 The 3GPP standards organization included edge computing support in 5G 966 [_3GPP.23.501]. Integration of MEC and 5G systems has been studied 967 in ETSI as well [ETSI_MEC_WP_28]. 969 Computing devices: From 3GPP standpoint, a mobile device may access 970 any computing device located in a local data network, i.e. traffic 971 is steered towards the local data network where the computing 972 device is located. 974 Service platform: An external party may influence steering, QoS and 975 charging of traffic towards the computing device. Session and 976 service continuity can ensure that edge service is maintained when 977 a client device moves. The network supports multiple-anchor 978 connections, which makes it possible to connect a client device to 979 both a local and a remote data network. The client device can be 980 made aware of the availability of a local area data network, based 981 on its location. 983 Edge cloud applications: Edge cloud applications in 3GPP can help 984 support the major use cases envisioned for 5G, including massive 985 IoT and V2X. 987 A.3.3. OpenFog Consortium 989 The OpenFog Consortium (now part of the Industrial Internet 990 Consortium) aims to standardize industrial IoT, fog and edge 991 computing. It produced a reference architecture for the Fog 992 ([OpenFog]), which has been published as IEEE standard P1934 in 2018. 994 Computing devices: Fog nodes include computational, networking, 995 storage and acceleration elements. This includes nodes collocated 996 with sensors and actuators, roadside or mobile nodes involved in 997 V2X connectivity. Fog nodes should be programmable and may 998 support multi-tenancy. Fog computing devices must employ a 999 hardware-based immutable root of trust, i.e. a trusted hardware 1000 component which receives control at power-on. 1002 Service platform: The service platform is structured around 1003 "pillars" including: security end-to-end, scalability by adding 1004 internal components or adding more fog nodes, openness in term of 1005 discovery of/by other nodes and networks, autonomy from 1006 centralized clouds (for discovery, orchestration and management, 1007 security and operation) and hierarchical organization of fog 1008 nodes. 1010 Edge cloud applications: Major use cases include smart cars and 1011 traffic control, visual security and surveillance, smart cities. 1013 A.3.4. Related Standards 1015 The IEEE Fog Computing and Networking Architecture Framework Working 1016 Group [IEEE-1934] published the OpenFog architecture as an IEEE 1017 document, and plan to do further work on taxonomy, architecture 1018 framework, and compliance guidelines. 1020 A.4. Research Projects 1022 A.4.1. Named Function Networking 1024 Named Function Networking ([Sifalakis]) is a research project that 1025 aims to extend ICN concepts (especially named data networking) to 1026 have the network orchestrate computation. Interests are sent for a 1027 combination of function and argument names, instead of using the 1028 content name in NDN. 1030 Computing devices: NFN-capable switches are collocated with 1031 computing devices. 1033 Service platform: NFN enables accessing static data and dynamic 1034 computation results in one data-oriented framework, thus 1035 benefiting from usual ICN features such as data authenticity and 1036 caching, as well as enabling the network to perform various 1037 optimizations, e.g. moving data, code or both closer to 1038 requesters. NFN also enables secure access to individual elements 1039 within Named Data Objects, e.g. for filtering or aggregation. 1041 Edge cloud applications: Use cases include some form of MapReduce 1042 operations and service chaining. NDN, on which NFN is based, has 1043 been studied in the context of IoT, where it can provide local 1044 trust management and rendezvous service. 1046 A.4.2. 5G-CORAL 1048 The 5G-CORAL project ([_5G-CORAL]) aims to enable convergence of 1049 access across multiple RATs using Fog computing, using for this 1050 purpose an Edge and Fog Computing System (EFS). 1052 Computing devices: Computing devices used in 5G-CORAL include cloud 1053 and central data center servers, edge data center servers, and 1054 fixed or mobile "Fog Computing Devices", which can be computing 1055 devices located in vehicles or factories, e.g. IoT gateways, 1056 mobile phones, cyber-physical devices, etc. 1058 Service platform: 5G-CORAL architecture is based on an integrated 1059 virtualized edge and fog computing system (EFS), that aims to be 1060 flexible, scalable and interoperable with other domains including 1061 transport (fronthaul, backhaul), core and clouds. An 1062 Orchestration and Control System (OCS) enables automatic discovery 1063 of heterogeneous, multiple-owner resources, and federate them into 1064 a unified hosting environment. OCS monitors resource usage to 1065 guarantee service levels. Finally, OCS also includes 1066 orchestration and life cycle functions, including live migration 1067 and scaling. Applications (user and third-party) both inside and 1068 outside the EFS subscribe to EFS services through APIs, with 1069 emphasis on IoT and cyber-physical functionalities. 1071 Edge cloud applications: EFS-hosted services include analytics 1072 obtained from IoT gateways (e.g. LORA or eNodeB gateways), 1073 context information services from RATs, transport (fronthaul and 1074 backhaul) and core networks. EFS-hosted functions include network 1075 performance acceleration functions, virtualized C-RAN functions 1076 for access nodes and possible end user devices. 1078 A.4.3. FLAME 1080 The FLAME project ([FLAME]) aims to improve performance of 1081 interactive media systems while keeping infrastructure costs low. It 1082 builds over virtualization technologies such as XOS, OpenStack and 1083 ONOS/ODL to offer a programmable media service platform. FLAME 1084 leverages IP-over-ICN technology developed through earlier projects 1085 including POINT ([POINT]). 1087 Computing devices: The FLAME platform provides a service layer on 1088 top of an infrastructure platform, which can include cloud servers 1089 as well as computing devices collocated with WiFi access points. 1091 Service platform: The FLAME platform can be seen as an edge + cloud 1092 computing platform with a use case focus on media dissemination, 1093 although the basic platform can be suitable for micro-services in 1094 general. The computing platform is comprised of: computing 1095 devices, an infrastructure platform (XOS, OpenStack, ONOS/ODL), 1096 NFV-MANO components (orchestrator, virtual infrastructure manager) 1097 and FLAME platform core services (PCE, network access point, 1098 surrogate manager). 1100 Edge cloud applications: IoT use cases include public safety, such 1101 as supporting body-worn camera for police and social workers. As 1102 opposed to other multi-media applications that are also envisioned 1103 (pre-processing, user reporting, curation...), where a typical 1104 goal is to curate content early at the edge, to reduce expected 1105 high data volume, public safety use cases are typically about 1106 implementing triggers at the edge: everything needs to be kept 1107 anyway, to be available in case of an audit. Content is stored 1108 offline during off peak-hours delivery. For privacy and data 1109 volume concerns, triggers for, e.g., alerting police, cannot be 1110 performed in the cloud and should be performed as close to the 1111 data source as possible. 1113 Authors' Addresses 1115 Jungha Hong 1116 ETRI 1117 218 Gajeong-ro, Yuseung-Gu 1118 Daejeon 34129 1119 Korea 1121 Email: jhong@etri.re.kr 1123 Yong-Geun Hong 1124 ETRI 1125 218 Gajeong-ro, Yuseung-Gu 1126 Daejeon 34129 1127 Korea 1129 Email: yghong@etri.re.kr 1130 Xavier de Foy 1131 InterDigital Communications, LLC 1132 1000 Sherbrooke West 1133 Montreal H3A 3G4 1134 Canada 1136 Email: Xavier.Defoy@InterDigital.com 1138 Matthias Kovatsch 1139 Huawei Technologies Duesseldorf GmbH 1140 Riesstr. 25 C // 3.OG 1141 Munich 80992 1142 Germany 1144 Email: matthias.kovatsch@huawei.com 1146 Eve Schooler 1147 Intel 1149 Email: eve.m.schooler@intel.com 1151 Dirk Kutscher 1152 University of Applied Sciences Emden/Leer 1153 Constantiaplatz 4 1154 Emden 26723 1155 Germany 1157 Email: ietf@dkutscher.net