A multiscale real-time navigation and communication satellite simulation model for OMNeT++.

Full text

Page 1

A Multiscale Real-Time Navigation and Communication
Satellite Simulation Model for OMNeT++
Andreas Lewandowski
andreas.lewandowski@tu-
dortmund.de
Ralf Burda
ralf.burda@tu-
dortmund.de
Christian Wietfeld
christian.wietfeld@tu-
dortmund.de
Communication Networks Institue (CNI)
Department of Electrical Engineering and Information Technology, Dortmund University of Technology
Dortmund, Germany
ABSTRACT
This paper presents the first steps of developing the Galileo
Satellite Communication Simulator (GSCS) based on the
INET Framework [2] of OMNeT++ simulation engine [1].
We present our mobility model for the accurate prediction
and modeling of satellite motion using NORAD’s (North
American Aerospace Defense Command) propagation algo-
rithm SGP (Simplified General Perturbations) for real-time
satellite position modelling.
Galileo specific satellite orbit data is generated in order to
establish the mobility of the prospective space segment. The
validity of the simulation implementation is then proved by
comparing the results of our simulation with two reputable
satellite tracking applications and to a real GPS receiver,
from which further extensions of the simulation system are
derived. In further steps the integration in a Multiscale Net-
work Simulation Environment is described. The dynamic
interaction between Environment, Radio Channel and User
Mobility can then be modelled in an adequate way.
Categories and Subject Descriptors
I.6.4 [Simulation and Modelling]: Model Validation and
Analysis; I.6.5 [Simulation and Modelling]: Model De-
velopment; I.6.6 [Simulation and Modelling]: Simulation
Output Analysis
General Terms
Performance, Design, Reliability, Experimentation, Verifica-
tion
Keywords
Galileo, Multiscale Simulation Environment, Satellite Mo-
bility Model, SGP4/SDP4, Two Line Elements
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
OMNeT++ 2008 March 3, 2008, Marseille, France
Copyright 2008 ACM 978-963-9799-20-2 ...$5.00.
1.INTRODUCTION
The European satellite navigation system Galileo offers a
promising technology to enhance the navigation resolution
and offers communication capabilities in combination with
the actual Search and Rescue (SAR) service of the COSPAS-
SARSAT system. Our actual research focus in the project
Galileo4FireBrigades lies on real time emergency communi-
cation services for firefighters even if no terrestrial network
is available. We are developing a hybrid communication
architecture with the objective to support out-of-coverage
communication using the enhanced SAR Service.
The Galileo System will be ready for use by 2013 and our
objective is to prove the real time capability of the SAR
Service with the proposed Galileo Satellite Communication
Simulator (GSCS) framework.
This paper presents the results of the first stage of develop-
ment of GSCS, which is the accurate modeling of the satel-
lites’ motion and position based on NORAD’s propagation
algorithm SGP (Simplified General Perturbations) and the
further developments SDP (Simplified Deep Space Pertur-
bations) for real-time satellite position prediction.
In order to enhance the simulation model itself, a Multiscale
Simulation Environment (MNSE) is built up which relies on
a tight coupling of an industry standard Radiowave Propa-
gation Simulator (RPS) and a CNI proprietary MObile Ob-
ject Simulation Environment (MOOSE) to OMNeT++. In
order to create a holistic system model of a wireless com-
munication network, a Central Event Broker (CEB) is set
up in a form of a OMNeT++ simulation module. The CEB
manages the synchronization and the distribution of events
which transit from one simulator to another. To indicate the
feasibility, a multiscale sample of this satellite communica-
tion system, comprising three mono scales, namely protocol,
radio propagation and user mobility, is used here. Opposed
to state-of-the-art multi-layer simulation systems [13], the
MNSE is not focused on the optimal interworking between
entities but rather supports their individual degree of free-
dom in order to engulf a vast problem space.
This paper is arranged by presenting a brief introduction to
the SGP4 and SDP4 algorithms in addition to an explana-
tion of NORAD’s Object Catalog in the second section. Key
aspects of the implementation of our simulation model in
OMNeT++ are discussed and two visualisation approaches
namely Global Projection View (GPV) and Local Projec-
tion View (LPV) are described. Finally the validity of the
accuracy and reliability of the simulation model is proven

Page 2

against well-known satellite tracking applications and a real
time GPS track followed by the generation of Galileo satel-
lite movements. Special implementation aspects on the sim-
ulative Galileo Satellite models and Ground Stations are de-
scribed in detail in section 3. In section 4 the multiscale sim-
ulation approach is depicted before the approach is turned
in to a formal architecture. We provide insight to the tech-
nology used for coupling the distinct simulation engines. A
representative simulation flow is described, too, before this
paper is wrapped up by an Galileo4FireBrigades application
example.
2.THE SATELLITE MOBILITY MODEL
2.1 Introduction
NORAD was founded by USA and Canada for space ob-
servation as a reaction to USSR’s launching the first satellite
in 1957. The primary task of NORAD was to provide de-
fence against intercontinental ballistic missiles. In order to
differentiate between missiles and satellites, all moving ob-
jects in the earth’s orbit are tracked continuously by a large
network of sensor base stations and the measurements are
archived as Two Line Elements (TLE) in NORAD’s Object
Catalog. Since the sensor base stations are not able to track
the satellites continuously, an algorithm called Simplified
General Perturbations (SGP) [4] was developed to forecast
the movement.
We propose using this algorithm in order to generate a highly
precise real time satellite mobility model for OMNeT++. In
combination with the actual NORAD Object Catalog, all
kinds of moving objects in the earth orbit can be tracked.
Even the motion and position of International Space Sta-
tion (ISS) and the Space Shuttle can be displayed by using
relevant TLEs. A simplified satellite mobility model could
Figure 1: SGP Prediction
be realised by modeling the movement based on regular Ke-
pler traces, but due to the absence of irregular perturbations
in Kepler traces that actually arise during a satellite’s mo-
tion, the trace of the satellite can not be modeled accurately
then. Figure 1 illustrates the difference between the two ap-
proaches.
2.2 The Propagation Algorithms
2.2.1Simplified General Perturbations No.4
The Simplified General Perturbations No.4 (SGP4) [5] al-
gorithm is an extension of the originally developed SGP
prediction algorithm. The calculation is accomplished by
adding the following effects to the regular Kepler Traces:
• Secular effects of atmospheric drag and gravitation pull
are calculated and added to the initial anomaly.
• Long periodic and short periodic changes are added.
• Zonal harmonic terms of the earth’s gravitation field
are calculated.
This algorithm is suitable for near earth orbits which usu-
ally takes less than 225 minutes to complete one revolution
around the earth.
2.2.2
The Simplified Deep Space Perturbations No.4 (SDP4) [5]
algorithm can be used for deep space satellites, which have a
revolution time of more than 225 minutes. The calculation
is based on the SGP4 algorithm, introduced previously, and
accomplishes additional calculations taking into account the
following:
Simplified Deep Space Perturbations No.4
• Influence of lunar and solar gravity fields
• Certain earth harmonics, which are important for half-
day to full-day periods.
The proposed implementation [8] selects the suitable algo-
rithm automatically. This API is integrated into the INET
Framework in order to minimize errors caused by a self im-
plementation.
2.3 Two Line Elements
The actual TLE sets can be downloaded at [6] and [7]
either as a full object catalog or a system specific set. Sev-
eral other information relating satellite tracking can also be
found on these websites. The parameters of the TLE for-
GIOVE-A
1 28922U 05051A 07308.04226181 .00000041 00000-0 10000-3 0 2730
2 28922 56.0446 172.9334 0008039 336.8309 23.2245 1.70194202 11502
0
00
000000
. ..
Figure 2: Two Line Element Format
mat used by the SGP4/SDP4 algorithms are shown in Fig-
ure 2 whereas Table 1 describes the various abbreviations of
the TLE format. Each TLE data set consists of three lines
Parameter
t0
n0
B∗
i0
Ω0
?0
ω0
M0
Description
Epoch Time
Mean Motion
Resistance Parameter
Inclination
Right Ascension
Eccentricity
Argument of Perigee
Mean Anomaly
Table 1: TLE Description
whereas line 0 consists of a 24 character name and line 1 and
2 contain the described data to accomplish the calculation.

Page 3

2.4Implementation in OMNeT++
This section discusses the key features and visualisation
approaches of our simulation implementation developed us-
ing the INET Framework of OMNeT++ version 3.3 simula-
tion software engine.
2.4.1
In order to retain the accuracy of the mobility model, rea-
sonable TLE data updates are necessary because of unpre-
dictable changes in the orbit. These changes are observed
by the ground stations and inserted in new TLE data. New
TLEs are available every 6 to 10 hours for Low Earth Orbit
(LEO) satellites and approximately once a week for geosta-
tionary satellites. Hence the needed TLE update for real
time prediction depends on the kind of modeled satellites.
The implementation offers a parser functionality, which pro-
vides an easy way to update TLEs by just copying the down-
loaded text files to the simulation directory. Only satellite
names and the file name have to be assigned in the simula-
tion initialization file. In order to minimize the parser pro-
cess, TLE data files should be limited to the specific satellite
system.
Two Line Element Update
2.4.2
The actual system time of the local computer is taken for
the reference time and used for the start point of the move-
ment prediction. For this reason TLEs have to be updated
reasonably. The user specific time zone has to be assigned in
the OMNeT++ initialization file since the TLE epoch time
bases on Greenwich Mean Time (GMT) at 0◦longitude.
Real Time Synchronization
2.4.3
In this visual projection, the satellite mobility is presented
via a 2-dimensional global view (Figure 3). This 2-D view
of the globe is made by transforming a relevant World Map,
which can be downloaded from [9] for non-profit use, using
the Cylindrical Equidistant Transformation, since this ap-
proach is the natural projection because the x–coordinate
is equal to geographic length and y–coordinate is equal to
geographic width. The calculated satellite positions are rep-
Global Projection View (GPV)
Figure 3:
Galileo satellite system in Global Projection
OMNeT++ GSCS Simulation View:
resented in longitude, latitude and elevation notation and
in order to plot the position of the satellites accurately over
our 2-D map the following equations are used:
pos.x = (((map.x
360
∗ longitude) + (map.x
2
))mod (map.x))
pos.y = (−(map.y
180
) ∗ latitude + (map.y
2
)mod (map.y))
where map.x/y are the dimensions of the chosen map. The
modulo operation is necessary to let the satellite appear on
the other side of the map before leaving the simulation play-
ground. The resulting GPV as viewed in the OMNeT++
environment is presented in Figure 3. This visualization can
be used for presentations and analysis of a holistic satellite
system.
2.4.4
This visualization depends on the actual position of the
user equipment in order to evaluate the performance of a
satellite system at a specific time and position. The exact
Local Projection View (LPV)
BIIR-04
BIIRM-3
BIIA-22
BIIA-27
BIIR-6
BIIA-23
BIIA-16
BIIRM-2
BIIA-24
BIIA-20
BIIA-21
BIIR-13
BIIA-12
BIIR-12
BIIR-03
BIIR-11
BIIA-10
BIIR-08
BIIR-10
BIIA-25
BIIR-07
BIIR-09BIIA-11
BIIA-14
BIIA-28
BIIA-15
BIIR-05
BIIRM-1
BIIR-02
Figure 4: OMNeT++ GSCS Simulation View: GPS
system in Local Projection
user position can be assigned in the initialization file of the
simulation. Visible satellites are located in the inner circle
and have an elevation higher than 10◦as shown in Figure
4. Non visible satellites are at the gray border of the outer
circle. The calculation depends on azimuth and elevation
degree calculated by the prediction algorithm. These values
are converted in the shown coordinate system (Figure 4) by
using the following equations.
radius = radiusmax− (elevation
π
2
∗ radiusmax)
pos.x = −cos(Azimuth +π
2) ∗ radius + radiusmax
pos.x = −sin(Azimuth +π
All satellites with an elevation greater than 10◦can be as-
sumed as visible as this first assumption relies on a flat sce-
nario with line of sight conditions to the satellite.
2.5Validation of the Implementation
The reliability and accuracy of our simulation implemen-
tation is validated in two steps. In the first step our model is
compared to the output of other reputable satellite tracking
applications. In the second step we validated the simulation
output against the real GPS System in order to evaluate the
constraints of assumptions made.
2) ∗ radius + radiusmax

Page 4

2.5.1Comparison to reputable satellite tracking ap-
plications
The performance of our simulation model is compared
against HeavenSat [10] and WxTrack [9], which are two pop-
ular satellite tracking applications. Both programs are using
the described SGP algorithm and Two Line Elements to pre-
dict satellite positions. The TLEs have been updated in all
programs short before the measurement began.
0
0,2
0,4
0,6
0,8
1
0,0000,0050,0100,0150,0200,0250,0300,035 0,0400,045
Deviation [deg]
WxTrack - HeavenSat
OMNeT++ - WxTrack
OMNeT++ - HeavenSat
Figure 5: Accuracy in comparison to approved satel-
lite tracking applications
Figure 5 shows the deviation of the azimuth in comparison
to the two satellite tracking tools. Only the azimuth degree
has been examined, since the other values give analog re-
sults.The results show a maximum deviation of 0.025◦,
which shows, that the implemented algorithm is working
correctly. In further steps the calculated satellite positions
are assumed to correspond to the real positions.
2.5.2
In order to prove the 10◦visibility assumption, the OM-
NeT++ implementation is validated by comparing the sim-
ulated satellite positions with a live GPS track using Visual
GPS [11] on a notebook connected with a SIRF Star III
GPS receiver. The measurements have shown irregularities
which correlate to the composition of the environment. The
specific results are not shown here, but lead to a further
extension of the simulation by adding a sophisticated envi-
ronment and channel model.
Comparison to a live GPS-Track
3.THE GALILEO SYSTEM
3.1 Galileo Space Segment
The prospective European satellite system Galileo is our
current research focus. Two Line Element (TLE) data is not
available for future satellite launches, hence we created new
TLEs using the Galileo System Simulation Facility (GSSF)
[12] to obtain the orbit data. An existing TLE of the first
Galileo satellite GIOVE-A (Galileo in Orbit Validation) was
the reference for 30 Galileo operational satellites, which are
moving on three different orbits in the Walker 27/3/1 con-
stellation in a height of 23260 km. Three satellites in every
orbit are used for quick recovery in case of failure.
Table 2 shows the relevant parameters, which have been
transferred to the TLE Format. The number of satellites
which are going to be equipped with Search-and-Rescue mod-
ules to enhance the SAR Service integrity are not defined
yet.
Parameter
Semir-major axis [km]
?0
i0 [deg]
Ω0 [deg]
ω0 [deg]
M0
Description
29600.318
0.000
56.00
0/120/240
0
40 deg dif. between satellites
Table 2: Galileo Orbit Parameters
Galileo.GIOVE-A[0]
Analyser
Receiver406
Receiver1544
notificationBoard
Transmitter1544
satelliteMobility
Transmitter406
Figure 6: OMNeT++ model of a Galileo satellite
Figure 6 explains the OMNeT++ simulation model of the
satellite. Two receivers are necessary since one is needed
for the Galileo Control Center Up– and Downlink on a fre-
quency of 1544MHz and the second is for the SAR module
operating on a frequency of 406MHz. A short time delay be-
fore the signal reaches the Analyser to be processed is imple-
mented. The Analyser is able to handle one emergency call
at a time. If no GPS/Galileo position is transmitted with
the emergency call, the Analyser starts the localization pro-
cess using the Doppler Effect. This localization approach
can only be accomplished by Low Earth Orbit (LEO) or
Medium Earth Orbit (MEO) satellites because of the rela-
tive movement to earth. Another delay is implemented to
consider the delay for sending the information down to the
sensor stations using Transmitter1544. The second Trans-
mitter406 is used for the Galileo specific acknowledgement
to inform the emergency caller for receiving the message.
These simplified assumptions meet our requirements in or-
der to validate the propagation and processing delay for the
SAR Service.
3.2Galileo Ground Segment
The future Galileo ground segment consists of 29 sensor
stations for tracking relevant signals from the orbits. Ad-
ditionally 5 uplink stations are responsible for movement
correction and controlling processes. Figure 7 describes the
model of a Galileo sensor station in detail. Receiver1544 re-
ceives the emergency call containing position information of
the caller. The Analyser checks the signal and sends it out
to the Search–and–Rescue Center of the COSPAS-SARSAT
system on a terrestrial way using a fiber optic connection.
The largest segment which has to be taken into account is
the user segment.A wide spread of new navigation and
communication applications is expected within the next few
years. We integrate this user group in the Multiscale Net-
work Simulation Environment (Section 4) and add a LPV

Page 5

Figure 7: OMNeT++ model of a Galileo Sensor Sta-
tion
for embedding the satellite system to the local scenario. The
resulting Galileo System in a simulation view is shown in
Figure 3. The divers satellite color indicate the movement
on different orbits.
4. MULTISCALE SIMULATION
In order to generate a holistic model of a Wireless Com-
munication Network (WCN), the dynamic mutual impact
of environment, network infrastructure and mobile objects
must be included in the model. Especially wireless ad–hoc
networks provide connections which are vulnerable to ef-
fects like multipath fading, dispersion and non–line–of–sight
(NLOS) conditions. In this context, mobile objects are not
necessarily subscribers of the network as even a moving pas-
sive object may cause variations in the radio channel and in
turn may influence network performance. Currently, OM-
NeT++ does not model these dynamic interactions precisely
but rather focuses on protocol aspects of mobility as such.
Radio propagation models are therefore kept straightforward
and rather static. Implemented user mobility models are
supported on a very basic level only. It is, of course, beyond
the current scope of the INET– or Mobility–Framework [3],
to model all the occurring dynamic dependencies which have
essential effects in a holistic wireless network model. To gain
capabilities for a modelling precision which is adequate to
evaluate even safety critical systems, significant extensions
to the INET simulation framework are presented in this pa-
per. Several claims are made by this modelling approach:
• A 3-D environment editor captures reasonable appli-
cation scenarios. The scenario model generated by
either Google SketchUp or the Radiowave Propagation
Simulator (RPS) front end [14] lays out the foundation
of each model.
• Realistic modelling of user mobility is enabled by
addressing dedicated path mobility and dynamic group
mobility. These features are supported by the Mobility
Simulator MOOSE [15].
• An industry standard channel model at high accu-
racy is derived from the results of the RPS simulation
due to the ray tracing features of that component.
• The full model dynamics is captured by the Central
Event Broker (CEB) which manages the synchronized,
mutual exchange of status data between all simulation
components.
4.1Multiscale Simulation Model
The central paradigm of the Multiscale Simulation Archi-
tecture (MSA) is the classification of source models and
a (holistic) system model [16] which interact by means
of a central event broker. A source model is thought
to represent network participants (both active and passive),
the so called objects in the model context. It comprises all
aspects of activity for each object. This addresses network
traffic models as well as movement and physical parameters
or capabilities. Especially radio parameters such as trans-
mit power, antenna configuration or receiver sensitivity are
valid examples for the latter. In general, a source model is
located in the genuine OMNeT++ domain and thus utilizes
all the features of the standard INET framework.
A system model represents twofold dynamic interactions
of all the source model entities. First, physical models like
radio propagation, individual antenna models and entity lo-
cation determine the physical connectivity. In turn results of
such a model may have impact on activity models in some of
the source entities. Similar, individual movement may cause
group effects which are handled by the specific mobility sim-
ulator in the system model. The utilization of best–in–class
tools for these complex sub systems advocates the open sys-
tem solution presented later on.
The CEB ensures time synchronisation between source
and system models, and therefore between all simulators.
It does so by routing relevant data to the affected entities.
An integrated decision support function schedules only rel-
evant update processes in order to minimize the calculation
overhead.
Figure 8 depicts the described MNSE along with the most
relevant information flows as an extension to the OMNeT++
simulation framework. The Central Event Broker (CEB),
operating as an adjunct to the well known ChannelControl
module, defines the core of the MNSE. The topology setup
for the next simulation interval is determined by those core
components.
4.2Simulation Architecture
4.2.1
To turn the basic concept as described in section 4.1 to a
valid executable, the concept components have been embed-
ded into a specific framework as shown in figure 9. The CEB
defines the context, in which the OMNeT++ simulation is
run and all subsidiary simulators (RPS, MOOSE and gen-
uine OMNeT++) are executed. The CEB mediates the data
flow between the coupled simulators and also makes use of
several supplementary tools which are grouped around the
core. The User Interaction component is responsible for the
GUI driven capturing of the application scenarios. The RPS
front end has been chosen to be used for this task, applying
the spatial model to all other simulators as input.
The control of the simulation flow and an online result
processing has been implemented as a separate GUI while
the central data management is set up as a link to a MySQL
data base.
As far as communication links are not predefined for the
exchange of status data, the CEB utilizes TCP sockets to
transfer all necessary information between different entities.
Components and Interaction relations

Page 6

NotificationBoard
InterfaceTable
InterfaceTable
Mobility
TCPUDP
PingApp
networkLayer
Sophisticated Radio Channel (RPS)
Event Broker
ChannelControl
timing adapted
channel data
Connection
table
external input
Radio Shadow caused
by moving Persons
Radio Shadow caused
by Environment Model
OMNeT++ Scenario
New 3-D detailled environment model (RPS)
Metal
Persons
Concrete
Accesspoint
Accesspoint
Accesspoint
Accesspoint
Mobile Client
Mobile Client
Mobile Client
External Mobility Simulator (MOOSE)
Figure 8: Multiscale Network Simulation Environment
Solid arrows indicate dynamic exchange of information as
long as the simulation is active. Dashed lines represent in-
formation which is generated in a pre-run. As for now, a
dynamic change of plan with respect to the movement pat-
tern is not implemented in the network objects.
4.2.2
As not all considered models might require online data ex-
change, two different types of simulator interfaces are used,
namely a passive one (dashed lines in figure 9) and an ac-
tive one (solid lines in figure 9).
Coupling the Simulation Environments
The passive interface
The passive interface is considered to be a storage and re-
trieval process from a central database only. A generating
simulator (here MOOSE) will generate all information in a
pre–run and store the results in the data base from which
the CEB will retrieve a snapshot of all positions any time
this is needed. This has been implemented by means of an
MySQL data base to achieve a high degree of flexibility.
The active interface
The active interface is a superset of the passive one in the
sense that the data source may update the information in
the data base while the simulation is executing. As an exam-
ple, coverage of a particular location in a WCN may change
due to fading effects if objects move. If the valid scope of
information is just bilateral and temporal, a simple TCP
socket connection is established between source and sink by
the CEB. Furthermore, socket connections are used by the
CEB to trigger update runs of the system model.
4.3Simulation flow
Actual CNI research activities on indoor localization with
IEEE 802.15.4/ZigBee [18] networks and Mobile WiMAX
rely on the presented MNSE. In these settings, a passive in-
terface has been chosen for the mobility model as no strategy
simulation for user behaviour as a function of communica-
tion performance is considered. Movements may therefore
be as well preassigned. However, as the nodes in the exam-
ples perform power control at the transmitter, a preassign-
ment of radio connectivity is prohibited as power conserva-
tion strategies are one of the facets of the research projects
mentioned.
As external simulators are executed in parallel to OM-
NeT++, we have activated multi threading in the code. As
an example, each entity may request an update of the radio
channel parameters from the event broker for a target time
t. The CEB triggers the appropriate simulator to deliver
the result in a new service thread and inserts a new service
event into the queue of the OMNeT++ main thread. That
event will block the simulation when scheduled if the service
thread did not terminate in time. If the servicing simula-
tion returns a result, the associated CEB service thread will
store it in the central data base and terminate afterwards.
The service event causes a reload of the model setup af-
ter unblocking and thus leaves the overall simulation in the
correct, new state.
4.4Propagation Example
The accuracy of the MNSE channel model is detailed us-
ing a simple Wireless LAN example as shown in Figure 10.
An isotropic WiFi source is sending at a power of 100mW.
Three 50cm concrete walls are modelled to describe the en-

Page 7

OMNeT++
Central
Data Management
Simulation
Flow Control
Online Result Processing
User Interaction
Radio Channel (x,y,z)
3-D Scenario
Transmitter
Characteristics
3-D Model of Persons
Material Parameters
OMNeT++
Channel
Control
Connectivity Map
External Mobility Model
Networking &
Protocols
Communication
Channel Model
Mobility
Model
2-D
Scenario
Event-Broker
Figure 9: Implementation of the multiscale simulation model
vironment. The receiver is positioned behind the wall and
for this reason invisible for the transmitter. The indicated
direct path (Figure 10) between transmitter and receiver is
examined. At first the received power is calculated using
the theoretical static path loss formula without attending
the environment. In the next step a path analysis is exe-
cuted in RPS. The results illustrated in Figure 11 present
the difference between these two approaches.
The radio coverage propagation shown in Figure 10 visu-
WLAN Transmitter
Receiver
20m
analysed path
50cm concrete walls
Figure 10: Wireless LAN Radio Channel Example
alizes the characteristics of the RPS graph shown in Figure
11. The first incursion is caused by the concrete wall in the
middle of the scenario. The receiving power is then rising
rapidly to a constant level because reflections on the outer
walls boost the signal. Another incursion is caused by the
user themselves. These artefacts are not taken into account
by the static pathloss model.
-100,00
-90,00
-80,00
-70,00
-60,00
-50,00
-40,00
-30,00
-20,00
-10,00
0,00
0,52,54,56,58,510,512,514,516,518,5
relative distance [m]
RSSI [dBm]
detailed pathloss model
simple pathloss model
Figure 11: Comparison of simulated and theoretical
pathloss model
5.APPLICATION SCENARIO
The Galileo4FireBrigades project is focussed on wide area
fire fighter missions including floodwater and forest fire catas-
trophes. A precise satellite coverage estimation as shown in
Figure 12 is needed in the simulation model to make a real-
istic prediction of the availability of satellite services.
The example scenario was modelled using the RPS front
end. A suburban area flooded with water is pictured for
this simulation. The GIOVE-A satellite configurations con-
taining transmit power, frequency band and position have
been transferred to the RPS ray tracing engine and can be
accessed in the OMNeT++ protocol simulation. The satel-
lite’s position is about 2500km in eastern direction depend-
ing on the local coordinates of the example scenario. We
are using the SAR frequency at 406MHz for this coverage
prediction.
The free space coverage is uniformly distributed, but espe-
cially the coverage around houses shows irregularities caused
by reflections on the outer walls. The blue shadows in Fig-
ure 12 indicate a very low signal level, as the white shadows
indicate that no satellite signal is available.

Page 8

buildings
300m
350m
Figure 12: Galileo Satellite GIOVE-A coverage es-
timation on a local flood water scenario
We propose using the satellite based SAR service only in
situations where the user is out of reach from the local com-
munications networks. Hence combining sophisticated user
mobility models and a highly precise channel propagation
engine, the number and the positions in the local scenario
can be estimated where satellite based SAR services are
needed. In order to generate a holistic system model, lo-
cal networks can be included in this scenario additionally to
the satellite coverage prediction.
6. CONCLUSION AND FURTHER WORK
As a token of our commitment to the OMNeT++ commu-
nity, we will be releasing a Galileo Ready compilation of
the INET Framework. The implementation offers a simple
application for satellite tracking without the need of exact
knowledge about space architecture and equations. Every
satellite currently in the earth orbit and even prospective
Galileo satellites can be modelled using this implementa-
tion approach. The tracking is highly precise, as proved in
section 2, in comparison to reputable satellite tracking ap-
plications. Further extensions are including this Galileo sys-
tem model in the proposed CNI Multiscale Simulation En-
vironment which is coupled to a sophisticated radio channel
and a 3-dimensional environment model in order to enhance
the simulation model of this wireless satellite communica-
tion system. We have shown a Galileo4FireBrigades specific
application scenario from which the usability in terms of
real–time–capability and service availability for fire fight-
ers will be evaluated.We are now able to evaluate the
Galileo4FireBrigades specific hybrid communication archi-
tecture containing terrestrial and satellite communication
components.
7.ACKNOWLEDGMENT
This work was funded by German Federal Ministry of Eco-
nomics and Technology (BMWI).
Project: Galileo4FireBrigades – Employment of Galileo ser-
vices for wide area fire fighter missions – 50NA0724
8.
[1] Andras Varga, The OMNeT++ Discrete Event
Simulation System, Proceedings of the European
Simulation Multiconference, 2001
[2] I Vari, INET Framework for OMNeT++,
http://www.omnetpp.org/doc, last visited Jan. 2008
[3] Witold Drytkiewicz, Steffen Sroka, Vlado Handziski,
Andreas K¨ opke, Holger Karl, A Mobility Framework
for OMNeT++, 2003
[4] Dirk Brouwer, Solution of the Problem of artificial
Satellite Theory without Drag, The Astronomical
Journal, Volume 64, Pages 378-395, October 1959
[5] T S Kelso, Felix Hoots, Ronald Roehrich, Spacetrack
Report No.3 - Models for Propagation of NORAD
Element Sets, December 1988
[6] T S Kelso, http://www.celestrak.com, last visited
November 2007
[7] Space Track - The Source for Space Surveillance Data,
www.space-track.org, last visited November 2007
[8] Michael F. Henry, http://www.zeptomoby.com, last
visited November 2007
[9] David Taylor, http://www.satsignal.net, last visited
November 2007
[10] HeavenSat Version 2.0.1, http://www.heavensat.ru,
last visited November 2007
[11] Visual GPS LLC, http://www.visualgps.net, last
visited November 2007
[12] ESA - Galileo System Simulation Facility,
http://www.gssf.info, last visited November 2007
[13] Dhaou, R., Gauthier, V., Tiado, M., Becker, M.,
Beylot, A.: Cross Layer Simulation: Application to
Performance Modelling of Networks composed of
MANETs and Satellites, 2005
[14] J. Deissner, J. H¨ ubner, D. Hunold, J. Voigt: RPS
Radiowave Propagation Simulator, User Manual,
www.actix.com
[15] S. Michaelis, C. Wietfeld: Comparison of user mobility
pattern prediction algorithms to increase handover
trigger accuracy, IEEE Vehicular Technology
Conference, Melbourne, May 2006
[16] Kuehn, P. J.: Multiskalen Simulation – Versuch einer
Systematik der Methoden und Ans¨ atze auf dem Gebiet
der Verkehrssimulation, Workshop Simulation, ITG-FG
5.2.1, Bremen, Germany, 2006
[17] A. Lewandowski, R. Burda, C. Wietfeld:
Tool-Description: Eine Multiskalen
Simulationsarchitektur zur Leistungsbewertung von
hochzuverl¨ assigen Mobilfunknetzen, 14th GI/ITG
Conference on Measurement, Modeling, and Evaluation
of Computer and Communication Systems, MMB 2008,
Dortmund, Germany, April 2008
[18] R. Burda, A. Lewandowski, C. Wietfeld: A Hybrid
Indoor Localization Approach combining Meshing and
Time of Arrival in IEEE 802.15.4 Networks, IEEE
Vehicular Technology Conference, Singapore, May 2008
REFERENCES