Cubin : Applied Research

Graeme Pendock 27/1/04

ARC Special Research Centre for Ultra-Broadband Information Networks

Outline
Rationale - why make stuff Obstacles - why we tend not to make stuff Proposal idea of something to make

Rationale or why make stuff ?

its an Engineering Department .. its a real (not abstract) world
we are surrounded by stuff that we use, control, interact with

balance theory vs. applied helps make research relevant

awareness from even understanding how stuff is made, works practical limits, implementation difficulties, tradeoffs

increase employability
broader range of useful skills e.g. real software/OS programming, linux, networking, device driver, VHDL, FPGA/CPLD, DSP etc

creates questions fun, satisfaction in making something

Obstacles why we shy away?

no previous experience
if all youve done is write Hello World programs then start with applied software (e.g. IO/device driver/network programming) rather than hardware

fear of unknown, intimidated by learning curve

never as bad as anticipated

fear of failure
cultural. so what ? it will work next time..

money
optics ($$$), rf ($$), computers ($), software ()

lack of infrastructure/support (external)

IT/computer, technical, purchasing

reduced publication output

Australia : publication volume is dominant metric (not universal)

Proposal (1)
flavour of the month : wireless sensor networks pin head size wireless sensors scattered from airplanes, float down rivers, go around your arteries, and report all back to big brotherblah..blah..yeah reality check : need electronic integration what turned me on last week : Berkley Motes + TinyOS
standard off-shelf electronics : atmel 8-bit processor + wireless module cc/coin size power 2xAA batteries for year simple sensing : temp, pressure, motion etc custom, simple open-source OS (self-forming network) research group (team of 9, 16 publications)

Proposal (2)
what drives wireless sensors is power, size and cost; but this limits functionality and range envision Australian applications (farming, forestry, environmental, mining) where require greater range (~km) desirable and cost and power less critical (eg. solar powered) relaxed power and size allow more powerful uCs and functionality
eg. 32-bit embedded processors

linux
existing applications, networking, devices aid development. use lab PCs reuse port later to target uC platform

prototype hardware
wireless module to PC (parallel port / i2c bus on memory ?) later to existing embedded module

Proposal (3)
low-hardware, low-capital, min-tech support vertical project requires range of people with different skills, expertise work required
interface of wireless module to PC/uC device driver media access network stack routing, networking applications

interested ? volunteers ?

An IP Network Test-bed
Tao Peng
ARC Special Research Centre for Ultra-Broadband Information Networks

Why an IP network test-bed?

Real-time performance It is important to publish source code as well as research papers Experiment is a good way to reduce the gap between theory and practice. It is better to study attack defense schemes in test-bed than waiting for an attack to appear in the Internet.

Our Proposal
Worm Traffic Modeling

Evaluation of Combined Defense Models.

Worm Traffic Modeling

collecting the traffic collecting the traffic

: Infected computer
: vulnerable computer

Evaluation of Combined Defense Models

Filtering at the source

Selective Pushback

Attack source
Filtering at the target

Something more
An IP network test-bed can also benefit the following research issues: Quality of Service (QoS) TCP flow control IP V.6

WLAN multi-user diversity

q(t)

mc

S1 S2 Core Network
Access Point (Router)

Sk

95% 80% 60%

Testbed
Access point monitors channel
Reception quality? Explicit signalling from mobiles? Told bit rate of previous transmission?

Chooses as next user the one which would get the highest rate
Fairness constraints Several existing algorithms

Requirements
WLAN cards which give:
Signal strength from last transfer Rate of last transfer (May be enough) Minimal internal buffering

Signalling scheme for receivers & BS? Time to learn about drivers...

Benefits
Study interaction with higher layers
CLAMP flow control

Gather statistics of actual channel use:

Simultaneous users? Rates achieved Time-scale of variation of rates

Hurdles / disincentives
Finding suitable cards Time investment What recognition?
Not publishable research Wont attract grant funding

Would real users use the setup?

Benefit only if many users on the network Need drivers on individual (MS) notebooks?