A Simulation Study of
Emergency Response
Networks
By
Fadi F. Mohsen
A thesis submitted to the Faculty of Graduate School of the
University of Colorado at Colorado Springs
in Partial Fulfillment of the Requirements
for the Degree of
Master of Science in Computer Science
Department of Computer Science
2010
II
 Copyright by Fadi F Mohsen 2010
All Rights Reserved
III
IV
This thesis for the Master of Science degree by
Fadi F. Mohsen
has been approved for the
Department of Computer Science
by
_______________________________________________________
Dr. C. Edward Chow, Chair
_______________________________________________________
Dr. Roger Sambrook
_______________________________________________________
Dr. Jugal Kalita
_______________________________
Date
V
VI
Fadi F. Mohsen (M.S., Computer Science)
A Simulation Study of Emergency Response Networks
Thesis directed by Professor Edward Chow
The increasing demand on the internet, and the fact that the Local, State and
hospitals share the Internet bandwidth with the public put the critical
healthinformation sharing at risk. In the last ten years, we have suffered from
different kinds of flu (e.g. Avian flu, Swine flu (H1N1)); scientists are expecting
more to come. In these kinds of situations, all the health organizations need to
exchange the information to increase their situation awareness and then to publish
information to the public in the form of instructions, latest news, and statistics.
This thesis started by studying the Colorado Health Emergency Response systems
and procedures, plus investigating the actions that need to be taken in case of an
emergency like that of the pandemic flu. The focus was on the importance of
information flow and the utilization of the Internet. An Ontology framework for
the US Air Force Academy Emergency Management is built using Protégé and
presented here as a proof of concept on the importance of information flow in
case of an emergency. The above information has been collected by searching the
literature, interviewing people from the health field, attending UCCS Public
Health Colloquium, and participating in an El Paso County full-scale emergency
VII
exercise. This thesis provides a model built using Google Earth that shows the
emergency response nodes, systems, and websites. From this model a simple
network simulation model was formulated then implemented using Network
Simulator 3 (NS-3) for evaluating the adequacy of network bandwidth and server
capacity under stress. Due to the fact that the systems and the websites used by
the emergency nodes are spread over the US and served by different ISPs [which
are reluctant or unwilling to share network related information], it is difficult to
get accurate information about the US internet backbone. The NS-3 program was
an implementation of an oversimplified model, so its results could not be
generalized. Instead, the thesis draws some conclusions and focus on studying the
counties’ websites performance and security. The performance tests are done
using a benchmarking tool called ab, whereas the security tests are done using
Nessus. The thesis has analyzed the importance of these websites as part of an
emergency management process. The performance and security test results show:
1. The relation between performance and hosting location: Websites’
performance is affected by the hosting locations, the average speed for the
in-state hosted websites is six times the out-state hosted websitesThe
relation between the security and hosting party: Websites’ security is
affected by hosting party; the number of risks is 11 times higher for the
websites hosted with the private sector versus those hosted with the nonprivate sector.
VIII
An architecture was proposed for a secure responsive hosting solution based on
the LVS load balancing technique. The solution provides a secure and fast hosting
environment for the health agencies’ systems and websites.
IX
Acknowledgements
I would like to take the opportunity to sincerely thank Dr. Edward Chow for the
support, effort, and the valuable time he has spent supervising me,and for the
direction to guide me through the challenging coursework I have taken with him.
I would like to thank Dr. Roger Sambrook for the encouragement he has provided,
and the direction to guide me through my work at NISSSC.
I would like to thank Dr. Jugal Kalita for the insightful thinking he has given me
through his comments on my proposal.
X
Table of Contents
Abstract ………………………………………………………………...
VI
Acknowledgment ……………………………………………………...
IX
Table of Contents ……………………………………………………..
X
List of Figures …………………………………………………………
XIII
List of Tables ………………………………………………………….
XIV
Appendices …………………………………………………………….
XIV
Chapter 1 Introduction
1
3
5
5
8
12
12
15
18
19
19
20
1.1 Related Work …………………………………………………………………...
1.2 Background ……………………………………………………………………..
1.3 Emergency Management ………………………………………………………..
1.4 Information Sharing …………………………………………………………….
Chapter 2 USAFA Emergency Management Ontology
2.1 Ontology ………………………………………………………………………...
2.2 USAFA Problem Description …………………………………………………..
2.3 Creating Classes ………………………………………………………………...
2.4 Creating Slots …………………………………………………………………...
2.5 Slots Facets ……………………………………………………………………..
2.6 Adding Instances ………………………………………………………………..
XI
2.7 Creating Queries ………………………………………………………………..
Cheater 3 US Health Organization & Structure ………………
Chapter 4 Colorado Health Emergency Network ……………
4.1 NS-3 Introduction ………………………………………………………………
4.2 NS-3 Model ……………………………………………………………………
4.3 NS-3 Experiments ………………………………………………………………
4.4 Conclusion ……………………………………………………………………...
Chapter 5 Technical Work
5.1 Health Emergency Network’s Nodes …………………………………………...
5.2 Emergency Systems …………………………………………………………….
5.3 Websites’ Hastings & Locations ………………………………………………..
5.4 Nodes’ Interactions……………………………………………………………...
5.5 Websites’ Analysis ……………………………………………………………...
Chapter 6 Performance & Security Analysis
21
24
27
27
28
38
41
43
44
45
45
48
49
51
……………………….
Chapter 7 A proposed Solution ……………………………………… 58
7.1 Introduction ……………………………………………………………………..
7.2 LVS ……………………………………………………………………………..
7.3 LVS & Health Emergency Network ……………………………………………
7.4 LVS Load Balancer ……………………………………………………………..
Chapter 8 Lessons Learned …………………………………………..
8.1 Field Research …………………………………………………………………..
8.2 Building the First Model ………………………………………………………..
.3 The Proposed Solution ………………………………………………………….
Chapter 9 Future Work ………………………………………………
Chapter 10 Conclusions ………………………………………………
References ……………………………………………………………..
58
58
59
62
63
63
64
64
65
67
69
XII
List of Figures
Figure 2.1 AFA Systems
Figure 2.2 Protégé Classes
Figure 2.3 Protégé Slots
Figure 2.4 Protégé Slots Facet
Figure 2.5 Protégé Instances
Figure 2.6 Protégé Query
Figure 3.1 USA HHS Structure
Figure 3.2 U.S. 10 Regions list
Figure 3.3 U.S. 10 Regions map
Figure 4.1 NS-3 Basic Components
Figure 4.2 Google Earth Model
Figure 4.3 Qwest IP Network Statistics Tool.
Figure 4.4 Simple Model for Colorado Health Emergency Network
Figure 4.5 The Run’s Delay Disparity
Figure 4.6 Run’2 Lost Packets Disparity
Figure 5.1 81Solutions Website (www.81solutions.com)
6
16
18
19
20
21
22
25
26
26
29
30
31
34
39
41
XIII
Figure 5.2 the closest point obtained using Google Maps
Figure 5.3 Colorado Local Health Departments’ Websites’ Hosting Locations.
Figure 5.4 Colorado Hospitals’ Websites’ Hosting Locations.
Figure 6.1 Nessus scan results on the local health department’s websites.
Figure 6.2 ab sample results
Figure 6.3 ab command results on the 17 largest population counties
Figure 7.1 A Proposed Solution Structure
46
46
47
48
52
55
60
List of Tables
Table 4.1 The Values Obtained From Qwest IP Network Statistics.
Table 4.2 Calculated Lines Bandwidth between different major cities.
Table 4.3 NS-3 values
Table 4.4 NS-3 Log Analysis
Table 5.1 Health Emergency Internet related actions.
32
33
38
41
49
Appendices
Appendix A
A.1 Local Helath Departments' Websites' Hosting Location
A.2 Hospitals' Websites' Hosting Location
73
73
73
XIV
A.3 Local Health Departments' Websites' Hosting Party
A.4 Hospitals' Websites' Hositng Party
Appendix B
B.1 Downloading Google Earth
B.2 Installing Google Earth
B.3 Starting Google Earth
B.4 Opening kml and kmz files
Appendix C
C.1 Subscribe to Plugin Feed
C.2 Download Nessus
C.3 Starting Nessus Server
C.4 Starting Nessus Web
C.5 Exploring Nessus
C.6 Nessus During A Scan
C.7 Short Report
Appendix D
D.1 Downloading and Installing Protege
D.2 Running AFA Ontology
D.3 Exploreing Protege
Appendix E
E.1 Download NS-3
E.2 Running NS-3 Code
E.3 NS-3 Output
E.4 NS-3 Code
74
74
76
76
76
77
78
79
79
79
80
81
81
82
82
83
83
83
84
85
85
85
86
86
Chapter 1
Introduction
The usage of the internet has grown dramatically the last ten years until it
became a vital part in our daily lives. Education, business, and even entertainment
rely heavily on the Internet. Nowadays, internet plays an important role in the
emergency response operations as well, by providing the space through which
most of the information can go through. The faster the information can go
through, the more likely lives can be saved, since the information helps people to
be aware of the situation and react positively accordingly. Much of the U.S
critical infrastructure is potentially vulnerable to cyber-attack. Critical
infrastructure is defined in the USA PATRIOT Act as those “systems and assets,
whether physical or virtual, so vital to the United States that the incapacity or
destruction of such systems and assets would have a debilitating impact on
security, national economic security, national public health or safety, or any
combination of those matters.” [USA PATRIOT 2001]. The emergency response
systems tend to achieve high coordination among the different parties which are
2
involved in the incident recovery. These systems tend to support the incident
recovery in two main ways:
First of all, it supports the information sharing; terrorist attacks, natural
disasters, and large scale and organized criminal incidents require advanced
information sharing capabilities. Moreover, enterprise wide information sharing is
also required to support the anti-terrorist operations according to the National
Information Exchange Model [NIEM 2007]. And this could be applied to health
emergencies, according to the World Health Organization; the contamination of
food for terrorist purposes is a real and current threat.
Secondly, it helps the decision makers by providing them with complete, on
time, accurate, and relevant information. In a pandemic flu situation, hospitals,
local, state, and federal health departments need to exchange information about
the situation such as number of reported cases, severity, and affected areas, etc.
This helps making better decisions such as closing the schools, canceling all the
air trips to the infected areas etc. Researchers have been investigating several
kinds of models and methodologies to make the information sharing real and
effective [Baja and Ram 2007, Bharosa et al. 2009, Lee and Rao 2007]. Others
studied the survivability, resiliency, and protection of critical infrastructure which
includes the systems and networks [Ellison et al. 2002, , Dekker 2005, Schintler et
al. 2007]. A notable addition from emergency and health people in this course is
illustrated here [Potter et al. 2004].
This study is to model the information flows between the health units during
a pandemic flu and to simulate part of it. Simulation has been chosen as the thesis
3
method because it offers great insight in the communications inner workings and
details [Jha, and Wing 2001, Chen et al. 2002, Woltjer et al. 2006]. But most of
the above studies and methodologies have been conducted and tested in
automatically generated networks or in a lab.
In this research, a model for the network between Colorado health units is
formulated using their actual physical locations, and their server’s physical
locations. The information and knowledge about their communications are
collected by searching the literature, interviewing people from the field, attending
an UCCS Public Health Colloquium, and participating in an El Paso County fullscale exercise. The UCCS Public Health Colloquium has taken place between
March 23-25, with the aim of understanding and utilizing information in public
health emergency. The El Paso County full-scale exercise or the “NOAA’s ARK”
exercise took place on June 5 and its objectives were to focus on evaluating
emergency response procedures, identifying areas for improvement, and
achieving a collaborative attitude. The simulation environment that is used for
translating the conceptual model into the simulation model is NS 3 [Azadehdel et
al. 2009]. The last part of the thesis focuses on studying Colorado counties
websites from performance and security perspectives.
1.1
Related Work
When I started searching the literature, I ran into a deadlock state. I found so
many resources, different titles, purposes and approaches. It was like travelling
across desert with no clear direction. I was looking for a suitable title to unify all
4
of the works, papers, and experiments I have found. Finally, I found that title
which is “Building an Integrated System for Emergency Response Operations”.
Having this title in consideration, each work I found can fit. The work here as
well goes underneath that title because it helps to explain the information flow in
case of a pandemic flu outbreak. The information flows between local health
departments, and hospitals, and between the local health departments and the
public. Some of the related works to this thesis were by Wiechers et al. 2004,
Burstein and Diller 2004 and Bharosa and Lee 2009, Dirk et al. 2009 . The thesis
focus is on the Information flow within the health networks domain. The study
provides many conclusions about potential risks and difficulties in the current
networks and draws some suggestions and opportunities to enhance and to fix
them. . The thesis provides the basis for more studies to follow as it offers the
collected information in a kml and xml file extension. The thesis provides a case
on using ontology in emergency management.
The proposed approach has many essential benefits over the approaches
suggested by the literature.
The thesis used an actual domain and environment; the results then can be
mapped to other places. The thesis’ main focus is on the information flow
between health departments and discards the other agencies, such as the FBI or
police, for two reasons: first of all, the proposed scenario is a pandemic flu
outbreak and most likely the local health departments and hospitals are the most
involved parties. Second, the thesis, by limiting its scope, avoids dealing with
political issues, since cross-agency information sharing is still in progress and has
5
a lot of difficulties. The thesis’ main focus is to grab peoples’ attention to the
communication problem that may affect the flow of information during a
pandemic flu. This thesis is going to help in developing a system that uses the
latest technology mentioned as a suggestion to better communicate during a
hazard. My work will result in a basic idea for futre works to come since I have
kept the thesis data (addresses, ip, websites, etc. ) in an xml and kml format that
are easy to share and r-use.
The model can be easily extended, as more
information becomes available, and can be easily added to the model.
1.2
Background
Past history has shown that the lack of information sharing amongst the
various agencies in an emergency situation and that caused harm and lose.
Information sharing has been poor and needs improvement as this is the core of
emergency management.
1.3
Emergency Management
Emergency management and hazard recovery systems are essential
components in today’s communications throughout the world [Tarchi 2009].
These systems consist of different parts: e.g., communication means data
warehouses, maps, and data integration engines. These systems tend to achieve
high coordination between the different parties that are involved in the incident
recovery. The aim of these systems can be illustrated in three words: avoidance,
response, and recover. Risk avoidance can be achieved by planning ahead.
6
Managers develop plans of action for when the disaster occurs. These plans
include personal training, systems testing, and exercising. The response phase
includes the recalling of the required emergency tools, personal, and first
responders in the affected area. The last phase is the recovery phase. The aim of
this phase is to restore the affected area to its previous state. Recovery efforts are
mainly concerned with actions that involve rebuilding destroyed property, reemployment, and the repair of other essential infrastructure. Emergency
management systems vary in their capabilities and complexities because of the
emergency type. Any emergency can fall in any of the seven categories shown in
Figure 1.1.
Emergency
Bioterror
ism
Chemical
Outbreak
s
Terroris
m
Radiation
Mass
Casualties
Natural
Disasters
Figure 1.1 Emergency Types
7
The above figure and the following reviews are based on Centers for Disease
Control and Prevention (CDC). Bio-terrorism refers to the deliberate release of
viruses, bacteria, or other agents used to cause illness or death in people, animals,
or plants. These agents can be spread through the air, water, or in food. Chemical
emergencies occur when a hazardous chemical is released and the release has the
potential for harming people’s health. Mass Casualties refer to incidents such as
fires, explosions, mass transit accidents, such as train crashes or bridge collapses,
which cause numerous deaths and injuries. Natural disasters refer to such natural
occurrences as earthquakes, extreme heat, floods, hurricanes, landslides and
mudslides, tornadoes, tsunamis, volcanoes, wildfires, and winter weather.
Outbreaks refer to flu epidemics, viruses, or other contagious diseases and can
also include food-borne outbreaks such as salmonella or E. coli. Radiation
emergency could be a nuclear power plant accident or a terrorist event such as a
dirty bomb or nuclear attack, which would expose people to significantly higher
levels of radiation than are typical in daily life, leading to health problems such as
cancer or even death. Terrorism refers to a deliberate act of murder and
destruction which disrupts infrastructure and is directed towards civilians with the
aim of meeting a political end. The study here focuses on the Outbreak
emergency, specifically the case of epidemic flu. Regardless of the emergency
type, the emergency management systems have to achieve high coordination
between the agencies involved by sharing the right information in the right time
which in turn results in making the correct decisions.
8
1.4
Information Sharing
Terrorist attacks, natural disasters, and large-scale and organized criminal
incidents require an advanced nation’s information sharing capabilities.
Moreover, enterprise-wide information sharing is also required to support the
anti-terrorist operations (Introduction to the National Information Exchange
Model [NIEM 2007]. As the importance of information sharing in the above cases
cannot be denied, information sharing is also important in other situations, like in
the case of epidemic flu, for example. In the epidemic flu scenario, reports, news,
and instructions have to be exchanged to help the people in charge to make
decisions and to spread the awareness between Inhabitants. Besides its
importance, information sharing has triple axes: politics, methods, and
survivability.
Politics comes from the fact that information should happen between
different agencies where each agency has different objectives, polices and
operational environments. The results from a preliminary study by Lee and Rao
2007 revealed that the current inter-agency information sharing systems in use
does not reflect social and operational environments of emergency management
organizations. The study administered a survey questionnaire to emergency
responders such as law enforcement personnel, intelligence agents, firefighters,
emergency medical staffs, and other government employees in the emergency
management’s area. One important way of agencies’ collaboration according to
9
Degwekar and DePree 2007 is to share not only data, but also human and
organizational knowledge useful for decision support, and problem solving and
activity coordination. The politics axis is the most complicated and presently it
has not been resolved. The colloquium, large scale exercise, and the interview
with the Elpaso County personnel assured that Therefore one must rely on the
methods and survivability axes to resolve those issues.
The methods are the set of technologies and tools that have been used to
approach cross-agencies information sharing. Extensible Markup Language
(XML) for instance has been largely used
as a technology solution for cross-
agency information sharing [Bajaj and Ram 2003]. Cross-agency information
sharing from the technology perspective is the integration of structured
information between heterogeneous data bases. Each agency has its own systems,
databases and applications. A tremendous amount of work can be found in the
literature that targets the integration issue [Hayne and Ram 1990; Reddy at al.
1994; Larson at al. 1989; Batini at al. 1986; Hearst 1998; Ram and Park 2003;
Ram and Zhao 2001]. XML became famous when the researchers started paying
attention to the area of the integration of unstructured information, for example,
free text documents between heterogeneous information sources [Bajaj and Ram
2003]. Khare and Rifkin 1997, Sneed 2002 and Glavinic 2002 have pointed out
the advantages of the XML as a means of adding varying degrees of structure to
information, and as a standard for exchanging information over the WWW [Bajaj
and Ram 2003]. More information sharing technologies to be mentioned here are
schema matching [Dhamankar et al. 2004; He and Chang 2004], data privacy
10
[Agrawal et al. 2003; Zhang and Zhao 2005], and schema mapping [Pantel et al.
2005; Yu and Popa 2005].
Survivability is the last axis discussed here. Emergency Response Network
survivability is the ability to continue functioning under an attack or pressure.
Attacks can be of two types: insider attacks and outside attacks. Insider threats
tend to cause more harm and losses. According to a survey done by CERT the
loss resulting from insider attacks is much bigger than any other attacks. An
Insider is a legitimate user who acts against a running system. This act mostly
happens as a kind of revenge. An employee who is about to lose his job may run
an insider attack to steal confidential information or just harm the system;
whereas outside attacks are those launched from remote computer and targeting
servers, routers, and links. The above mentioned attacks could happen against
health agencies and departments and for this reason the thesis conducts some
security tests. The pressure can be an issue and might be on the servers (websites),
routers and links. Most if not all of the health agencies and departments are
sharing the public internet bandwidth which is an uncontrolled unpredictable
environment. In case of an emergency, ambulances use the public streets, but in a
controlled fashion. Switching the siren on is enough for the public to clear the
roads for the ambulances plus the ability of using the police for this purpose or
even controlling the traffic lights. Is that possible in the internet world? For
instance, emergency related data could be forwarded in high priority. That is
possible but requires some changes to be made on local health department’s
internet connections.
11
The rest of the thesis is organized as follows: Chapter 2 presents the USAFA
Emergency Management’s Ontology. Chapter 3 describes the US Health
Organization and Structure. Chapter 4 examines Colorado Health Emergency
Networks and relations. Chapter 5 focuses on the methods and techniques used to
accomplish this work. Chapter 6 gives the performance and security analysis.
Chapter 7 proposes a solution for the identified problems. Chapter 8 highlights the
lessons learned. Chapter 9 sketches the future work. Chapter 10 offers
conclusions.
12
Chapter 2
USAFA Emergency
Management Ontology
2.1 Ontology
Ontology is defined [Neches et al., 1991] as a set of basic terms and
relationships of a vocabulary within an area or subject. In Emergency
Management, the terms or entities are: people, infrastructures, communication
devices, and emergency response systems. Ontology also includes rules to
combine terms and relations that extend the vocabulary. A rule can be, for
instance stated as: “when a fire is occurring in a building we know that we should
communicate with people by audio notifications instead of visual ones since
smoke can reduce visibility, but also that we could use the same kind of alert for
compensating disabilities, e.g. alerting blind users of a critical or dangerous
13
event” [Malizia et al., 2009]. Ontology has been used in many fields, such as
Software Development Life Cycle (SDLC), Security, and others. Ontologies are
used through the Software Development Life Cycle (SDLC starting from the
analysis and design and ending with the deployment ), [Happel and Seedorf,
2006]. In the analysis and design phase, ontology can be used for both, to describe
requirements specification documents and formally represent requirements
knowledge. In the implementation phase, ontology is used to narrow the gap
between design and implementation. Finally, in the deployment phase, ontology is
used to provide a mechanism to capture knowledge about the problem domain.
Reasoning can then be applied to reuse this knowledge for various purposes. In
security, the ontology supports the modeling of the basic security concepts and
their relationships. The advantages of deploying the ontology are: (a) express the
most important security concepts, (b) realize the relations among the above
concepts, (c) provide a common understanding and vocabulary of security issues
among application developers, and (d) facilitate the development of secure
applications [Dritsas et al.,].
Besides that, ontology has been successfully used in emergency
management. Malizia et al., 2009 has developed ontology for emergency
notification systems accessibility. Their ontology helps in automatically adapting
the notification of alerts to different kinds of users, including elderly and disabled,
depending on the type of technologies and devices they can access and
considering the impact of the disaster on alerts communication and
infrastructures. Ruzhi et al., 2009 presented a solution to the problem that resulted
14
from keeping the emergency preplans in static text or electronic document which
is difficult for emergency decision-makers to achieve accurately and quickly.
Their solution is based on putting forward an emergency preplan knowledge
representation framework. Starting by analyzing emergency preplan textual
knowledge, an emergency preplan ontology was built, and finally, an emergency
preplan semantic retrieval system was implemented with the help of ontology
reasoning mechanism. Xiang et al., 2008 addressed the need for building
collaborative Crisis Information Management Systems. They used an effective
ontology to establish a solid common ground for such systems. The steps to be
followed to create ontology are as follows:
 Defining classes
 Arranging classes in hierarchy
 Defining properties and their allowed values
 Filling in the values for properties for instances [Noy and Mc Guinness,
2001].
An ontology language is a formal language used to encode the ontology.
There are a number of such languages for ontologies, both proprietary and
standards-based , Web Ontology Language (OWL) is one of these languages.
OWL is a language for making ontological statements, developed as a follow-on
from the Resource Description Format (RDF) and RDF Schema (RDFS) , as well
as earlier ontology language projects including Ontology Interference Layer
(OIL), DARPA Agent Markup Language (DAML), DARPA in turn stands for
Defense Advanced Research Projects Agency and DAML+OIL[w3.org]. OWL is
15
intended to be used over the World Wide Web, and all its elements, such as
classes, properties and individuals are defined as RDF resources, and identified by
URIs. The good point here is that ontology is a perfect choice for modeling multiagency systems because the ontology can be encoded using universal languages,
like OWL, which is basically developed from RDF, which in turn is easy to share
and run over the World Wide Web.
1.2
USAFA Problem Description:
The United States Air Force Academy (USAFA) realizes that an effective
response to emergency incidents requires a complex interconnection of
information flows among its sections and organizations. At the University of
Colorado at Colorado Springs (UCCS), the National Institute of Science, Space
and Security Centers (NISSSC) objectives are a clear scientific understanding of
USAF emergency management and a model for constructing and implementing
effective and secure emergency management systems. They propose to build the
data dictionary assembly and then define elemental level relationships that will
form the body of a nearly completed ontological description of incident
management behavior for USAF. In the early stages, the set of all systems used by
the AFA organizations has been collected (see Figure 2.1).
16
The AFA has 18 organizations and sections, where each has its own systems.
A total of 298 systems have to be analyzed to look for potential relationships and
connections. In fact, not all of these systems are used in case of an emergency, so
finding out which is relevant and which is not is also needed. Drawing on user
requirements best practices available by Clark and Sambrook 2007, Robillard et.
Al. 2007 and information drawn from USAF documents, a basic ontological
model of USAF emergency management will be developed. Below are the steps
that have been taken to build the basic model:
Step 1: Generate some questions about the domain.
Some of the questions we want to answer are:

What are the AF sections?
o
Who is responsible for each section in the AF?
o
What are the programs/systems
that each section uses?
o
What information does each
program/system produce?
o
What databases do each
program/system connect to?
o
Which programs/systems are
being used in an Emergency?
Figure 2.1 AFA Systems
17
Step 2: List some of the important terms we need.
Once we have an idea of what we want to cover, we can list some of the
important terms we need. These can include basic concepts, properties they might
have, or relationships between them. As a start we can just collect the terms
without regard to the role they might play in the ontology.
Step 3: Categorize the different terms according to their function in the
ontology.
When we have a fairly complete list, we can start to categorize the different
terms according to their function in the ontology. Concepts that are objects, such
as AF Weather or Captain, are likely to be best represented by classes. Properties
of the classes, such as Location or Responsible, can be represented by slots, and
restrictions on properties or relationships between classes and or slots, are
represented by slot facets.

Protégé_3.4.4 is used to create the basic ontology. Protégé is developed at
the Stanford Center for Biomedical Informatics Research [protege.stanford.edu].
Building an ontology using Protégé has to be in the following sequence:Creating
classes

Creating slots

Creating slot facets

Entering instances

Creating a relationship between instances

Creating and saving a query
18
In the subsequent sections, we will go over these steps; first, we will show
the classes, the slots, and slot facets will follow. Then, we will show how to add
instances, and at the end we will show how creating and running queries can be
done.
2.3 Creating Classes
In this section, we list the concepts that constitute the AFA emergency
management. These concepts should be general enough to describe the domain
probably, because of that we processed the systems first. Processing the systems
has been done via identifying every system characteristics, such as users, data,
and organization.
The idea behind keeping the concepts general is to accept as many instances
as possible; later on we can add more details to the basic model. The four general
Classes ((Internal_Access_Software
and External_Access_Software) and Data.
Figure 2.2 shows these classes, notice
that how every Protégé class should be a
subclass of THING class.
External_Access_Software class has two
super classes: THING and Software. This
gives the ability to have multiple relations
Figure 2.2 Protégé Classes
19
between the ontology concepts.
2.4 Creating Slots
In Protégé, Classes are more than simple objects arranged in a hierarchy.
They can also have attributes, such as a name, number, or type, and relations
between them, such as the Generator of a Data. Class attributes and relations are
described using slots. For our ontology, the slots are: name, number, type,
location and role.
Figure 2.3 shows the Protégé Slots.
Notice that, we capitalized the first letter
in each class name, and we kept it small
for
the
slots
name.
Adapting
this
terminology helps in avoiding confusion
when using the ontology.
Figure 2.3 Protégé Slots
2.5 Slots facets:
The above slots are simple. However, slots themselves can have properties.
Slots can be used to create relationships between classes. The properties of a slot,
called facets, can be created and edited in more than one way. In our Ontology,
ESF class can have facets on its number slot, such as the minimum acceptable
20
value for the slot should be 1, whereas the maximum should be 15. In Protégé,
that can be done by setting minimum=1, and maximum=15 (see Figure 2.4).
Figure 2.4 Protégé Slots’ Facets
In Figure 2.4, Integer can be also considered a facet.
2.6 Adding Instances
Instances are the actual data in the knowledge base. As a good practice, it is
beneficial to finish the structure as soon as possible before entering extensive
numbers of instances, because making any change to a class or a slot specification
after adding the instances is hard and would definitely generate errors. Some of
the instances that we added to our ontology categorized by the class name:
Data (Financial_Data, Flight_Data, GeoSpatial_Data, Personnel_Data,
Transportation_Data, and Weather_Data), ESF (Communications, Firefighting,
Transportation), Organization (CivilEngineering, FireEmergencyServices) and
Software (Internal (AFDS, DOD 411), External (AFRIMS, WSCRS)).Figure 2.5
shows the classes, and the instances; where the number that appears next to each
21
class represents the number of instances that exist on the knowledge base. Notice
also, the four tabs shown on the top of the figure; Classes tab, Slots tab, Forms
tab, Instances tab, and Queries tab. In the figure the Instances tab is selected. The
middle part shows the list of instances for the selected class, and the right part
shows the Instance Editor screen for editing the current selected instance.
Figure 2.5 Protégé Instances
2.7 Creating Queries
The ultimate purpose of going through the previous steps is to be able to
query the resulting knowledge. With Protégé, queries can be created, saved and
executed. (see Figure 2.6). Again, in the top five tabs, Queries tab is selected. The
Query screen (right) shows the class that has been selected as a base, as well as
the
slot
name
and
value.
To
the
left
where
the
results
appear,
FireEmergencyServices is the Organization, its role is OCR and it uses WSCRS.
22
We can add unlimited number of slots to the query to be more complicated. In
some complicated emergencies, complicated queries are needed!.
Figure 2.6 Protégé Query
Now, that we have the Protégé knowledge base, what could be done with it?
What software can read it? Protégé uses a plug in for manipulating Ontology Web
Language, OWL and RDF are much of the same thing, but OWL is a stronger
language with greater machine interpretability than RDF. OWL comes with a
larger vocabulary and stronger syntax than RDF. The Resource Description
Framework (RDF) is a W3C standard for describing Web resources, such as the
title, author, modification date, content, and copyright information of a Web page
[w3schools.com]. More importantly, RDF is written in XML. EXtensible Markup
Language (XML) was designed to transport data. From this connection, a
conclusion could be made; Protégé has the ability to export the resulted
knowledge base into different formats (e.g. HTML, OWL, RDF schema, etc.), so
depending on the needed software the output can be changed accordingly. In the
AFA case, the resulted ontology exported into an XML file format, and then
23
integrated into Keyhole Markup Language (KML) files. KMLis an XML
grammar and file format for modeling and storing geographic features such as
points, lines, images, polygons, and models for display in Google Earth, Google
Maps and other applications [earth.google.com].
24
Chapter 3
US Health Organization
and Structure
The Department of Health and Human Services (HHS) is the United States
government’s principal agency for protecting the health of all Americans and
providing essential human services, especially for those who are least able to help
themselves. The work of HHS is conducted by the Office of the Secretary and 11
agencies (see Figure 3.1). The agencies perform a wide variety of tasks and
services, including research, public health, food and drug safety, grants and other
funding, health insurance, and many others.
Offices are that subdivisions of the office of the secretary provide direct support for
the secretary's initiatives [www.hhs.gov]. HHS has divided the US into 10 regions, where
each region has at least 4 states; Figure 3.2 lists these regions and the member states,
whereas Figure 3.3 shows them over distributed over the US map. Each region has a
25
central office, for instance, region 1 contains Connecticut, Maine, Massachusetts, New
Hampshire, Rhode Island, and Vermont. The central office is located in Boston. Colorado
is located within region 8. In each state there is the Department of Health and Human
Services, and in each county it has a department. In Colorado, The Department of Health
and Human Services is located in Denver, and it oversees the state’s 64 counties.
Figure 3.1 USA HHS Structure
26
HHS Regional Offices
Region 1 – Boston
Connecticut, Maine, Massachusetts, New Hampshire, Rhode Island, and Vermont
Region 2 – New York
New Jersey, New York, Puerto Rico, and the Virgin Islands
Region 3 – Philadelphia
Region 4 – Atlanta
Region 5 – Chicago
Region 6 – Dallas
Region 7 – Kansas City
Region 8 – Denver
Region 9 – San
Francisco
Region 10 – Seattle
Delaware, District of Columbia, Maryland, Pennsylvania, Virginia, and West
Virginia
Alabama, Florida, Georgia, Kentucky, Mississippi, North Carolina, South Carolina,
and Tennessee
Illinois, Indiana, Michigan, Minnesota, Ohio, and Wisconsin
Arkansas, Louisiana, New Mexico, Oklahoma, and Texas
Iowa, Kansas, Missouri, and Nebraska
Colorado, Montana, North Dakota, South Dakota, Utah, and Wyoming
Arizona, California, Hawaii, Nevada, American Samoa, Commonwealth of the
Northern Mariana Islands, Federated States of Micronesia, Guam, Marshall
Islands, and Republic of Palau
Alaska, Idaho, Oregon, and Washington
Figure 3.2 U.S. 10 Regions list
Figure 3.3 U.S. 10 Regions map
27
Chapter 4
Colorado Health
Emergency Network
4.1 NS-3 Introduction
The NS-2 simulator has been used widely for research and education on
Internet Protocols and other network technologies [McCanne and Floyd 1997].
NS-3 in the other hand is intended as an eventual replacement for the popular NS2 simulator, but not an extension. NS-3 is a discrete-event network simulator for
Internet systems, targeted primarily for research and educational use. NS-3 is free
software, licensed under the GNU GPLv2 license, and is publicly available for
research,
development,
and
use.
Based
on
borrowed
concepts
and
implementations from several open source simulators including NS-2 and the
28
works of Lecage and Henderson 2006, and Riley 2003, NS-3 was built. NS-3
differs from NS-2 in several ways, including: new software core, attention to
realism, software integration, and support for virtualization, testbed integration,
attribute system, and tracing architecture. NS-3 has been the best overall
performance, and is capable of carrying out large-scale network simulations in an
efficient way [Weingartner et al. 2009]. However, NS-3 is still in the early stages,
and more models and capabilities needed to be ported from NS-2. Scripting in
NS-3 is done in C++ or Python. As of NS-3.2, most of the NS-3 API is available
in Python, but the models are written in C++ in either case. A working knowledge
of C++ and object-oriented concepts is required to use NS-3. The NS-3 uses
several components of the GNU (toolchain) for development. A software
toolchain is the set of programming tools available in the given environment
[http://en.wikipedia.org/wiki/GNU_toolchain]. NS-3 uses gcc, GNU binutils, and
gdb. NS-3 can be used in Linux or a Linux-like environment [www.nsnam.org].
Running NS-3 under Windows is also possible, e.g. Cygwin environment.
4.2 NS-3 Model
NS-3 uses the commonly networking terms, but with different meanings, (see
Figure 4.1).
Starting from the left: Node is the basic computing device abstraction used
by NS-3. Node corresponds to host or sometimes an end system. Because NS-3 is
a network simulator, not specifically an internet simulator, the term host is not
used, since it is closely related with the internet and its protocols. Application is
29
the basic abstraction for a user program that generates some activity to be
simulated. This term does not include the concept of operating system and
privilege levels. NS-3 applications run on ns-3 nodes to drive simulations in the
simulated world. Channel is the media over which data flows between different
nodes. There are three specialized versions of the Channel called CsmaChannel,
PointToPointChannel and WifiChannel. Net Device abstraction in NS-3 covers
both software driver and the simulated hardware. A net device is installed in a
Node in order to enable the Node to communicate with other Nodes in the
simulation via Channels. Similar to the Channel, Net Device has three versions
called CsmaNetDevice, PointToPointNetDevice, and WifiNetDevice. Lastly,
Topology Helpers is provided to combine the many distinct operations into an
easy to use model, for example
creating NetDevice, installing it on Node,
Configuring it, and then connecting it to a Channel.
NS-3
Topology
Helpers
Node
Channel
Application
Net
Device
Figure 4.1 NS-3 Basic Components
The thesis is using the Topology Helpers to build the Emergency Network
topology.
30
The thesis has adapted the agile like method in solving the problem. The
Google Earth model (see Figure 4.2) plays like a prototyping stage for the
problem that helps define the NS-3 model attributes. As new information becomes
available, it will be added to the basic model. The model shows the different
nodes: Hospitals, Local Health Departments, and their websites locations it also
shows the Satool, EMSystem and the Department of Health and Human Services
and the Emergency Office.
Figure 4.2 Google Earth Model
As shown in figure 4.2, the model also contains a layer for the Qwest fiber
network (the red lines and black points). The red place marks with “H” are
Colorado hospitals, whereas the place marks with “D” are the local health
departments. The dark blue numbered place marks are the local health
31
departments’ websites’ hosting locations, whereas the light blue ones are for the
hospitals’ website’s hosting locations. The situation awareness tool (satool.org)
and EMSystem are the green place marks. The technical steps for building this
model will be explained in the next sections.
From the above model and for NS-3 to be used, a simple model has been
drawn. The model is built based on the techniques mentioned here [Siamwalla
1998] and with the help of Qwest IP Network Statistics Tool. Figure 4.3 shows
the tool, Table 4.1 and Table 4.2 show some data obtained from this tool, and
Figure 4.4 shows the model.
Figure 4.3 Qwest IP Network Statistics Tool
Source
Destination
FTP (ms)
Denver
Denver
Seattle
Dallas
1.63
null
HTTP
(ms)
32.85
24.4
Latency
(ms)
30.48
22.4
32
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Denver
Seattle
Salt Lake City
Phoneix
Kansas City
Kansas City
Omaha, Nebraska
Minneapolis, Minnesota
Houston, TX
Houston, TX
Houston, TX
Pheonix
Salt lake city, utah
Portland, Oregon
Sacramento_CC
Sunnyvale, CA
Burbank, CA
Tampa, FL
Tukwila, Washington
Atlanta, GA
Boston, MA
Cermak, IL
Chicago, IL
Eckington, DC
Highlands Ranch, CO
Kansas City, KA
Minneapolis, Minnesota
Newark, NJ
New York, NY
Omaha, Nebraska
Sacramento_CC
Sacramento_CC
Sacramento_CC
Omaha, Nebraska
Chicago, IL
Minneapolis, Minnesota
Chicago, IL
Chicago, IL
Kansas City, KA
1.45
null
0.63
1.81
null
1.53
null
2.6
null
2.05
16.73
null
1.32
null
0.96
0.69
1.33
2.45
null
0.96
null
null
null
0.39
0.82
0.54
0.41
0.9
0.54
35.52
null
20.59
43.62
48.26
30.61
41.21
51.74
33.46
43.67
117.99
null
26.62
null
3.72
13.93
26.69
49.62
50.05
19.39
38.85
32.91
32.81
7.92
16.74
20.65
12.57
32.17
18.25
27.2
22.2
10.5
34.2
37.31
28.23
34.19
49.91
31.19
38.73
51.08
25.39
24.21
44.43
1.41
11.68
24.44
43.33
45.36
17.2
27.55
21.5
20.99
5.74
14.23
18.43
10.49
30.04
16.09
Table 4.1 The Values Obtained From Qwest IP Network Statistics.
The colors are used in Table 4.1 to identify the different paths between
Denver and Satool located in California and to EMSystem located close to
Chicago.
33
Source
Denver
Denver
Denver
Denver
Denver
Seattle
Salt Lake
Pheonix
Kansas
Omaha
Kansas
Houston
Houston
Minneapolis
Destination
Seattle
Salt Lake City
Pheonix
Houston
Kansas
Sacramento
Sacramento
Sacramento
Omaha
Minneapolis
Chicago
Kansas
Chicago
Chicago
Line 1
OC-12
OC-48
OC-3
OC-3, OC-12, OC-192
OC-3
OC-48
OC-12
OC-12, OC-192
OC-12
OC-3
OC -192
OC-192
OC-192
OC-48
Calculated
(megabits/second)
622
2500
155
1859
155
2500
622
5111
622
155
2500
2500
2500
2500
Table 4.2 Calculated Lines Bandwidth between different major cities.
Value
34
Figure 4.4 Simple Model for Colorado Health Emergency Network
Once all the telecommunication links capacities and topologies are collected,
the NS-3 code can be written as follows to simulate the network traffic and collect
information about the network performance. Writing the NS-3 code starts by
creating the nodes,
35
NodeContainer c;
c.Create (24);
And then relating these nodes together as follows,
NodeContainer s1r1 = NodeContainer (c.Get (0), c.Get (2));
NodeContainer r1r2 = NodeContainer (c.Get (2), c.Get (3));
NodeContainer r1r3 = NodeContainer (c.Get (2), c.Get (4));
NodeContainer r1r4 = NodeContainer (c.Get (2), c.Get (5));
r1 node and r2 are directly connected.
After connecting the created nodes, a TCP/IP stack should be installed in all
the nodes, and this can be done with the following command,
InternetStackHelper internet;
internet.Install (c)
Creating the channels will follow,
PointToPointHelper p2p;
p2p.SetDeviceAttribute("DataRate",StringValue ("2500Mbps"));
p2p.SetChannelAttribute ("Delay", StringValue ("27.55ms"));
NetDeviceContainer d1d2=p2p.Install (r1r2);
The next step is to assign the IP addresses,
Ipv4AddressHelper ipv4;
ipv4.SetBase ("10.1.1.0", "255.255.255.0");
ipv4.Assign (d1d2);
36
Creating router nodes, initializing routing database and setting up the routing
tables in the nodes is the next step,
Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
The following lines of code are used to set up a UDP echo server
application on Satool.org node we have previously created..
UdpEchoServerHelper echoServerS(9);
ApplicationContainer serverAppsSatool=
echoServerS.Install(c.Get(0));
serverAppsSatool.Start(Seconds(1.0));
serverAppsSatool.Stop(Seconds(100.0));
The last two lines will cause the echo server application to start at one second
into the simulation and to stop at twenty seconds into the simulation.
This application is installed on EMSystem as well. For future work, it could
be installed on the nodes representing the websites. The echo client application is
set up using a method similar to that for the server.
UdpEchoClientHelper echoClientSh (is1.GetAddress (0), 9);
echoClientSh.SetAttribute("MaxPackets",UintegerValue(10000));
echoClientSh.SetAttribute("Interval", TimeValue (Seconds (0.00001)));
echoClientSh.SetAttribute("PacketSize",UintegerValue(1024));
ApplicationContainer clientAppsSh = echoClientSh.Install (c.Get (23));
clientAppsSh.Start (Seconds (2.0));
clientAppsSh.Stop (Seconds (20.0));
37
The echo client application is installed on the department of health node and
the local health departments’ nodes. For the echo client, five different Attributes
have to be set: “RmoteAddress”, “RemotePort”, “MaxPackets”, “Interval” and
“PacketSize”.
The next lines of code are used to monitor and report back packet flows
observed during a simulation which we will analyze in Section 4.3.
Ptr<FlowMonitor> flowmon;
if (enableFlowMonitor)
{
FlowMonitorHelper flowmonHelper;
flowmon = flowmonHelper.InstallAll ();
}
if (enableFlowMonitor)
{
flowmon->SerializeToXmlFile("My-global-routingResult.flowmon", true, true);
}
At this point, what left, is to run the simulation? The first statement runs the
simulator whereas the last two lines are to cleanup and exit.
Simulator::Run ();
Simulator::Destroy ();
Return 0;
The thesis is providing the full code (See Appendix).
38
4.3 NS-3 Simulation Results
The NS-3 implementation for Colorado Health Emergency Network’s model
presented in the previous section integrated with the values from Table 1 and
Table 2 is tested. The results were obtained over three different runs. The
objectives were, first, to find the effect of increasing the number and the
frequency of the exchanged packets [which is represented with “MaxPackets” and
“Interval” in NS-3]. The second objective is to find the effect of removing links
out of the model. The effect is estimated based on the “Delay” and “Lost
Packets”. The table below shows the values used to test the model.
Run
MaxPackets
Interval (s)
Removed Links
Run 1
10000
0.0001
No
Run 2
100000
0.00001
No
Run 3
100000
0.00001
Yes
Attr
Table 4.3 NS-3 values
During the run, the data flow information was captured in xml files, these
files are provided with this thesis.
The simulation time is selected to be twenty seconds simulation time (not
processing time), which is suitable to cover all of the events presented in chapter
39
5. Figure 4.5 and Figure 4.6 show the results summary. In Figure 16, notice how
the delay is affected by both the number and frequency of exchanged packets, and
the removed links. In Run 3, the delay is high because we removed four links out
of the model and we used a higher value for the “MaxPackets” and a lower value
for “Interval”. In Run 2, the delay is lower because we returned the links back to
the model. In Run 1, the delay is lower than Run 2 because we decreased the
“MaxPackets” and increased the “Interval”. Run1 represents the early stage of an
emergency; Run 2 represents the second stage, whereas Run3 is the emergency
peak. During the early stages of an emergency, the departments and hospitals
exchange less information compared to those exchanged in the next stages until it
reaches the maximum. In Preparing for an emergency, the worst case should be
considered.
Delay
3.16E+10
3.14E+10
3.12E+10
3.1E+10
3.08E+10
Delay
3.06E+10
3.04E+10
3.02E+10
3E+10
Run 1
Run 2
Run 3
Figure 4.5 The Run’s Delay Disparity
40
Figure 4.6 shows the great effect of removing the links out of the
model on the number of lost packets. The number of lost packets dropped down
when we returned the links back to the model. Whereas, reducing the number of
generated packets and the frequency has no effect on the packet loss. From Run 1
to Run 2 the number of lost packets remains the same.
To find the mystery behind the increase on the “Delay” and “Lost
Packets”, the NS-3 log files have to be re-visited. Table 4.4 shows the number of
packets each node in the model [presented in the previous section] has processed.
In Run 3, Node 8 and Node 13 have received twice and four times what they have
received in Run 2 and Run 1. Reducing the number of links made these two
routers deal with large number of packets more than they could handle. This
situation forced them to delay some packets and drop others. If we to build a
conclusion based on these results, it would be, emergency’s websites and systems
hosting company’s backbone is critical and need to be investigated.
41
Lost Packets
10000
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
Lost Packets
Run 1
Run 2
Run 3
Figure 4.6 Runs’ Lost Packets Disparity
Node
# Packets (Run 3)
Node
# Packets (Run 2)
Node
# Packets (Run 1)
0
1272
0
1272
0
1272
1
1274
1
1274
1
1274
8
2546
8
637
8
637
13
1274
13
637
13
637
23
10638
23
10638
23
1638
24
10640
24
10640
24
1640
….
…
…
…
…
…
Table 4.4 NS-3 Log Analysis
4.4 Conclusions
The NS-3 code could not help in drawing any conclusions because of the
oversimplifications and the complexity of the internet. NS-3 works best on a close
environment. The distribution of health systems and websites across the US
restricts the success of using NS-3. The thesis was counting on getting more
information from the private sector and research lab about the US internet
42
backbone, but it did not work out. The thesis’ main focus was on studying the
information flow between the health nodes in case of emergency. Google Earth
model revealed important information about the emergency network. The network
is spread over the US and could be simulated with the current information and
tools. The purpose of this study is to discover some risks related to information
sharing and flow in case of emergency. In the last section, performance and
security issues will be tested for the emergency network end nodes. The Google
Earth model leads to that trend.
43
Chapter 5
Technical Work
5.1 Health Emergency Network Nodes
A scenario of future health emergency, like, pandemic flu was derived from
the back ground research and the interview with El Paso County Health
Department. The scenario was useful to identify the nodes and their roles.
The scenario starts by a call from a local hospital (H1) to a local health
department (D1). The call is to inform seeing 10-15 patients with similar
symptoms, such asfever (usually high), headache, muscle aches, chills extreme
tiredness, dry cough, runny nose, and stomach symptoms). D1 will also inform
the Colorado Department of Public Health and Environment (CDPHE).The
Center for Disease Control and Prevention (CDC) will take over by sending its
surveillance group to H1 location for the purpose of interviewing patients and
getting more data. CDC will report to CDPHE the results. The results show the
44
existence of pandemic flu situation. CDPHE will publish an alert into the
Situation Awareness Tool (SATOOL) and ask for more input from other local
health departments and hospitals. As time passes,more reports and news are
published into the SATOOL. Each local health department has to stay connected
by reading every update coming out on the SATOOL. The local health
departments in some situations have to make some decisions, like, shutting down
the schools. The hospitals will be heavily dependent on their nearest health
departments on getting the instructions, updates on the situation, and required
procedures. The hospitals may get this information via the fax, email or the health
department’s websites. The hospitals have to update their information on
EMSystem (e.g. number of beds, staff, ambulances, etc.); the Emergency Office
will need this information to process the requests coming in. Local health
departments will play a monitoring role over the EMSystem.
From the above scenario, the following nodes have been identified:
1) Colorado Department of Public Health and Environment (CDPHE),
2) Local Health Departments (64),
3) Hospitals (98),
4) State Emergency Office.
5) Centers for Disease Control and Prevention.
The locations for the above nodes are saved on Google Earth. The Hospitals
marked with H, Local Health Departments with D,
5.2 Emergency Systems
45
The Emergency Systems are Situation Awareness Tool, EMSystem, and the
web technology. There are more, but these are the top most used internet related
systems.
5.3 Emergency Node’s Websites Hosting and Locations
To find out the emergency nodes’ websites’ hosting and locations,
http://www.whoishostingthis.com and www.81solutions.com are used. The first
website gives the hosting company of a given website, whereas the second
website gives its location on a map. But the location is just shown on a map, so
maps.google.com has to be used to find the address. The following figures explain
that:
Figure 5.1 shows the result of querying 81solutions.com on
www.elpasocountyhealth.com. Is it on 17th street, Wazee street or Wynkoop
street? The three choices have been tried; the closest point to it was on 1660
Wynkoop St, Denver, Colorado 80202 (see Figure 5.2).
46
Figure 5.1 81Solutions Website (www.81solutions.com)
Figure 5.2 the closest point obtained using Google Maps
47
The nodes list, websites, addresses, IPs, IPs locations, and the host
companies are provided in excel and xml formats. Figure 5.3 shows that nearly
50% of Colorado Local Health Departments are hosted outside Colorado State,
and more than that for the hospitals (see Figure 5.4). The details are tabulated in
the Appendix.
Figure 5.3 Colorado Local Health Departments’ Websites’ Hosting
Locations.
48
Colorado
Outside
Figure 5.4 Colorado Hospitals’ Websites’ Hosting Locations.
To find out the hosting companies for both local health and hospitals, a tool
from whoishostingthis.com has been utilized and verified using netcraft.com. The
former tool takes various chunks of info from several databases and then tries to
do simple research and find the web hosting provider. It differs from other tools
which pull the results from some huge database. This database is sometimes
obsolete and does not support specific countries (Top Level Domains). The tool
used in this study is not 100% accurate, but it works well enough, and certainly
better than doing this research by hand.
5.4 The Health Emergency Nodes’ Interactions
The following table summarizes the health emergency related interactions.
49
Node
System/Tech
Action
CDPHE
Satool
Write
Local Health Depts.
Satool
Read
Hospitals
EMSystem
Updates
Emergency Office
EMSystem
Read
Local Health Depts.
EmSystem
Monitor/View
Hospitals
Websites
Write
Local Health Depts.
Websites
Write
Table 5.1 Health Emergency Internet related actions.
5.5 Local Health Department’s Websites Analysis
The pandemic flu scenario mentioned earlier has revealed the importance of
local health department websites in the emergency management process. It is the
way through which these departments reach the people. The information that has
to be published is vital for saving peoples’ lives. Satool.org receives feeds from
the social networks like “Facebook” and “Twitter”. These feeds would help the
health personnel “read” what is on peoples’ minds. The posts that most people
make on the social networks could be used to figure out any misunderstanding to
the disease or the situation. Correct information that solves these misunderstood
issues could be then published on the websites. These websites have to be secured
50
and running on a good performance machines. The next section discusses these
two criteria by investigating the biggest 17 counties health departments’ websites.
51
Chapter 6
Performance and
Security Analysis
For the performance and security study, two factors have been identified.
Hosting location (inside or outside the state), and hosting party (Commercial or
Non-commercial hosting).The health departments’ websites’ security issue has
been raised here because these websites are considered critical infrastructure as
explained earlier. Since some of these websites and systems are hosted by the
private sector, security might be a concern Private sector’s main concern is
achieving higher profit. Security and survivability cost money, so they might skip
security to get cost effective systems. Schintler et al. 2007clarified this issue, “A
problem facing all nations is that they have the responsibility for securing
52
infrastructure but critical aspects are owned by the private sector” [chap. 14]. The
thesis investigated the websites’ security and its relation with the hosting party. A
security test has been launched over the hosting websites using Nessus [Cordova
2010]. Nessus can perform remote security checks, and suggest solutions for
security problems. The test results for launching Nessus on Colorado health
departments’ websites are shown below.
180
160
140
120
100
80
60
40
20
0
Figure 6.1 Nessus scan results on the local health department’s websites.
The hosting IP addresses and the vulnerable websites have been removed
from the figure for ethical reasons. The figure clearly explains the relation
between commercial hosting and security. Over the four types of vulnerabilities
(High, Medium, Low, and Open ports), commercial hosting proved to be nonsecure. These vulnerabilities can be used by “bad guys” to steal confident
information, change the contents by providing false information, and/or shutting
the server down. Indeed, if anything of the fore-mentioned happens, emergency
53
management is in danger and so are the people. Examples of these vulnerabilities
are: the remote host is missing patches; perhaps the apache chunked encoding
vulnerability. Versions of the Apache web server up to and including 1.3.24 and
2.0 up to and including 2.0.36 contain a bug in the routines which deal with
invalid requests which are encoded using chunked encoding. This bug can be
triggered remotely by sending a carefully crafted invalid request. The remote FTP
server allows credentials to be transmitted in clear text. It is possible to determine
the exact time set on some hosts which is classified as an ICMP Timestamp
Request Remote Date Disclosure. Look at the following vulnerability description
Synopsis:
The remote FTP server is affected by multiple vulnerabilities.
Description:
The remote host is running Serv-U File Server, an FTP server for Windows. The installed
version of Serv-U is earlier than 9.0.0.1 and as such is reportedly affected by following
issues : - Provided 'SITE SET' command is enabled, an authorized user may be able to
crash the remote FTP server by sending a specially crafted 'SITE SET
TRANSFERPROGRESS ON' command. - An unprivileged user may be able to view all
drives and virtual paths for drive '\'.
As we clarified earlier, these risks are critical on the emergency management
survivability and efficiency. If the above vulnerability could be compromised, the
website’s, and systems hosted on that server are at risks, which means their role in
the emergency management will become idle.Performance test is done using
apache benchmarking tool called ab [ab]. The test applied on the 17 largest
54
population counties. Sample of the test results is shown below. The ab runs are
launched over the weekend to get more accurate results and to avoid any
inconvenience that may arise from stressing the website. Command variables
were set to be:


-n 5000: ab will send 5000 number of requests to the server in order to
perform for the benchmarking session.
-c 20 : 20 is concurrency number i.e. ab will send 5 number of multiple
requests to perform at a time to the server.
55
Figure 6.2 ab Sample Results
56
More complicated studies could be done to analyze the ab results, in this
study the number of request per second used to prove the performance problem
validity.
600
500
400
300
200
100
0
Series1
Figure 6.3 ab command results on the 17 largest population counties
Figure 6.3 shows ab command run results. The average speeds of the
websites hosted on servers located within Colorado state borders is a way greater
than those located outside. For instate hosting the average speed is 500
requests/sec, and less than 100 requests/sec for the outside hosting. Another
comparison is made regarding the speed between commercial and noncommercial the result appears on Figure 6.3. The result shows the average speed
of non-commercial hosting is double the average speed of commercial hosting.
Does the performance affect the emergency management process?
57
Absolutely! The faster the people receive the information the more life could
be saved. I will take one county to demonstrate the effect of bad performance on
emergency management or broadcasting the knowledge about the disease and
situation.
County T, population 1,250,000, and health website performance is 20
requests/sec.
Assume that 1/10 of the population make requests for the health website.
That means 125,000 requests, since these requests will be made using different
locations, then assuming that these requests arrives into 5 different equal groups
with one minute difference. Then:
The first 25,000 arrives first and will take them 25000/20 = 20 minutes to
finish.
The second group will take them 20 + 19 = 39 minutes.
The third group will take them 20 + 19 + 18 = 57 minutes.
The fourth group will take them 20 + 19 + 18 + 17 = 74 minutes.
The fifth group will take them 20 + 19 + 18 + 17 + 16 = 90 minutes.
The above assumption with its bad consequences assumed that the users are
just browsing the first page which contains the needed information, and that they
are just browsing that page only once. This shows how important the performance
during the emergency.
58
Chapter 7
A proposed solution
7.1 Introduction
As we clarified earlier, the health emergency network suffers from
performance and security problems. The proposed solution has to solve them at
first hand, to offer new advantages and to be cost effective. The following
sections will show how LVS could handle all of that.
7.2 LVS
LVS (Linux Virtual Server Clusters) came out as a solution to the increasing
demand on the Internet. The increasing demand or the traffic put the websites
under pressure to keep up, particularly during peak periods of activity [Zhang and
Zhang 2003]. The basic idea of LVS is to combine multiple physical servers into
one virtual server, which eliminates single points of failure (SPOF). LVS has
59
been used mostly by companies that have mission-critical applications on the
internet, and require always-on service. The LVS provides highly-available and
highly-scalable network services.
7.3 LVS and Health Emergency Network
The proposed solution is based on using LVS to provide the health
emergency network with an always-on service’s requirement. This solution solves
the performance and security issues by providing a self-hosting service. By so
doing, the risks of breaking into any of them from neighbors will be removed.
Another benefit is the performance can be improved because the load can be
estimated, since the location of the hosting servers and the users are located
within the same area. Moreover, the number of users for each website and system
will be known ahead from the population numbers and emergency management
procedures. The server’s upgrades and updates can be set to fit the local health
departments and the hospitals, which give them enough time to update their
methods and functions. Failing to update the methods and functions for website’s
code when the hosting’s webserver or operation system is upgraded is risky. Both
the local health departments and the hospitals could work together to get that
infrastructure done (see Figure 7.1). In Colorado we counted 64 local health
departments and 98 hospitals, so the cost will be reasonable. In Figure 7.1,
emergency’s websites and systems will be hosted in Real Server (N), Real Server
(C) and Real Server (S). The three servers have the same content and any change
on one of them should be then synchronized to the others. The three servers
appear as a single (virtual) server. The proposed solution structure shown in
60
Figure 7.1 includes backup and recovery plans in case of failure which guarantees
the continuous flow of information between emergency nodes themselves and
between them and the public.
Figure 7.1 A Proposed Solution Structure
Sequence of operations:
1) A user makes a request
2) Dynamic DNS returns Director 1 IP address
3) Director 1 direct the request to the one of the servers (Load Balance)
4) The selected server processes the request and returns the result back to the
user
The above architecture can easily balance the load between the three servers
according to scheduling algorithms [Zhang and Zhang 2003]. More nodes
61
(servers) can be easily added or removed to the cluster to achieve scalability, for
instance, in case of an emergency more nodes can be added to avoid any failure.
The three servers have to be programmed to not to accept any request unless it is
directed by any of the two directors, so that many attacks can be avoided. A
programmed set of status messages have to flow between directors and the
Dynamic DNS and the directors and the servers. The purpose of the first set of
messages is for the Dynamic DNS to change the sequence of look up table’s
records. For example, if the Dynamic DNS doesn’t receive “I’m a life message”
from the Director 1; it will substitute the first record with Director 2 address.
Whereas the purpose of the second set of messages is to accept or reject any
request not directed by any of the directors. For instance, if the 3 servers don’t
receive “I’m a live” messages from the two directors then they will start accepting
any requests even If they are not directed. The proposed architecture doesn’t
necessarily need to buy new hardware, given that some of; If not all of the local
health departments and hospitals have their own servers and hardware which can
be utilized to implement the architecture.
7.4 LVS Load Balance
In the previous sections, we said that the director or the load balancer balance
the traffic into the servers using different techniques. In this section we will go
over them and describe the one used in the proposed solution. There are three load
balancing techniques: VS/NAT, VS/DR, and VS/TUN. Virtual Server via
62
Network Address Translation is used when there is a shortage in IP addresses and
due to security considerations whereas the load balancer and real servers should
be interconnected by a switch or a hub. Virtual Server via Direct Routing requires
that load balancer and the real servers must have one of their interfaces physically
linked by an uninterrupted segment of LAN such as Ethernet switch. Virtual
Server via IP Tunneling uses IP tunneling which is a technique to encapsulate IP
datagrams within IP datagrams, which allows datagrams destined for one IP
address to be wrapped and redirected to another IP address. Real servers can have
any real IP addresses, and the servers and the load balancer can be geographically
distributed. The proposed solution uses this technique since this technique could
survive in case of load balancer failure. When the load balancer receives a
request, it encapsulates the packets within an IP datagram and forwards it to any
of the servers. The server receives the encapsulated packet, then decapsulates it,
processes it, and returns the results directly to the user.
63
Chapter 8
Lessons Learned
This chapter describes the experiences and lessons learned from analyzing
Colorado Health Emergency Network with the focus on the information sharing
technology and survivability.
8.1 Field Research
The most difficult part of the thesis was to conduct the emergency
management field study. The study’s resources can be classified into two
categories: the literature and the onsite visits/interviews. Searching the literature
at the beginning was so hard because the first founded papers could not be easily
categorized and analyzed. Background knowledge was needed and later on gained
while working on emergency related certificates. The onsite information is
obtained from meeting with people from the field by setting up appointments with
them or just having a dialog. Setting an appointment required patience and
64
perseverance. Attending the colloquium and participating in the El Paso County
Exercise were not possible without approaching the right people and keeping
track of the thesis’s related events and activities.
8.2 Building the First Model
The first model has to meet the balance between the real world and the
available information. The facts that health emergency tools were spread over the
US make the modeling of the real world so complicated and in the other hand, the
available information was very rare and insufficient. The solution was to build a
simplified model that could tell something about the real world and possible to be
implemented using NS-3.
8.3 Proposed Solution
In fact, suggesting a solution started as a challenge and ended as a success.
The solution had to solve the identified problems, to offer new advantages and to
be cost effective. The suggested solution has utilized the knowledge obtained
from taking courses at UCCS: CS591, CS526, and CS691, since these courses
require solving challenging home works.
65
Chapter 9
Future Work
The main focus of the thesis has been on the display of Colorado health
emergency network nodes, connections and visual displays. As part of this thesis,
good information regarding the systems in use, the flow of information and the
emergency management plans have been collected. One of thesis objectives is to
study the Internet infrastructure survivability, in so doing, an NS-3 model for the
Colorado Health Emergency Network has been built. This model has integrated
Qwest Internet Network information and statistics. The results obtained from this
model could not be generalized because more information was needed. The future
work is to extend this model by collecting more information regarding the US
Internet network. This information can be obtained from a company like Qwest.
Regarding the security and performance analysis results, two future works can be
66
done. First, searching for better hosting, better hosting means security and
performance are assured. Finding the hosting company’s backbone is critical and
should be studied. Most of these companies tend to hide their backbone’s details
for competition reasons; so, the second future work is to implement the proposed
solution mentioned in Chapter 7. Implementing the proposed solution requires
the health staff’s approval which is difficult without showing them evidences.
These evidences would be a case study on the possibility for implementing the
new proposed solution to host the local health departments, and hospital’s
websites and their emergency systems. The results obtained from this study could
be then communicated to the health staff, for them to make a decision. The last
possible future work would be to automate the steps I have went through to
visualize the health emergency network. This tool could be then be used by other
states’ health emergency networks, and enhance their performance and security .
67
Chapter 10
Conclusions
Information sharing is on the core of emergency management thus
survivability is critical; survivability is the ability to continue functioning with the
existence of pressure and danger. Colorado Health Emergency Network and its
functionality were documented through interviewing people from the field. It is
found that Colorado Health Emergency Network is diffused across the US. This
diffusion complicates the assurance or assessment of its survivability, since it
depends on so many factors. A simplified model for their network is developed
and simulated. An NS-3 implementation for that model was built . The simulation
results show the current network is capable of handling surge of network traffic
under pandemic situations.. Further performance and security analysis show that
the current health emergency’s websites and systems in use are inadequate and
requires attention. A strong connection between the performance and hosting
68
location was made. In-state’s hosting has a performance advantage over the outstate’s hosting. On the other hand, non-commercial hosting is more secure than
commercial hosting. Asolution was proposed that offers secure and high speed
hosting. The solution utilizes Linux Virtual Server Clusters (LVS) which has been
used in the Internet to achieve scalable, speed and secure webhosting services.
69
References:
ab – Apache HTTP server benchmarking tool, http://httpd.apache.org/docs /2.2/programs/ ab.html.
Agrawal, R., Evfimievski, A., Srikant, R. Information Sharing across Private Databases. SIGMOD, USA, 2003, pp. 8697.
Azadehdel, R., Dadashtabar, K., Enami, E. Design and Architecture of A New Crisis Situation Room (CSR). . In
Proceedings of the 10th Annual Interanational conference on Digital Government Research: Social Networks: Making
Connections between Citizens, Data and Government. ACM, 2009, pp. 302-308
Bajaj, A., Ram, S. (Oct-Dec 2003). IAIS: A Methodology to Enable Inter-Agency Information Sharing in
eGovernment. Emergencymanagement,Wikipedia, http://en.wikipedia.org/wiki/Emergency_management.
Batini, C., Lenzerini, M., Navathe, S. B. A Comparative analysis of methodologies for database schema integration.
ACM Computing Services, 1986, 18(4), pp. 323-364.
Bharosa, N., Lee, J., Janssen, M., Rao, H. A Case Study of Information Flows in Multi-Agency Emergency Response
Exercises.
Bharosa, N., Lee, J. A Case Study of Information Flows in Multi-Agency Emergency Response Exercises.In
Proceedings of the 10th Annual International Conference on Digital Government Research: SocialNetworks: Making
Connections between Citizens, Data and Government. 2009, 277-282.
Burstein, H., M., Diller, E., D. A Framework for Dynamic Information Flow in Mixed-Initiative
Human/Agent Organizations. 20(3), 2004, 283-298.
Chen, D., Garg, S., Trivedi, K.. Network survivability performance evaluation: A quantitative approach with applications
in wireless ad-hoc networks. In Proceedings of the 5th ACM international workshop on Modeling analysis and
simulation of wireless and mobile systems. Atlanta, Georgia, 2002, pp. 61-68.
.Clarke, J.L. Sambrook, R.C. A review of emergency operations center and crisis control software. White Paper US Air
Force Office of GeoIntegration.
Degwekar, S., DePree, J., Beck, H., Thomas, C., Su, S. Event-triggered data and knowledge sharing among collaborating
government organizations. In Proceedings of the 8th annual international conference on Digital government research:
bridging disciplines & domains, Philadelphia, Pennsylvania, 2007, pp. 102-111.
Dekker, A. (2005). Simulating network robustness for critical infrastructure networks. Proceedings of the Twenty-eighth
Australasian conference on Computer Science. 38, 59-67. Retrieved January 1, 22010, from ACM Digital Library.
Dhamankar, R. et al. iMAP: Discovering Complex Semantic Matches between Database Schemas. SIGMOD, France,
70
2004, pp. 383-394.
Dirk, B., Schiller, B., Aitenbichler, E., Liebau, N. Towards a Distributed Crisis Response Communication System.
Proceedings of the 6th International ISCRAM Conference, Gothenburg, May 2009
Dritsas, S., Gymnopoulos, L., Aryda, M., Alopoulos, T., Kokolakis, S., Lambrinoudakis, C., Ritzalis, S. Employing
Ontologies for the development of Security Critical Applications. Department of Informatics, Athens University of
Economics and Business, GR-10434, Greedce 2006. Computer Science 189/2005, pp. 187-201.
Ellison, R. Linger, R. Lipson, H. Mead, N. Moore, A. (2002). Foundations for survivable systems engineering. Retrieved
January 1, 2010, from http://www.cert.org/archive/html/SSE_foundations.html.
Floyd, S., Paxson, V. Difficulties in simulating the internet. IEEE/ACM Transactions on Networking (TON). 9, 4 (2001),
392-403.
G. F. Riley. Large Scale Network Simualtions with GTNETS. In Proceedings of the 2003 Winter Simulation
Conference, 2003.
Hayne, S., Ram, S. Multi- User View Integration System (MUVIS)- An Expert System for View Integration. In the IEEE
International Conference on Data Engineering (ICDE). 1990, pp. 402-409.
He, B., Chang, K. A holistic paradigm for large scale schema matching. SiGMOD, France, 2004, pp. 20-25.
Hearst, M. Trends and controversies: Information Integration. IEEE Intelligent Systems Journal, 1998, pp. 12-24.
Hoppel, H., Seedorf, S. Application of Ontologies in Software Engineering. In Workshop on Semantic Web Enabled
Software Engng., 5th Intnl. Semantic Web Conf. (2006).
Jack, P., David, A., Dale, H., Sukumar, D. Architecture and Principles of a Modern Integrated Emergency Medical
Information Network. Topics in Emergency Medicine: April/May/June 2004 - Volume 26 - Issue 2 - p 103-109
Jack, P., David, A., Dale, H., Sukumar, D. Architecture and Principles of a Modern Integrated Emergency Medical
Information Network. Topics in Emergency Medicine: April/May/June 2004 - Volume 26 - Issue 2 - p 103-109
Jha, S., Wing, J. Survivability analysis of networked systems. In Proceedings of the 23rd International Conference on
Software Engineering. Toronto, Ontario, 2001, pp. 307-317.
Larson, J. A., Navathe, S. B. Elmasri, R. A Theory of Attribute Equivalence in Databases with Application to Schema
Integration. In IEEE Transactions on Software Engineering, 1989, 15(4), pp. 449-463..
Lee, J., Rao, H., R. Exploring the Causes and Effects of Inter-Agency Information Sharing Systems Adoption in the
Anti/Counter-Terrorism and Disaster Management Domain.
Lee, J., Rao, H., R. Exploring the Causes and Effects of Inter-Agency Information Sharing Systems
Adoption in the Anti/Counter-Terrorism and Disaster Management Domain. In Proceedings of the 8th annual
international conference on Digital government research: bridging disciplines & domains, Philadelphia, Pennsylvania,
2007. Pp. 155-163.
Malizia, A., Onorati, T., Diaz, P., Aedo, I., Astorga-Paliza, F. An ontology for emergency notification systems
accessibility. Expert Systems with Applicatons 37(2010), pp. 3380-3391.
M., Lecage and T.R. Henderson. Yet another network simulator. In WNS2 ’06:Proceeding from the 2006 workshop on
71
ns-2: the IP network simulator, page 12, New York, NY, USA, 2006. ACM.
National Information Exchange Model (NIEM) Program Management Office. Introduction to the National
Information Exchange Model (NIEM), Document Version 3. Available from http: //
www.niem.gov/files/NIEM_Introduction.pdf (2007); accessed 1 March 2010.
Neches, R., Fikes, R., Finin, T., Gruber, T., Senator, T., Swartout, W. Enabling technology for knowledge sharing.
Al Magazine 2006, 12(3), pp. 119-125.
Noy, N.F., Mc Guinness, D.L. “Ontology Development 101: A Guide to creating your first ontology”. Stanford
Knowledge Systems Laboratory Technical Report KSL-01-05. 2001.
Pantel, P., Philipot, A., Hovy, E. Aligning Database Columns using Mutual Information. National conference on
Digital Government Research, Georgia, 2005, pp. 205-210.
Ruzhi, X., Xiaoliang, D., Feng, Y., Peiguang, L. Emergency preplan knowledge representation and semantic
retrieval system based on ontology. In Proceedings of the ICMECG’09 International Conference on Management of eCommerce and e-Government, Jinan, China, 2009, pp. 124-127.
Reddy, M. P., Prasad, B. E., Reddy, P. G., Gupta, A. A methodology for Integration of Heterogeneous Data-bases.
In IEEE Transactions on knowledge and Data Engineering, 1994, 6(6), pp. 920-933.
Ram, S., Zhao, H. Detecting both schema-level and instance level correspondences for the integration of Ecatalogs. Paper presented at the Workshop on Information Technology and Systems (WITS), 2001.
R. Siamwalla, R. Sharma, and S. Keshav. Discovering internet topology. IEEE INFOCOM’ 99. July 1998.
Ram, S. Park, J. Semantic conflict resolution ontology (SCROL): An efficient hierarchical ontology schema for
detecting and resolving data and schema-level semantic conflicts. IEEE Transactions on Knowledge and Data Engineering
, 2003, 15(5).
S. McCanne and S. Floyd. The LBNL network simulator. Software on-line: http://www.isi.edu/nsnam. 1997,
Lawrence Berkeley Labortory.
Schintler, L.A. , Gorman, S. , Kulkarni, R. , Stough, R. (2007). Moving from protection to resiliency: A path to
securing critical infrastructure. In A.T. Murry, T.H. Grubesic (Ed.), critical infrastructure (pp. 291-307). School of Public
Policy, George Mason University, USA.
State Demography Office. Colorado Population Estimates by County 2000-2008. Colorado Department of Local
Affairs, 2008.
Tarchi, D., Fantacci, R., Marabissi, D. The Communication Infrastructure for Emergency Management: the In.Sy.Eme.
Vision. IWCMC’09, June 21-24, 2009, Leipzig, Germany, pp.618-622.
United and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism (USA
PATRIOT) Act, P.L. 107-56, Title X, Section 1016. 2001.
Woltjer, R., Trnka, J., Lundberg, J., Johansson, B. Role-playing exercises to strengthen the resilience of command
and control systems. In the Proceeding of the 13th European on cognitive ergonomics: trust and control in complex sociotechnical systems. Zurich, Switzerland, 2006, pp. 71-78.
Wikipedia. Ontology Language. Retrieved June 21, 2010 from http://en.wikipedia.org/wiki/Ontology_language
72
Wiechers, W., Daskapan, S., Vree, W. Simulating the establishment of trust infrastructures in multi-agent systems.
Proceedings of the 6th international conference on Electronic commerce, 2004. Pp. 255-264.
Weingartner, E., Lehn, H., Wehrle, K . A performance comparison of recent network simulators. IEEE International
Conference on Communications. Dresden, 2009, Pp. 1-5.
Weingartner, E., Lehn, H., Wehrle, K. A performance comparison of recent network simulators. IEEE International
Conference on Communications. Dresden, 2009, pp. 1-5.
Xiang, L., Gang, L., Anhong, L., Jian, Z., Ning, A., Lian, L., Yongzhong, S. Building a practical ontology for
emergency response systems. In Proceedings of the International Conference on Computer Science and Software
Engineering, Wuhan, Hubei, 2008, pp. 222-225.
Yu, C., Popa, L. Semantic Adaptation of Schema Mappings when Schema Evolve. Norway, 2005, pp. 1006-1017.
Zhang, W., Zhang, W. Linux Virtual Servers Clusters. Linux Magazine, 2003, pp. 1-13.
Zhang, N., Zhao, W. Distributed Privacy Preserving Information Sharing. VLDB, Norway, 2005, pp. 889-900.
73
Appendix A:
Websites’ Hosting Party and
Location
A.1 Local Health Departments’
Websites’ Hosting Location
This table shows the Local Health Departments’ Websites’ hosting per state.
State
Colorado
Kansa
Texas
Pennsylvania
California
Illinois
Utah
Florida
Massachustts
New york
Wisconsin
Washington
# of websites
41
8
4
4
4
3
3
1
1
1
1
1
A.2 Hospitals’ Websites’
Hosting Location
This table shows the Local Health Departments’ Websites’ hosting per state.
State
Colorado
Kansas
California
Iowa
# of websites
46
6
6
5
74
Tenassee
Canada
Virginia
Texas
Arizona
Georgia
Alabama
Utah
Florida
North Carolina
New york
4
3
3
3
3
2
2
1
1
1
1
A.3 Local Health Departments’
Websites’ Hosting Party
Local Health Departments
Hosting
Commercial
City and County of Denver
Denver Health and Hospital Authority
Colorado Government TechnologyServices
NorthEast Colorado Health Department
County of Lake
San Juan County
Universities
Frequency
63
1
1
5
1
2
1
2
A.4 Hospitals’ Websites’
Hosting Party
Hospitals
Hosting
Community Health Systems
Denver Health and Hospital Authority
CITY AND COUNTY OF DENVER
Frequency
3
1
2
75
Headquarters, USAISC
MEDSEEK
Departments of Veterans Affairs
Health South Corporation
Colorado Government TechnologyServices
MEMORIAL HEALTH SYSTEM
MERCY MEDICAL
Universities
CARETECH SOLUTIONS
1
4
3
1
3
1
1
1
1
76
Appendix B:
Downloading and Installing Google
Earth 5.1
B.1 Download Google Earth
from http://earth.google.com/download-earth-advanced.html
B.2 Install Google Earth
77
B.3 Start the Google Earth
from the Start menu
78
B.4 Open the kml and kmz
files into your working space
79
Appendix C:
Downloading and Installing Nessus
C.1 Subscribe to a Plugin
Feed to be able to use Nessus
http://www.nessus.org/registe
r/
C.2
Download
Nessus
http://
80
www.nessus.org/download/nessu
s_download.php
C.3 Star the Nessus Server
81
C.4 Start Nessus Web
Application
C.5 Explore Nessus
To explore Nessus, go over the top menu taps from right to left. Manage
users first, then create a policy, launch a scan by providing IP addresses each per
line or provide a text file that contains the entire target IP addresses
82
C.6 Nessus during the scan
C.7 Short Report
83
Appendix D:
Downloading and Installing Protégé
D.1 Download Protégé 3.4.4
(this version support Owl AND
RDF) from http://
protege.stanford.edu/download
/protege/3.4/installanywhere/
D.2 after you finish the
download and install, start
84
the program and hit open,
then select AFAO.pprj
D.3 Explore the top five tabs
85
Appendix E:
Network Simulator 3.6
E.1. to Download Network
Simulator 3.6 follow the
steps in http://
www.nsnam.org/docs/tutorial.h
tml#Downloading-ns_002d3
E.2 Run the Thesis NS-3 Code
Copy the NS3Code.cc file into the ns-3.6/ scratch folder, then compile with
./waf command, then run using ./waf –run,
Then you should see this,
86
E.3 NS-3 Output
The ns-3 code will produce two kinds of output: pcap files and flowmon (xml)
file.
The pcap files can be opened using WireShark.
Whereas the xml file can be opened with any text editor (e.g. gedit for linux,
TextPad for windows). The xml file reports the flow information.
E.4 NS-3 Code
87
88
89
90
91
92
93
94
95
96
97
98