Figure 2: The TinyOS mica2
To generate network topologies, we used TOSSIM’s
empirical model, based on data gathered from TinyOS
motes [7]. Figure 1 shows an experiment illustrating the
model’s packet loss rates over distance (in feet). As link
directions are sampled independently, intermediate dis-
tances such as twenty feet commonly exhibit link asym-
metry. Physical topologies are fed into the loss distribu-
tion function, producing a loss topology. In our studies,
link error rates were constant for the duration of a simu-
lation, but packet loss rates could be affected by dynamic
interactions such as collisions at a receiver.
In addition to standard bit-level simulations, we used a
modified version of TOSSIM that supports packet-level
simulations. This version simulates loss due to packet
corruption from bit errors, but does not model collisions.
By comparing the results of the full bit-level simulation
and this simpler packet-level simulation, we can ascer-
tain when packet collisions – failures of the underlying
MAC – are the cause of protocol behavior. In this paper,
we refer to the full TOSSIM simulation as TOSSIM-bit,
and the packet level simulation as TOSSIM-packet.
2.3 TinyOS motes
In our empirical experiments, we used TinyOS mica2
motes, with a 916MHz radio.
1
These motes provide 128KB
of program memory, 4KB of RAM, and a 7MHz 8-bit
microcontroller for a processor. The radio transmits at
19.2 Kbit, which after encoding and media access, is
approximately forty TinyOS packets/second, each with
a thirty-six byte data payload. For propagation experi-
ments, we instrumented mica2 motes with a special hard-
ware device that bridges their UART to TCP; other com-
puters can connect to the mote with a TCP socket to read
and write data to the mote. We used this to obtain mil-
lisecond granularity timestamps on network events. Fig-
ure 2 shows a picture of one of the mica2 motes used in
our experiments.
We performed two empirical studies. One involved
placing varying number of motes on a table, with the
transmission strength set very low to create a small multi-
hop network. The other was a nineteen mote network
1
There is also a 433 MHz variety.
in an office area, approximately 160’ by 40’. Section 5
presents the latter experiment in greater depth.
3. TRICKLE OVERVIEW
In the next three sections, we introduce and evaluate
Trickle. In this section, we describe the basic algorithm
primitive colloquially, as well as its conceptual basis. In
Section 4, we describe the algorithm more formally, and
evaluate the scalability of Trickle’s maintenance cost, start-
ing with an ideal case – a lossless and perfectly synchro-
nized single-hop network. Incrementally, we remove each
of these three constraints, quantifying scalability in sim-
ulation and validating the simulation results with an em-
pirical study. In Section 5, we show how, by adjust-
ing the length of time intervals, Trickle’s maintenance
algorithm can be easily adapted to also rapidly propa-
gate code while imposing a minimal overhead. Trickle
assumes that motes can succinctly describe their code
with metadata, and by comparing two different pieces of
metadata can determine which mote needs an update.
Trickle’s basic primitive is simple: every so often, a
mote transmits code metadata if it has not heard a few
other motes transmit the same thing. This allows Trickle
to scale to thousand-fold variations in network density,
quickly propagate updates, distribute transmission load
evenly, be robust to transient disconnections, handle net-
work repopulations, and impose a maintenance overhead
on the order of a few packets per hour per mote.
Trickle sends all messages to the local broadcast ad-
dress. There are two possible results to a Trickle broad-
cast: either every mote that hears the message is up to
date, or a recipient detects the need for an update. Detec-
tion can be the result of either an out-of-date mote hear-
ing someone has new code, or an updated mote hearing
someone has old code. As long as every mote communi-
cates somehow – either receives or transmits – the need
for an update will be detected.
For example, if mote A broadcasts that it has code φ
x
,
but B has code φ
x+1
, then B knows that A needs an
update. Similarly, if B broadcasts that it has φ
x+1
, A
knows that it needs an update. If B broadcasts updates,
then all of its neighbors can receive them without having
to advertise their need. Some of these recipients might
not even have heard A’s transmission.
In this example, it does not matter who first transmits,
A or B; either case will detect the inconsistency. All that
matters is that some motes communicate with one an-
other at some nonzero rate; we will informally call this
the “communication rate.” As long as the network is con-
nected and there is some minimum communication rate
for each mote, everyone will stay up to date.
The fact that communication can be either transmis-
sion or reception enables Trickle to operate in sparse as
well as dense networks. A single, disconnected mote
剩余13页未读，继续阅读
yufanloveyou
- 粉丝: 0
- 资源: 2
我的内容管理
展开
最新资源
- JSP+SSM科研管理系统响应式网站设计案例
- 推荐一款超级好用的嵌入式串口调试工具
- PHP域名多维查询平台：高效精准的域名搜索工具
- Citypersons目标检测数据集：Yolo格式下载指南
- 掌握MySQL面试必备：程序员面试题解析集锦
- C++软件开发培训：核心技术资料深度解读
- SmartSoftHelp二维码工具：生成与解析条形码
- Android Spinner控件自定义字体大小的方法
- Ubuntu Server on Orangepi3 LTS 官方镜像发布
- CP2102 USB驱动程序的安装与更新指南
- ST-link固件升级指南：轻松更新程序步骤
- Java实现的质量管理系统Demo功能分析与操作
- Everything高效文件搜索工具：快速精确定位文件
- 基于B/S架构的酒店预订系统开发实践
- RF_Setting(E22-E90(SL)) V1.0中性版功能解析
- 高效转换M3U8到MP4：免费下载工具发布
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
