We propose, trendy, a new registry-based Service Discovery protocol with context awareness. It uses CoAP-based RESTful web services to provide a standard interoperable interface which can be easily translated from HTTP. In addition, trendy introduces an adaptive timer and grouping mechanism to minimise control overhead and energy consumption. Trendy ’s grouping is based on location tags to localise status maintenance traffic and to compose and offer new group based services. Our simulation results show that trendy techniques reduce the control traffic considerably and also reduce the energy consumption, while offering the optimal service selection.

1. TRENDY: Adaptive
and Context-Aware
Service Discovery
Protocol for 6LoWPANs
Talal Ashraf Butt, Dr. Iain Phillips,
Dr. Lin Guan, Dr. George Oikomonou
Loughborough University
1

2. Overview
• WoT vision and Role of Service Discovery (SD)
• WoT SD Requirements
• Our proposed solution: TRENDY
• Experiments and results
• Future Work
2

3. Web of Things (WoT)
How to make application-specific WSNs to be
active part of the web?
6LoWPAN Internet of Things
Service discovery Discoverability
Web Services Interoperability
Web of Things 3

4. Role of Service Discovery
User Agent I need * service
Router
(UA)
• Switch off the lights in corridor of x building
• Give me the overall temperature of x building
• Close all the windows when its windy
• Close all the windows when no one in the room
• If rooms temperature is below x and someone in the room
Then Switch on the heating and close the windows
4

5. Existing Solutions: Gaps
6LoWPAN constraints Heavy Dependencies
limited Sleeping Protocols
Packet Nodes
Size
Bulky
limited Limited formats
Bandwidth ROM and RAM
Compact version for 6LoWPAN Architecture
Translation PULL-based
Overhead
5

6. WoT: SD Requirements
Compact Compact
Scalability
packets Size
Sleep Efficiency
6LoWPAN General Requirements
Cycles Requirements
Service
Heterogeneity Service
Interoperability Selection
Composition
6

7. TRENDY SD Protocol
CoAP
Based Service Context
Grouping Adaptivity
Restful Composition Awareness
Web services
TRENDY: An Adaptive and Context-Aware Service
Discovery Protocol for 6LoWPANs
7

8. Service Description
• Very simple at registration time (Comma
separated URLs)
• Optional: Detailed IETF CoRE well-
known descriptions
8

9. Context awareness
Location based tags
User Agent I need * service in * place Directory Agent
(UA) (DA)
• Switch off the lights in corridor of x building
• Give me the overall temperature of x building
• Close all the windows when its windy
• Close all the windows when no one in the room
• If rooms temperature is below x and someone in the room
Then Switch on the heating and close the windows
9

10. Context awareness
Service Selection
I need temperature service
in H room
User Agent of x building
DA
(UA)
Two Options:
Select the one with
1. Hit count (Popularity)
2. Less battery consumed H room
3. More reliable
10

11. Discovery Query Options
I need temperature service
in H room
of x building
User Agent
(UA) DA
URL(s) and IP address(es)
of matched service(s)
Using URI-query with: H room
1. Keyword
2. Keyword and location
3. 1 or 2 with select the optimal option
11

12. Status maintenance
Every node randomly selects
a interval between 50 and 90% of time window for status updates
o Static interval Basic Time window = 600
o Multihop effect DA GL1 = Active
GM1 = Active
GM2 = Active
GM3 = Active
Interval = 412
GM1
GM6 Interval = 501
Interval = 431 GM2 GM4
Interval = 521
GM5
GM3
Interval = 476
Interval = 511 12

13. Adaptive timer
Basic Time window = 600
GM1 timer counter = 2
GM2 timer counter = 2
DA
GM3 timer counter = 3
GM4 timer counter = 2
GM5 timer counter = 3
Interval = 512*2 GM6 timer counter = 2
GM1
GM6
Interval = 501*2
Interval = 531*2 GM2 GM4
Interval = 521*2
GM5
GM3
Interval = 476*3
Interval = 411*3 13

14. Benefit: Adaptive Timer
Increases
status Decreases
maintenance Control
interval Overhead
14

15. Grouping
Basic Time window = 600
GL1 = Active
DA GM1 = Active
Implements GL GM2 = Active
CoAP resource GM3 = Active
GL1
GM3
Interval = 412
Interval = 501
GM1 GM2
Interval = 431 Interval = 521
15

16. Grouping
Basic Time window = 600
GL1 = Active
GM1 = GM of GL1
DA
GM2 = GM of GL1
GM3 = Active
Interval = 412 GL1
GM3
Interval = 501
GM1 GM2
Interval = 431 Interval = 521
16

17. Multiple available GLs
Basic Time window = 600
GL1 = Active
DA GM1 = Active
GM2 = Active
GM3 = Active
GL1
GM3
Interval = 412
GL2
Interval = 501
Interval = 476
GM2
GM1
Interval = 521
Interval = 431
17

18. Optimal GL Selection
• If multiple GLs available
• Select one with high rank
Rank = st + nGM - f - (b/1000)
st b
(serving time) (battery consumption)
nGM f
(number of (number of failures)
registered GMs)
18

19. Architecture
DA
GL GL
GM
GM GM
GM
GM
GM GM GM
GM
GM
Area: INB01 Area: JKF01
19

20. Adaptive Timer: Grouping
Group Members report to
corresponding Group Leaders
Basic Time window = 600
GL1 timer counter = 3
DA GM1 timer counter = GM
GM2 timer counter = GM
GM3 timer counter = 2
Interval = 412*3 GL1
GM3
Interval = 501*2
GM1 GM2
Interval = 431*3 Interval = 521*3
20

21. Benefits: Grouping
Group Based on Enable
nodes their Service
locations Composition
Reduces
Registry
load
21

22. Experiments Setup
• Linux process
DA • Java based CoAP Implementation
COOJA: Simulator
• CONTIKI (OS)
GL
• CSMA (MAC)
• CONTIKIMAC (Duty cycling)
• ENERGEST (Energy estimation)
• C-based CoAP Implementation
GM
25 Tmote sky nodes (+1 border router)
with 10 runs for 100 minutes 22

23. Results
Control
Method Energy (J)
Packets
BASIC 810 62.08
TRENDY TIMER 163 61.27
TRENDY FULL 297 60.13
23

24. Future Work
 Load balancing
More responsible GLs  Large-scale
Grouping Scope
Adaptivity Proxy
 Intelligent Timer (e.g. trickle)  Caching
 Publish/Subscribe Interoperability
Service composition
24

25. T h a n k y o u
Questions?
Loughborough University
25