DATA TRANSPORT ON THE NETWORKED SURFACE James Scott and Frank Hoffmann {jws22,fh215}@cam.ac.uk www-lce.engm.ac.uk/

1. DATA TRANSPORTON THENETWORKED SURFACE James Scott and Frank Hoffmann {jws22,fh215}@cam.ac.ukhttp://www-lce.eng.cam.ac.uk/

2. 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 James Frank Andy Glenford Mike Introduction

3. Introduction to Networked Surfaces Prototype Architecture Connecting Objects Communicating with Objects Measurements using the Prototype Surface Conclusions Presentation Overview

4. 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 Networked Surfaces

5. Wired vs Wireless vs Surface

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

7. Prototype Hardware Surface Pads Power for Tile Controllers Tile Controller FunctionBusses Object Pads TileControlBus Object Controller PCI Interface to PC acting as Surface Manager

8. 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...

9. 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

10. Beacon Tile Controller Object Controller Beacon Request “TX” Many Connections on Standby Connection on Standby Confirmed Connection Standby Beacon Request “TX” Standby Beacon Confirm Beacons Confirmed Connections Beacon TX RX GND TX RX GND Tile Control Bus “New Object” message sent to Surface Manager Ack “TX” Handshaking Protocol

11. Registration Protocol Manager Tile 1 Tile 2 Object Handshaking finished - object is connected but pads will expire without registration Object Registration (includes details of strips the object is connected to) Confirm 2 Strips Confirm 2 Strips Strips Confirmed Strips Confirmed Object Registration Ack (including “session address” assignment) Pads are confirmed – Object can now use network

12. 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 I2C bus • Also used for tile control bus

13. “Token Star” Link Layer • 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

14. “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…

15. “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

16. 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

17. 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

18. 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 LVDS Bus Speed Results

19. 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 LVDS Bus Speed Analysis

20. 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 Conclusions

21. 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 Other Issues to Explore

22. Thanks for listening!To get in touch:James Scott and Frank Hoffmann{jws22,fh215}@cam.ac.ukhttp://www-lce.eng.cam.ac.uk/