Convergence of device and data at the Edge Cloud

www.huawei.com
Security Level:
HUAWEI TECHNOLOGIES CO., LTD.
Overview of
Edge and IoT Networks for
Federated Learning
Murali Rangachari, NFV-CC Santa Clara, CA, USA

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential 2
Agenda
 A scan of Edge & IOT Ecosystem
 Emergence of Intelligent Devices
 Overview of Protocols of Device Communications
 Edge Gateways vs Edge Cloud
 Federated Learning Models
 IOT Communications
 Explore Mesh Routing Strategies – 6lowPAN, ZigBee, RPL
 Edge Cloud Designs and Considerations
 Edge Data Strategies for AI

Explosion of IOT Market (from different sources)
 Every indications are that there
will be exponential growth in
Intelligent Devices
 McKinsey reported $11.1 Trillion
market value by 2025
 14 billion connected devices –
Bosch
 5- bn connected devices – Cisco
 309 billion IoT supplier revenue –
Gartner
 1.9 trillion Economic Value-add –
Gartner
 7.1 trillion IoT solutions revenue --
IDC
Source: MIT Review, 2014

Actual vs Projected Number
 Growth better than forecast (IDC**)
 Number of devices (Statista***) -- Actuals 2015(15.41B) 2016(17.68B) 2017(20.35B)
** https://www.enterprise-cio.com/news/2018/jan/04/roundup-of-internet-of-things-forecasts-and-market-estimates-2018/
*** https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

Implications…
 No denying IoT storm is here. We have to manage billions of connected devices
 There will be a “deluge of data” ** by 2020:
 ~1.5 GB of traffic per day from average internet user
 3000 GB per day – Smart Hospitals
 4000 GB per day – self driving cars EACH
 Radars ~10-100 kb per sec
 Sonar ~10-100 kb per sec
 GPS ~50 kb per sec
 UDAR ~10 – 70 MB per sec
 Cameras ~20-40 mb per sec
 40,000 GB per day – connected aircrafts
 1,000,000 GB per day – connected factories
** Keynotes at OFA-2018 by Bill Magro, Intel: https://www.youtube.com/watch?v=x8BOBVTiPVc

Evolution of Devices
 Connected devices & Intelligent Systems are not new
 PLC, SCADA, automated factories have been there since the 1980s
 Electrical/magnetic sensors connected to logic controls
 Mostly dumb sensors connected to intelligent hubs
 Control hubs got more distributed with & miniaturized with micro-controllers
 Biggest push came after cheap ARMs/SOCs emerged
 Reduced cost of intelligent nodes
 Computing scheme changed
 Characteristics of IoT boards of today:
 Has local CPU, memory, NIC, wifi, GPIO, uart, GPS, GSM, LTE… in a small package
 CPU is not very powerful – but sufficient
 Low memory – few MB to few GB at best
 Slow lossy links
 Battery operated (most often at remote locations)

Review of Device Options
 Arduino (https://www.arduino.cc/) – one of the first microcontroller based soc
platform (s/w stack)
 Arduino has a set of devices of their own at various price levels
 Many other boards support Arduino like BLEduino, Airboard etc
 Beagle board (https://beagleboard.org/)
 Can run full linux, very powerful & has good community support
 They have boards ranging from $25 all the way to $1000 with varying capability
 Rasberry Pi (https://www.raspberrypi.org/) – popularized by hobbyists & kids kits
 Zephyr OS – New real time OS (Intel / Windriver promoting)
 Many boards supports -- http://docs.zephyrproject.org/1.5.0/board/board.html
 Cheaper boards emerging today Espressif from China
 ESP8266
 ESP32

Some popular boards
Adafruit
Arduino Uno
Beaglebone
Black
Ras-Pi 3
ESP-8266
ESP-32
CHIP-Pro

Communication Protocols for IoT
 Because the IoT endpoints are intelligent (has CPU), we will need a
communication protocol over low power & lossy channels
 Most protocols are modeled after the web style protocols such as
HTTP(S)/WebSockets with proxies or direct or use message queues
 The scale is much smaller due to restrictions of packet sizes and
transfer rates
 Types of communication type around IoTs
 Device to Gateways – between devices to network gateways
 Device to Device – multi-hop, relay type
 Gateway to Cloud – typical cloud interface today
 Device to Cloud – yes, that is possible too. If the Cloud is at the Edge

Major Communication IoT Protocols Today
 MQTT – Message Queue Telemetry Transport
 Light weight small footprint pub-sub – Standard: ISO/IEC PRF 20922
 Requires a message broker (… resembles corba!)
 Data Agnostic (no standard data structure, just text based labels and
info)
 Messages delivered with or without confirmation or guaranteed but
many (delivery) and guaranteed deliver once only
 CoAP: Contrained Application Protocol – for constrained
nodes & networks for IoT
 Standard: RFC 7252
 Light weight fast HTTP (10s of bytes over 6lowPAN vs 1000s of
bytes in typical http over tcp/ip)
 Specifically for constrained nodes with limited resources
 RESTful interfaces
 May contact device to cloud or via proxy to cloud, or device to device
Broker
Pub
Pub
Pub
Sub
Sub
Sub

Cloud (web) & V2X Protocols
 It is not unusual to see HTTP(S) / Websockets for IOT
 IOT is not only low power devices but has all types of devices
 Video streams, intelligent stations with more powerful Device (ARM64
based etc) use regular web protocols
 Augmented Reality / Virtual reality
 V2X Protocols (Wireless Access for Vehicular Env):
 IEEE 802.11p:
 IEEE 1609.1-4
 SAE 2735
 V2V & V2X protocols: constantly evolving
 IIOT Protocols besides MQTT, CoAP, Websockets: OPC/UA, DDS, AMQP… evolving

Communication Medium
 Generally we have two types of communication – Wired or Wireless
 Wired communications are traditional. IOT is evolving Wireless
 Zigbee: Very popular full stack wireless protocol & supporting s/w
 Not interoperable with other wireless protocols
 Used by wireless light switches, electric meters, IIOT etc
 Fixed 250 kbps data rates
 Limited range like BT
 BT5 – Blue Tooth version 5 – faster, further…
 Widely used protocol extended. Needs multi-hop
 6loWPAN – IEEE 802.15.4
 IPv6 Low Powered Wireless Personal Area Network
 With billions of devices, we have to use IPv6

Wireless MESH
 Because we have a large number of devices with limited power & range,
it is imperative we need to chain them in some way.
 Star topology can work with local hubs
 Hubs can be networked over wired interfaces
 Bus topology – in vehicles such as CAN bus
 Mesh topology -- requires a coordinated communication path
 A number of protocols exist today for Routers
 Examples OSPF, OLSR (Optimized Link-state), ZRP (Zone Routing), DSR (Dynamic Source
Routing) etc
 IOT are low powered and lossy – so most of these protocols don’t work very well
 RPL is gaining popularity in 6loWPAN env
 Major options: IEEE 802.15.4, Zigbee, EnOcean, SIGFOX

Why 6loWPAN / IEEE 802.15.4?
 Let us look into just the 6loWPAN – very active with major players into it
 Other options have their own merits/limitations
 Low powered network of large number of IOT nodes over wireless channels
 If batteries used, it must last several years (5 to 8 years?)
 Self-Organize – meaning must balance by itself (in protocol)
 Limited range of devices means require multi-hop (handle within protocol)
 Coexistence & jamming
 ISM bands can interfere with appliances like microwave (use spread spectrum to mitigate)
 802.11b & Bluetooth don’t work very well when colocated
 The protocol must be interoperable with standard OSI 7 layer networks (L1 to L7)
 Zigbee isn’t compatible to OSI type protocols like tcp/ip
 Must be low cost

How Wireless Technologies Stack-up?
Source: https://people.eecs.berkeley.edu/~prabal/teaching/cs294-11-f05/slides/day21.pdf
NOTE: Old Data (2005) but
shows comparison very well

 An Example Topology
for any 6lowpan
networks
 Source:
http://www.ti.com/lit/wp
/swry013/swry013.pdf
6loWPAN Topology

The 6loWPAN Stack
Source: http://www.ti.com/lit/wp/swry013/swry013.pdf

Source: http://www.ti.com/lit/wp/swry013/swry013.pdf
RPL
OpenThread

DAGs
 Uses Directed Acyclic Graph
 Acyclic as in spanning tree (STP)
 All paths are directed to a
common root
 Types of Nodes:
 FFD – Full Function Device
 Anywhere in Topo
 PAN Coordinator
 RFD – Restricted Function Device
 Limited to Star Topo
 Leaf Node
 Smallest device, no relay
functions

RPL – Destination Oriented DAG (DODAG)
 RPL is a routing protocol
 Distance Vector & Source Routing Protocol
 A node (FFD) that acts as Border Gateway or Router (BR) – assigned an IPv6 address
 The BR has information about all nodes in the neighborhood
 All nodes within its DAG has same prefix
 Neighborhood is built (using link local)
 Intermediate nodes in the DAG has capability to relay or respond to BR (RFD)
 Leaf Nodes can’t relay and are typically connected in Star topology to RFD
 The BR keeps sending DIO (DAG Info Obj) message southbound
 To downstream nodes send DAO (Dest Advt Obj) northbound
 Intermediate nodes will relay it to the root
 Root sends DAO Ack in response to DAO upon which the nodes in DAG sends DIS (DAG
Info Solicitation)
 Now all nodes have found paths to the Root

So many Protocols & Technologies – How do we Converge?
 Use Gateways?
 Limited to protocols
 Protocols are fast evolving so hard to develop custom hardware for all these protocols
 Ties into silos
 What is an Edge Cloud?
 Google Cloud, AWS, Azure… all of them have defined what is their edge – Edge of THEIR Cloud
 For a Cloud Provider, ISP / Access Points are the edge
 For an Enterprise WAN – each branch office is an Edge
 A Cell Phone can be an edge
 A Vehicle in V2X can be an Edge
 V2X will have hubs per city block and relay stations connected to tracking end-points – Edge?
 A building in IIOT could be an Edge – Each floor could be Edges

Enter the World of Federated Learning / Analytics
 What are an Intelligent Systems?
 Each system or sub-system can make decision based on variety of stimulus
 Distributed decision making – because we cannot traverse long distances with so many devices
involved
 The Intelligence is driven by Data – IOT Enables data collection
 We don’t do IOT just because devices are cheap but device got cheap because we needed data from many
resources and someone developed devices tailor made for those -- Necessity
 In-place decision making – need to build hubs of decision making
 What is an Edge?
 An Edge is relative to the Cloud it talks to
 It can be cascaded – GCP-Edge maybe your cloud if You are providing traffic tracking
– Each vehicle is your Edge
– Vehicle is Edge Cloud for Devices within the Car – auto device vendors report to Vehicle Cloud
 Edges are Nodes in Hierarchical Decision Making Infrastructure -- Federated Cloud

Federated Analytics
 Source: Keynotes at ELC-2018
https://www.youtube.com/watch?v=x9haDnOaNzg
 Data is distributed – and so is intelligence
 Multi-layered Edge, Fog and clusters of
Cloud distributed across the globe
 Analytics In-Place at each Edge / Fog
nodes
 Central (logical) distributed cloud services
would work in coordination with edges to
deduce intelligence
 Security (authentication) & spheres of
influence established – hence Federated
 Build Virtual Data & Analytics Fabric
 Challenges:
 Trust, transparency & traceability (security)
 Federated compute frameworks
 Federated learning platforms
 Federated Data Addressing

Networking for Federated Learning at the Edge
 Simple gateways don’t scale – so the
Edge Networking must be deployed as a
Cloud
 The Edge Cloud needs to build gateways
to all types of networks:
 RPL / BT Mesh for device networks
 Information from devices must be translated to
intelligent data at the Edge
 High throughput channels for Video
applications
 Distributed data platform at the Edge to
perform in-place analytics
 Analytics platforms have multi-tiered Edge
Clouds/Fogs as distributed compute nodes –
Replications or MPI?
 Use HPC Tools for distributed cloud platforms

Thank you
www.huawei.com
Copyright©2011 Huawei Technologies Co., Ltd. All Rights Reserved.
The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and
operating results, future product portfolio, new technology, etc. There are a number of factors that could cause actual results and
developments to differ materially from those expressed or implied in the predictive statements. Therefore, such information is provided for
reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time without notice.

Convergence of device and data at the Edge Cloud

More Related Content

What's hot

Similar to Convergence of device and data at the Edge Cloud

More from Michelle Holley

Recently uploaded

Convergence of device and data at the Edge Cloud