1. WP04: Wireless Networking Libelium David Remón & Anartz Nuin Brussels, March 31, 2014 Midterm Review1 31/03/2014

2. WP04 Objetives ● Setting up wireless connections ● Selection of a low level wireless data transfer protocol ● Adaptation of the high level application protocol layer ● Testing the wireless communications Midterm Review2 31/03/2014

3. WP04 Partners 1. UNIMI 2. AMIS 6. GORE 7. LBL 8. UPV Midterm Review3 31/03/2014

4. WP04 Tasks ● T4.1 Definition of Requirements (LBL, GORE, AMIS, UNIMI) [M6-M10] ● T4.2 Functional Analysis (LBL, GORE, AMIS, UNIMI) [M9-M12] ● T4.3 Implementation (GORE, LBL) [M10-M15] ● T4.4 Construction and validation of network performance model (UPV, LBL, UNIMI) [M11-M17] ● T4.5 Tests (LBL, GORE, AMIS) [M12-M23] Midterm Review4 31/03/2014

5. WP04 deliverables ● D4.1 Wireless Protocols Report (LBL) [M10] ● D4.2 First Experimentation Report (GORE) [M15] ● D4.3 Report on predicted system performance (UPV) [M17] ● D4.4 Final report on experimentation (LIB) [M23] Midterm Review5 31/03/2014

6. Gantt D4.1 (LIB) ● Delivered D4.2 (AMIS) ● Delivered D4.3 (UPV) ● Expected delivering with delay MS5 Month16 ● Partially achieved: communication chain completed but not integrated. Final integration at Cartif mockup Midterm Review6 31/03/2014

7. Goals Communication chain completed Security Layer: TLS QoS layer established State Diagram for SandS Board defined Managing Connections: Keep Alive Handling Command Queues Frame treatment in both ends Midterm Review7 31/03/2014

8. Midterm Review8 31/03/2014 Task report

9. Midterm Review9 31/03/2014 Tasks ● T4.1 Definition of Requirements ● T4.2 Functional Analysis ● T4.3 Implementation ● T4.4 Construction and validation of network performance model ● T4.5 Tests Midterm Review9 31/03/2014

10. Midterm Review10 31/03/2014 T4.1 Definition of requirements Coming from WP01 Results shown in D1.1, D3.1 and D3.3 Branded and Non branded Solution Different approach = Different requirements Defining recipes, instructions/commands

11. Midterm Review11 31/03/2014 T4.2 Functional Analysis ● Branded and Non branded Solution. ● Branded Solution - Dedicated web server. - Specially developed test application - Extensive tests Explained in Task 3.5

12. Midterm Review12 31/03/2014 T4.2 Functional Analysis Security - TLS Communications: - MQTT - TCP - WiFi Wifi Access Point Interface Design

13. Midterm Review 13 31/03/2014 Double Layer Security WiFi encryption WEP/WPA/WPA2 TLS encryption

14. Midterm Review14 31/03/2014 COMMUNICATIONS & SECURITY - Two ends carrying out communications and encryption: DI CM & appliance UN DI CM

15. Midterm Review15 31/03/2014 ● mqtt ● TLS Linux board AR9331 DI CM libmosquitto C implementation of MQTT libmosquitto uses library OPENSSL mqtt.js implementation of MQTT in node.js mqtt.js uses library OPENSSL

16. Midterm Review 16 31/03/2014 Accessing the eahouker WiFi network 1. Sands board configures as Access Point. 2. eahouker introduces WiFi credentials.

17. Midterm Review 17 31/03/2014 Accessing the eahouker WiFi network Designed. Next step: Implementation In SandS board

18. Midterm Review18 31/03/2014 T4.3 Implementation ● Branded and Non branded Solution. ● Branded Solution - Dedicated web server. - Specially developed test application - Extensive tests Explained in Task 3.5

19. Midterm Review19 31/03/2014 ● Non branded solution: - Two ends carrying out communications: DI CM & appliance UN DI CM

20. Midterm Review20 31/03/2014 DI end: DI Connection Manager ● Manage all the connections from/to appliances

21. Midterm Review21 31/03/2014 DI CM ● node.js: direct integration with DI (NTUA) ● In order to increase Performance: Multiple workers, as much as CPU cores

22. Midterm Review22 31/03/2014 DI CM ● - Receiving info from appliances: Three kind of messages: - Completed task - Info (for example, sensor measures) - First Connection status. - Sending info to appliances: One kind of message: - commands

23. Midterm Review23 31/03/2014 DI CM ● Sending info to the appliances: Recipe Payload xml 2 command mqtt wrapper mqtt message to the appliance

24. Midterm Review24 31/03/2014 Appliance end - Backup solution to avoid longer delay: Replacement SandS board Arduino YUN

25. Midterm Review25 31/03/2014 SandS board working Diagram Linux processor Arduino Part SandS Board

26. Midterm Review26 31/03/2014 SandS board working Diagram Linux processor Arduino Part SandS Board In charge of Communications In charge of running the appliance

27. Midterm Review27 31/03/2014 ● Linux processor AR9331: - in charge of the communications in the appliance end. - Communicates with Arduino part ATmega2560 through serial port. SandS board working Diagram

28. Midterm Review28 31/03/2014 ● Linux processor AR9331: - receives commands from DI-CM - sends commands to Arduino part - receives ACK's & status info from Arduino part SandS board working Diagram

29. Midterm Review29 31/03/2014 ● Linux processor AR9331 SandS board working Diagram

30. Midterm Review30 31/03/2014 ● Linux processor AR9331: Payload libmosquitto mqtt frame Message coming from DI-CM SandS board working Diagram Commands sent 1by1 to the Arduino ATmega 2560 parse

31. Midterm Review31 31/03/2014 SandS board working Diagram Linux processor Arduino Part SandS Board In charge of Communications In charge of running the appliance

32. Midterm Review32 31/03/2014 ● Arduino part Atmega 2560: - Controls the appliance. - Communicates with Linux processor AR9331 through serial port. SandS board working Diagram

33. Midterm Review33 31/03/2014 ● Arduino part Atmega 2560: - This programmed diagram allows SandS partners to add a new appliance to SandS network just by inserting the working code in the structure and defining the used commands. SandS board working Diagram

34. Midterm Review34 31/03/2014 ● Arduino part ATMega2560 SandS board working Diagram

35. Midterm Review 35 31/03/2014 Implementation: QoS Quality of Service Layer Implemented Handled by libmosquitto and mqtt.js QoS value = 1 (MQTT) mqtt message received → at least 1 ACK sent.

36. Midterm Review 36 31/03/2014 Implementation: keep alive timer - Implemented as MQTT Standard - keep_alive_time=maximum time without message from the appliance - Exists “Grace Time”=1,5 x keep_alive_time - If an appliance must send a message every 60 seconds, it will be disconnected from Sands when 90 seconds have passed

37. Midterm Review37 31/03/2014 T4.4 Network Performance Models In progress ● Extension of models in WP01 ● Dependencies on last project decisions and tests. ● Will be finished when whole project picture completed Integration: Cartif Small Scale Mockup

38. Midterm Review38 31/03/2014 T4.5 Tests In progress ● Stress tests in pieces of the communication: - DI CM - keeping alive the connection UN - DI - QoS - Security

39. Midterm Review39 31/03/2014 Stressing the DI-CM ● Simulation ● Thousands of appliances

40. Midterm Review40 31/03/2014 ● Simulation ● Thousands of appliances 100% success managing connections Stressing the DI-CM

41. Midterm Review41 31/03/2014 ● Done: Tests in parts of the communications ● To be done: Testing the integration SandS Boards – Communications – DI Cartif small scale mockup Tests

42. Recovering delays: - Migrating: Arduino Yun → SandS board Next steps on Communications: - Finishing Implementation Wifi Access Point - Closing the loop ARD – LIB - NTUA - Integration: Cartif small scale mockup Appliances ↔ DI - Scalability & number appliances: large scale mockup Midterm Review42 31/03/2014

43. DEMO Midterm Review43 31/03/2014

44. Thanks for your attention Midterm Review44 31/03/2014