Laboratory for Communications EngineeringEngineering 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/

Laboratory for Communications EngineeringEngineering 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

James Frank Glenford MikeAndy

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

Presentation Overview• Introduction to Networked Surfaces

• Prototype Architecture

• Connecting Objects

• Communicating with Objects

• Measurements using the Prototype Surface

• Conclusions

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

Wired vs Wireless vs Surface

Physical Medium

Wired networkWireless network

Networked Surface

Bandwidth High LimitedHigh (though not quite as good as a shielded wire)

Multi-AccessDedicated Connections Possible

Intrinsically Shared Medium

Dedicated Connections Possible

Mobility Tethered 3D-FreeSurface-based“2D-Free”

PowerCan easily be provided

Hard to provideCan be provided, with safety concerns

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

T I L

E

C

O N

T R

O L

B U

S

Tile

Controller

Tile

Controller

SurfaceManager

(keeps trackof objects,allocates

resources,controls tiles)

To othernetworks

Object

Controller

Object

e.g.Palm PilotComputerKeyboard

Mobile phoneetc

System Architecture (Hardware)

Handshaking

Data Traffic

F U

N C

T I O

N

B

U S

S E

S

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

Prototype HardwareSurface Pads

Tile Controller

Object Pads

Object Controller

Function Busses

Tile Control Bus

PCI Interface to PC acting

as Surface Manager

Power for Tile Controllers

Laboratory for Communications EngineeringEngineering 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...

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

TX RX GND

TileController

Tile Control Bus

TX RX GND

ObjectController

Handshaking Protocol

Beacons

Beacon

Request “TX” Beacon

Ack “TX”

Beacon Request “TX”

Connection on Standby Many Connections on Standby Standby Beacon

Confirm

Standby Beacon

Confirmed ConnectionConfirmed Connections

“New Object” message sent to Surface Manager

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

Registration Protocol

Manager Tile 1 ObjectTile 2

Handshaking finished - object is connected but pads will expire without registration

Pads are confirmed – Object can now use network

Object Registration(includes details ofstrips the object isconnected to)

Confirm 2 Strips

Strips ConfirmedStrips Confirmed

Object Registration Ack(including “session address” assignment)

Confirm 2 Strips

Laboratory for Communications EngineeringEngineering 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 I2C bus– Also used for tile control bus

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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…

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering Department, University Of Cambridge

Handshaking Times

Handshaking Timing

0

10

20

30

40

50

60

70

3 4 5 6 7 8 9 10 More

Cycles

% o

f Con

nect

ions

Mad

e

• 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

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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

Laboratory for Communications EngineeringEngineering 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/