Transcript Networked Surfaces - Microsoft Research

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 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
James
Frank
Andy
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Glenford
Mike
Presentation Overview
• Introduction to Networked Surfaces
• Prototype Architecture
• Connecting Objects
• Communicating with Objects
• Measurements using the Prototype Surface
• Conclusions
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
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Wired vs Wireless vs Surface
Physical Medium
Wired network
Wireless network
Networked
Surface
Bandwidth
High
Limited
High (though not
quite as good as a
shielded wire)
Multi-Access
Dedicated
Connections
Possible
Intrinsically
Shared Medium
Dedicated
Connections
Possible
Mobility
Tethered
3D-Free
Surface-based
“2D-Free”
Power
Can easily be
provided
Hard to provide
Can be provided,
with safety
concerns
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
System Architecture (Hardware)
To other
networks
BUS
CONTROL
Tile
Controller
TILE
(keeps track
of objects,
allocates
resources,
controls tiles)
FUNCTION
Surface
Manager
BUSSES
Handshaking
Controller
Object
Controller
Tile
Data Traffic
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Object
e.g.
Palm Pilot
Computer
Keyboard
Mobile phone
etc
Prototype Hardware
Surface Pads
Power for Tile
Controllers
Tile Controller
Function
Busses
Object Pads
Tile Control
Bus
PCI Interface
to PC acting
as Surface
Manager
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Object
Controller
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 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
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Handshaking Protocol
Beacon
Request “TX”
Standby Beacon
Beacon
“TX”
Confirm
Confirmed
Confirmed
Connections
Connection
Many
Connection
Connections
on
Standby
on Request
Standby
Standby
Beacon
Ack
“TX”
Beacon
TX RX GND
Tile
Controller
Beacons
Tile Control Bus
“New Object” message sent to Surface Manager
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Object
Controller
TX RX GND
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
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 I2C bus
– Also used for tile control bus
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
“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
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…
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
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
Handshaking Times
• Handshaking occurs in a
minimum of three “cycles”
Handshaking Timing
• Each pad goes from a
“handshaking” mode to a
“standby” mode, and then to a
“connected” mode
70
% of Connections Made
60
50
40
• Each cycle takes 0.1s, during
which every pad on the surface
is “beaconed” on once
30
20
10
0
3
4
5
6
7
8
9
Cycles
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge
10
More
• Dropped “beacons” and other
errors cause some connections
to take longer than the 3-cycle
minimum
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 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
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
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
• Convenience
• Ubiquity
– Currently “wired” devices can become 2D-mobile
– No need to carry wiring around
– Common interface for many network types
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
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/
Laboratory for Communications Engineering
Engineering Department, University Of Cambridge