Cubin : Applied Research

Graeme Pendock 27/1/04
ARC Special Research Centre for Ultra-Broadband Information Networks

• 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 ….. • it’s 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 you’ve 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 brother”…blah..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


S1 S2 Core Network
Access Point (Router)


95% 80% 60%

• 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

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

• 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 – Won’t attract grant funding

• Would real users use the setup?
– Benefit only if many users on the network – Need drivers on individual (MS) notebooks?