A Network Architecture for the Web of Things


Published on

The ``Web of Things" is emerging as an exciting vision for seamlessly integrating everyday objects like home appliances, digital picture frames, health monitoring devices and energy meters into the Internet using the Web's well-known standards and blueprints. The key idea is to represent resources on these devices as URIs and use HTTP verbs (GET, PUT, POST, DELETE) as the uniform interface to manipulate them. Unfortunately, practical considerations such as bandwidth or energy constraints, firewalls/NATs and mobility pose interesting challenges in the realization of this ideal vision. This paper describes these challenges, examines potential solutions and presents the design and implementation of a gateway-based network architecture to address these concerns. To the best of our knowledge, it represents the first attempt within the Web of Things community to tackle these issues in a comprehensive manner.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Network Architecture for the Web of Things

  1. 1. A Network Architecture for the Web of ThingsVipul Gupta, Ron Goldman, Poorna Udupi{vipul.x.gupta, ron.goldman}@oracle.com, poorna@netflix.com Second International Workshop on the Web of Things (WoT 2011), Pervasive 2011 1
  2. 2. Web Of Things• What? “A vision where everyday devices and objects are integrated into the Web using well-known standards and blueprints (URIs, HTTP, REST).” “Seamless integration of physical and conceptual resources” Also: “The physical web”, “the tactile web”• How? - Connect device to Internet, - Embed web server, - Model resources as URIs - Manipulate resources via HTTP verbs 2
  3. 3. Example• Read a resource, e.g. read the light sensor reading GET /sensors/light HTTP/1.1 Client Accept: */* Sun SPOT HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 3 138• Update a resource, e.g. change color of LED 4 PUT /actuators/leds/4 HTTP/1.1 Content-Type: text/plain Client Content-Length: 7 Sun SPOT 0,255,0 HTTP/1.1 200 OK 3
  4. 4. But ...• Need to ensure URIs are: • Available -- when a device sleeps • Reachable -- when the device is behind a NAT or firewall • Stable -- even as the device moves around • Discoverable -- whether they are local or remote to the client 4
  5. 5. Energy Constraints• Devices sleep periodically to conserve battery• Use sleep-proxy to queue requests, cache responses zz z Sleep zz zz proxy Sun SPOT Client (sleep notification) GET /spots/01AB/temp HTTP/1.1 Cache-Control: max-age=60 HTTP/1.1 200 OK Age: 22 Content-Length: 5 86.45 PUT /spots/01AB/leds/5 HTTP/1.1 Content-Length: 7 0,255,0 HTTP/1.1 202 Accepted Retry-After: 45 Location: spots/01AB/requests/1cqfw 5
  6. 6. Network Bandwidth Constraints• HTTP, XML are verbose. TCP connection setup/teardown adds overhead.• Compression via binary encoding, use UDP • Efficient XML Interchange (http://www.w3.org/XML/EXI/) • HTTP header compression (draft-tolle-core-ebhttp-00, draft-frank-6lowpan-chopan-00) Sun SPOT Uncompressed Compressed Client GET /spot-5317/temp HTTP/1.1 Accept: */* 13 bytes Host: localhost:8080 0000 - 68 36 47 2f 74 65 6d 70-00 0e 00 00 00 h6G/temp..... Content-Length: 0 User-Agent: curl/7.19.7 ... zlib/1.2.3 HTTP/1.1 200 OK 18 bytes Content-Type: text/plain 0000 - 48 36 40 11 b0 01 0a 00-3c 0e 00 05 00 38 39 2e H6@.....<....89. Cache-Control: max-age=60 0010 - 31 35 15 Content-Length: 5 89.15 6
  7. 7. Network Topology Constraints• Device could be behind firewall/NAT, might move• Use relay, with “long-poll” and Reverse HTTP (draft-lentczner-rhttp-00) Sun SPOT Client relay.net POST /spot-5317 HTTP/1.1 Upgrade: PTTH/1.0 Connection: Upgrade Host: relay.net HTTP/1.1 101 Switching Protocols Upgrade: PTTH/1.0 Connection: Upgrade GET /spot-5317/light HTTP/1.1 Host: relay.net GET /spot-5317/light HTTP/1.1 HTTP/1.1 200 OK HTTP/1.1 200 OK Connection: close Connection: close Content-Length: 3 Content-Length: 3 216 216 7
  8. 8. Mobility• IP address may change due to mobility or expiration of short-term lease (perceived mobility)• Mobile IP and dynamic DNS • not widely deployed • don’t help when device is on a private network• Mobile IP home agent and dynamic DNS server can be thought of as gateways that keep track of the current location. 8
  9. 9. Discovery• Discovering devices -- broadcast (e.g. mDNS) or registry• Discovering URLs on a device and relationships: • Bootstrapping: Well defined location for metadata (/.well-known, RFC 5785) • Typed links: Use the “rel” attribute in links to describe relationships (draft-nottingham-http-link-header-10), e.g. Link: </>; rel=“http://example.net/foo’’See also: http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux 9
  10. 10. Putting it all together ... 10
  11. 11. Clients WoT Gateway, G Geotracker 1. WoT device with IP addr in location A opens RHTTP channel and notifies SPOT is awake gateway of current address and next sleep period.C1 2. While the WoT device is awake, a request for its current location from C1 is forwarded to the device. The response is cached at G and returned to C1. 3. Client C2 requests a location reading within SPOT is asleep Time the last 10 mins while the geotracker is asleepC2 and the gateway returns a cached response. 4. Client C3 requests an alert subscription and C3 C1 repeats its request for a current location while the geotracker is asleep and the gateway queues the requests, sends back statusC1 monitoring URIs to C3 and C1. 5. WoT device wakes up in location B and gets SPOT is awake address It reopens RHTTP channel and notifies gateway of current address and next sleep period. 6. Gateway forwards queued request, caches 11 response and updates status URIs.
  12. 12. Clients WoT Gateway, G Protocol Alert device translator SPOT is asleep 1. Client requests a POST to the `alert URI. Gateway queues request, returns status monitoring URI. 2. WoT device wakes up, notifies the protocol translator of its next sleep period and its WoT gateway using its native (non-HTTP) protocol. SPOT is awake Time 3. Protocol translator opens up RHTTP channel with gateway and conveys the WoT device’s sleep schedule and its own IP address as the devices’s ``location”. 4. Gateway forwards queued request to WoT device via the translator. Device buzzes and blinks LEDs. Gateway caches returned response, updates status URI. 12
  13. 13. Summary• Outlined a gateway-based network architecture to ensure URLs are WebApp1 WebApp2 available, reachable, stable and /app1 /app2 discoverable ...• Implemented a preliminary version MetaApp on Sun SPOTs, available as a built- /.well-known in “Web of Things” demo NanoAppServer• Plan to make this an integral part CHTTPHandler RHTTPHandler HTTPHandler of SPOT libraries ... Nano App server 13