1. CloudMAC: Moving 802.15.4 MAC frames processing of the Sink to Cloud

2. Background: 802.15.4 standard 802.15.4 standardized physical layer and link layer protocol for wireless sensor networks.

3. Scenario: Smart home Many WSN applications are potentially be deployed for smart home Security: image sensors Smart meter: gas meter sensor, water meter sensor Door control, window control: door sensor, occupation sensor, window light sensor Atmosphere control: HVAC sensors, temperature Light control system: light sensor, occupation sensor Environment monitoring system: CO2, temperature, …. Sensors Remote control: remote adaptor, power control, smart fridge, smart air conditioner, smart light control,…

4. Problem Statement 1 Although 802.15.4 is standardized protocol for the physical and link layer of WSNs, there are variety different implementation for MAC layer and upper layer such as application protocols: Zigbee 6LoWPAN ISA …. Different sensors from different manufacturers may use different application protocols  incompatible problem! In such a smart home environment with different applications, separate systems in which sensor devices may be produced using different MAC technologies from different manufacturers,…  result in interoperability problem.  leading to the following cases Multi-sink/ Gateways required for one smart home: Each application/system is deployed with a Gateway. This is the current fact of smart home applications, each system may be corresponding with a GW in a set.  home security from company A, smart fridge from company B, smart light control from company C, smart door/ windows control from company D, gas and smart meter from company E, HVAC system from company F,….  your house becomes a storage of bundle of Gateways One Sink/GW and monopoly problem: If want only one Gateway, then we have to buy every application, sensor from the same manufacturer  not good and even not possible

5. Problem Statement 2: Security and Management Security is a big big concern to realize IoT these days. Sensors are constrained devices, not possible for complex security mechanism  weak Considering conventional sink node/ GW deployment at home: A sink/ GW is deployed at home to forward data from sensor data to Internet. Security functions many be deployed there based on this hardware. Limited functions and applications can be deployed due to a limited capability of such a hardware of the sink It is not feasible for a home owner to buy devices for security purpose for their smart home network such as firewalls, IDS system,… For security, software/ applications need to be updated regularly. But it is not feasible for such a smart home gateway, not easy for normal users to update GWs and GWs are normally fixed by manufacturer. Difficult for management and to upgrade GWs when want to deploy new brand sensors or applications,…

6. Problem Statement 3: Network operators/ providers want to easily gather and manage IoT data Network operators/ providers want a solution to gather and manage all IoT data Current GW for each smart home application is implemented by manufacturers of the application

7. IoT cloud is a trend

8. IoT-cloud: In the view of data perspective IoT cloud is a trend. In such a trend, IoT data will be gathered to Cloud, exploit powerful resources of Cloud for processing and distribution  Should network plane of Iot should also be changed following the trend?  may need to re-think about the network architecture for IoT toward cloud

9. vSink CloudMAC Ideas

10. Proposed ideas: vSink CloudMAC Targets: One physical sink can support different 802.15.4 tech devices or application protocols (i.e., zigbee, 6LoWPAN – CoAP, MQTT,…) from different manufacturers. Reduce processing load at the physical sink Easier management, flexible update Suppose to be a secured solution for IoT deployment Enable operators to control and manage IoT traffic in smart home

11. Proposed ideas: vSink CloudMAC Virtualize 802.15.4 MAC frame processing, and separating the physical sink from logical one denoted as vSink Moving all MAC frames processing at the conventional sink to the Cloud. Physical sink just forwards MAC frames to a virtual sink in Cloud Off loading MAC layer processing to virtual sink/ virtual machine provided by cloud services

12. Proposed ideas: vSink CloudMAC vSink can be a virtual machine deployed using OpenStack. We define vSink as a network function including several network function component

13. vSink CloudMAC: What are Benefits?

14. vSink : one sink for different 802.15.4 devices Benefits 1:  without processing MAC and upper layer packets  physical sink can be GW for any 802.15.4 devices  unified sink/ GW for smart home, cutting cost of deployment, avoid monopoly in smart home applications Reduce processing load for physical sink

15. vSink : Secured solution vSink is implemented using NFV on cloud of operators/ network providers Exploit security-as-a-service using NFV for sensor traffic such as firewall, authentication, threat detection, IDS,..  improve security for IoT. Tools/ software of the virtual sink can be updated easily by operator/ network providers  more secured

16. vSink : For Network operators/ providers vSink is deployed in data center of operators/ network providers,… All IoT smart home traffic is routed to their networks Operators can gather and manage IoT data  valuable data Operator can provide vsink-as-a-service for smart home. vSink can be deployed in data center of the operator so that operator can control and manage IoT traffic. That is what they really want to do Data means…money

17. vSink : For Management Easier and flexible in management As vSink is deployed in Cloud, it is easier for the service provider to manage using a centralized approach Easy to update software, update new type of services or specs for new type of devices Faster react to failures or network problems

18. vSink : Higher Availability In the current architecture, if the sink is failed by many reasons(i.e., protocol errors, outdated software, security attack like DDOS, …), data from sensors cannot be forwarded to the Internet. Moving data processing to vSink using NFV in Cloud, traffic can be filtered before reach to the sink, thus attacks. Processing in physical sink is much simpler, not require multiple protocols like before  reduce errors. The complexity is put into vSink. When virtual Sink fails, NFV may have reliable mechanisms for quickly recover or use backup node,…, to process incoming sensor data.

19. vSink CloudMAC: Is it feasible? We think Yes! Moving processing to cloud is the trend. Let’s see what is going on in this topic?

20. Mobile network: C-RAN Cloud Radio Access Network Move processing to cloud to enable scalability, agility, faster service delivery, cost savings, and improve coordination of radio capabilities.

21. Wifi Network: CMAC wifi Move all MAC frames processing to cloud to achieve a new level of flexibility, control and reconfigurability

22. What’s going on in oneM2M

23. oneM2M: Main problem to be addressed: Challenge

24. oneM2M: The goal

25. oneM2M: Solution – IoT MiddleWare

26. oneM2M: Overall Architecture for Implementation

27. Discussion Our idea is somehow in the direction of oneM2M, can contribute to the oneM2M

28. Further study Detail design for vSink as a NFV consisting multiple component Binding mechanism between physical sink and vSink QoS enabled 802.15.4 MAC, using NFC for different types of traffic

29. Reference Jonathan Vestine and Andreas Kassler, “QoS enabled wifi MAC layer processing as an example of a NFV service,” IEEE Netsoft 2015. K. Sundaresan, “FluidNet: a flexible cloud-based radio access network for small cells,” IEEE/ACM Trans on Networking, 2015