A Network Architecture for the Web of Things
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

A Network Architecture for the Web of Things

  • 1,785 views
Uploaded 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......

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,785
On Slideshare
1,004
From Embeds
781
Number of Embeds
4

Actions

Shares
Downloads
42
Comments
0
Likes
0

Embeds 781

http://www.webofthings.com 421
http://www.webofthings.org 351
url_unknown 8
http://webofthings.org 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Putting it all together ... 10
  • 11. Clients WoT Gateway, G Geotracker 1. WoT device with IP addr 10.217.217.252 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 10.217.183.21. 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. 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. 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