Download presentation
Presentation is loading. Please wait.
Published byAntony Lucas Modified over 9 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.