Presentation is loading. Please wait.

Presentation is loading. Please wait.

Laboratory for Communications Engineering Engineering Department, University Of Cambridge DATA TRANSPORT ON THE NETWORKED SURFACE James Scott and Frank.

Similar presentations


Presentation on theme: "Laboratory for Communications Engineering Engineering Department, University Of Cambridge DATA TRANSPORT ON THE NETWORKED SURFACE James Scott and Frank."— Presentation transcript:

1 Laboratory for Communications Engineering Engineering Department, University Of Cambridge DATA TRANSPORT ON THE NETWORKED SURFACE James Scott and Frank Hoffmann {jws22,fh215}@cam.ac.uk http://www-lce.eng.cam.ac.uk/

2 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Introduction The Laboratory for Communications Engineering In the Engineering Department at Cambridge University Founded 3 years ago by Professor Andy Hopper Strong links with industry, including AT&T Labs Cambridge, where Andy is MD James Scott and Frank Hoffmann Fourth year PhD students From Computer Science and Electronics backgrounds respectively Advisors at AT&T Labs: Glenford Mapp and Mike Addlesee JamesFrankGlenfordMikeAndy

3 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Presentation Overview Introduction to Networked Surfaces Prototype Architecture Connecting Objects Communicating with Objects Measurements using the Prototype Surface Conclusions

4 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Networked Surfaces Provide network connectivity using physical surfaces Such as desks, floors, etc. All devices are surface-bound due to gravity: lets make use of this! No 'plug', no special position/alignment required Provides near-total mobility for non-wearable devices Uses precise “topology” of metal pads to achieve this Supports a range of services Ethernet-style inter-computer networks Slower serial busses for peripherals Power Other devices

5 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Wired vs Wireless vs Surface Physical MediumWired networkWireless network Networked Surface BandwidthHighLimited High (though not quite as good as a shielded wire) Multi-Access Dedicated Connections Possible Intrinsically Shared Medium Dedicated Connections Possible MobilityTethered3D-Free Surface-based “2D-Free” Power Can easily be provided Hard to provide Can be provided, with safety concerns

6 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Example App: Networked Desk Get rid of “spaghetti” behind desks and of need for trunking everywhere Eliminates possibility of mis-wiring Novices don’t want to know what a “serial port” is c.f. Ubiquitous Computing Power provided as low voltage DC With current limiting hardware No danger to humans Most devices do not use mains-level AC anyway

7 Laboratory for Communications Engineering Engineering Department, University Of Cambridge T I L E C O N T R O L B U S Tile Controller Tile Controller Surface Manager (keeps track of objects, allocates resources, controls tiles) To other networks Object Controller Object e.g. Palm Pilot Computer Keyboard Mobile phone etc System Architecture (Hardware) Handshaking Data Traffic F U N C T I O N B U S S E S

8 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Prototype Hardware Surface Pads Tile Controller Object Pads Object Controller Function Busses Tile Control Bus PCI Interface to PC acting as Surface Manager Power for Tile Controllers

9 Laboratory for Communications Engineering Engineering Department, University Of Cambridge System Architecture (Software) Low Level Driver (Startup/Shutdown/Interrupts) Character Device Interface I 2 C Engine Network Device Interface LVDS Engine (inc. Token Star link layer) Linux Devices Linux Kernel Driver /dev/ns_tilectrl ns_lvds0 surfaced Tile Control and Object Registration Linux IP Stack User Space Daemon Other Networks & The Internet Bus Interface (PCI/PCMCIA)

10 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Connecting Objects: Topology Arrangement of metal pads with: –Rectangular strips on Surface –Circular pads, themselves in a circle, on Object –Surface gaps bigger than object pads hence no shorts Connects regardless of object location proven mathematically and in computer simulations Minimises number of pads required and hence the amount of controlling circuitry Could be implemented invisibly conducting paints, novel materials...

11 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Connecting Objects to the Surface Two stage connection: “Handshaking” and “Registration” “Handshaking” = connecting new objects to networks Performed in distributed fashion using tile controllers -> scaleability – job of handshaking the many surface pads is not centralised “ Registration” = confirming new connections Performed end-to-end using the newly acquired network -> test network before allowing tile pads to be committed If handshaked pads are not registered, they expire -> robustness – surface manager must actively accept pads before tile controllers release them

12 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Handshaking Protocol ManagerTile 1ObjectTile 2 Object placed on Surface Object is connected but pads will expire without registration Beacon Function Request Beacon Function Request Beacon Function Request Beacon In this example, the object is placed across two tiles, and asks for four pad connections

13 Laboratory for Communications Engineering Engineering Department, University Of Cambridge TX RX GND Tile Controller Tile Control Bus TX RX GND Object Controller Handshaking Protocol Beacons Beacon Request “TX” Beacon Ack “TX” Beacon Request “TX” Connection on StandbyMany Connections on Standby Standby Beacon Confirm Standby Beacon Confirmed ConnectionConfirmed Connections “New Object” message sent to Surface Manager

14 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Registration Protocol ManagerTile 1ObjectTile 2 Handshaking finished - object is connected but pads will expire without registration Pads are confirmed – Object can now use network Object Registration (includes details of strips the object is connected to) Confirm 2 Strips Strips Confirmed Object Registration Ack (including “session address” assignment) Confirm 2 Strips

15 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Surface Busses On the Surface, all busses must be true multi-drop i.e. not Ethernet, which nowadays is hubbed High speed bus used in prototype uses “Bus LVDS” modulation –Low voltage -> produces less noise for other busses –Differential signalling -> less sensitive to noise –Baseband –> transceivers are small discrete components -> easy debugging using oscilloscope Low speed devices are catered for with I 2 C bus –Also used for tile control bus

16 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Ethernet-style CSMA/CD not possible due to hardware High serial resistance in “wire” Wireless-style CSMA/CA possible… “Token Star” arbitration scheme may be better –Surface Manager is always on the bus –Object registration -> manager knows which objects are on bus –Manager is therefore good choice as bus arbiter “Token Star” Link Layer

17 Laboratory for Communications Engineering Engineering Department, University Of Cambridge “Token Star” Link Layer Semantics Manager sends an object a grant message Object replies to grant with “nothing to send” packet, or with a single IP packet for manager to forward Manager then becomes transmitter, sends one IP packet from its outgoing queue (to any object on bus) Manager then sends next object a grant message, and so on…

18 Laboratory for Communications Engineering Engineering Department, University Of Cambridge “Token Star” Link Layer Properties No collisions -> fewer retransmissions required Disconnection detection is automatic and very quick (< 0.1s) Dynamic link layer addresses assigned on registration -> small LL headers (currently a 1 byte address and 1 byte packet type) Grants could convey a byte “allowance” instead of a packet allowance Manager can choose to prioritise between objects -> QoS

19 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Handshaking Times Handshaking occurs in a minimum of three “cycles” Each pad goes from a “handshaking” mode to a “standby” mode, and then to a “connected” mode Each cycle takes 0.1s, during which every pad on the surface is “beaconed” on once Dropped “beacons” and other errors cause some connections to take longer than the 3-cycle minimum

20 Laboratory for Communications Engineering Engineering Department, University Of Cambridge New Handshaking Times Modified handshaking occurs in only one cycle Each cycle still takes 0.1s The huge majority of connections are made in ~0.1s This result also shows that the chosen topology works

21 Laboratory for Communications Engineering Engineering Department, University Of Cambridge LVDS Bus Speed Results Setup: Object is notebook with PCMCIA interface to H/W –Hardware performs handshaking and LVDS bus functions –Hardware FIFOs buffer outgoing and incoming packets for LVDS –FIFOs are only 127 bytes due to hardware limitations (FPGA space) –Simple pings are used to see if the bus will operate at various speeds Expected: Oscilloscope shows LVDS rise/fall times to be ~80ns –Bandwidth using current bus hardware should go up to ~13Mbit/s –Current hardware has 300  serial resistance per mux -> other hardware choice might go faster Actual results: Only 1Mbit/s achieved for packets > 127 bytes –Indicates bottleneck in PCMCIA interface

22 Laboratory for Communications Engineering Engineering Department, University Of Cambridge LVDS Bus Speed Analysis 1 Mbit/s bottleneck was PCMCIA interface –Bad choice of Digital I/O card (its spec sheet implied it would go faster) Another bottleneck is the hardware clock speed = 20MHz –Clock synchronisation algorithm requires 5 cycles per bit -> 4Mbit/s limit Lesson for prototyping: be very aware of your bottlenecks –Novel components should not be stifled by supporting hardware Improvements made: –New PCMCIA Interface implemented capable of ~6Mbit/s –40MHz clock chip substituted -> can clock bus up to 8Mbit/s –Preliminary results: bandwidths up to 6Mbit/s for all packet sizes OK

23 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Conclusions A Networked Surface prototype has been built Object discovery and connection takes ~ 0.1s Doesn’t matter if we disconnect and reconnect once in a while The current prototype bus can perform at 6Mbit/s But the bottleneck isn’t the network! Advantages of Networking with Surfaces Mobility – Currently “wired” devices can become 2D-mobile Convenience – No need to carry wiring around Ubiquity – Common interface for many network types

24 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Other Issues to Explore Transport Layer Implications –Getting TCP to cope with frequent disconnection and reconnection Sentient Computing –Can discover location and orientation of each object –Could implement networked sensors easily –The desk itself becomes an interface Choice of Physical Transmission Medium –Could use capacitive coupling to avoid direct wire interface –Could use inductive coupling for ultra-safe provision of power

25 Laboratory for Communications Engineering Engineering Department, University Of Cambridge Thanks for listening! To get in touch: James Scott and Frank Hoffmann {jws22,fh215}@cam.ac.uk http://www-lce.eng.cam.ac.uk/


Download ppt "Laboratory for Communications Engineering Engineering Department, University Of Cambridge DATA TRANSPORT ON THE NETWORKED SURFACE James Scott and Frank."

Similar presentations


Ads by Google