Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(295)

Side by Side Diff: src/devices/uan/uan.h

Issue 1350041: UAN module addition
Patch Set: Created 13 years, 10 months ago
Left:
Right:
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
View unified diff | Download patch
OLDNEW
(Empty)
1 /* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */
2 /*
3 * Copyright (c) 2009 University of Washington
4 *
5 * This program is free software; you can redistribute it and/or modify
6 * it under the terms of the GNU General Public License version 2 as
7 * published by the Free Software Foundation;
8 *
9 * This program is distributed in the hope that it will be useful,
10 * but WITHOUT ANY WARRANTY; without even the implied warranty of
11 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
12 * GNU General Public License for more details.
13 *
14 * You should have received a copy of the GNU General Public License
15 * along with this program; if not, write to the Free Software
16 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
17 *
18 * Author: Leonard Tracy <lentracy@gmail.com>
19 */
20
21 /**
22 * \ingroup devices
23 * \defgroup UAN UAN Models
24 *
25 * \section UanOverview UAN Module Overview
26 *
27 * The main goal of the UAN Model is to enable researchers to
28 * model a variety of underwater network scenarios. The UAN model
29 * is broken into three main parts: The channel, PHY, and MAC models.
30 *
31 *
32 * \section UanPropOverview UAN Propagation Models
33 *
34 * Modelling of the underwater acoustic channel has been an active
35 * area of research for quite some time. Given the complications involved,
36 * surface and bottom interactions, varying speed of sound, etc..., the detailed
37 * models in use for ocean acoustics research are much too complex
38 * (in terms of runtime) for use in network level simulations. We have
39 * attempted to provide the often used models as well as make an attempt to brid ge, in part, the gap between
40 * complicated ocean acoustic models and network level simulation. The three pr opagation
41 * models included are the ideal channel model, the Thorp propagation model and
42 * the Bellhop propagation model (Available as an addition).
43 *
44 * All of the Propagation Models follow the same simple interface in ns3::UanPro pagationModel.
45 * The propagation models provide a power delay profile (PDP) and pathloss
46 * information. The PDP is retrieved using the GetPdp method which returns type UanPdp.
47 * ns3::UanPdp utilises a tapped delay line model for the acoustic channel.
48 * The UanPdp class is a container class for Taps, each tap has a delay and ampl itude
49 * member corresponding to the time of arrival (relative to the first tap arriva l time)
50 * and amplitude. The propagation model also provides pathloss between the sou rce
51 * and receiver in dB re 1uPa. The PDP and pathloss can then be used to find th e
52 * received signal power over a duration of time (i.e. received signal power in
53 * a symbol duration and ISI which interferes with neighbouring signals). Both
54 * UanPropModelIdeal and UanPropModelThorp return a single impulse for a PDP.
55 *
56 * a) Ideal Channel Model ns3::UanPropModelIdeal
57 *
58 * The ideal channel model assumes 0 pathloss inside a cylindrical area with bo unds
59 * set by attribute. The ideal channel model also assumes an impulse PDP.
60 *
61 * b) Thorp Propagation Model ns3::UanPropModelThorp
62 *
63 * The Thorp Propagation Model calculates pathloss using the well-known Thorp a pproximation.
64 * This model is similar to the underwater channel model implemented in ns2 as described here:
65 *
66 * Harris, A. F. and Zorzi, M. 2007. Modeling the underwater acoustic channel i n ns2. In Proceedings
67 * of the 2nd international Conference on Performance Evaluation Methodologies and Tools
68 * (Nantes, France, October 22 - 27, 2007). ValueTools, vol. 321. ICST (Institu te for Computer
69 * Sciences Social-Informatics and Telecommunications Engineering), ICST, Bruss els, Belgium, 1-8.
70 *
71 * The frequency used in calculation however, is the center frequency of the mo dulation as found from
72 * ns3::UanTxMode. The Thorp Propagation Model also assumes an impulse channel response.
73 *
74 * c) Bellhop Propagation Model ns3::UanPropModelBh (Available as an addition)
75 *
76 * The Bellhop propagation model reads propagation information from a database. A configuration
77 * file describing the location, and resolution of the archived information mus t be supplied via
78 * attributes. We have included a utility, create-dat, which can create these data files using the Bellhop
79 * Acoustic Ray Tracing software (http://oalib.hlsresearch.com/).
80 *
81 * The create-dat utility requires a Bellhop installation to run. Bellhop take s
82 * environment information about the channel, such as sound speed profile, surf ace height
83 * bottom type, water depth, and uses a gaussian ray tracing algorithm to deter mine
84 * propagation information. Arrivals from Bellhop are grouped together into eq ual length
85 * taps (the arrivals in a tap duration are coherently summed). The maximum ta ps are then
86 * aligned to take the same position in the PDP. The create-dat utility averag es together
87 * several runs and then normalizes the average such that the sum of all taps i s 1. The same
88 * configuration file used to create the data files using create-dat should be passed via
89 * attribute to the Bellhop Propagation Model.
90 *
91 * The Bellhop propagation model is available as a patch. The link address wil l be
92 * made available here when it is posted online. Otherwise email lentracy@gmai l.com
93 * for more information.
94 *
95 *
96 * \section UanPhyOverview UAN PHY Model Overview
97 *
98 * The PHY has been designed to allow for relatively easy extension
99 * to new networking scenarios. We feel this is important as, to date,
100 * there has been no commonly accepted network level simulation model
101 * for underwater networks. The lack of commonly accepted network simulation
102 * tools has resulted in a wide array of simulators and models used to report
103 * results in literature. The lack of standardization makes comparing results
104 * nearly impossible.
105 *
106 * The main component of the PHY Model is the generic
107 * PHY class, ns3::UanPhyGen. The PHY class's general responsibility
108 * is to handle packet acquisition, error determination, and forwarding of succe ssful
109 * packets up to the MAC layer. The Generic PHY uses two models for determinati on
110 * of signal to noise ratio (SINR) and packet error rate (PER). The
111 * combination of the PER and SINR models determine successful reception
112 * of packets. The PHY model connects to the channel via a Transducer class.
113 * The Transducer class is responsible for tracking all arriving packets and
114 * departing packets over the duration of the events. How the PHY class and the PER and SINR models
115 * respond to packets is based on the "Mode" of the transmission as described by the ns3::UanTxMode
116 * class.
117 *
118 * When a MAC layer sends down a packet to the PHY for transmission it specifies a "mode number" to
119 * be used for the transmission. The PHY class accepts, as an attribute, a list of supported modes. The
120 * mode number corresponds to an index in the supported modes. The UanTxMode co ntains simple modulation
121 * information and a unique string id. The generic PHY class will only acquire arriving packets which
122 * use a mode which is in the supported modes list of the PHY. The mode along w ith received signal power,
123 * and other pertinent attributes (e.g. possibly interfering packets and their m odes) are passed to the SINR
124 * and PER models for calculation of SINR and probability of error.
125 *
126 * Several simple example PER and SINR models have been created.
127 * a) The PER models
128 * - Default (simple) PER model (ns3::UanPhyPerGenDefault): The Default PER model tests the packet against a threshold and
129 * assumes error (with prob. 1) if the SINR is below the threshold or succe ss if the SINR is above
130 * the threshold
131 * - Micromodem FH-FSK PER (ns3::UanPhyPerUmodem). The FH-FSK PER model calc ulates probability of error assuming a
132 * rate 1/2 convolutional code with constraint length 9 and a CRC check cap able of correcting
133 * up to 1 bit error. This is similar to what is used in the receiver of t he WHOI Micromodem.
134 *
135 * b) SINR models
136 * - Default Model (ns3::UanPhyCalcSinrDefault), The default SINR model assumes that all transmitted energy is captured at the receiver
137 * and that there is no ISI. Any received signal power from interferes acts a s additional
138 * ambient noise.
139 * - FH-FSK SINR Model (ns3::UanPhyCalcSinrFhFsk), The WHOI Micromodem operating in FH-FSK mode uses a predetermined hopping
140 * pattern that is shared by all nodes in the network. We model this by only including signal
141 * energy receiving within one symbol time (as given by ns3::UanTxMode) in cal culating the
142 * received signal power. A channel clearing time is given to the FH-FSK SINR model via attribute.
143 * Any signal energy arriving in adjacent signals (after a symbol time and the clearing time) is
144 * considered ISI and is treated as additional ambient noise. Interfering si gnal arrivals inside
145 * a symbol time (any symbol time) is also counted as additional ambient noise
146 * - Frequency filtered SINR (ns3::UanPhyCalcSinrDual). This SINR model calcula tes SINR in the same manner
147 * as the default model. This model however only considers interference if th ere is an overlap in frequency
148 * of the arriving packets as determined by UanTxMode.
149 *
150 * In addition to the generic PHY a dual phy layer is also included (ns3::UanPh yDual). This wraps two
151 * generic phy layers together to model a net device which includes two receive rs. This was primarily
152 * developed for UanMacRc, described in the next section.
153 *
154 *\section UanMAC UAN MAC Model Overview
155 *
156 * Over the last several years there have been a myriad of underwater MAC propos als
157 * in the literature. We have included three MAC protocols with this distributi on:
158 * a) CW-MAC, a MAC protocol which uses a slotted contention window similar in n ature to
159 * the IEEE 802.11 DCF. Nodes have a constant contention window measured in slo t times (configured
160 * via attribute). If the channel is sensed busy, then nodes backoff by randoml y (uniform distribution) choose
161 * a slot to transmit in. The slot time durations are also configured via attri bute. This MAC was described in
162 *
163 * Parrish N.; Tracy L.; Roy S. Arabshahi P.; and Fox, W., System Design Consid erations for Undersea Networks:
164 * Link and Multiple Access Protocols , IEEE Journal on Selected Areas in Commun ications (JSAC), Special
165 * Issue on Underwater Wireless Communications and Networks, Dec. 2008.
166 *
167 * b) RC-MAC (ns3::UanMacRc ns3::UanMacRcGw) a reservation channel protocol whic h dynamically divides
168 * the available bandwidth into a data channel and a control channel. This MAC protocol
169 * assumes there is a gateway node which all network traffic is destined for. T he current
170 * implementation assumes a single gateway and a single network neighborhood (a single hop network).
171 * RTS/CTS handshaking is used and time is divided into cycles. Non-gateway nod es transmit RTS packets
172 * on the control channel in parallel to data packet transmissions which were sc heduled in the previous cycle
173 * at the start of a new cycle, the gateway responds on the data channel with a CTS packet which includes
174 * packet transmission times of data packets for received RTS packets in the pre vious cycle as well as bandwidth
175 * allocation information. At the end of a cycle ACK packets are transmitted fo r received data packets.
176 *
177 * When a publication is available it will be cited here.
178 *
179 * c) Simple ALOHA (ns3::UanMacAloha) Nodes transmit at will.
Josh Pelkey 2010/06/08 19:24:26 very nice documentation :)
180 *
181 *
182 */
OLDNEW

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b