Low Power Ad-Hoc Network for Ground to Air
Communication
by
Joshua J. Stults
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Electrical Engineering and Computer Science
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 22, 2000
Copyright 2000 Joshua J. Stults. All rights reserved.
The author hereby grants to M.I.T. permission to reproduce and
distribute publicly paper and electronic copies of this thesis
and to grant others the right to do so.
Author
art ent of Electrical Engineering and Computer Science
May 17, 2000
Certified by
Michael A. Deaett
Carles Stark Draper Laboratory
Thesis Supervisor
Certified by
Steven G. Finn
The~supervisor
Accepted by
Arthur C. Smith
Chairman, Department Committee on Graduate Theses
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
ENG
JUL 2 7 2000
LIBRARIES
Low Power Ad-Hoc Network for Ground to Air
Communication
by
Joshua J. Stults
Submitted to the Department of Electrical Engineering and Computer Science
on May 22, 2000 in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Electrical Engineering and Computer Science
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
Abstract
In this thesis we consider the design of a multi-subscriber, ground-to-air communications
system for guidance of unmanned aircraft or aerial users. The system consists of a
central controlling node called a Grid Coordinating Station (GCS) and a multihop,
wireless network of low power data relay stations, termed Grid Reference Stations
(GRSs). In addition to relaying destination update messages, GRSs generate and transmit
Global Position System (GPS) differential correction messages to the aircraft.
Communications is conducted at 10 Ghz using CDMA and a slotted half-duplex
approach. A significant feature of our system is the Ad-hoc deployment and setup of the
relay network. The throughput, latency, message reliability and user capacity of the
proposed system are evaluated by analysis and simulation, to demonstrate that acceptable
performance is achievable.
Faculty Thesis Supervisor:
Steven G. Finn
Draper Thesis Supervisor:
Michael A. Deaett
2
ACKNOWLDEDGMENT
May 22, 2000
This Thesis was prepared at The Charles Stark Draper Laboratory, Inc., under project
15085 - Distributed Platform Data Link Network Design, contract number 00-0-2012.
Publication of this thesis does no constitute approval by Draper or the sponsoring agency
of the findings or conclusions contained herein. It is published for the exchange and
stimulation of ideas.
(
I'
3
A
'
(au ~r's signature)
[This Page Intentionally Left Blank]
4
Acknowledgements
I would like to thank the Charles Stark Draper Laboratory for sponsoring my
research on this project. I would like to thank my advisor at Draper, Michael Deaett, for
his help and guidance during the project. I would also like to thank Professor Steven
Finn, my MIT faculty thesis advisor for his assistance on this project.
5
Table Of Contents
Table Of Contents ............................................................................................................................ 6
List of Figures ................................................................................................................................... 8
List of Tables .................................................................................................................................... 9
1
Introduction .............................................................................................................................. 10
1.1
Past W ork ........................................................................................................................ 11
Problem Description ......................................................................................................... 12
1.2
Thesis Outline and Approach ........................................................................................... 13
1.3
2
Prelim inary Analysis ................................................................................................................ 16
*- 16
*"*'*"*...
..... ****"****** ....
..................
:**-- ......
2.1
Link Issues ...
Traffic Analysis ................................................................................................................. 17
2.2
2.3
A Simple Deployed System Example .............................................................................. 19
2.4
TDMA Solution and Performance .................................................................................... 19
GRS MAC ................................................................................................................................ 23
3
Multi-Access & Scheduling .............................................................................................. 23
3.1
3.2
CDMA ............................................................................................................................... 25
3.3
Scheduling ....................................................................................................................... 27
4
LINK ........................................................................................................................................ 30
4.1
Data Rates ....................................................................................................................... 30
4.2
Coding for Processing Gain ............................................................................................. 32
Modulation ........................................................................................................................ 35
4.3
Link Budgets .................................................................................................................... 35
4.4
4.5
Processing Gain ............................................................................................................... 37
4.6
Time Slot Size .................................................................................................................. 43
5
Routing .................................................................................................................................... 45
Transm ission Priority ....................................................................................................... 48
5.1
6
Additional Topics ..................................................................................................................... 51
6.1
Network Setup ................................................................................................................. 51
6.2
Propagation ...................................................................................................................... 51
7
Analysis ................................................................................................................................... 54
8
Sim ulation ................................................................................................................................ 61
8.1
High Uplink Load .............................................................................................................. 62
8.2
Uplink Capacity Limit ....................................................................................................... 63
8.3
Medium System Load ...................................................................................................... 64
8.4
High System Load ............................................................................................................ 66
9
Conclusion ............................................................................................................................... 70
10 Appendix 1 - OpNet ................................................................................................................. 72
10. 1 N etwo rk Leve I.................................................................................................................. 72
10.1.1
Overview ................................................................................................................... 72
10.1.2 Options ..................................................................................................................... 73
10.2 GCS ................................................................................................................................. 75
10.2.1
Overview ................................................................................................................... 76
10.2.2 Packet Generator ...................................................................................................... 77
10.2.3
Router Object ............................................................................................................ 78
10.2.4 MAC Object .............................................................................................................. 81
10.2.5 Radio Objects ........................................................................................................... 82
10.2.6
Receive Module ........................................................................................................ 82
10.3 GRS ................................................................................................................................. 83
10.3.1
Overview ................................................................................................................... 83
10.3.2
Generator Object ...................................................................................................... 83
10.3.3
Router Object ............................................................................................................ 84
10.3.4 GRS MAC Object ..................... I................................................................................ 85
10.3.5 Radio Objects ........................................................................................................... 87
6
10.3.6
User .......................................................................................................................... 88
88
11 *1*1* 1*1 11, ..... *....
-110.4 Matlab ........... :*,** ...
11 Appendix 2 - Terrain ................................................................................................................ 90
12 References .............................................................................................................................. 93
7
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
19
1: Sample scenario containing one GCS and four GRS's. .............................................
2: Power efficiency is greater when multiple hops are made........................................
24
3: Scheduling Example ..................................................................................................
27
4: Example of an orthogonal and biorthogonal codeword set........................................ 33
5: Signal to Interference ratio seen at a GRS 1/d 2 (a) and 1/d 4 (b) path loss.................39
6: Signal to Interference ratio seen at a user................................................................
41
7: Illustration of possible modified antenna patterns to reduce user S/I ratio.................42
8: Routing example using deterministic (a) and probabilistic (b) distributed algorithms.... 46
9: Capacity limit as a function of the amount of user and routing data...........................56
10: Network view of scenario in which 80 users are all serviced by one GRS ...............
62
11: Packet latency versus simulation time for 80 users ................................................
62
12: Final queue size after 10 seconds versus number of users. ....................................
64
13: Packet latency versus simulation time for 240 users............................................... 65
14: Network level view of simulation with 240 users.....................................................
64
15: Packet latency versus simulation time for 480 users............................................... 67
16: Number of messages lost as a function of Khz of spectrum used............................68
17: OpNet screen capture of the network level view of the 240 user simulation............72
18: Rule for determining the next node of a message ...................................................
74
19: OpNet screen capture of the GCS node model .......................................................
75
20: OpNet screen capture of the packet generator settings ..........................................
77
21: OpNet screen capture of the GCS router process model........................................ 79
22: OpNet screen capture of the GRS node model. ......................................................
83
23: OpNet screen capture of the GRS router process model FSM. ...............................
84
24:OpNet screen capture of the GRS MAC process model FSM...................................86
25: OpNet screen capture of User node model ..............................................................
88
26: Terrain generated by gforge and rendered by POV-RAY........................................ 90
8
List of Tables
Table
Table
Table
Table
Table
Table
Table
Table
1:
2:
3:
4:
5:
6:
7:
8:
Link budget for a 25 km line of sight link from a GRS to a user..................................
Maximum bit rate with Gr = 3dB and various distances ..............................................
Message types and characteristics ..............................................................................
Link budgets for uplink and crosslink radio links..........................................................
Estimated transmitter utilization percentages. .............................................................
Simulated transmitter utilization percentages. .............................................................
Transmitter utilizations for a high load simulation .......................................................
Number of lost messages for different amounts of spectral usage.............................
9
16
17
18
36
60
66
68
69
1
Introduction
The aim of this project is to design a data link network for a real-time unmanned
aircraft navigation system. The system consists of aerial users, often referred to as
simply users, Grid Reference Stations (GRSs), and a central control node called the Grid
Coordinating Station (GCS). The aerial users employ onboard Global Positioning
System (GPS) receivers and other guidance equipment to guide them to a destination. To
obtain a more accurate position location, the user GPS receiver receives GPS differential
corrections from the nearest GRS. The user also wants to receive updated destination
coordinates, enabling destination changes during flight. For the aerial user to accurately
reach its destination, these coordinates and the GPS differential corrections must be
reliably transmitted to the user in a timely fashion.
The coordinates are transmitted to the user through a network of GRSs. The data
is transmitted through the network until it reaches the GRS nearest to the aerial user. The
GRS knows its position accurately and generates GPS differential corrections for the area
it services. The destination update data and the differential corrections are then
transmitted up to the user. Each GRS may communicate with many users and there may
be many GRS's in the system.
In the system, there is one GCS which manages the network and interfaces with
external communications systems to obtain updated destination coordinates. The GCS is
in communication with each of the GRS's to query their status and to provide them with
updated destination coordinates.
There are many systems that use communications networks for navigational
updates, but this system differs in how the network is deployed. The GRS's will be
10
arranged in a grid extending from the location of the departure sites out to and covering
the area containing the destination sites. This creates an area in which the aerial users,
can precisely find their positions, and receive data updates (such as destination
coordinates). The terrain may be unknown and, as the grid may be located in or near an
undeveloped area, we may have many restrictions when designing and laying out the
grid. The GRSs may be disposable and battery powered, and may even be simply
dropped from airplanes rather than actually being accurately placed. This places tight
constraints on the transmission power of the devices. This distribution of transmitting
devices into a grid is similar to a cell phone network, except that the careful planning
involved in placing a cell tower is not possible in this environment and wireline links
between the cells are not available.
The network should be designed to maximize the reliability of data delivery while
at the same time allowing communication with many users simultaneously. The
guidance accuracy also depends on the rate and latency at which the data is received.
This accuracy should also be optimized as much as possible given the constraints. The
data rate of the communications link is somewhat limited due to the physical
characteristics of the users and the low power output of the GRS's. The routing and
multi-access methods should be efficient to meet these requirements.
1.1
Past Work
Since this application is similar to the design of a cellular phone network there is
applicable prior work in the area of cellular communications system design. This can be
used in estimating the capacity of the system, in terms of the number of users that it can
11
support [2, 10]. Past work can be helpful in deciding how the spectrum can be reused.
Research in the area of packet radio is also applicable to both the GRS to GRS
communications and in communications with the users, which we now define as
crosslink and uplink communications respectively [4,12]. Past work also exists in the
area of Ad-hoc networks [3,5,12]. Most of this applies to networks in which the nodes
are mobile and therefore the connections may be changing frequently. The links between
the GRSs aren't very dynamic, but some of the ad-hoc network concepts are still
applicable. As the system will be deployed in a variety of environments we must take
into account the effects of terrain and foliage. A great deal of material is available in
both of these areas [1,6]. This material is useful in designing the system to function well
in a variety of environments. It may also be used to model real world environments for
simulating the system once it has been designed.
1.2
Problem Description
The focus of the project is to design a method of efficiently transmitting
destination updates from the GCS to aerial users through the GRS network. The GRSs
are arranged to provide full coverage to a large area so that users can be guided to
destinations anywhere in the area. Since the individual components have limited
transmission range, multi-hop is used to transmit data to a distant GRS, which then relays
the update data and sends the differential corrections to the users. The network must be
able to reliably transmit the destination updates from the GCS to a user and GPS
differential updates from a GRS to a large number users. Basic system performance
12
requirements have already been laid out1 . We now define uplink capacity as the
maximum number of users supported simultaneously within the coverage area of a single
GRS, and the system capacity as the maximum number of users supported simultaneously
by the entire network. Our uplink and system capacity goals are 90 and 200 respectively.
We would like to support a grid size of 150x50 km and transmit data to users with
altitudes as high as 17km. The user flight times vary between one and a half and two and
a half minutes.
1.3
Thesis Outline and Approach
We begin with a preliminary analysis, in section 2, to get a general idea of what
the issues are. Here we analyze the message sizes and frequencies to obtain a basic
model of the network traffic. We also analyze the communication links and determine
realistic bit rates. A simple system approach is then proposed and various design choices
are explored. We get some initial capacity measurements, which are below our goals.
We then proceed by investigating how to improve on the simple approach.
In section 3 we look at the organization of the network in general. We discuss
using multi-hop to transmit data to a distant GRS. We discuss using Code Division
Multiple Access CDMA (CDMA) to allow multiple GRSs to transmit simultaneously and
share the communications channel. The GRSs are half-duplex so scheduling is required
to ensure that a node is not transmitting while it should be receiving data. Here we
introduce our method of scheduling and discuss the size of the transmission time slots.
1These
specifications are from personal conversations with Draper employees and unpublished
Draper internal documents
13
In section 4 we develop improvements to the link level portion of the system. We
begin by calculating desired bit rates to reach our target capacity. We then propose
improvements to reach these bit rates and recalculate the link budgets. Finally we
analyze the how much extra spectrum will be required to implement CDMA.
In section 5 we focus on routing in the GRS network. We propose various
methods, discuss advantages and disadvantages, and choose an algorithm to be used for
the later analysis and simulation. This section also contains a discussion of how to
prioritize messages to reduce latency.
In section 6 we discuss two areas which are not specifically addressed in our final
design. The first is the setup and initialization of the network once it is deployed. The
network topology needs to be determined by the GCS and various parameters need to be
set before our design can operate. Second we discuss the possibility that we are not able
to model the propagation characteristics between the GRSs as free space loss. We
discuss the impact of this on the design and propose some possible ways overcome this
obstacle.
Next, in sections 7 and 8, we combine the elements we have proposed in the
earlier sections and we analyze and simulate our design. Using several different
scenarios we analytically estimate the capacity of the system and the latency that can be
expected. We follow this with measurements of system capacity and performance
through simulation. This data is compared with the predicted data from the analysis
section. Finally, in section 9, we summarize our results and discuss areas for future
work.
14
Appendix A provides a more detailed description of the simulation design.
Appendix B describes some additional research about vegetation and terrain and their
effects on communications.
15
Preliminary Analysis
2
Before we can design a good network we need to get a rough idea of the
requirements. This includes an estimate of how much data will need to be sent across the
network and how many users should be supported. Prior work2 places some restrictions
on the capabilities of the receiver and transmitter hardware. It also defines basic message
sizes and their frequencies for both the differential corrections and for the destination
updates. This data is outlined below and a simple system approach is presented to
illustrate the system concept. After an initial analysis, we see that our simple approach
does not meet our goals, and we begin making improvements, to arrive at a design that
better meets our requirements.
2.1
Link Issues
One of the major restrictions in the system is the rate at which data can be
transmitted to the users. The GRSs are battery powered devices with limited
transmission power (<10W), and the users have very low gain antennas at the desired
frequency of 10Ghz. Table 1 shows an approximate link budget for a 25km line-of-sight
Variable
EIRP
Gr
EdNo
kTj
L,
Lo
Margin
R
Description
Effective power output of the transmitter
Gain of the receiver antenna
Bit energy to noise ratio
Thermal noise factor
Space loss
Noise Loss
EIRP + Gr - Eb/No - Margin - kT 0 - Ls - Lo
Value
1OdbW
-10dB
11dB
-204dBW/Hz
140.4 dB (f = 10GHz, d =25 km)
4dB
3dB
45.6 dB = 36.3 Kbps
Table 1: Link budget for a 25 km line of sight link from a GRS to a user. Based on results
in [9].
2
Unpublished Draper Internal Document
16
link between a GRS and an aerial user, based on formulas developed in [9]. To simplify
our discussion, we call the link between the GRS and a user the uplink, and the links
between GRSs and between the GCS and GRSs crosslinks. As can be seen from the
table, the maximum data rate for the 25 km uplink is 36.3 Kbps. As will be seen in the
following sections, this data rate does not satisfy our capacity goals, given the traffic
requirements.
Because the GRSs and GCS do not have
.
.
.25
this same limitation on their antenna gains as the
user receiver, we can transmit data between them
Distance
km
Bit Rate
720 Kbps
54km
154Kbps
34 km
391 Kbps
Table 2: bit rate with G, = 3dB and
higher rate. Table 2 shows the maximum bit
various distances. (other parameters
equal to table 1)
rates for various distances with G, = 3dB (this is
assuming line-of-site communications with l/d2 propagation loss).
2.2
Traffic Analysis
The message traffic between the GRS and the GCS and messages sent from the
GRS to the users have been defined 3. This data is summarized in Table 3. Most messages
are sent either once every 10 seconds or once every second, depending on the proximity
of the user to the destination. As the user nears the destination, the updates must occur
more rapidly. Some documentation also seems to indicate that increases in accuracy
could be obtained by further increasing this rate 3 . For the current analysis we assume that
updates occur once per second throughout the user's flight.
3 Unpublished Draper Internal Document
17
Message Type
GRS Destination
Update
GCS Status
GRS Control
GRS Status1
GRS Status2
GPS Differential
Corrections
User Destination
Update
Frequency
1Hz
Size (bits)
296/destination
Link
GCS to GRS
124
115
95/destination
29
1440
GCS
GCS
GRS
GRS
GRS
GRS
GRS
GCS
GCS
User
1Hz
1Hz
1Hz
1Hz
1Hz
267/destination
GRS to User
1Hz
to
to
to
to
to
Table 3: Message types and characteristics.
Below we calculate the message traffic that must occur between the GCS and one
GRS, and between that GRS and any users it is servicing. These calculations are
therefore per GRS and to find the total traffic in the system one would need to sum up the
traffic required for each GRS.
Communication between the GRS and the GCS occurs according to the following
rates:
n = the number of users being serviced simultaneously by the GRS.
Total data sent from GCS to GRS per second:
RCR = 296n + 124 + 115 bits
(2.1)
Total data sent from GRS to GCS per second.
RRC = 29 + 95n bits
(2.2)
Total data sent between GRS and GCS (both directions).
RTOT = RCR + RRC = 268 + 391n bits
(2.3)
Total data sent by GRS to the users it is currently servicing:
RRU = 1440 + 267n bits
(2.4)
18
2.3
A Simple Deployed System Example
A simple deployment is a front of about 100 km in width with the destinations in
range of the aerial users (25-30 km). To form this grid, four GRSs are arranged in a line.
For this example the GRS are 34 km apart completely covering a rectangular area of 34 x
136 km. The distance between the GCS and GRS2 and GRS3 is therefore about 24 km,
and the distance between GCS and GRS 1 and GRS4 is 54 km.
GRSI
Radius of
Communication
(25km)
...
........
RS4
GRS3
RS
..
..
GCS
A Departure Site
Figure 1: Sample scenario containing one GCS and four GRS's spread across a 100 km
front.
2.4
TDMA Solution and Performance
A simple solution is to use Time Division Multiple Access (TDMA) across the
whole network, so that no GCS or GRS node interferes with another node's transmission.
All GCS, GRS and user nodes transmit and receive at the rate of 36.3 Kbps, calculated in
section 2.2. Based on the data rate and message traffic requirements, section 2.2, we can
calculate an upper bound for the system and uplink capacities. In this section we assume
that the users are evenly distributed across the network. We calculate the uplink capacity
by considering only the traffic sent to and sent by GRS 1. Since this traffic associated with
GRS 1 is 1/4 of the total traffic sent in the network, it can use 9.075 Kbps of bandwidth.
19
The bound on uplink capacity is then calculated by summing equation 2.3 and 2.4, setting
this equal to 9.075Kbps and solving for n. The uplink capacity is 11 and the system
capacity is 44.
nu = (9075 - 1440 - 268)/(391 + 267) = 11 users/GRS
ns = 44 users total
where nu = uplink capacity
ns= system capacity
The limit on the bit rate is primarily due to the low gain (-10dB) antenna on the
user receiver. Since the GCS and GRS antennas have a +3dB gain, the crosslink bit rate
can be increased to 154Kbps, assuming that the GCS communicates directly with each
GRS and the maximum distance from GCS to GRS is 54km (Table 2). One way to
increase system capacity is to use a data rate of 154Kbps for the crosslinks, continuing to
use 36.3Kbps for the uplink. We now calculate the uplink and system capacities with this
modification. We will analyze this by calculating the fraction of a unit of time that must
be spent transmitting at the slower bit rate (2.5), and then the fraction of time that must be
spent transmitting at the higher rate (2.6), for n users. The sum of these two fractions is
then set to 1, and the equation is solved for n to calculate the uplink capacity. The system
capacity is four times the uplink capacity.
F1 = Fraction of channel utilization to transmit to users
F1-
(# of GRS's).(Bit Rate per GRS) _ 4(1440+267on)
36300
(Channel Bit Rate)
(2.5)
F2 = Fraction of channel utilization for GCS-GRS communication
F2
Rate per GRS) _
_ (# of GRS's).(Bit
(Channel Bit Rate)
F1 +F2= 1
4(1440+267en)
154,00
(2.6)
(2.7)
20
Now solving for n:
nu ~21 users/GRS
n_ 84 users total
By using separate uplink and crosslink data rates we have nearly doubled the
uplink and system capacities.
A further improvement is to use multi-hop to communicate between distant
GRS's and the GCS. For example, if GRS 1 and GRS4 do not communicate directly with
the GCS, then the maximum distance between stations is 34 km (between GRS 1 and
GRS2 or GRS3 and GRS 4), and the maximum bit rate for this range would be 391 Kbps
(Table 2). Repeating the calculations above, F1 is the same as (2.5), and F2 is as follows:
F2 =
(#of GRS's).(Bit Rate per GRS) _ 6(268+391*n)
391,000
(Channel Bit Rate)
(2.8)
We note in (2.8) # of GRSs parameter is has been modified to reflect the effective
number of GRSs. Here the number # of GRS's is six, because all data to and from GRS 1
and GRS4 must be transmitted over the channel twice.
F1 +F2= 1
Now solving for n:
nu =23 users/GRS
n, ~92 users total
The capacity has again increased slightly, but latency will increase due to the
retransmission of messages destined for GRS 1 and GRS4.
21
Note that capacities are still well below our goals of n, = 90 and n, = 200. In the
sections that follow we will further develop the design to increase the uplink and system
capacities.
22
3
GRS MAC
The Medium Access Control, or MAC, portion of the system determines how the
GRS and GCS transmitters share the channel. For this analysis, we assume the GRSs are
arranged in a regular square grid and there are no line of sight issues. In other words, if
GRSs are in range of each other, communication is possible. These constraints allow
some simplification of the problem, which facilitate greater efficiency. Some of these
constraints may have to be relaxed when line-of-site issues are considered, but the current
analysis will be made under these assumptions.
3.1
Multi-Access & Scheduling
The initial analysis assumed that all stations shared the same channel, but it also
assumed perfectly efficient use of the channel. This is not usually the case. Many
different medium access protocols exist to allow multiple users to share a
communications channel.
The simple Aloha protocol is probably the most primitive [7]. Each station
simply transmits when it has information to transmit. If a collision occurs the
transmission is repeated. The maximum channel efficiency for this protocol is only about
18%. For our application, this is unacceptable. Slotted aloha improves on the aloha
protocol by requiring that transmission begin only in set time slots. This avoids
collisions in the middle of packet transmission and increases the maximum channel
utilization to about 37%. This can still be improved upon greatly.
Ethernet, which is commonly used in local area networks, is a carrier sensing
protocol. Simply stated, this protocol listens to see if the channel is free, and if so, it
23
begins transmission. 10Mbps wireline ethernet can obtain an efficiency of 85% or more.
IEEE 802.11 is an Ethernet type protocol for wireless LANs that has recently gained
popularity [8]. 802.11 is a complete system specification which is much more than
simply a medium access control protocol. Its link level specifications have elements to
overcome multi-path and fading which are important factors in wireless networks, and
especially indoor networks.
This protocol could be a viable option for our system, but there is one major
difference between these systems and ours. In our system the GRSs'main purpose is to
provide communications to the user. Therefore they are located to provide
communications (as long as they are within 25 km of each other). In the other types of
LANs, the nodes are placed according to other requirements (where a desk or piece of
machinery is located). Many nodes of
P =4
the LAN may directly communicate
this is not needed. The ideal layout of
our system would have the nearest
the
neighbors of each node exactly at
P =1
P =1
with many other nodes. In our system
Node 1
Node 2
Node 3
Figure 2: Power efficiency is greater when
multiple hops are made.
limit of the node's transmission radius. Transmitting farther than that is a waste of
power.
For instance, suppose there are three nodes in a line and they are each spaced 1
unit of distance apart as in Figure 2. Also assume that it takes one unit of power to
transmit a unit of data across one unit of distance. Now if node 1 transmits 1 unit of data
to node 2 and then node 2 transmits that unit of data to node 3, 2 units of power have
24
been used. Now if node 1 transmits this unit of data directly to node 3, covering 2 units
of distance, 22 = 4 units of power will be used. It is therefore advantageous, from a
power standpoint, for a node to communicate only with its closest neighbors.
In our system, a node only communicates with a limited set of its closest
neighbors and packets are routed to the desired node, using multi-hop.
3.2
CDMA
CDMA is used as a multi-access protocol, to avoid interference from adjacent
nodes with which communication is not desired. In a CDMA system, multiple users
transmit simultaneously, all using the same frequency band, but using separate codes [9].
A receiver can then detect the signal associated with a specific code, amplify it with
respect to noise and the other signals, and receive the data.
TDMA and Frequency Division Multiple Access (FDMA) schemes, other options
that were considered, provide completely orthogonal channels between users. This
means that separate frequencies or time slots would be required for each communication
link in the system. If TDMA were used, each node would be allowed to transmit for only
a short percentage of the time. As our bit rate is limited, the amount of bandwidth
available to each node would quickly decrease as nodes were added to the system.
In an FDMA system, each node would transmit in a separate region of the
frequency spectrum. Frequency reuse, allowing multiple nodes to transmit on the same
frequency if they are located sufficiently far apart, could also be employed to conserve
spectrum. One advantage of CDMA is that it allows us to continuously adjust our
spectrum usage while designing the system. Since many nodes can transmit
25
simultaneously a node will receive interference in addition to the desired signal. As will
be discussed in section 4.5, the receiver can more accurately receive the desired signal
when the spectral usage is increased. In FDMA, increasing the number of unique
frequencies decreases interference and also allows the receiver to more accurately receive
the desire signal, but the number of frequencies can obviously only be adjusted by integer
amounts, making CDMA more attractive. Since CDMA nodes all transmit using the
same frequency band, all nodes have identical hardware except for the spreading code
being used. FDMA requires that different frequency bands be used to communicate with
different users, increasing the transmitter and receiver complexity. In addition, CDMA
inherently protects against jamming and interception of the signals. This feature could be
critical for certain applications.
We propose that each GRS and GCS have its own unique code used for
transmitting, both to the users and to neighboring GRSs. It is capable of receiving from
its four nearest neighbors on four distinct codes. This scheme is different from most
CDMA schemes in which each user has its own spreading code. There are several
reasons for choosing this type of scheme. The first reason is to efficiently broadcast the
GPS differential corrections. All users within a GRS's radius of communication must
receive the same GPS differential corrections each second. As less bits are actually
transmitted, it is much more power efficient to simply transmit using one code that can be
received by all of the users rather than simultaneously transmitting the information using
many different codes. This scheme also permits extending the system to allow users to
simultaneously receive from multiple GRSs. The user would simply have multiple
receiver channels that receive using different spreading codes. Multiple GRSs could
26
transmit redundant messages to a user for added reliability, especially in an environment
with irregular terrain.
3.3
Scheduling
The GRSs are half-duplex (they cannot simultaneously transmit and receive),
because they transmit and receive in the same frequency band and the radiated power
during transmission would drown out any signals being received. Scheduling is needed
to ensure that a GRS does not transmit while it should be receiving data. Using a square
grid and allowing a GRS to transmit to, at most, its nearest four neighbors we can meet
our scheduling requirements with only two slots. The stations are simply divided into two
groups. While group one is transmitting, group two is receiving and vice-versa. This is
illustrated in Figure 3. During a GRS's transmission slot, it can transmit either uplink or
crosslink data, but not both simultaneously. In [12], scheduling is further explored for
environments in which there is no order to the node locations, and nodes can
communicate with more than four of their neighbors. For this work, we consider only
our two slot scheduling algorithm.
There are two
important trade-offs in
Slot 1
Slot 2
choosing the time slot length.
Since messages make
multiple hops through the
network, the message latency
will increase as we increase
Figure 3: During time slot 1 the dark nodes transmit while
the white nodes receive and during time slot 2 the white
nodes transmit while the dark nodes receive.
27
the slot length. As we make the slot length smaller, the ratio of overhead to data becomes
larger. The messages would also have to be split up and transmitted in pieces if the slot
is made to short to transmit an entire message. In choosing the slot size, we need to
balance these two effects.
As will be discussed later, there are various methods of routing the data in our
network, requiring different amounts of overhead to be placed in the packet header. For
now we assume 16-bits of routing overhead, and 4 bits overhead for priority information.
The priority field is used to ensure that the most important packets reach their destination.
I will also assume that 4 bits of data, used to tell the GRS the approximate altitude of the
user, is added to the GRS Destination Update message. The system message types and
sizes are listed in Table 3. The GRS Destination Message is 296 bits, and is the largest
crosslink message. Adding the 20 bits of routing overhead and the additional 4 bits of
data, its total size is 320 bits.
For reasons that will be discussed in section 4, we set the crosslink bit rate to 3.2
times the uplink bit rate. We now analyze how efficiently the transmission time can be
utilized for various time slot lengths.
One obvious choice for the time slot size is the size required to transmit one full
320 bit GRS Destination Update packet. This is smallest possible slot size without
fragmenting any of the crosslink messages. The GRS Status 1 messages are 95 bits each,
so three messages plus the routing overhead, could be contained in one time slot, using
305 bits. This requires that the GRS collect the GRS Status 1 messages and form them
into packets of three messages each. If this is not done then each packet will have a size
28
of 115bits. This will reduce efficiency, but may be simpler than attempting to decide
how long to wait for additional messages to form a full three-message packet.
Since the uplink data rate is lower than the crosslink data rate, messages sent in a
single slot on a crosslink will not fit into a single uplink time slot. Therefore, they must
be fragmented and transmitted in multiple time slots. The User Destination Update
message will require 2.67 uplink slots and the GPS Differential Corrections message will
require 14.4 uplink time slots. Sending a User Destination Update message leaves 11%
of the available transmission time unused, and sending a GPS Differential Corrections
message leaves 4% of the available transmission time unused, yielding efficiencies of
89% and 96% respectively.
One possible improvement is to more efficiently pack the User Destination
Update messages by transmitting several consecutively. Three 267 bit GRS to user
messages would fit into 8.01 time slots. This is close enough that added efficiency would
be gained by slightly increasing the slot size. The slot size is now set to allow
transmission of 321 bits per slot at the crosslink data rate. Now 7.98 time slots are
required to transmit three User Destination Update messages, for an efficiency of 99.8%.
The 320 bit GRS Destination Update messages are now 99.7% efficient, and the 305 bit
messages containing the 3 GRS Status 1 messages are 95% efficient. The above scheme
significantly improves efficiency, and could be used when the arrival rate of user data is
sufficiently high.
29
4
Link
In This section we explore options for improving the performance over the initial
design and begin to arrive at a design to be used in the later analysis and simulation.
4.1
Data Rates
Based on the traffic requirements from section 2.2 and desired uplink and system
capacity from section 1.2, we can calculate necessary bit rates for the uplinks and
crosslinks. As stated in section 3.3 and further discussed in section 4.2, the crosslink rate
is 3.2 times the uplink rate. We use an analysis similar to equations (2.5)-(2.7) to
calculate the bit rate required to obtain an upper bound of 90 users for the uplink
capacity. Equation (4.1) says that the percentage of time required to transmit uplink
traffic plus the percentage of time required to transmit crosslink traffic equals the
percentage of time that the GRS is allowed to transmit. The percentage of time the GRS
is allowed to transmit is always 50% for our scheduling scheme. Equation (4.2) solves
(4.1) for the uplink rate, and (4.3) is filled in with values from Table 3. Finally (4.4)
gives us the required uplink rate to support an uplink capacity of 90 users.
(users) -(msgu ) + (diff )
rated
(users) -(msg,) + (status)
rater
-
tx%
(4.1)
ratec=3.2-rateu
rateu = (users) -(msgu)+(diff)
1
(users) -(msgc)+(status)
tx%
3.2
rateu = (90) -(267) + (1440) + (90) -(95)+ (29)}1
1
3.2
).5
30
(4.2)
(4.3)
rateu =56,301 bps
(4.4)
rateu = uplink bit rate
rate, = crosslink bit rate
users = number of users
msgu = the size of the User Destination Update message
msgc= the size of the GRS Status] message
status = the size of the GRS Status2 message
diff= the size of the GPS Differential Correctionsmessage
tx% = the percentage of time that the node is transmitting(50% for our scheduling scheme)
Since overhead and inefficiency will reduce uplink capacity, we set the uplink bit
rate to 60Kbps. The crosslink bit rate is then 192 Kbps. We define the crosslink
capacity as the number of users whose data can be routed through a GRS, to then be
uplinked by other GRSs. The maximum crosslink capacity is attainable when the GRS is
not uplinking any data. We calculate an upper bound on this capacity in (4.5) by setting
RTOT (2.3) equal to one half of the crosslink bit rate, because the GRS only transmits 50%
of the time due to the scheduling scheme.
192,000
users -
2
268
391
(4.5)
- 244
We now calculate the upper bound on the number of users whose data can be
transmitted into the network by the GCS. We calculate this bound in (4.6) by setting RCR
(2.1) equal to one half of the crosslink bit rate.
192,000 -239
users =
2
296
= 323
(4.6)
The upper bound on the system capacity depends the uplink capacity limit and the
bounds in (4.5) and (4.6), depending on the configuration of the grid and the distribution
of the users within the grid. If there are sufficient GRSs, on the order of 4 to 5, and the
users are evenly distributed in the grid, the uplink capacity will not limit the system
31
capacity. In this case the system capacity will be limited by the GRS or GCS crosslink
capacity. If the GCS communicates only with a single GRS, then the upper bound on the
system capacity is the upper bound on the GRS crosslink capacity. If the GCS
communicates with more than one GRS, the system capacity bound will be the GCS
crosslink capacity bound. In this case, the system capacity could be improved by
allowing the GCS to simultaneously communicate with all of its neighbors by
transmitting with different spreading codes. The upper bound on the system capacity
would then depend on the number of neighbors, and the upper bound on the GRS
crosslink capacity. Specifically, if there were n neighbors, the upper bound on system
capacity would be n times the upper bound on the GRS crosslink capacity. For the rest
of this work we assume that the GCS transmits to only one GRS at a time.
Based on our assumption that the crosslink data rate is 3.2 time the uplink data
rate and our system capacity goals, we have chosen an uplink data rate of 60 Kbps and a
crosslink data rate of 192 Kbps. We continue by designing the link and determining how
much power and bandwidth is be required to transmit at these rates.
4.2
Coding for Processing Gain
From analysis in section 2.4 and section 4.1 we see that a crosslink data rate of 3-
4 times the uplink rate will satisfy our system capacity goals. In this section we discuss
using this data rate difference to conserve power in the uplink. We also discuss why we
have chosen the crosslink to uplink data rate ratio to be specifically 3.2. Both uplink and
crosslink communications occur in the same frequency band, but assuming that both use
the same modulation scheme, the uplink will use less spectrum than the crosslink. The
32
extra spectrum used by the crosslink would be unused during uplink transmission. By
increasing the spectrum used by the uplink, we can take advantage of this unused
spectrum to reduce the power required for uplink transmissions.
Using bi-orthogonal codes is one simple way of expanding the uplink spectrum
usage. Biorthogonal codes map groups of bits into longer sequences of bits, or code
words [9]. Several bits may be sent across the link to communicate one bit of useful data.
We define an actual bit of message data to be an information bit. Using bi-orthogonal
codes, the channel bit rate is increased, but the information bit rate remains the same.
The energy per bit of information that must be seen at the receiver to obtain a given
information bit error rate is reduced. This
Data Set
reduction in required received energy is
00
0 0 0 0
= 0 1 0 1
0 0 1 1
0
referred to as coding gain. Bi-orthogonal
Orthogonal codewords
1 0
1 1
codes are very simple, reducing the need for
complicated coding and decoding logic.
L0
Data Set
Bi-Orthogonal codes are most easily
explained by first defining orthoganal codes.
Orthogonal codes function by mapping k bits
into 2k orthogonal code words. An example
1 1 oj
Biorthogonal codewords
0
0
0
0
0
1
0000
0 1 0
1
0
1
0
0 0
1
1
0 1
1
0
0
1
1
1
0
0
1
0
1
1
0
1
1
1
0
1
1
0 0
1
11
1
0
0
B=
1 1 11
0
1_
of an orthoganol codeword set is shown in
figure Figure 4. Biorthogonal codes are
Figure 4: Example of an orthogonal codeword
set for k = 2 and a biorthogonal codeword set
for k = 3.
formed from a set of orthogonal code
words and their inverses. For instance, to form a set of biorthogonal codes to represent 3
bits of data (k=3), 8 code words are needed. These code words are the 4 orthogonal code
33
words representing 2 bits of data, and their 4 inverses. This is illustrated in Figure 4. A
more detailed explanation of orthogonal codes, bi-orthogonal codes and coding in general
is provided in [9].
The bandwidth required when using biorthogonal codes is 2k/2k times the
bandwidth required without coding, for equal information bit rates [9]. Coding with k =
5, increases the bandwidth by 3.2 times over the uncoded case and gives a coding gain of
about 3.5 dB [9], reducing the uplink transmission power.
Using bi-orthogonal coding to expand the uplink spectrum usage, also simplifies
the hardware implementation. Although the uplink has an information bit rate of 60
Kbps, both the uplink and crosslink have data rates of 192 Kbps. The same receiver
hardware can be used for both uplink and crosslink communications. The only difference
is that the uplink data is coded before being transmitted.
An alternative to using bi-orthogonal coding is to use different spreading codes
for uplink and crosslink. As discussed in section 4.5 the gain from spreading codes is
equal to the bandwidth expansion, so an expansion of 3.2 yield a gain of 5dB. This is
more efficient than the 3.5dB from bi-orthogonal codes, but would require more
complicated hardware.
We consider both approaches in our work, but choose the more power efficient,
separate spreading code method in the simulation. In spite of using this alternative
approach we continue using a crosslink information rate 3.2 times the uplink information
rate.
34
4.3
Modulation
For simplicity, we only consider BPSK modulation in this work. BPSK is
commonly used and would be less difficult to implement in hardware than more complex
schemes. It is worth nothing, that there are many types of modulation that could have
been considered. There are various modulation techniques which provide more
resistance to errors due to doppler shift and others which help overcome problems
associated with multi-path. For example, OFDM, the modulation technique used by the
IEEE 802.11 standard is designed to be resistant to multipath and fading [8]. Other
modulation techniques may also be more resistant to fading caused by tress and
vegetation [14].
4.4
Link Budgets
The link budget calculations in our initial analysis showed that we were limited to
36.3 Kbps for uplink communication, but as discussed in section 4.1, we need 60Kbps to
meet our capacity goals. We can improve the uplink bit rate, by modifying the user's
receivers, the GRS's, and the layout of the system.
Through options discussed in section 4.2 we can increase the uplink bit rate by
expanding its spectrum use. As seen in section 4.2 the bandwidth expansion using
biorthogonal coding gives us a coding gain of 3.5dB, and using separate spreading codes
gives a gain of 5dB.
The -10dB gain of the user's receive antenna at 10Ghz is one of the major reasons
that the bit rate is low. If the user receiver's antenna gain, Gr. were greater, the bit rate
could be much higher. It is not clear whether this is a possible modification to the aerial
35
users's communications system. For now we assume that the antenna remains the way it
is.
The space loss can also be reduced if the maximum distance between a GRS and a
user were decreased. This could be accomplished by laying out the GRS's in a more
tightly spaced grid. For instance, if the distance between the GRSs were 17 km, the
maximum distance between a GRS and a user would be 19km.
We now recalculate the power required by rearranging the link budget equation in
Table 1, to solve for power, and adding our coding/processing gain parameter, G. A
more detailed discussion of link budget calculation is provided in [9]. As seen in Table 4,
only 2.136 Watts of power is required for GRS to user communications and only about
Link Budget
Gr
EJNO
Gc = Coding/Processing
Crosslink
Uplink
(using biorthogonal
Uplink
(using seperate
coding)
spreading codes)
3
11
0
-10
11
5
-10
11
3.5
gain
-204
-204
-204
19000
19000
17000
Ls
138.015072
138.015072
137.0489784
LO
4
4
4
3
60000
2.136281366
3
60000
1.512371387
3
192000
0.614043405
KTO
distance (m)
Margin
R = Rate (Kbps)
Pt (Watts)
(Pt= R - Gr - G+
EN + Margin + kT + L, + Lo - G)
in dB
Table 4: Link budgets for uplink and crosslink radio links.
.614 Watts are required to transmit between GRS's. Table 5 also lists the power that
would be required if we used different codes and therefore gain 5dB due to the bandwidth
expansion. The required output power is much lower than our original limit of 1OW, but
as the nodes are battery powered this additional power reduction is advantageous.
36
4.5
Processing Gain
The crosslink communications run at a data rate of 192Kbps using uncoded
BPSK. Since BPSK uses about 1Hz/bit/s spectrum usage is 192KHz [9]. The uplink
communications use the same amount of spectrum, but at a lower information bit rate.
The CDMA spreading codes transmit at a much higher rate than the data stream and
therefore use significantly more spectrum. When the code is applied to the data stream
the total spectral usage is essentially the spectrum required by the spreading code. The
processinggain is the amount of power gain that the coding scheme gives to the desired
signal, against noise and signals using other codes. The processing gain for direct
sequence spread spectrum is equal to the code rate divided by the data rate, or
equivalently the spectrum used by the spreading code divided by the spectrum required
for the data sequence [9]. For instance, if a processing gain of 20dB were needed, then
19.2Mhz of bandwidth would be required for our 192Kbps link. The amount of
processing gain required depends on the signal to interference ratios seen at nodes in the
network and by the users in the air. There are several factors that affect this ratio,
including the path loss characteristics, the grid size and the space between GRSs in the
grid. An analysis of signal to interference is carried out below using various values for
these parameters, first in the ground network and then for the air, to determine a realistic
figure for the required processing gain.
To determine how much processing gain is required, it is necessary to determine
how interference from adjacent nodes affects the Eb/N 0 at the receiver. We start with
equation (4.7) from [9] and then treat the interference as noise in equation (4.8).
37
Eb/No = required energy per bit to noise spectral density
BW = the amount of bandwidth or spectrum used
R = the bit rate
S = the signal power
N = the noise power
No
BW S
R N
Eb
BWS
Eb
I0
N
-- =
Eb
10
=EBWS
-
R I
+10
Eb
R I
(4.8)
BW S
+-
=R
Eb
R N
BW S
N
BW
S
Lb
(4.9)
S
1
R
No
N0 +10
(4.10)
I
BW S
Eb
For our system E/N >>I (about 11dB), S/I is <
E
S
b
No +10
If
G
E
=
1 andfor BPSK modulation R/BW is ].
(4.11)
1
=the E/N 0 required by the receive, the requiredprocessing gain, Gp, is:
b
S
(4.12)
(the above analysis is based on equationsfrom [9])
The ground propagation characteristics have a significant effect on signal to
interference ratio seen at the GRSs and by the users. As discussed in the literature [20],
the loss rate for radio waves propagating across the ground can be proportional to
between l/d2 and 1/d6. If the space loss for the crosslink were proportional to 1/d
4
versus
l/d2 there would be much less interference from adjacent GRSs, and the processing gain
38
and therefore spectrum usage could be reduced. However, since the path loss for the
uplink is proportional to 1/d 2 , the interference received by a user is greater than that seen
by a GRS on the ground. This is further analyzed later.
Another factor affecting the
2
S/I for 1/d
-4.5
amount of processing gain required is the
loss
-5
-5.5
number of GRS's in the grid. This
-6
-
becomes less important as the path loss
-6.5
;Z-7.5
exponent increases, but is still a factor.
-8
-8.5
We also need to determine whether the
-9
0
50
100
150
200
250
Number of nodes (square grid)
crosslink or the uplink places the
(a)
constraint on the processing gain. For
S/I for 1/d
4
loss
instance, if crosslinks only requires 15dB
-4.8
of processing gain, but the uplinks require
-4.9
m -5
20dB, then 20dB of processing gain
S~ -5.1
would be required (although the
C -5.2
-5.3
crosslinks would then require less
-5.4
-5.5
transmit power). Ideally the required
0
50
100
150
200
250
Number of nodes (square grid)
(b)
processing gain for each would be the
same so that neither portion of the system has
Figure 5: Signal to Interference
ratio at the4
2
center of a square grid for 1/d (a) and 1/d
(b) path loss.
significantly more gain than necessary.
First we analyze the spectrum required for the crosslinks, using various
parameters. The first thing that needs to be determined is the worst case signal to
interference ratio. This is done by assuming that all nodes in the slot are transmitting
39
simultaneously and that the desired receiving node is at the center of the grid. The results
will depends both on the size of the grid and the propagation model used. A matlab
function was written to calculate these values and the resulting graphs are shown in
Figure 5.
The matlab script implements the following equation:
S
I
1
d'd
n 1
1"i0d
di = distance between center of the gridand the i'h
interfering node.
dd . distance to the desired transmittingnode
n =the number of interferingnodes in the grid
1 path loss exponent
(all nodes transmit with equal power)
(4.13)
Comparing the two graphs, It can be seen that the crosslink signal to interference
for a given grid size is lower for the 1/d
4 path
loss. However, higher path loss would
require the nodes to be closer together, requiring more nodes to cover the same area.
Further study is necessary to determine exactly what the propagation characteristics of Xband (10 Ghz) is in various environments. It can be seen that although increasing the
number of nodes increases the interference, interference increases at a lower and lower
rate as the number of nodes increases.
To illustrate how to choose the processing gain, we present an analysis assuming
a maximum grid size of 15x15 GRSs. As illustrated in the graph this yields a worst case
S/I of -9.06dB for l/d 2 loss and -5.44dB for l/d 4 loss. An Eb/NO of approximately 11dB
is required to receive uncoded BPSK at a bit error rate of 10-6 . Therefore, from (4.12),
20.06dB of processing gain would be needed in the l/d 2 case and 16.44dB in the 1/d
case. This is a worst case figure because it is unlikely that all nodes would be
transmitting simultaneously.
40
4
S/ at shell (alt: 17 15x1 5 grid)
S/I at shell (alt: 17 spacing: 17)
-1
-2
'
-2
-4
-3
-6
-4
-8
-5
-10
-6
-12
-7
-14
80
50
100
150
200
250
-16 35
30
25
20
15
10
5
Distance between nodes
(b)
Number of nodes (square grid)
(a)
Figure 6: Signal to Interference ratio seen at a user for grid spacing of 17km (a) and for a
15x15 square grid (b).
Now we use the same approach to analyze the signal to interference seen by an
aerial user in flight. We calculate the interference seen at a user directly above the center
GRS in a square grid. Again using matlab scripts we create graphs (Figure 6) that show
the signal to interference for different numbers of GRSs and grid spacings.
The equation used for this analysis is as follows:
1
a2
S
di = distance between the center of the grid and
the i'h interfering node.
a
n
I
i
(s
.~
2
2
a2 + s *di
2.
n
=
altitude of user
=
spacing between the GRSs
=
number of interfering nodes in the grid
(4.14)
(all nodes transmit with equal power)
Figure 6a assumes a user altitude of 17km and a spacing of 17km between the
GRS's for a grid with various numbers of GRSs. Figure 6b assumes an altitude of 17km
and 225 GRSs in a square grid, with various distances for the spacing between GRSs.
These results will change if the altitude or grid spacing is changed. If the grid
spacing is 34km and the altitude is 17km, as in our initial example, the S/I for 225 nodes
would be only -2.14dB, compared with -7.64dB for a spacing of 17km. When terrain is
41
considered, it may be necessary to reduce the distance between the GRSs due to obstacles
and increased path loss. Figure 6b illustrates that as the grid size is reduced the
interference increases. This could be compensated for by increasing the processing gain,
but then the spectral usage would become large.
One solution to compensate for this increase in interference is to use separate
antennas for the uplink and crosslink
A
transmissions. For uplink transmissions,
19Km
an antenna with a higher gain in the
50Km
vertical direction could be used to allow
Isotropic Antennas
more closely spaced GRS's without
A
19Km
increasing the interference. This is
illustrated in Figure 7. This would allow
50Km
the same uplink signal to interference
values obtained with a spacing of 17km
Modified Antennas
Figure 7: Illustration of possible modified
antenna patterns to reduce user S/I ratio.
in a much more closely spaced grid. One
of these methods for reducing uplink interference will probably be necessary when terrain
issues are considered and when we consider the fact that the crosslink path loss may be
greater than 1/d 2 .
Another solution would be to place the GRS to GRS communications in separate
frequency bands. This would increase the spectral usage, but would allow the GRSs to
be placed arbitrarily close without increasing the interference seen by the users.
An additional factor to consider is the probability that a user will actually be
17km up in the air. The system must be designed for this, but it is a worst case which
42
may not happen often. As the altitude increases the S/I ratio will go down, but the
message could be duplicated or a lower bit rate could be used to obtain the same message
error rate.
For the rest of the work, we assume isotropic antennas and that both uplink and
crosslink communication is done in the same frequency band.
4.6
Time Slot Size
Using 192Kbps for the crosslink and 60Kbps uplink (section 4.1), the time
required to transmit 321 bits is 321/192,000 = 1672 usec. This is the time required to
transmit the data, but to ensure that a GRS does not begin transmitting before it has
finished receiving data, the time slot size must be the transmission time plus the
maximum crosslink propagation delay. As a worst case figure we choose 30km, (17km
for the maximum propagation distance plus some margin to account for synchronization
inaccuracies), as the maximum transmission distance, yielding a propagation delay of:
td
30,000
,
3-10'
8.3-10-5 s=100ps
The minimum slot size would therefore be 1772 microseconds.
The optimal size will depend on what scheme is chosen for grouping packets. As
outlined in section 3.3, an optimal slot size is a function of how messages are grouped
together into packets. The first option is to set the time slot size to the minimum required
to transmit a User Destination Update message. As stated in section 3.3, using this
scheme, 2.67 slots would be required to transmit the update to the user. Since we are not
doing any grouping of messages, the 95 bit messages are transmitted as single packets.
43
With the routing data included, their total size will be 115 bits. This would require
115/320=.359 time slots to transmit one packet.
From these initial calculations there is one obvious improvement. The slot size
could be set so that in 3 time slots, 1 User Destination Update message and 1 GRS
Status 1 message can be transmitted. This helps because any time that GRS User Update
message is received, a User Update Message and a GRS Status 1 message are transmitted.
Therefore, this ordering will occur with out any extra work. If both message can be
transmitted in 3 time slots rather than four, the efficiency will be increased.
This new slot size is calculated as follows:
267
=
60,000
115
3
192,000
1683k
Adding the 100 microseconds per slot, that we use to account for propagation
delay yields a time slot size of:
ts = 1,783ps
This last scheme is that which is used in the rest of this design and in the
simulation.
44
5
Routing
Routing in this system is an interesting problem. Because the GCS is the central
controlling node and has knowledge of the status of traffic in the network, it can make
many routing decisions. This makes source routing attractive. On the other hand only
each node will immediately know the actual status of a link (whether it exists and how
good it is). It is often not desirable to put the complete route in the packet header as this
can become large if there were many hops.
One possible distributed method would be to route based on location. Since the
grid is regular, a location field could be placed in the header of the packet and each node
would simply forward the packet on in the correct direction. One method is to send the
packet in the direction in which the greatest distance remains. We will refer to this as the
deterministicpath approach. A 16-bit field in the header would support a grid as large as
256 by 256 GRS's.
One drawback of the deterministic path approach might be congestion. Because
the route to a particular GRS would be constant, the nodes along the route could become
congested and other adjacent GRSs may not be used. One option to alleviate this
congestion is to vary the path randomly. We refer to this as the random path approach.
The following example illustrates the concept. A GRS has a packet that is destined for
the node at location (5,2) and it's location is (1,1). Using the deterministic path
approach, it would transmit the packet to the GRS at (2,1), (3,1), (4,1), (5,1) and finally
(5,2). Now, to vary the path, the GRS could use a probability function to choose between
transmitting to (2,1) and (1,2). The probabilities could simply each be
would yield a shortest path, and this would create greater path diversity.
45
if both paths
-~
~.r
--
~
--
We
compare the
deterministic and
(6)
33%
(7)
(6
(7,8)
(6
ld 33%
17% (6,7)
(6)
(6,7,8)
(6,7)
(6)
(6,7)
100%
random path
(6,7,8)
approaches with an
100%
17%
-66%
(6
8%
(6,7)
42%
(6)
(6,7)
(6,7,8)
100%
33%
example. The
example consists
(a)
(b)
Figure 8: Routing example using deterministic (a) and probabilistic (b)
distributed algorithms.
of one GCS and 8
GRSs. It is illustrated in Figure 8. The example assumes that the GCS is sending out
enough traffic to use all of a GRS's transmission slots. Nodes 6, 7 and 8 are the
recipients of this traffic and they all receive it in equal amounts. This example considers
only the traffic transmitted from the GCS to the GRSs. The numbers in parenthesis
indicate the destination GRSs of the traffic flowing over a given link, and the percentages
indicate what percentage of a node's transmission time is being used for routing traffic.
Figure 8a uses the deterministic routing approach so a message at 5, destined for 6 would
be routed to node 4. If both the horizontal and vertical distances are equal, the message is
routed vertically. Figure 8b uses the random path approach. If there are two options
which will give a shortest path, the routing algorithm will randomly choose between the
two using probability of 1/2 for each choice. As illustrated in the figure, the traffic is
much more evenly distributed in the second example. There would still be room to
improve, and more optimally choose the path by using source routing, but this algorithm
is a good compromise because only the location of the destination GRS, rather than the
46
whole route, is stored in the header. It offers greater path diversity while still using a
distributed, shortest path scheme.
Another option is to base these probabilities on a congestion measurement
received from the neighbors. This may increase the routing overhead, but may yield
better congestion control. This could also aid in dealing with lost links. If a link goes
down the probability of transmitting over that link would simply be set to 0.
There is very minimal routing required in uplinking to a user, when terrain is not
considered. When a packet reaches its destination the GRS simply transmits it up to the
user. When terrain is considered, the GRS that is physically closest to the user may not
be able to communicate with it. One option is for the user message to propagate out to a
number of GRSs surrounding the actual destination. Those GRSs could all transmit to
the user, providing added redundancy and reducing the probability of a missed message.
A factor in transmission to the aerial users is the user altitude. The system must
be able to support users as high as 17km, but the majority of the time, they will probably
not be that high. Power can be conserved by only transmitting with enough power to
reach the user. This could be accomplished by including an approximate user altitude
field in the GRS Destination Update message, and using this value to set the GRS's
uplink transmission power.
The actual design and simulation implementation do not include the broadcast
option and do not consider the altitude of a user in deciding the power levels. The
simulation uses the deterministic routing approach outlined above, and illustrated in
figure 8a.
47
For this design a distributed routing algorithm has been chosen, but it is worth
mentioning and contrasting source routing with our chosen design. Source routing
definitely has its advantages. Since the GCS knows what users are where and what
communication is required, it can very accurately determine how congested particular
links are. The GCS could efficiently distribute the traffic across all available links in the
network. This is not possible in our distributed routing scheme because an individual
GRS does not have detailed information about the congestion in other parts of the
network.
One of the disadvantages of such a scheme is that it requires the GCS to know
which links are enabled and whether a particular GRS has failed. The route is determined
before the packet leaves whereas the more distributed method simply finds a path through
the network based on available links. This reduces the overhead traffic needed to keep
the GCS updated. Another disadvantage of source routing is that as the network size
increases, the route sizes will increase, increasing the message header size. If the routes
become too large this becomes inefficient. Source routing is attractive for reducing
congestion and would be worth considering in future work, especially given that the GCS
has detailed knowledge of the network activity.
5.1
Transmission Priority
In addition to deciding the route for each message, the GRS also may have to
decide based on some type of priority scheme when and in what order messages should
be transmitted. For instance, to improve timeliness of destination update information a
packet that has to make 100 hops through the network probably should be placed in the
beginning of the queue, ahead of messages that may only need to make 5 hops before
48
reaching their destination. There must also be a method of deciding how to allocate the
available transmission time between data destined for other GRS's and data to be
forwarded to users.
The problem of deciding which messages should be forwarded first could be
difficult and there could be many possible solutions with varying degrees of complexity.
The first issue is ensuring that messages that must travel a long distance are forwarded
promptly, and the second issue is ensuring that messages with lower priorities don't sit in
queues indefinitely. One method is to place a priority field in the outgoing messages of
the GCS. This priority, along with a measure of how long a message had been in a
GRS's queue would be used to determine the order in which the messages are
transmitted. As a message spends more time in a GRS queue, the GRS will try harder to
place it ahead of incoming traffic. One problem with this method is that it does not
capture any knowledge of how much time a message has spent in the queues of previous
GRSs on the route.
One way of overcoming this and still keeping the message header size small
would be to modify the priority set by the GCS, as the packet progresses through its path.
As a packet spends more time in a GRS's queue its priority field is increased. The time
that it has spent waiting can then be considered in making priority decisions later in the
route. This seems like a reasonable approach, but the current 4 bits that have been
allocated for message priority may be insufficient. 8 bits might be a more realistic size.
Another issue is how to decide between transmitting uplink data and transmitting
crosslink data. A simple approach would be to use separate queues for uplink and
crosslink data, and to transmit from whichever queue contains the most messages. One
49
problem here is that it takes a long time to transmit uplink messages. If there is crosslink
data waiting in the queue and a packet containing three User Destination Update
messages is uplinked, the GRS will have to wait 8 transmission slots or a total of 16 time
slots before transmitting the crosslink data. If this happened at many of the nodes during
a message's path to its destination, the latency could very quickly become unacceptable.
The priority field could also be used for this decision. If an uplink message has a high
priority (because it is very important, or has spent a lot of time reaching its destination, or
both) it will be transmitted before crosslink messages. If a crosslink message has a
higher priority, it will be transmitted first.
These priority schemes are optimizations that could improve the performance,
especially in high loads or networks with many nodes, but they will not be considered in
the initial design. The simulation will therefore not use the priority field in routing. The
only priority decisions that are made in the current design are whether to send uplink or
crosslink data based on the relative sizes of the respective queues. Data is taken first
from the queue with the most messages.
50
6
6.1
Additional Topics
Network Setup
The methods that have been chosen for scheduling and routing require the GCS
and the GRSs to know certain information such as their assigned time slot and the
topology of the network. This information will need to be obtained, during a setup and
initialization stage, before the network can operate properly. This is done manually in
the simulation and analysis to follow, but in a real world implementation this will need to
be handled automatically.
There are various methods of accomplishing this, but here we outline one possible
implementation. The first problem is scheduling. Our scheduling scheme cannot
function if the nodes have not been assigned their proper time slots. One way to
accomplish this is to simply use an Aloha type medium access protocol at system startup.
This is inefficient, but that isn't really important at this stage. Using this type of basic
mode of operation the GCS can query all accessible GRSs for their positions. Once it has
built a map of the network it can assign each node its time slot and integer coordinate
within the grid. Once this information has been correctly set, a message can be broadcast
instructing all nodes to change to the normal mode of operation and the network will
function as described in the rest of this document.
6.2
Propagation
The current design, analysis and simulation has been done assuming a path loss
proportional to 1/d 2 . If the GRSs are resting on the ground the conditions will probably
51
not be this good. The loss may be proportional to something closer to l/d 4 [20].
Although this design has been done assuming l/d 2 loss, we discuss the effects that 1/d
4
loss would have on the system, and we suggest some solutions.
This higher path loss rate will greatly reduce the maximum distance between
GRSs. With simply isotropic antennas the maximum range is only a few hundred meters,
with other parameters being the same as our current design. Using multiple antenna
beams for both the receiver and transmitters, each with a gain of around 20dB, crosslink
transmissions of over a kilometer may be achieved. As was discussed in the section on
processing gain, the signal to interference ratio seen by the users increases as the density
of the GRS grid increases. Two solutions, using directional antennas or separate
frequency bands for GRS to user and inter-GRS communications, were suggested. Using
multiple antenna beams may eliminate the need to use either of these solution, although
using multiple antenna beams is similar to the first solution. If multiple antenna beams
were used, then the interference seen by users from crosslink communication would be
low because very little power would be radiated up into the air.
If 1km spacing were achievable it would still require a very large number of
GRSs. The 50km x 150km grid that was used for the analysis and simulation would
require a grid of GRSs covering a 34km x 120km area. This would require over 4000
GRSs if the area were to be completely covered. This could be greatly reduced by
removing GRSs and thinning out the grid to provide communications to certain GRS
which are needed for providing user communication. If the GRSs from our original grid
were used for user communication, and rather than filling in the whole grid with a 1km
spacing, GRSs were simply added along the links between these existing GRSs, links
52
could be established to all neighbors using a total of 592 + 23 GRSs. This is because 16
GRS would be required to provide communications between 2 GRSs 17km apart and in
our 8x3 grid there are 37 links between GRS. This number is still very high, but may be
acceptable. This would greatly increase the number of hops required for a message to
reach its destination, but the existing design uses very small transmission time slots to
minimize the delay due to multi-hop, possibly allowing the latency to stay within
acceptable limits. The latency due to 5 hops in our current system is l8ms. If there were
GRSs every 1km we would have 17 times the number of hops yielding a latency of
308ms which may still be acceptable. The actual acceptable latency values will be
dependent on the specific requirements of the user guidance hardware.
Another solution to the 1/d
4
crosslink propagation, is to use a system that does not
have to transmit across the ground. There are many possibilities. UAV's could be used
in place of GRS to provide communications. The GRS could simply send out the
differential corrections and a network of UAV's in the air could provide communications
to the users. This would give us line of site communications with 1/d
2
propagation loss.
Maintaining the UAV's is certainly more difficult than simple ground stations, but the
number of units required would be greatly reduced because of the much more efficient
communications.
53
7
Analysis
Now that the various elements of the system have been discussed, we analyze the
performance of an example system. We assume l/d 2 loss for the crosslink
communications. The system consists of 24 nodes (23 GRS's and 1 GCS) arranged in an
8 x 3 grid. The spacing between nodes is 17km, covering an area in excess of 150 x 50
km. Using the matlab scripts that implement (4.13) and (4.14), the signal to interference
figures for crosslink and uplink are -6.2dB and -3.2dB respectively, assuming all nodes
are transmitting during their transmission slots. From (4.12) the processing gain
required, Gp, is:
Gp= 11dB + 6.2dB = 17.2dB
This figure, multiplied by the 192Khz required for BPSK modulation of a
192Kbps link yields a spectrum usage of about 10Mhz.
Since all nodes within a time slot could be transmitting simultaneously, the
system capacity is simply limited by the bit rates of the links. Based on the estimates of
packet sizes calculated above, we now estimate the capacity of the system. Using
equation 4.1, the maximum uplink capacity is calculated as follows:
115
192,000
267
60,000
(29+20)
192,000
1440
60,000
1
2
n = the number of users
The left half of the equation is the sum of the number of seconds needed to transmit each
type of data which equals 1/2. (because transmission only occurs half of the time)
=
n = 94 users
54
This assumes perfect efficiency, but our current design will be somewhat less than
this. For now, the 29 bit GRS Status2 messages will be ignored and we will focus only
on the user updates, return messages and differential corrections. As discussed in section
4.6, 3 time slots are required to transmit one GRS Destination Update message and one
GRS Status 1 message, and 15 slots are required to transmit a GPS Differential
Corrections. If the time slot size is 1784 microseconds, as calculated in section 4.6, there
will be 560 time slots per second, half of which are transmission slots. Subtracting the
slots used by differential corrections leaves 265 slots for update and status data. The total
number of users is therefore:
265
n = -- ~ 88 users
3
Now we calculate the network traffic by adding the routing data to (2.1), (2.2) and
(2.3). In (7.4) we calculate the new upper bound on the crosslink capacity of a GRS.
RCR
=
320n + (124+20) + (115+20) bps
(7.1)
(7.2)
RRC = (29+20) + 115n bps
Total traffic between GRS and GCS:
RTOT= 3 2 8
users-
+ 4 3 5 n bps
(7.3)
192,000 /2 - 328
= 220
435
(7.4)
The capacity in (7.4) assumes perfectly efficient use of the availabe transmission
time. If efficient methods are used to pack the data into time slots this number will
55
remain virtually unchanged, but without these methods, the crosslink capacity will
decrease.
Our current
implementation simply
transmits packets as they are
received. A worst case
figure for this
g
implementation can be
obtained by assuming that
o
each message requires a full
Uplink Loa
time slot even if it is only a
115 bit return message. If the
. .. ...
.
ue rs)
Figure 9: Capacity limit as a function of the amount of user
and routing data.
time slot size is 1784 microseconds, there will be 560 time slots per second. 280 of these
are transmission slots and 15 of these are used for differential corrections. This leaves
265 slots available for data. Since there is one outgoing and 1 return message per user,
the upper bound on the GRS crosslink capacity is 133 users.
These upper bounds on the uplink and crosslink capacities assume that the GRS is
either transmitting only crosslink or only uplink data. In the real system the GRSs will be
transmitting both uplink and crosslink data and the limit at which a GRSs capacity will be
reached is a function of both. Figure 9 shows where the capacity limit occurs, assuming
1 message per time slot. It shows the uplink capacity limit as a function of the crosslink
load in number of users.
56
The GCS only transmits GRS Destination Update messages so its capacity is
higher. The GCS can transmit data into the network to handle a certain maximum
number of users, calculated as follows:
users
-
192,000 /2
= 300
320
We now estimate the expected error rates in sending a message from GCS to user.
BPSK modulation, at our chosen power levels, should gives a bit error rate of 10-6, or 1
bit error every 106 bits of data. Considering only the 320 bit User Destination Update
messages, there would be on bad packet for every 106/320= 3125 sent. The probability of
successful transmission is (1-1/3125). This number is only for a single transmission and
will go down as multiple hops are made. For instance, 5 hops would yield a probability
of successful packet reception of (1-1/3125)5=.9984 which translates to 1 bad packet per
625 packets sent. This is the probability of correct reception at the destination GRS. The
packet error rate for uplink of a User Destination Update message transmission will be 1
per 10 6/267=3745. Considering both the crosslink and uplink transmissions, the
probability of correct reception at the user is (1-1/3125)'(1-1/3745)=.9981, corresponding
to 1 bad packet per 536 sent. This error rate seems high, but for now we continue the
analysis in this manner. Performance will probably improve in the simulation results
because the assumption that all nodes are always transmitting is a worst case assumption.
This will probably not occur, causing less interference in the network and decreasing the
message error rate. The interference analysis was done assuming equal power output for
uplink and crosslink transmissions so another likely improvement is due to the fact, that
although the crosslinks only need to transmit at .6W, they will probably transmit with
57
same power as the uplink. This will result in a higher signal to noise ratio and lower
error rate for crosslink communications.
The latency in the system will be dependent primarily on the time slot size and the
number of hops required until the traffic levels begin to increase. As the traffic increases
the latency will begin to be affected by queuing delays. If the time slot size is 1800
microseconds then the delay to make 4 hops and then transmit up to the user would be
about 5*3.6ms =18ms.
The service time, or time required for a GRS to re-send a received message, for a
message is essentially constant in this system. The once per second differential
correction and user messages take several slots to transmit, but all other messages will be
sent out in only one time slot. The service time is therefore essentially constant. The
arrival rate is also essentially constant for a certain number of users being serviced. The
updates simply occur once per second per user. Since the arrival rate and the service time
are constant and deterministic the queue will only grow if messages are arriving faster
than they can be sent. If not, the queue size will be essentially zero in steady state. We
can easily calculate this limit and if we can stay below it, the message latency will be
dependent almost entirely on the time slot size and the number of hops taken.
We now analyze two specific scenarios, to gain an idea of the actual performance
characteristics of the system. The first scenario consists of many users leaving from one
location. This scenario is illustrated in Figure 10. In this scenario, all users begin flight
and begin communications at the same time. This is an unlikely scenario, but it is an
easy way to test the expected performance of the system with one heavily loaded GRS,
and to test the GRS uplink capacity. This scenario will consist of 80 users all leaving
58
from one point and reaching their destinations, which are all contained within a second
GRS's coverage area. As calculated above, the absolute limit should be about 88 users so
this scenario should function without problems. The minimum latency will be 1 Sms and
will occur when a message is immediately transmitted at each node that it is routed
through. The maximum latency will occur when a message is en route to its destination
during a differential correction broadcast. A differential correction broadcast takes 15
time slots or about 54ms. The maximum latency should be the sum of this value and
latency due to the multihop. This sum is about 72ms.
The second scenario will consist of users leaving from several different locations
across the grid. In this scenario there is a total of 240 users, but they are distributed
across the network. The scenario is illustrated below in Figure 13. The users leave
according to a poisson process. In this example, the inter-arrival rate is 1 user per
second. With this inter-arrival rate and the user flight times varying between about one
and a half and two and a half minutes, the maximum number of users in the system at a
given time is about 120. The system maintains a steady state user count of between 100
and 120 for about a minute and a half until the last user begins flight. This scenario
allows us to do a more realistic performance analysis and later simulation.
The GCS can send data for up to 300 users at a time, so there should be no
bottleneck leaving the GRS. It appears that the largest bottleneck will occur at the nodes
immediately ahead of the GCS: Nodes 11, 12, 13 and 14 in the figure above. These
nodes have to uplink data to users, but they also have to route data to several GRSs that
are farther out in the network. An estimate of the loading of each GRS is made by
assuming that the 120 active users are evenly divided between the 12 GRSs that are
59
servicing the users. This means that
each GRS is sending data to 10 users
in addition to whatever routing it may
be doing. Using the deterministic
routing scheme that is implemented in
the simulation, we can calculate the
crosslink traffic and determine the
utilization of each node. The results of
this analysis are listed in Table 5. The
first column lists the percentage of the
Actual TX
Node
Tx Slot
GRS 3
Utilization 19% Utilization9%
GRS 5
34%
19%
GRS 6
GRS 10
GRS 11
GRS 12
GRS 14
4%
15%
30%
42%
30%
4%
13%
23%
39%
23%
11%
11%
GRS 15
GRS 18
11%
11%
GRS 19
15%
15%
19%
19%
GRS 20
GRS 21
15%
15%
16%
19%
GRS 22
GRS 23
11%
11%
45%
45%
GCS
Table 5: Estimated transmitter utilization
percentages. (unlisted nodes are unused and have
5% utilization due to differential corrections)
time slots used and the second column
estimates the actual percentage of transmission time spent transmitting. The estimate in
the second column considers the fact that when a smaller return message is transmitted in
a time slot, transmission is only occurring for about 1/3 of the total time slot period. This
analysis shows that this scenario should be well within the capabilities of the system.
The capacity should begin to be reached when there are about twice as many users in the
system.
60
8
Simulation
The simulations serve two purposes. First, they verifies that the design as
proposed could function. It verifies that the capacities proposed are possible, given the
latency requirements, and that the proposed error rates can be met. It serves to back up
the estimated results from the above section. Second, it can be used to optimize the
design. Many worst case assumptions were used in designing the system. Real world
use may cause less interference than was used in previous calculations and may allow
reduction of spectrum usage and/or power while still meeting the desired performance
and capacity.
The simulation is done using OpNet and Matlab. Matlab scripts are used to
generate the user trajectories that are then used by OpNet during the actual simulation
run. The Matlab scripts generate the trajectories by first generating random destinations
within a user defined rectangular area. A user supplied list of take-off site locations is
then used to create a flight path from the nearest site to the destination. The flight paths
were created according the specifications of a potential draper internal application for this
system. The trajectories are then read by OpNet when the simulation is started.
The simulation uses the same basic scenario that was outlined in the section 7, an
8 x 3 grid of GRSs. Several different types of statistics including latency and transmitter
utilization are recorded during simulation. Simulations were done with various
parameters to verify the results of the above analysis and to discover further
optimizations.
61
-
8.1
-,
ir
-'----~
High Uplink Load
Figure 10: Network view of scenario in which 80 users are all serviced by one GRS.
The first simulation contains
o
.......
,.'".
...
.----.
...
80 users all departing from one
location and travelling across two
.............................
.
..........
GRSs. All users leave at the same.........
time. Although this is not realistic
(a)
behavior, it is an easy way to
determine the performance when a
certain number of users are being
serviced simultaneously. This is
what we are concerned with in this
simulation. We want to determine
performance and verify
A
..
...
(b)
Figure 11: Packet latency versus time for total
simulation time (a) and an 8 second view of the same
data (b).
functionality near the capacity limit of a single GRS. Figure 10 shows the network level
OpNet view of this scenario. The lines near nodes 15 and 23 are the user flight paths.
62
Figure 11 is a graph of the packet latency versus time. This is a wide view of the
results as the time axis includes the whole simulation time of over two and a half
minutes. This graph shows us that the latency is almost constantly varying between
about .018 seconds and about .07 seconds between simulation time 0 and a simulation
time of about 60 seconds and then slightly increases after 60 seconds. As discussed in
the analysis section above, the .018 second latency occurs when a message is routed
directly to the destination and then increases to about .07 seconds when a message has to
wait in a GRS queue for differential corrections to be transmitted. This is further
illustrated in Figure 11b. The slight increase at about 60s occurs when the users
transition from node 15's cell into node 22's cell. There is a slight increase in latency due
to the additional hop.
Finally, the thinning of data near the end of the simulation time is
due to the fact that the users have different flight times and as the simulation nears its end
there are fewer users in the air. There are therefore fewer data points per time on the
graph.
In the simulation, the GRS sends out 9,469 packets and the same number are
successfully received by the users. There were therefore no bit errors over the simulation
time. This high reliability is probably due to the fact that there is almost no activity in
other parts of the network and therefore very little interference.
8.2
Uplink Capacity Limit
To further test the limit of the single GRS capacity several 10-second simulation
runs of the scenario in section 8.1, were made using different numbers of users. At the
end of each simulation the number of messages in the GRS queue of node 15 was
63
recorded. Figure 12 is a graph of
'
IBM
.0.
this data. When there are 80-88
...
users in the system the final queue
R
size is 1, but when there are 89
.
users the queue size ends at 6.
.
With 90 users the queue size is 15
and with 95 users there are over
Figure 12: Final queue size after 10 seconds versus
number of users. Shows single GRS capacity limit of 88
users.
60 messages in the queue. This
data seems to support our
prediction that the queue size would stay relatively constant, near zero until the capacity
is reached, at which point it will begin to grow. The capacity limit of 88 is exactly what
was predicted in the analysis section.
8.3
Medium System Load
......
.
.. . .
....
...............
........
...
......'
Figure 13: Network level view of simulation with 240 users.
This scenario is to test various parameters when the system is more evenly loaded.
The matlab scripts were used to generate 240 destinations and trajectories uniformly
64
distributed in a rectangular area serviced by 6 GRSs. The user departures occur
according to a Poisson process with an arrival rate of one per second. As was described
in the analysis section, this yields a maximum simultaneously active user count of about
120. This network level view, including the trajectories, is shown in.
The simulation run has a
total of 240 users departing
according to an exponential interarrival rate. This is the same
scenario that was used in section 7
section. The analysis estimated that
(a)
this load would be within the
systems capabilities and that the
. ...
latency would therefore be
acceptable. The latency graph in
an
figure 14 supports this analysis.
The results are similar to the 80
(b)
4i
v
si
I
Figure 14: Packet latency (a) and moving average of
packet latency with a 1 second window size.
user case. The latency varies
between a minimum of about .01s and a maximum of about .08 seconds. Figure 14b
shows that the average is about .18 and that there are only occasional messages with a
higher latency due to GPS Differential Corrections messages being sent. The more
detailed view of the latency spikes due to differential corrections is not shown here, but is
identical to the graph shown above for the 80 user simulation. This is the same affect
seen in the analysis for 80 users. It is obvious from this data that the latency is relatively
65
constant, that the queues are not filling up and that the system is still operating within its
capacity.
OpNet includes a utilization statistic for each transmitter and receiver module.
These statistics have been captured and can be compared to the predicted load for each
grs that was calculated in the analysis section. The actual simulation implementation has
a separate transmitter module for transmitting to users and transmitting to other GRS.
For our current design these modules differ only be their bit rate and cannot both transmit
simultaneously. Therefore the total transmitter utilization for a GRS will simply be the
sum of the utilization statistics for each of the two modules. The actual utilization
statistic that is captured is
Node
also 1/2 of the actual
GRS3
GRS5
GRS6
GRS10
GRS11
GRS12
GRS13
GRS14
GRS15
GRS18
GRS19
GRS20
GRS21
GRS 22
GRS 23
GCS
value because the
transmitter is only
allowed to transmit 1/2 of
the time. The numbers in
the table have already
been doubled to
GRS Tx
Utilization
3%
16%
3%
2%
12%
30%
18%
8%
1%
1%
4%
12%
7%
6%
1%
43%
User TX
Utilization
5%
5%
5%
14%
22%
16%
20%
20%
14%
14%
22%
16%
27%
19%
13%
N/A
Total TX
Utilization
8%
21%
8%
16%
34%
46%
38%
28%
15%
15%
26%
28%
34%
25%
14%
43%
Predicted
Utilization
9%
19%
4%
13%
23%
39%
29%
23%
11%
11%
15%
19%
15%
16%
11%
45%
compensate for this.
Table 6: Simulated transmitter utilization for active used GRSs.
8.4
High System Load
To further test the capacity of the system a simulation, which contains 480 users
has been setup and run. In other respects, the simulation is identical to the 240 users
simulation except that it has more users and the user departure rate is 2 rather than 1.
66
With this arrival rate, the maximum number of simultaneously active users is 228.
During the busiest portion of the simulation there is a two minute period in which there
are at least 200 simultaneously active users.
Figure 15 is a graph of
the latency over the entire
simulation time. The results
are similar to the 240 user case,,
but it is obvious that the system
.
.
.
is nearing capacity. Up until
..
about 1 minute the maximum
latency appears to be about 73
Figure 15: Global latency for simulation of 480 users.
ms, but then it starts to increase.
Most packets still have a latency below 100ms and a few are as high as 150ms. The
worst latencies appear to be between about 2 and 4 minutes. This makes sense as it is the
period with the largest concentration of users. By about five minutes the latency has
become lower and does not again exceed 73ms. These latency figures should still allow
acceptable performance, but it does appear that the system may be nearing its capacity.
67
The utilization statistics
Node
Total TX
GRS Tx
User TX
Utilization
Utilization
Utilization
5%
11.5%
captured from OpNet, listed in
GRS 3
6.5%
GRS 5
GRS 6
34%
8%
5%
5%
39%
13%
table 8, seem to indicate that
GRS 10
4%
22%
26%
GRS 11
21%
27%
48%
GRS 12
49%
30%
79%
GRS 13
36%
18%
54%
GRS 14
22%
30%
52%
GRS 15
3%
27%
30%
The statistics could be a bit
GRS 18
2%
23%
25%
deceiving though because they
GRS 21
8%
26%
34%
GRS 22
12%
32%
44%
GRS 23
3%
28%
31%
most nodes are still not that
close to reaching their capacity.
record the actual percentage of
9%
GRS 19
37%
76%
76%
GCS
time spent transmitting.
28%
Table 7: Transmitter utilizations for a 480 user simulation .
Therefore if a time slot is half
only half used but another packet can not fit it, the statistic will record that slot as only
being 50% utilized. Based on the latency figures above and the utilization statistics it
appears that for the current implementation, the capacity is being neared, but that the
capacity could be increased by
more efficiently packing
messages into the time slots.
.
We now conduct an
analysis of the error rate for
messages being sent from the
GCS to a user in flight. In the
...
analysis section we estimated
that a packet making 5 hops
Figure 16: Number of messages lost as a function of Khz Af
before being uplinked to a user
spectrum used
68
would have a probability of error of
Bandwidth
Messages
Message
1/536 if the bit error rate of the
(1,K0
links was 10-6 Our simulation
05000
2500
Lost
41
2579
4s2Rate
1/1268
1/20
results are actually better than this.
1000
500
17862
28256
1/3
1/2
Table 8: Number of lost messages for different
Probably due to the over-designed
amounts of spectral usage. The total number of
messages sent was 51,989.
processing gain. Figure 16 shows the
number of messages lost for several different runs of the 480 user simulation. The
simulations runs use different amounts of spectrum and therefore different amounts of
processing gain. The total number of messages sent out by the GCS is 51,989. We can
conclude from these results that we can reduce the spectrum used by our system and still
have an acceptable error rate. The exact error rate required will depend on the specific
application, but it can simply be changed by increasing or decreasing the processing gain.
69
9
Conclusion
An analysis of many different components of this wireless communications
system including, routing, scheduling and the radio links has been done. We identified
specific designs which seemed reasonable for this particular application. We chose these
designs so that the system can reliably supply an adequate number of users with the
proper data to guide themselves to their destinations. The communication system
protocols have been designed to ensure that the data arrives in a timely fashion, and that
the transmission power levels are kept to a minimum. Terrain issues, radio propagation
issues and other routing schemes, which have not been specifically incorporated into this
design, have also been discussed during this process.
A final system was designed was
then analyzed and its performance was estimated. This performance was then further
explored using OpNet and Matlab simulations. The OpNet simulation essentially is a
software implementation of the system. Each node is defined to act as it would if it were
an actual piece of hardware. These nodes are then arranged in what could be a real world
deployment and the OpNet environment simulates all of the communications between the
nodes to predict the system's behavior.
The final system satisfies the performance goals of a preliminary system design,
discussed in the introduction. About 88 users can be serviced by a single GRS and in
excess of 200 users can be serviced by the whole network. This corresponds to a user
departure rate of about 2 departures per second. Even with a load of over 200
simultaneous users the latency from the time a message is transmitted from the GRS until
it is received by a user has a peak of just over 100ms and an average of about 30 ms. The
transmission power levels required are about 2.1 watts, significantly lower than the 10
70
watts that had originally been set as our upper limit. The 10Mhz of bandwidth occupied
by the design is large, but may be acceptable at the intended center frequency of 10GHz.
The proposed design achieves acceptable performance under the assumed ideal
RF propagation characteristics. Additional work is required to mitigate the higher
propagation losses commonly experienced by near ground communications links. This
issue was briefly examined in the section 6.2, but more work in this area is required.
First, a more detailed analysis of the propagation characteristics of X-band (10 Ghz) radio
waves across the ground would help determine how close the GRSs actually need to be.
This may be accomplished using existing research, but it may be necessary to conduct
field tests to obtain accurate models for our specific application. The affects of trees,
foliage and terrain should also be incorporated into the propagation models, as discussed
in Appendix B. Development of improved antenna designs is a key to making a ground
network of this type work. If multi-beam antenna's with sufficient gain can be designed,
this ground network model may be feasible even in an environment with much higher
path loss and channel fading.
71
10 Appendix 1 - OpNet
10.1 Network Level
Figure 17: OpNet screen capture of the network level view of the 240 user simulation.
10.1.1 Overview
The network level is the highest level in the simulation and contains the nodes of
the network and their locations. The simulation that I chose to create consists of 23
GRSs and one GCS arranged in an 8 x 3 grid. The GRSs are named based on a node
number and the time slot in which they transmit. For instance node_1_0 is GCS number
1 and it transmits during time slot 0. The simulation uses the node numbers only for
printing information messages and the time slot value is actually set as a node option, its
inclusion in the name is simply as a reference aid.
72
The users are the nodes arranged at the bottom of the screen. OpNet does not
allow nodes to be created during the running of the simulation, so the maximum number
of nodes that will be required during simulation is created beforehand. Each user node
has a trajectory associated with it. The dark black lines represent these trajectories. The
positions of the nodes during the running of the simulation are dependent on these
trajectories and not on their placement at the bottom of the network view window. These
trajectories are generated externally by Matlab scripts. The files conform to a format
specified by OpNet. Once the trajectory file parameters of the user nodes have been set,
these files can be regenerate by the Matlab scripts to run the simulation using different
trajectory data.
10.1.2 Options
There are several simulation options that can be set from this level of the
simulation. The first type of options are simulation wide variables which can be set to
change the behavior of the simulation. These may be used to control the length of the
simulation or to change system wide parameters. It may be desirable to change these
parameters to determine how they affect the performance of the system.
max-packets
This option sets the maximum number of packets which will be transmitted by
the GCS. This can be used to regulate the length of the simulation.
Time Slot Size
This option is used to change the length of the transmission time slot. The
parameter is an integer and specifies the length of the transmission slot in microseconds.
73
slots affect efficiency
This parameter can be varied to determine how different sized time
and latency.
but are
The second types of options are those which affect individual nodes,
affect all nodes of a
promoted up to this level of the simulation. There are options that
only each individual
certain type, which will be discussed later, but these options affect
simulation is created.
copy of a node. These options generally need to be set up when the
and what spreading
They specify options such as which time slot a node transmits in
codes are used by transmitter and receiver channels.
receive
The spreading code options control which node a receiver channel will
data from. The GCS has
three receiver channels and
Receiving
Transmitting
1
3
each GRS has four. The
number of the receiver
2
2
channel corresponds to the
direction from which it
receives (north, south, east,
west). For instance, if
1
3
(a)
(b)
Figure 18: Rule for determining the next node of a message. The
numbers in (a) indicate the number that must be placed in the
node 20 is located to the
packet header to transmit in the direction specified. The
north of node 12 and
specified direction is received.
numbers in (b) indicate on which receiver channel data from the
receiver channel 1 receives
using the
data from the north, then receiver channel 1 will receive communications
set up correctly
spreading code associated with node 20. These parameters all need to be
is
for the simulation to function. The correct method for setting up these parameters
74
shown in Figure ?. The transmitting diagram illustrates the what number needs to be
placed in the packet header to transmit in a particular direction. For instance, the router
would place a 2 in the packet header to transmit to the node to its right. The receiving
diagram illustrates what channels are used for receiving from what directions. This is
what is used to set up the spreading codes. Since packets coming in from the left should
be received on channel 2, the spreading code for channel 2 must correspond to the
transmit spreading code of the node to the left. The same method is used to set the other
2 channels. In a real world system this would be automatically done during the network
setup and initialization phase rather than being user inputs.
The transmitter power levels of both the GRS and the GCS can be set at this level
to allow the simulation, as it may be desirable to run the simulation with different values
of these parameters.
10.2 GCS
GCS rcv
gen
GCS-router
rr_0
a_1
rt_0
a-0
GCSMAC
Figure 19: OpNet screen capture of the GCS node model
75
10.2.1 Overview
The GCS is responsible for sending out all correction data to the users. It is the
central control unit and therefore knows how many GRS there are and what their
locations are. In the simulation environment this is simply accomplished by various
function calls to query information about the other nodes in the network. Since there is
only one GCS it is also used for storing global information about the simulation, such as
how many packets have been sent into the network and how many have been successfully
received by users.
The diagram above is a screen capture of the node description of the GCS. Then
gen object is what generates the packets to be sent out to the users. The rate at which it
generates packets is modified when users begin or finish their flight.
The GCSrouterobject takes the packet in from the generator and fills in the
packets routing information to send it to the correct GRS. The GCS knows the
trajectories of the users and therefore routes the packet to the GRS that is currently
nearest to the user. It keeps track of how many active users there are and controls the
packet generation rate. This node also fills in the creation time of the packet and the
packet number. It will discard all packets if the maximum number of packets has already
been exceeded.
The GCSMAC object controls the access to the medium. This is where the time
slot scheduling is implemented. When this object receives a packet from the router it
places it in a queue. Then it reads packets from this queue and, based on the global time
slot size, the current simulation time and the slot that the GCS is assigned to, it transmits
these packets into the network. It also receives return data from the GRS network and
passes it to the GCS_rcv object.
76
The GCS_rcv object simply receives incoming packets, calculates the time that
has passed since that packet was sent out and prints out an informational message, if this
debugging option is enabled. The packet is then simply discarded.
The GCSMAC sends and receives data through the radio receiver and transmitter
objects, which are then connected to antenna modules. The antennas are simply isotropic
but other patterns could be used to test additional antenna options. The receiver and
transmitter objects specify the radio link parameters used for communicating with the
GRS's. This is where the channel models are set and also all of the communications
parameters and power levels. As can be seen in the figure, there is one packet stream
from the MAC to the transmitter object and three receiver streams coming from the
receiver object to the MAC. These correspond to the single transmitter channel and the
three receiver channels.
10.2.2 Packet Generator
The generator
module is where the
packets are actually
created. Figure ? lists
some of the options
that can be set for this
Attribute
Value
name
gen
interarrival pdf
constant
interarrival args
1000000
pk size pdf
constant
pk size args
175
field (0)
pdf
constant
field (0)
args
0.0
packet format
object.
The interarrival
MTK.packet.locr
V
Figure 20: OpNet screen capture of the packet generator settings.
pdf is currently set to constant so that the packets will be generated and sent at regular
times. This could be changed depending on how the system was to be modeled.
77
Currently it is assumed that the GCS receives updated destination data and then at regular
intervals this data is transmitted out to the users. This destination data may arrive at the
GCS in a more random fashion and could then be immediately transmitted to users upon
arrival. This could be simulated by changing the interarrival pdf to a function that
models the arrival of destination data.
The interarrival args parameter simply specifies the interarrival time of the pdf. It
is initially set to a very large value so that no packets will be generated. When a user
begins its flight, this parameter will be modified by the GCSrouter. It will be modified
whenever a user begins or ends its flight to maintain a generation rate of 1
packet/sec/user that is currently in flight.
The pk size args parameter sets the size of the packet. The total size of the packet
is this number plus the size of the fields described by the packet format. The total size is
320 bits to simulate the estimated size of the destination update packets.
The packetformat parameter simply specifies which type of packet will be
generated. This packet contains fields for storing routing data and other useful
information such as creation time and packet number, which are used for informational
purposes in the simulation.
10.2.3 Router Object
The router object's primary function is to receive packets from the generator,
decide which user to send them to, decide which GRS should communicate to the user,
and then fill in the appropriate routing fields and send the packet. To accomplish this, it
must also keep track of what users are in the air at a given time, information about the
78
GRS grid and other simulation information. The router object'functionality is described
by the finite state machine in Figure 21.
When the
.E,..:*
E
E
simulation begins, the
FSM begins in the init
state. This state is
responsible for
querying other parts of
the simulation an ....
initializing several
pieces of data which
Figure 21: OpNet screen capture of the GCS router process model.
will be later used in
deciding where generated packets should be sent. It initializes the total packet count to
zero and retrieves the maximum packet count simulation attribute. It also retrieves the
grid location parameter for this node. This parameter specifies where the GCS is located
in the grid and is a parameter that is set at the network level.
The state then determines how many GRS's are in the grid and allocates and array
of data to store information about each GRS. The information that is stored includes the
GRS locations in x, y and z coordinates, the integer i and j coordinates within the grid
and the spreading code that is used for sending data to users.
This state also has to maintain information about the users. This data is read in
from an external file, generated by matlab scripts. This file contains a list of the start and
end times of the user trajectories. This file is read in and interrupts are generated at each
79
of these times. Each time the simulation encounters one of these interrupts, the
interarrival rate of the generator object is updated to reflect the change in the number of
active users.
The idle state is where the FSM spends most of it's time. It simply waits there for
interrupts to occur. When a packet is received, it moves to the route state which
determines where to route the packet and fills in the header data. This state also sets the
receive spreading code of the user to correspond with the transmitting code of the nearest
GRS. This function would be done within the user in a real world system, but for our
purposes it simplifies the simulation design to place the code here and doesn't affect the
functionality. If the maximum packet count has not been exceeded, the state then
increments the total packet count parameter, logs this variable as a statistic and sends the
packet to the MAC.
The user-change state is responsible for processing the interrupts that occur when
a user begins or ends its flight. A variable specifying the total number of active users is
maintained. When a user begins flight this value is increased and when it ends the value
is decreased. This value is then used to set the interarrival parameter of the packet
generator.
80
10.2.4 MAC Object
(def ault)
(i FR E E)/schedsl ot_-in t rp t-gc s 0E
OWT.FREE
(de f ault)
itWAIT
uinmX
(FREE)
(!QUEUE-EMPTY)
-- -- - - -- -- -----
(FREE)
K-
(TX-END &
CTX-END &&QUEUEEMPTY)/sched-slot
-- -- ---
------
-------
TX.PKT
!QUEUEEMPTY)
-intrptgcs 0
(def aul t)
This object is essentially a simplified version of the MAC processor contained in
the module, but its basic functionality and the differences will be outlined here. A more
detailed description of the MAC will be included in the section describing the GRS.
This object controls the interaction with the radio channel. It queues outgoing
packets and sends them during the proper time slot and forwards incoming packets to the
router. Each of the light colored states in the diagram (TX.WAIT, TXENDWT,
WTFREE) calls a function to process interrupts before leaving the state. This function
puts any packets coming from the router into an output queue and forwards any packets
received from the radio link up to the router.
81
When there is no data to be sent, the FSM will be in the TXWAIT state. When a
packet arrives it is placed in the queue. The queue is then not empty and the transition to
the GETPKT state will be made. The FREE condition is then used to determine
whether the current time corresponds to a valid transmission slot for this node. If it does,
and the packet can be transmitted before the end of the slot, it will transition to the
TXPKT state. If not, it will transition to the WTFREE state and an interrupt will be
scheduled at the beginning of the next valid transmission slot. When that interrupt
executes, the FSM will transition to the TXPKT state and the packet will be sent to the
radio transmitter. The state then sets an interrupt to indicate the end of the packet
transmission and transitions to the TXENDWT state. It remains in this state until the
packet has finished. At this point the TXEND condition will be true and the FSM will
transition to the GETPKT state if there are packets remaining in the queue or the
TXWAIT state if the queue is empty. The cycle then simply repeats.
10.2.5 Radio Objects
The radio receiver and transmitter objects are fairly straightforward. They control
which modules are used for the modeling of the radio channel. The simulation just uses
the default modules included in OpNet. These modules also specify the bit rate of the
channel, the spectrum usage and processing gain for the channel.
10.2.6 Receive Module
This module simply receives the return packets from the router and discards them.
It also prints out status information such as the packet number and the time that has
passed since the packet was created and sent out to the network.
82
I
Ii
10.3 GRS
10.3.1 Overview
The GRS
node description is
shown in Figure 22.
It receives data from
the network and then
u.
routes it either to
another GRS or sends
Figure 22: OpNet screen capture of the GRS node model.
it directly to a user.
Each GRS has four receiver channels that can receive from up to four neighboring GRS's.
It also has two transmitter channels. One for transmitting to users and a second for
transmitting to other GRSs. These two channels could be essentially combined if desired,
but for now they are left separate. This allows simulation of separate frequency bands for
inter-GRS communication and GRS to user communications if desired. As seen in the
figure above, there are two packet streams from the router to the GRSMAC. One is for
data destined for users and the other is for data being sent to another GRS.
10.3.2 GeneratorObject
The generator object creates packets to simulate the differential corrections. This
generator creates a formatted packet to be sent to the user. The total size of the packet is
1440 bits and the packet is generated once per second.
83
10.3.3 Router Object
The router
(def aul t)
object is what
controls where
-init
-d
---
(K.
V
--
rout
packets received by
the GRS will be
forwarded to.
The
Figure 23: OpNet screen capture of the GRS router process model FSM.
FSM consists only of three states. The init state initializes several pieces of data that are
later used during simulation. It sets up statistics used to log how many packets have been
received by the node and how many packets have been dropped due to excess latency.
The router is currently set to drop any packet that it encounter which is more than 5
seconds old. Next this state retrieves its location in the grid and the location of the GCS
and stores them in local variables. The GCS location is needed for routing status and
return data back to the GCS. Finally the state fills in an array specifying which links are
enabled and which are disabled. Disabled links are specified by setting the receiver
spreading code to 255. (This setting is done at the network level)
Whenever a packet arrives, either from the packet generator or the MAC, the
FSM transitions from the idle state to the route state. If the packet is being sent from the
generator, then it is immediately sent out to the MAC, to be sent to the users. If the
packet is being received from the MAC it is passed to the routing function to be
processed. The routing algorithm is as follows. First the creation time is checked against
the current time to determine if the packet is too old. If so, it is discarded. If the packet
is valid its destination field is read and compared with the current GRSs location. If they
match, then the packet has reached its destination. The destination fields of the packet
84
will then be changed to send it back to the GCS and its size will be changed to
correspond to the size of the return message. Next a user packet will be created. Its
destination user fields and creation time fields will be filled in using data from the
original packet and it will be sent to the MAC through the user data stream.
Now the packet will be forwarded to the next GRS based on it's destination fields.
This portion is the same whether the packet is being sent back to the GCS or being
forwarded on further. The routing is done by examining the (ij) coordinates of the
current node and those of the destination node. The next node field is then set to forward
the packet in the direction in which the greatest distance remains. If there are links
disabled it will try to forward it in the best available direction. The next node field is
only a 2 bit field corresponding to the four possible direction in which the packet could
be transmitted. This number corresponds to the receiver channel number on which the
adjacent node will be receiving this GRSs code. For instance, to transmit a packet
northwards the next node field would be set to 3. The network setup will have already set
receiver channel three of the node to the north to receive using the current node's
spreading code. This method allows the space required by the next node routing info to
be minimized and simplifies the routing functions because no additional tables are
needed.
Only the next node field and the receiver channel number are required to
determine if a packet should be accepted or discarded by a MAC. Once the next node has
been determined and the field has been set, the packet is sent to the MAC through the
GRS packet stream.
10.3.4 GRS MAC Object
85
Figure 24:OpNet screen capture of the GRS MAC process model FSM.
The GRSMAC object controls the access to the radio channel. It receives data
from the radio links and then forwards it to the router and accepts data from the router
and sends it to the appropriate node. It contains three subqueues. One for storing packets
to be sent to users, one for storing packets to be sent to other GRSs and a third to hold
packets that are about to be transmitted. The operation is similar to that of the GCS MAC
but it is slightly more complicated. It still schedules interrupts at the beginning of slots in
the same manner and determines whether the channel is free using the same method, but
it has the additional complexity of also having to transmit user data.
The init state reads the time slot and slot size and also stores the bit rates used for
communicating with users and other GRSs in local variables. These values are used in
determining how long it will take to transmit a packet.
86
As in the GCS, the unforced states all call an interrupt function upon exit. This
function receives data coming in from the radio link and determines if it has reached its
intended destination. If not it is discarded and if so it is sent up to the router module.
Packets that are received from the router over the user data stream are placed in the user
queue and packets received over the GRS data stream are placed in the GRS queue.
If either queue is non-empty, the FSM will transition to the GETPKT state. Both
queues will then be examined and a packet will be removed from the largest queue. The
design allows for fragmentation of packets being sent to users so if a packet is greater
than the maximum size allowable, given the time slot size, it will be fragmented and each
smaller packet will be placed in the transmission queue. If the packet is smaller than this
maximum it will simply be placed in the transmission queue.
The next few steps are identical to the GCS MAC. The FSM transitions to the
READY state and a packet is removed from the transmission queue. When the channel
becomes free the packet is transmitted and then the process waits for the transmission to
finish. At this point the FSM will transition back to the READY state if there are still
packets left in the transmission queue. This ensures that all fragments of a user message
are sent consecutively. Once all fragments have been transmitted the FSM will transition
to either the TX_WAIT or GETPKT state depending on whether there is data in either
the user or GRS queues.
10.3.5 Radio Objects
The radio receiver and transmitter objects are essentially the same as for the GCS.
There is an additional transmitter channel, but otherwise, they are identical. They control
which modules are used for the modeling of the radio channel. The simulation just uses
87
the default modules included in OpNet. These modules also specify the bit rate of the
channel, the spectrum usage and processing gain for the channel.
10.3.6 User
The user object is fairly simple.
I consists of an antenna, a receiver
-
module and a single processor. This
processor simply receives the packets
Figure 25: OpNet screen capture of User node
model
from the receiver module and modifies
statistical and informational data. If the packet is the last packet in a fragmented
destination update message, then the global packet received counter is incremented and
the time since the packet's creation is logged as the global latency statistic. The packet is
then discarded. All other types of packets are simply discarded.
10.4 Matlab
Matlab is used to generate the user trajectories to be used by the simulation. The
script takes in several arguments:
" A list of coordinates specifying the placement of departure sites
* A rectangular area where the destinations are located
* The number of users in the simulation
* The inter-arrival rate of the user departures appearances
"
Output file prefix (simulation currently expects 'user')
The scripts first generate random destination locations within the specified
rectangular area. Uniform PDFs over the dimensions of the specified area are used for
the x and then the y coordinates. The script then starts a loop that examines each
88
destination and determines the closest departure site. A flight path is then generated
between the departure site and destination locations. Within this loop there is a time
value which increments at each termination of the loop according to an exponential PDF
using the specified inter-arrival rate. This time value specifies when the user will begin
its flight.
Each trajectory is then written out to a file conforming to an OpNet trajectory file.
OpNet trajectory files use a constant time step, which is placed in a header. To limit the
file size and the redrawing time of the simulation windows, a value of 2.5 seconds has
been chosen. Therefore times used in the scripts are rounded to the nearest 2.4 seconds.
The scripts additionally create two more output files. The first is used by the
simulation to retrieve general information about the user trajectories. It lists the start and
end times of each user trajectory. This is used by the GCS to determine how many users
will be used in the simulation. It is also used to schedule simulation interrupts to change
the message generation rate based on the number of currently active users.
The last file is an informational file that is not used by the simulation. It is for use
by the user in setting up and analyzing the simulation. It gives information such as the
time of the last user departure and last user landing. It also lists the number of active
users in the system at 2.5 second increments.
89
11 Appendix 2 - Terrain
Although the simulation does not simulate the terrain, some research was done in
this area. There have been papers which illustrate the use of random noise in simulation
of ad-hoc network performance [1]. This method would be perfect for simulation of our
system. Various software tools, available in the public domain, have been found and
could be used to simulate the
system performance in various
types of terrain.
The first
thing that is required is a tool to
generate terrain. This is a very
common requirement in the world
of computer graphics and that is
where the most information appears
Figure 26: Terrain generated by gforge and rendered
by POV-RAY.
to be available. I have found a
program called gforge which allows a random terrain to be created using various
parameters to set it's basic characteristics. The program outputs the data as an image file,
sometimes called a height field file. The height and width determine the horizontal
dimensions of the terrain area and the color values specify the terrain height. As this is a
common format used in computer graphics, the terrain can then be easily visualized by
rendering it using a ray tracer. Figure 26 shows an example of terrain generated by
gforge and rendered using POV-RAY.
These images are useful for visualizing the terrain that is being used in the
simulation, but the simulation will probably use the actual height field file. Some
90
investigation was done to determine how to best implement this in the simulation. I
found some code examples that could be used to determine, based on square grid of
height values and the three dimensional locations of two points, whether line of sight
exists between them. This code could then be added to the OpNet radio pipeline module
which determines whether or not a communications link exists between two nodes. A
method for reading in and storing the image file that describes the terrain will need to be
developed, but it appears that OpNet is flexible enough that a solution can be found.
Another option is to actually use real world terrain data. As greater efficiency is
sought, communications systems are further analyzed before being deployed. Digital
terrain models can be used to determine propagation characteristics in an actual real
world site. These are used to predict the optimal placement of transmitters [17,18]. This
same method could be used to simulate the performance of our system, using real terrain.
This concept could even be used in a final system to automatically decide the optimum
locations of the nodes in the grid. Thereby automatically planning the deployment of the
system, based on digital terrain maps of the destination area, rather than simply
simulating it.
The second factor in modeling the environment is the affect of trees and
vegetation on the signal propagation. There has been a large amount of research done in
this area, although there seems to be very little at the 10Ghz range. Some research has
been done into these affects at lower frequency bands. Many of the same results should
apply at 10Ghz. Using this past research and possibly during some testing at 10Ghz, it
should be possible to come up with models for the signal behavior in various
environments. This data could be used to predict a loss due to vegetation and could be
91
incorporated in to the simulation. Based on the literature it seems that the best way to
implement this would be to have different probabilistic loss functions for different types
of vegetation [6, 11]. The type of vegetation would be a simulation input. When the
radio pipeline is executed a sample of this probabilistic function will be included in the
calculation of the received power.
92
12 References
[1] Christiaan Roobol, "Multihop Radio Networks in Random Terrains: Connectivity and
Some Terrain Adaptive Routing Agorithms", Military Communications Conference,
1993. MILCOM '93. Conference record. Communications on the Move., IEEE Volume:
2, 1993 , Page(s): 428 -431 vol.2
[2] David W. Matolak, Steven L. Smith, "Estimation of TDMA and CDMA Capacities
for an Air-To-Ground Communication System", MILCOM 97 Proceedings Volume: 1 ,
1997 , Page(s): 424 -428 vol.1
[3] Zygmunt J. Haas, Siamak Tabrizi, "On Some Challenges and Design Choices in AdHoc Communications", Military Communications Conference, 1998. MILCOM 98.
Proceedings., IEEE Volume: 1 , 1998 , Page(s): 187 -192 vol.1
[4] Barry M. Leiner, Donald L. Nielson, Fouad A. Tobagi, "Issues in Packet Radio
Network Design", Proceedings of the IEEE, Vol. 75, No. 1, January 1987.
[5] Vincent D. Park, M. Scott Corson, "A Highly Adaptive Distributed Routing
Algorithm for Mobile Wireless Networks", INFOCOM '97. Sixteenth Annual Joint
Conference of the IEEE Computer and Communications Societies. Driving the
Information Revolution., Proceedings IEEE Volume: 3, 1997 , Page(s): 1405 -1413 vol.3
[6] Julius Goldhirsh, Wolfhard J. Vogel, "Handbook of Propagation Effects for Vehicular
and Personal Mobile Satellite Systems", http://www.utexas.edu/research/mopro/
[7] Andrew S. Tanenbaum, Computer Networks,
191
93
2 nd
Edition, Prentice-Hall, 1989, pp 183-
[8] "IEEE Std 802.11-1997 Information Technology-telecommunications And
Information exchange Between Systems-Local And Metropolitan Area Networks-specific
Requirements-part 11: Wireless Lan Medium Access Control (MAC) And Physical Layer
(PHY) Specifications", IEEE Std 802.11-1997, 18 November 1997 , Page(s): i -445
[9] Bernard Sklar, DigitalCommunicationsFundamentalsand Applications, Prentice
Hall, 1988, pp 195-206, 251-257, 478-493
[10] Szu-Lin Su, Wen-Chang Pan, "3D Cellular Systems for Air-land Communications",
Universal Personal Communications, 1994. Record., 1994 Third Annual International
Conference on , 1994 , Page(s): 485 -489
[11] Dr K Benzair, "Measurements and Modeling of Propagation Losses through
Vegetation at 1-4GHz", Antennas and Propagation, 1995., Ninth International
Conference on (Conf. Publ. No. 407) Volume: 2, 1995 , Page(s): 54 -59 vol.2
[12] Hisham Ibrahim Kassab, "Low-Energy Mobile Packet Radio Networks: Routing
Scheduling, and Architecture", MIT Ph.D. Thesis.
[13] Young-Bae Ko, Nitin H. Vaidya, "Using Location Information in Wireless Ad-hoc
Networks", Vehicular Technology Conference, 1999 IEEE 49th Volume: 3, 1999,
Page(s): 1952 -1956 vol.3
[14] Junghwan Kim, D. Haschart, S. C. Kwatra, Mark J. Vanderaar, G. H. Stevens,
"Performance Evaluation of Land Mobile Satellite System under Vegetative Shadowing
using Differential Multiple TCM and QPSK", Military Communications Conference,
1990. MILCOM '90, Conference Record, A New Era. 1990 IEEE, 1990 , Page(s): 263267 vol.1
94
[15] Mr. Martin Hope, Prof. Nigel Linge, "Determining the Propagation Range of IEEE
802.11 Radio LAN's for Outdoor Applications", Local Computer Networks, 1999. LCN
'99. Conference on, 1999 , Page(s): 49 -50
[16] Jyrki Leskeli, "Deterministic Multihop Radio on the top of 802.11 MAC", RealTime Systems, 1998. Proceedings. 10th Euromicro Workshop on, 1998 , Page(s): 71 -78
[17] F. Pirez-Fontin, J. M. Hernando-Ribanos, "Comparison of Irregular Terrain
Propagation Models for using in Digital Terrain data Based Radiocommunication System
Planning Tools", Broadcasting, IEEE Transactions on Volume: 39 3 , Sept. 1993,
Page(s): 335 -343
[18] M. Lebherz, W Wiesbeck, H-J Basberg, W. Krank, "Calculation of Broadcast
Coverage Based on a Digital Terrain Model", Antennas and Propagation, 1989. ICAP
89., Sixth International Conference on (Conf. Publ. No.301) , 1989 , Page(s): 355 -359
vol.2
[19] Marvin Silver, "Modular Hybrid Avionic System for Precision Tactical Weapons",
Position Location and Navigation Symposium, 1988. Record. Navigation into the 21st
Century. IEEE PLANS '88., IEEE , 1988 , Page(s): 402 -407
[20] Ramjee Prasad, CDMA for Wireless PersonalCommunications, Artech House,
Boston-London, 1996, pp 145.
95