pitfalls, remedies, and opportunities in modeling …yannis/presentations/wln...pitfalls, remedies,...

Pitfalls, Remedies, and Opportunities in Modeling Wireless Networks

Ioanis [email protected]

Computing Science, U. of Alberta,

Edmonton, Canada

Joint Work with:Pawel Gburzynski ([email protected])

Christian Schlegel ([email protected])

7th IEEE International Workshop on Wireless Local Networks (WLN) 2007Keynote Presentation

© 2007, Ioanis Nikolaidis 2

The Modeling Dilemma

• Should we dig deeper into details (all the way to elementary physics) OR rely on (reasonable) approximations?

• The challenge: we do not necessarily know in advance the level of detail we will need.

• In wireless networking research it seems we have to pay often homage to physics to uncover “the truth”.

• Let’s try a buzzword: “cross-layer design”


A Word about Cross-Layer Design

• Cross-Layer design recognizes that wireless channel access opportunities require fast high layer decisions → higher layer responsive to small timescales that are key to the physical layer.

• Examples:

– scheduling based on channel-state,

– joint routing and scheduling,

– MAC with multi-user detection/decoding.


Simulation

• Simulating the physical (wireless) world leads to the need to model continuous time phenomena for use by discrete event simulators.

• Pure numerical (e.g., finite element) computations of wave phenomena at arbitrary resolutions are possible but prohibitively expensive in terms of computation.

• A possible compromise is to settle for simulations progressing in increments of coherence time. – Still, computationally intensive / slow. (Do it in hardware.)– Coherence time depends on other parameter, e.g., mobility speed.– Usually considered in EE circles, almost ignored in CS circles.


What We (Really) Care About

• Replicating experimental results.

– Difficult to call it “science” otherwise.

• Reasoning on relative merits of techniques.

– Although absolute numbers may not matter a lot.

• Determining absolute performance metrics.

– To address questions of feasibility in the “real world”.

• Interpreting “real” empirical results.

– (Dis-)agreement between model and measurements.

• Transfer from conceptual to tangible artifact.

– By evaluating a system we are also building it.


Pitfall 1: Circular Coverage


Physical Layer for Computer Scientists

• A transmission is received error-free up to range R, and completely disappears after that range.

• Simultaneous transmission from transmitters at distance less than R results in reception of garbage (“collision”).

• Still widely used in papers employing theoretical, graph theoretic, modeling angle.

• Cautious model in one sense but sloppy in another. [Does it produce pessimistic of optimistic results?!]


Fixes to Entertain

• Extended “interference” range.– Different co-centric circles.

• Sum/cumulative interference and capture.– Capture usually simplistic.– Little (or no) regard for jamming margin.

• Temporal dimension of the problem. – Even if nodes remain static, the environment changes.


Limitations of Simulated Models

• A few representative studies:

– Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks [Takai et al. ’01]

– The mistaken Axioms of Wireless Network Research [Kotz et al. ’03]

– Modeling and Simulation Best Practices for Wireless Ad Hoc Networks [Perrone & Yuan ’03]

– MANET Simulation Studies: The Incredibles [Kurkowskiet al. ’05]

– On the Credibility of MANET Simulations [Andel & Yasinsac ’06]


The Mistaken Axioms[Kotz et al. ’03]

• The world is flat.• A radio’s transmission area is circular.• All radios have equal range.• If I can hear you, you can hear me (symmetry).• If I can hear you at all, I can hear you perfectly.• Signal strength is a simple function of distance.

Worth reciting them every time you are about to read a paper.


Fixing Problems(Without Really Fixing Them)

Example:

• Maximum forward progress heuristics, e.g., greedy forwarding in geometric routing sends packets to the furthest reachable neighbor.

• Unsurprisingly, the most distant neighbor exhibits the worst BER! If we insist on it being the next hop, we waste energy in retransmissions.


Fixing Problems (Without Really Fixing Them)

• [Kuruvila et al. ’04] fixed it by determining an optimal distance to forward the frame (.7R - .8R for radius R). A brave attempt, but no cigar! The coverage was never circular to begin with.

• Even when we try to fix it, we still buy into the fiction of a particular geometry. Which remains constant over time. And it ignores noise too!


Can We Handle The Truth?

BER < 10-x


Some Measurements

• Platform: DM2200– RFM TR8100

– TI MSP430F148• 48 KB Flash

• 2 KB RAM

– 916.5 MHz (916.3-916.7)• OOK on BPSK spreading

• 9.6 kbit/sec www.rfm.com


Indoor Measurement Locations


Indoor Measurements

52 byte packets


Indoor Measurements (RSSI)


Outdoor Measurement Locations


Outdoor Measurements

52 byte packets


Outdoor Measurements (RSSI)


Apartment Building Measurements

52 byte packets


Apartment Building Measurements (RSSI)


HELLO Protocols & Packet Error Rate

• HELLO messages– Used to determine adjacency / topology– Usually repeated often for dynamic /mobile env.

• What we find in the literature– Short HELLO used for discovery, but large data packets

sent for regular payload. (Large packets fail where HELLO succeeded.)

– HELLO ill-defined in many studies. Simulated as negligible length, yet specific schemes require lengthy HELLO, e.g., to convey neighbor or neighbor’s neighbor information.


Pitfall 2: When Is A Frame “Received”


The Usual Definition of Capture

• The common view: capture is a matter of relative reception power over the combined simultaneous “interfering” transmissions. The signal with the stronger received power (by at least a threshold) will be decoded/received.

• Evaluating the capture at the first symbol (or bit) time of a transmission is how reception is decided in much-less-then-perfect simulators.

• The frame reception is a continuous process until all symbols/bits deemed relevant to the frame have been received. The simulation must keep track of the received signal over the entire “body” of a frame.


Another Side of Capture

Delay Capture

• Two transmissions (even if with the same spreading code) starting slightly later one than the other allow the receiver to “lock onto” the first and ignore the second one even though it is technically a “collision”.

• The combined delay+power capture can be used creatively, in that it is possible, e.g., for a receiver in a DS/SSMA system to capture multiple packets simultaneously [H.-H. Chen ‘01]


Capture is Not Perfect

• For delay capture to occur the two packet transmissions must be separated a sufficient amount of time, Tc.

• The time separation Tc is influenced by particular receiver design (AGC etc.) to end up being several symbols long.

• Also, after capture has declared the “winner” a strong jamming margin (e.g., 20dB) is needed to “harm” the captured frame, which reduces the potential post-capture interferers significantly. (Carrier sensing is an additional safeguard of course.)


Capture & Preamble

• For receivers, the “game” of capture is on until a seemingly correct preamble is detected out of noise and/or spurious transmissions.

• The preamble length influences the receiver performance. Concerns about the preamble are usually hidden from view because simulations tend to use legacy MAC protocols, where preamble reception is accounted for in an overarching PER. However, MAC protocol designers should keep preamble concerns in mind.

• Also consider the possibility of MAC protocols to adjust the preamble length based on the environment.


Preamble Measurements


Beyond Capture

Multi-User Detection / Decoding

• What happens when multiple transmissions are possible to be captured concurrently by the receiver.

• Increase in potential throughput by increased receiver complexity. Also, a good excuse to get rid of Collision Avoidance techniques (if we ever used them that is!).

• Simulation complications: during the reception of a frame we may have to “fork” another reception task of another frame, as needed, repeatedly.


Beyond Capture (contd.)

Collaborative Decoding• Interconnect nodes (e.g., APs with a wired backbone) so

they can collectively decide on the received bits, using a combining strategy (usually Maximum Ratio Combining), i.e., network-based MIMO.

• Also, dealing with soft values (or re-inventing them!) is today a fashionable area of research, for collaborative decoding as well as for other schemes, e.g., certain H-ARQ schemes.

• Simulation complications: reception to be modeled as a sequence of soft value receptions (certainly cannot be decided on the first bit reception of a frame!).


Some Notes About The Future

Practical Scalable Ad Hoc Networks

• The ongoing quest of characterizing the capacity of an ad hoc network begs the question of what (if any) of these schemes are realizable and how. Increasing interest in exploiting concepts and ideas allowing higher capacity.

• The recent work by Cadambe & Jafar (“Interference Alignment and Spatial Degrees of Freedom for the K User Interference Channel”) is not likely to be ignored.– + 50%, 900% and 4900% for 3, 20 and 100 interfering users


Some Notes About The Future (contd.)

Not All Noise is Gaussian

• Problem: Simulations where interferers sum up to a Gaussian background noise are particularly unsuitable for certain modulation techniques (e.g., Impulse UWB) and small user populations.

• Researchers solve the inadequacy of simulators on a piece-meal basis re-inventing the architecture of the simulator, e.g., R. Merz, J.-Y. Le Boudec, and J. Widmer(“An Architecture for Wireless Simulation in ns-2 Applied to Impulse-Radio Ultra-Wide Band Networks”, EPFL TR)


The Question

Are current simulation/emulation environments up to snuff for the advances we need to study network-wide scale deployment of new wireless network technologies?

Issues:Scale (think dense sensor deployment).Fidelity (not just for legacy techniques).


Features for Simulators

• Evaluation of the “health” of a frame reception event during theentire length of the frame (at bit, symbol, or just at coherencetime increments).

• Dynamic (time and space dependent) expressions for the relative signal strength of received transmissions.

• “Hooks” to allow access to preamble and to the rest of the frame independently (including the potential that the two are coded differently and subject to different channel behavior).

• Sufficiently accurate sampling of received signals to allow wider range of receiver logic to be modeled (e.g. distributed collaborative decoding).

• …


SMURPH/SIDE for Wireless


SMURPH Threads OverviewTransmitter:: perform {state NPacket:

if (S->ready (MinPL, MaxPL, FrameL))proceed Transmit;

else {Client->wait (ARRIVAL, NPacket);Bus->wait (ACTIVITY, Busy);

}state Transmit:

Transmitting = YES;Competing = YES;Bus->transmit (Buffer, XDone);Bus->wait (COLLISION, SenseCollision);

state Busy:Bus->wait (EOT, SenseEOT);Bus->wait (COLLISION, SenseCollision);

state XDone:Bus->stop ();Transmitting = NO;Competing = NO;Buffer->release ();proceed SenseEOT;

...

Transmitter:: perform {state NPacket:



}state Transmit:




...

FSM and co-routine with implicit control transfer and multiple entry points.

declarewaking

conditions

declarewaking

conditions

sleepsleep

wakeupwakeup

...eventevent

. . .. . .


SMURPH Threads Overview (contd.)




}state Transmit:




...




}state Transmit:




...

FSM and co-routine with implicit control transfer and multiple entry points.

declarewaking

conditions

declarewaking

conditions

sleepsleep

wakeupwakeup

...eventevent

. . .. . .


Generic Channel Model

class RFChannel {...virtual double RFC_att (double p, double d,

Transceiver *S, Transceiver *D);virtual double RFC_add (int N, int ign,

const SLEntry *L, const SLEntry *T);virtual Boolean RFC_bot (

RATE r, // transmission ratedouble l, // received signal leveldouble s, // receiver sensitivityconst IHist *ih); // interference histogram

virtual Boolean RFC_eot ( ... );virtual Long RFC_erb (

RATE r, // transmission ratedouble l, // received signal leveldouble s, // receiver sensitivitydouble ifl, // interference levelLong nb); // signal length (bits)

...


...virtual Long RFC_erd (

RATE r, // transmission ratedouble l, // received signal leveldouble s, // receiver sensitivitydouble ifl, // interference levelLong par); // selector

Generates a randomized interval (in bits) until an interesting (from the viewpoint of the driver) event.

virtual double RFC_cut (double p, // Transmitter powerdouble s); // Receiver sensitivity

Cut-off distance (to narrow down “neighborhoods”).

Generic Channel Model (contd.)


Some Useful Data Structurestypedef struct {

double Level;Long Tag;

} SLEntry;

Accounts for possible “special” properties of the signal, e.g., code (CDMA).

class IHist {. . .

void update (double sig) {...};double avg ( ) {...};double max ( ) {...};

. . .};

Maintains interference histories and enables the calculation of statistics on selected intervals.


Example Shadowing Modeldouble RFC_att (double xp, double d, Transceiver *src,

Transceiver *des) {if (d < Rdist)

return xp;else

return xp * LFac * dBToLin (dRndGauss (0.0, Sigma)) * pow (d, NBeta);

};

Long RFC_erb (RATE tr, double sl, double rs, double ir,Long nb) {

return lRndBinomial (ber (sl/(ir + BNoise)), nb);};

Long RFC_erd (RATE tr, double sl, double rs, double ir,Long nb) {

return (Long)(dRndPoisson (1.0 / ber ((sl * rs) / (ir + BNoise)));

};


Example Assessment Methods

Boolean RFC_bot (RATE r, double sl, double sn,const IHist *h) {

if (h->bits (r) < MinPr) {return NO;

}if (error (r, sl, sn, h, -1, MinPr)) {

return NO;}return YES;

};

Boolean RFC_eot (RATE r, double sl, double sn,const IHist *h) {

return !error (r, sl, sn, h);};


Back to square one …

• Replicating experimental results.

– Difficult to call it “science” otherwise.

• Reasoning on relative merits of techniques.

– Although absolute numbers may not matter a lot.

• Determining absolute performance metrics.

– To address questions of feasibility in the “real world”.

• Interpreting “real” empirical results.

– (Dis-)agreement between model and measurements.

• Transfer from conceptual to tangible artifact.

– By evaluating a system we are also building it.


From Simulation to Emulation

• Provide the tools/abstractions necessary for developing an implementation which will be one and the same regardless of whether it is used for simulation/evaluation or as the real software/hardware embodiment.

• When used for evaluation purposes, the implementation must be unable to distinguish whether it runs on a fictitious or the real environment.

• Problems:– Finding the right abstractions (must still be low level).– Build powerful virtual underlay (mix real & simulated).– Real-time performance (may need hardware assistance).


Emulator Scalability

• Emulation is supposed to provide real-time behavior, indistinguishable from the behavior of the real system.

• An emulation based solely on software suffers from eventual slow down as the scale of the emulated system grows.

• Solutions:– Restrict/simplify emulated models (bad)– Move emulation functionality to hardware


Simulation + Emulation Efforts

• UCLA: WHYNET / TWINE

J. Zhou, Z. Ji, and R. Bagrodia, “TWINE: A Hybrid Emulation Testbed for WirelessNetworks and Applications” INFOCOM 2006.


Simulation + Emulation Efforts

• CMU: Wireless Network Emulator

G. Judd and P. Steenkiste, “Design and Implementation of an RF Front End for Physical Layer Wireless Network Emulation” VTC 2007.


A Common Drawback

Commitment to Particular Level of Detail

• The CMU platform samples the RF.•Problematic in terms of scalability. (bandwidth)•Suited for handling legacy (commercial) MAC. •No choice of granularity for channel model.

• The WHYNET/TWINE platform.•Scalability problem of software-based emulation.•Suited for higher-layer protocol development.•Not suitable for low capability platforms. (sensors)

– …


From Simulation to Emulation

• Provide the tools/abstractions necessary for developing an implementation which will be one and the same regardless of whether it is used for simulation/evaluation or as the real software/hardware embodiment.

• When used for evaluation purposes, the implementation must be unable to distinguish whether it runs on a fictitious or the real environment.

• Problems:– Finding the right abstractions (must still be low level).– Build powerful virtual underlay (mix real & simulated).– Real-time performance (may need hardware assistance).


Abstraction & Performance

FSMs from Discrete-Event Simulation to Real Application

• Borrow from discrete-event simulation the event processing loop, but make it implicit under a guise of particular communicating Finite State Machines, i.e., the user “programs” fairly general Finite State Machines.

• Commodity OS abstractions not suitable for small footprint platforms (sensors). The same paradigm used in the simulation (SMURPH/SIDE) can be used by an OS runtime (PicOS in our case). Code transportable with little (mechanical) changes back and forth.


Abstraction & Performance (contd.)

Virtualization Underlay

• A virtual execution environment which provides necessary instantiations of nodes/objects and supports an arbitrary scale of interactions between real devices and virtualized/simulated devices.

• Where necessary, e.g., MAC behavior, channel models, etc. use reconfigurable hardware (FPGAs) to attain real-time operation.


Our Approach

– a specialized OS: PicOS

– a reasonable abstraction: communicating FSMs

– same abstraction as for discrete-event simulation

– multitasking programming model (unlike TinyOS)

– low level “disciplined” access to physical layer (VNETI)

– relegate heavy processing to reconfigurable HW (FPGA)

– PicOS threads are re-active (not for CPU-bound work)

– all of channel behavior eventually emulated by FPGAs

– configurable channels to allow emulation of topologies


Small Footprint OS

What is the problem?

Containing the amount of resources needed to sustain a single thread.

codecode

datadata

stackstackx

shared, ROM (flash)shared, ROM (flash)

needed anywayneeded anyway

gets in the waygets in the way


Threads in PicOSprocess (sniffer, sess_t)

char c;entry (RC_TRY)

data->packet = tcv_rnp (RC_TRY, efd);data->length = tcv_left (packet);

entry (RC_PASS)if (data->user != US_READY) {

wait (&data->user, RC_PASS);delay (1000, RC_LOCKED);release;

}...

entry (RC_LOCKED)...

entry (RC_ENP)tcv_endp (data->packet);signal (&data->packet);proceed (RC_TRY);

endprocess (1)

process (sniffer, sess_t)char c;entry (RC_TRY)

data->packet = tcv_rnp (RC_TRY, efd);data->length = tcv_left (packet);

entry (RC_PASS)if (data->user != US_READY) {

wait (&data->user, RC_PASS);delay (1000, RC_LOCKED);release;

}...

entry (RC_LOCKED)...

entry (RC_ENP)tcv_endp (data->packet);signal (&data->packet);proceed (RC_TRY);

endprocess (1)

Allows us to use only one stack.


PicOS Architecture

microcontroller

PicOS kernel

VNETI

praxis(application) TARP other

plugins

RFmodule

phy

othernetworkdevices

API plugs

driver driver

...GPIO, ADC, DACUART


VUEE Architecture

VNETI


plugins

phy

API plugs

VUEE = Virtual Underlay Emulation Engine

VirtualRF module

VirtualUART

VirtualI/O pins

Othervirtual

hardware

Interface daemon

Channelmodel

Virtualnetwork

Remote agents


Hardware Implementation Flexibility

VNETI


plugins

phy

API plugs


VirtualRF module

VirtualUART

VirtualI/O pins

Othervirtual

hardware

Interface daemon

Channelmodel

Virtualnetwork

Remote agents

Instead of software, implement these on reconfigurable hardware.


Hardware Implementation Flexibility

VNETI


plugins

phy

API plugs


VirtualRF module

VirtualUART

VirtualI/O pins

Othervirtual

hardware

Interface daemon

Channelmodel

Virtualnetwork

Remote agents

Alternative boundary for hardware implementation (under investigation).


NEWAGE Conceptual Architecture


Example: Single Receiver


Example: Multiple Access Channel


Example: Relay Channel


Example: Ad Hoc Network


Our Tool Chain:NEWAGE/VUEE/PicOS/SMURPH

• PicOS is not restricted to high-end platforms.• Simulation in SMURPH portable to PicOS.• Access to low level physical/radio activity (VNETI).• Large scale network emulation using VUEE.• PicOS application (praxis) can run directly under VUEE.• FPGA implementation for real-time and CPU bound parts.• FPGA-based channel emulation models (NEWAGE).• Channel emulation at desired level of detail (not only RF).

“One Stop Shop for Wireless Protocol and Application Development”

66

www.olsonet.com (VUEE & PicOS)

67

HCDC Lab (FPGA-based MAC, PHY, Channel Models)

Questions?

pitfalls, remedies, and opportunities in modeling …yannis/presentations/wln...pitfalls, remedies,...

Documents